Building Custom Software That Survives a GDPR Review
Compliance reviews rarely fail on the privacy policy. They fail on the data model: a field that was never classified, a backup that outlives the deletion request, an admin screen that shows more than it should. All three are engineering decisions made long before anyone reads the policy.
When a European client asks whether a system is "GDPR compliant", the honest answer is that compliance is a property of an organisation and its processes, not of a codebase. What a codebase can do is make compliance possible or make it expensive. Those are the decisions we can actually control during a build, and they are worth fixing early because they are almost free at design time and very expensive after launch.
Start with the data inventory, not the policy
Every review we have been through starts with the same question: what personal data does this system hold, where did it come from, who can see it, how long does it stay? A team that can answer that in a table has already done most of the work. A team that cannot will spend the review reconstructing it from database schemas under time pressure.
In practice this means the first deliverable of a build is not a screen, it is a register: table, field, category of data, lawful basis, retention period, who has access. It is a spreadsheet, and it is tedious, and it is the single artefact that makes every later question cheap to answer.
The four decisions that come up in every review
One: where the data physically lives
A European client will ask which region the database sits in, and whether backups and logs sit in the same region. A common and preventable failure is a primary database in the EU with object storage, a CDN log bucket or an error-tracking service defaulting to a US region. The answer is not necessarily "keep everything in the EU" — transfers can be lawful — but the answer must be known and documented rather than discovered later.
Two: what the logs keep
Application logs are the most common accidental personal-data store. Request logs capture email addresses in URLs, tokens in query strings, full request bodies on error, and occasionally entire form submissions. Logs are also frequently retained far longer than the data they describe, and are readable by more people than the production database.
- Decide which fields are never logged, and enforce it in code rather than in a review checklist.
- Set a retention period for logs and make it real — a scheduled job, not an intention.
- Treat error-tracking payloads as personal data if they can contain request bodies.
- Restrict log access to the people who need it for incident response.
Three: who can see what
Role design is usually driven by convenience during the build: an admin role that can do everything, then narrower roles added later. The result is that internal staff routinely see more personal data than their job requires, which is exactly what the minimisation principle is about. Designing access by task — support needs to see the ticket and the order, not the identity document — is cheaper to do at the start.
Four: how deletion actually runs
The right to erasure is where documentation and reality diverge most often. A "delete account" button that sets a flag is not deletion. A record removed from the primary database still exists in the nightly backup, the analytics warehouse and the email platform. A workable implementation names each store, then either deletes or irreversibly anonymises per store, and keeps a record that the request was fulfilled.
| Store | Typical gap | What a workable implementation does |
|---|---|---|
| Primary database | Rows soft-deleted and still visible to support tools | Hard delete or anonymise on request, with a defined grace window |
| Backups | "Backups expire eventually" and nothing else | Documented rotation period, and restoration treated as a re-application of the deletion list |
| Analytics / warehouse | Events keyed to a user id that is never removed | Delete or rotate the identifier so events become unlinkable |
| Email / CRM platform | Contact kept as a suppression record without a basis | Keep the minimum needed to honour the opt-out, and document that basis |
| Logs | Retention indefinite | Short retention plus a documented exception for security incidents |
Cookies and analytics on a B2B site
For a corporate site, the highest-risk surface is usually the marketing stack rather than the product. A common pattern is a consent banner that blocks the analytics script but leaves a chat widget, an advertising pixel or a session recorder loading before consent. The fix is technical: tag every third-party script with the consent category it belongs to, load none of them before consent, and verify with the browser network panel rather than the vendor dashboard.
What belongs in the agreement and the technical annex
A data processing agreement is the client\u2019s document, but the technical annex is where engineering either helps or hurts. Three sections matter most:
- Sub-processors: a named list with purpose and location for each, plus a mechanism for notifying changes.
- Security measures: encryption in transit and at rest, access control model, patching cadence, backup and restore testing.
- Incident handling: what counts as an incident, who notifies whom, and within what time — with the notification path tested rather than assumed.
A pre-launch checklist
- Data register complete, covering every field that can identify a person, including free-text fields.
- Retention period defined per table and enforced by a scheduled job.
- Deletion path implemented and tested end to end, including backups and third-party stores.
- Access roles reviewed against actual job tasks, not against the org chart.
- Log payloads reviewed for personal data; retention set; access restricted.
- Consent categories mapped to scripts, verified in the network panel.
- Sub-processor list current, with locations and purposes.
- Incident notification path written down and tested once.
None of this substitutes for legal advice, and it is not meant to. It is the engineering half of the answer, and it is the half that determines whether the legal answer is affordable to operate.
Questions we are asked
Does a system built outside the EU create a compliance problem?
Location matters less than access and storage. A team outside the EU can build a compliant system; what matters is where data is stored, who can access it, what the transfer mechanism is, and whether those facts are documented. Those are design decisions, not consequences of where the developers sit.
Can we host in the EU but keep a staging copy elsewhere?
Often yes, if the staging copy uses anonymised or synthetic data. Copying production data to a staging environment in another region is one of the most common findings in reviews, and it is entirely avoidable.
How long should we retain logs?
There is no single number. What matters is that the period is chosen for a stated purpose — security investigation, debugging, billing — and then enforced. "Forever by default" is the answer that fails review.
