Most UK GDPR work in a SaaS company happens in a document, and most UK GDPR failures happen in a database. The policy says personal data is deleted within thirty days; the nightly backup keeps it for a year, the analytics warehouse keeps it forever, and the application log has the email address in a stack trace. Nobody lied. The engineering never matched the writing.
This is an engineering checklist, not legal advice. Where your obligations begin and end depends on your product, customers and sector — a conversation for a solicitor or data protection specialist. What follows is the part a lawyer cannot do for you: making the system behave the way the paperwork claims.
Lawful basis has to exist in the schema
There are six lawful bases for processing, and a mature product does not use one for everything. Billing records sit under contract. Fraud checks and security telemetry usually sit under legitimate interests. Marketing to prospects normally needs consent. Retaining invoices for tax is legal obligation. If your system cannot tell you which basis applies to a given row, you cannot answer the two questions that follow: can this person object, and can they demand erasure?
The practical move is to make the basis a property of the data, not of a policy page. Tag tables and columns with the purpose and basis they serve, keep the tags in migrations so they are reviewed like code, and derive retention from the tag rather than from a spreadsheet.
-- purpose and basis declared alongside the table
COMMENT ON TABLE billing_invoice IS
'purpose=billing; basis=contract; retention=6y_after_last_payment';
COMMENT ON TABLE product_event IS
'purpose=analytics; basis=legitimate_interest; retention=13m; pseudonymise_after=90d';Once that metadata exists, a scheduled job can enforce retention and a test can fail the build when a new table arrives undeclared. Compliance stops being an audit activity and becomes a lint rule.
Minimisation is a design decision, not a clean-up task
Minimisation is far cheaper at the point of collection than anywhere downstream. Three habits do most of the work. Do not collect a field because it might be useful later; adding it when you need it costs a migration, and holding it wrongly for two years costs more. Separate identity from behaviour, so telemetry references an opaque internal identifier rather than an email address. And keep personal data in one system of record instead of letting it copy itself into the warehouse, the CRM, the support tool and three CSV exports on someone’s laptop.
The copies are the part that bites. Every export path you build is a deletion path you now owe.
Deletion that includes backups and logs
Nearly every SaaS product implements erasure as a soft delete, and soft delete alone is not erasure. A workable design has three layers.
- Live data: a hard delete, or crypto-shredding — encrypting each subject’s data under a per-subject key and destroying the key. The latter is often cleanest when referential integrity makes row deletion painful, provided the key really is the sole means of access.
- Backups: you generally cannot surgically edit a backup, and you are not usually expected to. What you are expected to do is have a defensible position: a bounded backup retention window, encryption at rest, no restores into production without re-running pending deletions, and documentation of both. A ninety-day backup cycle with a replay-deletions-on-restore step is a defensible answer. An indefinite archive of nightly dumps is not.
- Logs and derived stores: the ones teams forget. Application logs, error trackers, the message queue’s dead-letter store, search indexes, caches, the data warehouse, and any third-party tool receiving webhooks. Keep an inventory of every sink personal data can reach, and make the erasure job fan out to all of them.
Better still, keep personal data out of logs in the first place: log the internal user identifier, not the email address; a request identifier, not the request body. It costs nothing at write time and removes an entire category of deletion work.
Audit logs, and the awkward tension inside them
You need an audit trail: who accessed what, when, and on whose authority. It answers a regulator’s questions after an incident and detects misuse by your own staff. But the audit log is itself personal data, and it is the one store you cannot freely rewrite without destroying its value.
The usual resolution is to write audit entries that are append-only, that reference subjects by stable pseudonymous identifiers rather than embedding names and emails, and that carry their own bounded retention. When an erasure request arrives, the identifier-to-person mapping is destroyed while the integrity of the trail survives. Keep the audit store separate from the application database, with different credentials, so a compromise cannot silently rewrite history.
Processors, subprocessors and the parts you do not control
If you sell B2B SaaS, you are almost certainly a processor acting on your customer’s instructions, and every vendor in your stack is your subprocessor. Your customers’ procurement teams will ask for the list, and increasingly their contracts will require notice before you change it.
Treat that list as an artefact generated from reality rather than maintained by hand: if a service is in your infrastructure-as-code and receives personal data, it belongs on the page. Record what data it receives, why, where it processes it, and what happens if it disappears. The exercise doubles as an exit plan.
International transfers under the UK regime
Since Brexit the UK operates its own regime, and it is not simply a mirror of the EU one. Transfers to a country without UK adequacy regulations need an appropriate safeguard — typically the ICO’s International Data Transfer Agreement, or the UK Addendum bolted onto EU standard contractual clauses you already have — supported by a transfer risk assessment. The UK also has its own route for certain transfers to the United States. The detail changes as adequacy arrangements are reviewed and domestic legislation amends the regime, so check current ICO guidance rather than any article’s snapshot.
What engineering owes this process is a truthful map: which regions your data actually sits in, including the ones you did not choose deliberately. Managed services often replicate across regions by default, error trackers and support tools frequently process in the United States, and a model API call sends data wherever the provider runs inference. Pin regions explicitly in your infrastructure configuration and assert them in tests.
Subject access requests without the manual scramble
The statutory clock is one month, extendable by a further two for genuinely complex requests. Handled by hand, each request costs engineer-days, produces inconsistent output, and quietly misses data held in systems nobody remembered.
The alternative is a subject data interface that every service implements: given a subject identifier, return everything held about them, and separately, delete it. A central coordinator fans the request out, collects the responses and assembles a package. New service, new implementation, enforced in code review.
Two details save trouble later. Redact third-party personal data before export — a support thread often contains another customer’s details, and disclosing it is its own breach. And identity-verify the requester properly; an access request is a superb social engineering vector, and handing a full data package to an attacker who guessed an email address is worse than the delay of asking them to authenticate.
What to check before your next release
- Every table holding personal data declares a purpose, a lawful basis and a retention period, and a test fails when one does not.
- The erasure job reaches logs, caches, search indexes, the warehouse and every third-party sink — and you can name them all.
- Backup retention is bounded and pending deletions are replayed after a restore.
- The audit log is append-only, separately credentialed, and references subjects pseudonymously.
- The subprocessor list is generated from what is actually deployed, with the processing region recorded for each.
- A subject access request can be fulfilled by running one command, and the output has been reviewed for third-party data.
- You can detect and report a personal data breach within 72 hours, which means you have alerting on unauthorised access, not just on downtime.
If you can only do one this quarter, do the deletion fan-out. It is the item most likely to be wrong, the hardest to retrofit once data has spread, and the one that turns a policy commitment into something you can demonstrate.