Bespoke data and privacy compliance tooling that protects people, not just ticks boxes
Charities and legal services handle deeply sensitive information: immigration status, health records, abuse histories. Getting data wrong doesn't just risk fines. It risks the people you're trying to help.
Most organisations treat compliance as a box-ticking exercise. Cookie banners appear, privacy policies get rewritten by lawyers, and the underlying data practices stay exactly the same. Compliance built this way is expensive to maintain and fragile under scrutiny. Worse, it doesn't actually protect anyone.
The alternative is weaving 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.
Putting it into practice
The Law Centres Network messaging platform is a good example of what this looks like when you get it right. I designed and built a complete compliance layer across the platform: 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, I'd be happy to chat. Drop me a line at andrew@flett.cc.