Privacy and data rights: tooling that protects people, not just ticks boxes
Most organisations treat privacy and data laws like a chore. When forced to get in line cookie banners appear, privacy policies get rewritten, but the underlying data practices stay exactly the same. Compliance built this way is fragile under scrutiny.
The alternative is to take a proactive approach, and weave data rights into every design decision from the start. When you do that, compliance stops being a cost centre and becomes something genuinely useful for both the organisation and the people whose data you hold.
Treating privacy as a core design principle
A recent client project was the opportunity to think this through properly. A complete compliance layer was designed and built from the ground up: retention automation, subject access tooling, erasure workflows, full audit trails, and the admin interfaces to manage all of it. Every feature was designed to be practical and straightforward, not just legally defensible.
Retention policies
Contacts and their data are automatically deleted after a configurable period of inactivity. Administrators set the retention window (anything from 30 days to 10 years) and choose whether deletion triggers on last activity or creation date.
This isn't just about storage limitation under GDPR Article 5. It means organisations aren't sitting on years of sensitive data they no longer need. The less you hold, the less there is to breach.
Subject access requests
When someone asks to see their data (as is their right under GDPR Article 15), staff can generate a complete export in a couple of clicks. JSON for technical integrations, CSV for anyone who just wants to open it in a spreadsheet.
Exports include everything: messages, notes, activity history, consent records. The whole lot, packaged up and ready to hand over within the one-month response window.
Right to erasure
Permanent deletion is deliberately difficult to do by accident. It requires a documented reason, a typed confirmation phrase, and a very clear warning that this cannot be undone.
Under GDPR Article 17, people can request their data be erased. When that happens, everything goes: messages, notes, assignments, the contact record itself. An immutable erasure log records what was deleted, by whom, and why, without retaining any personal data. These logs are kept for seven years as compliance evidence.
Audit trail
Every significant action in the system is logged: who accessed what, when, and from where. The audit viewer shows before-and-after comparisons for every change, with filtering by action type, record type, and user.
Accountability is a core GDPR principle. If you can't demonstrate who did what with personal data, you can't demonstrate compliance. The audit trail makes that straightforward.
Scheduled jobs
Automated compliance jobs (like retention policy enforcement) run on a schedule, and administrators can see exactly when they last ran, what they processed, and whether anything failed.
Transparency matters. If data is being automatically deleted, the people responsible for that data should be able to see when and how.
The design principle
All of this comes back to one idea: compliance should be a feature, not a burden. When it's designed into the system from the beginning, it's cheaper to build, easier to maintain, and it actually does what it's supposed to do. It protects people.
Accessibility advocates have been saying the same thing for years. Bolt it on at the end and it's expensive and incomplete. Build it in from the start and it becomes invisible, in the best possible way.
Get in touch
If you're building tools that handle personal data and want compliance built in properly, get in touch at andrew@flett.cc.