GDPR is law. Here's what we changed across every client site.
May 25, 2018. A two-year warning shot finally landed. We spent the last six weeks auditing every client system we own — here's the punch list, what it cost, and the architectural decisions every team should be making from here on.
GDPR went live on May 25. The two-year transition period that started in 2016 finally ran out, and the warning emails everyone had been ignoring became enforcement risk. Most of our clients had been told it was coming. Very few had actually done anything about it. The last six weeks were spent making sure none of them ended up in the kind of news story the ICO loves.
Here's the practical audit — what GDPR actually requires, what we changed, what it cost, and what we'd do differently if we were building from scratch today.
What GDPR actually says, in plain terms
- 01Lawful basis: You need a documented legal reason to process personal data. 'We always have' is not a legal basis.
- 02Consent: When consent is the basis, it must be specific, informed, freely given, and easy to withdraw. Pre-ticked boxes are out.
- 03Transparency: Users must know what data you hold, why, who you share it with, and how long you keep it. The privacy policy is now a real document.
- 04Data subject rights: Users can access, correct, delete, port, and restrict the data you hold on them. Each must be honoured within 30 days.
- 05Breach notification: A personal data breach must be reported to the ICO within 72 hours. Documented incident response is mandatory.
- 06Privacy by design: Data protection must be considered from the start of any new system, not bolted on later.
What we changed across every client site
- 01Cookie banners on every site that uses any non-essential cookies. Banner blocks tags until consent — no pre-firing of Google Analytics, Facebook Pixel, anything.
- 02Privacy policies rewritten in plain English. The lawyer-speak versions almost guarantee an ICO query — and they don't satisfy the 'informed consent' test either.
- 03Contact forms — explicit consent checkbox, separate from the submit, with a clear retention statement. The 'by submitting you agree to our terms' pattern is dead.
- 04Data export endpoints for every system holding identifiable data. The user must be able to download their data in a portable format within 30 days.
- 05Data deletion endpoints. 'Right to be forgotten' became a real engineering requirement, not a vague policy commitment.
- 06Audit logs of every read and write to personal data. Without these, breach forensics are impossible.
- 07Vendor audits — every third-party tag, every analytics tool, every SaaS we feed data into. Some got cut. Some required new Data Processing Agreements.
- 08Incident-response runbooks documented and rehearsed. 72 hours is not enough time to figure out who to call mid-incident.
The cost, project by project
| Project age | Project type | GDPR effort (days) | Pain points |
|---|---|---|---|
| < 2 years old | Modern Nuxt + Mongo SaaS | 2–4 | Mostly UI work — privacy banner, consent UI, exports |
| 2–4 years old | Nuxt + Express, custom auth | 4–7 | Audit logs missing, deletion required schema work |
| 4–6 years old | PHP + MySQL, legacy CMS | 8–15 | User-table rebuild, vendor contract renegotiation |
| > 6 years | Wordpress + custom plugins | 10–20 | Half the third-party plugins broke the new requirements |
What it actually cost
Less than the fear suggested, more than the optimists hoped. Clients we'd built systems for in the last two years were mostly fine — modern architectures separate identity, consent, and data cleanly enough that wiring in GDPR was a couple of days of work. Legacy systems were harder. One client's bespoke 2012-era PHP app needed a rebuild of its user table because there was no way to mark records as deleted without losing the relational integrity of every downstream report.
The biggest single line item across clients was the privacy policy rewrite. Most of them were boilerplate cribbed from somewhere five years ago. Rewriting them in language that the ICO would accept, that the marketing team would approve, and that the user would actually read — that's a week of legal-meets-copywriting work per project.
The boring upside of getting GDPR right is that the systems that are right for the regulator are also the systems users trust more. The same audit log that defends you to the ICO also debugs your support tickets faster.
The patterns we now default to
- 01Identity and personal data live in their own service, behind a thin API. Other services hold a reference; they don't duplicate the data.
- 02Every write to a personal data table is appended to an audit log with timestamp, user, action, and source IP.
- 03Soft deletes for 30 days, then hard deletes by automated job. The window gives time to recover from mistakes without keeping data forever.
- 04Consent is a first-class object — version, timestamp, what was agreed to, and the IP at the time. Not a boolean flag.
- 05Data export and deletion are admin-tool buttons, not engineering tickets. The cost of supporting a request is now five minutes, not five hours.
- 06Privacy policies are versioned. When they change, users see the change and re-consent if the change is material.
Going forward
Privacy by design is non-optional. Every new system we ship treats consent, retention, and deletion as first-class concerns. The architectural ask is not large — most of it is discipline, not technology. The hard part is institutional: marketing teams used to collecting everything 'just in case' have to be re-trained to collect only what they have a documented purpose for.
We expect the next two years to bring a steady drip of enforcement actions. The early ones will be against egregious offenders — companies who ignored GDPR completely. The middle ones will be against companies who 'complied' on the surface but kept doing what they always did underneath. The late ones will set the precedents that determine what good practice actually looks like. Worth watching closely.