GDPR in SaaS without the paperwork theatre: roles, retention, anonymisation
Five architecture decisions that let a children's camp booking system process health data in line with GDPR, rather than merely “having a policy”.
A privacy policy does not protect data. Architecture does. Bookli processes children’s data, health data included, so GDPR compliance had to be a property of the system, not a document in the footer.
1. Least privilege through roles
Every role sees only what it needs for its job. Accounting sees payments but not health data or national ID numbers. Camp staff see what they need to look after the children, but not the amounts. That is data minimisation written into code.
2. Field-level encryption
Personal and health data is encrypted at field level. A leaked database copy does not mean a leak of a child’s allergy information.
3. Tenant isolation
Every company sees only its own data. Isolation works at the query level, not just in the interface, so a bug in a view cannot expose another organiser’s data.
4. Automatic retention
Data has an expiry date. After the retention period the system anonymises it on its own, without relying on someone remembering. Statistics remain, people disappear.
5. Audit log and versioned consents
Every access to sensitive data and every change leaves a trace. Consents are versioned: you know which consent text a parent accepted and when.
Bonus: zero trackers
The app has no Google Analytics or other trackers, and the servers are in the EEA. The simplest way to solve the third-country transfer problem is not to have one.