Privacy problems are cheap to create and expensive to remove. Add a form without a retention rule, copy production data into staging, install a convenient embed, and the site acquires another invisible obligation. A policy update at launch does not repair the architecture.
Article 25 GDPR requires data protection by design and by default. For a developer, that becomes a concrete design question: does the default system collect only what the service needs, send it only where intended, retain it for an agreed period and support correction or deletion?
This checklist helps a technical team build those controls. It does not choose legal bases or replace legal advice.
Map data before choosing components
Bottom line: no form, widget or integration should enter the backlog without a named data flow.
For every feature, record the input, purpose, destination, access, retention and deletion route. “Contact form” is not enough. A useful entry says which fields are collected, where the submission is stored, whether email receives a copy, which staff can see it and when both copies disappear.
| Question | Technical evidence |
|---|---|
| What enters? | Field schema and request payload |
| Where does it go? | Network trace and architecture diagram |
| Who can access it? | Roles and access-control configuration |
| How long does it remain? | Retention job and backup policy |
| How is it removed? | Tested deletion procedure |
This becomes the bridge between the privacy record and the deployed system.
Minimise the default request
Bottom line: collect fewer fields before trying to protect a larger dataset.
Challenge every required field. A newsletter normally does not need a phone number. A first sales enquiry may not need a precise birth date. Free-text fields deserve special attention because people can paste sensitive information that the interface never requested.
Use short prompts that tell users what not to submit. Apply server-side validation, not only browser validation. Avoid placing personal data in URLs, analytics event names and verbose error messages. URLs leak easily into logs, browser history and referrer headers.
Data minimisation is not merely visual simplification. Confirm the backend does not append identifiers, enrichment fields or tracking parameters that the form never displayed.
Keep optional services off by default
Bottom line: the initial page state should be the most private state that still delivers the requested page.
Do not initialise optional analytics, advertising, chat or media embeds and hope a consent tool reverses them. Build the dependency so it cannot load until the relevant state permits it. A blocked network request is stronger evidence than a configured dashboard toggle.
Consent withdrawal must affect future behaviour and should be as accessible as the original choice. Test reject, selective accept, accept all and withdrawal as separate states.
Some storage or access may be strictly necessary. That classification needs legal review. The implementation still needs to match it exactly.
Separate production, staging and support access
Bottom line: test environments should not receive production personal data by convenience.
Use synthetic fixtures in development and staging. If an exceptional debugging case needs production data, create a controlled, time-limited process with an owner and audit trail. Do not leave database exports in shared folders or developer laptops.
Production access should use individual accounts, least privilege and strong authentication. Log administrative access, but do not let audit logs become an uncontrolled second copy of the underlying personal data.
Make retention executable
Bottom line: a retention sentence is not a control until software or a named operation enforces it.
Identify every copy: primary database, CRM, mailbox, object storage, analytics platform, support system, logs and backups. Define which system is authoritative and what happens when a record expires.
Automate deletion where volume and risk justify it. Add monitoring so a failed cleanup job becomes visible. For low-volume manual processes, create an owner, cadence and evidence record. “We delete when no longer needed” is not testable.
Backups need their own treatment. Immediate selective deletion may be impractical in immutable backups, but restoration procedures should prevent expired records from silently returning to active systems. Legal counsel should review whether the proposed schedule and exceptions fit the processing purpose.
Design for access, correction and deletion
Bottom line: use a stable internal reference so one person’s data can be found across systems without broad searching.
Document where a request enters, how identity is verified, which systems are searched and who approves the result. Build exports that a person can understand rather than dumping raw tables. Test deletion for attachments, derived fields, queues and downstream integrations.
Do not promise a one-click deletion feature if staff must still remove copies manually. Describe the actual process and improve it over time.
Control third-party dependencies
Bottom line: every external service needs a technical owner and an exit path.
For each processor or independent recipient, record the purpose, data categories, regions, subprocessor information, configuration and contract location. Avoid sending full payloads when a pseudonymous identifier is sufficient. Rotate credentials and restrict API scopes.
Prefer local assets for fonts and previews when practical. Delay optional embeds until interaction. Review international transfer arrangements with qualified counsel when data leaves the EEA or is accessible from another country.
Build observable privacy controls
Bottom line: privacy behaviour should be testable in CI and production without recording unnecessary personal data.
Useful automated checks include:
- unexpected third-party hosts before consent
- new cookies or local-storage keys
- forms that add unapproved fields
- retention jobs that stop running
- public pages that expose personal data
- analytics events containing email addresses or full URLs with identifiers
Keep test evidence proportionate. A screenshot, sanitized HAR and test result can prove behaviour without creating another sensitive archive.
Keep the privacy notice tied to releases
Bottom line: a feature that changes data flow should trigger both technical and documentation review.
Add a privacy impact field to pull requests or release tickets: does this change collect, send, store, expose or delete user-related data? A “yes” routes the change to the feature owner and privacy reviewer before release.
The notice should name real purposes and recipient categories in language users can understand. It should not list services removed months ago or omit a new CRM because nobody told the person maintaining the legal pages.
Launch checklist
Bottom line: ship only when each control has an owner and evidence.
| Area | Ready when |
|---|---|
| Inventory | Data flows match the deployed release |
| Minimisation | Every required field has a purpose |
| Defaults | Optional requests are off initially |
| Security | Environments and roles are separated |
| Retention | Schedules are implemented and monitored |
| Rights | Retrieval and deletion have been tested |
| Vendors | Destinations and configurations are recorded |
| Notice | Wording matches observed behaviour |
Frequently asked questions
Is privacy by design only required for new systems?
No. Existing systems should be reviewed as purposes, risks and technology change. New work simply offers the cheapest moment to make the right architectural choice.
Does encryption satisfy privacy by design?
Encryption is one safeguard. It does not justify unnecessary collection, solve excessive retention or stop an optional third party from receiving data.
Who owns the checklist?
Product owns the purpose, engineering owns implementation evidence, and qualified privacy counsel reviews legal conclusions. A single “GDPR person” cannot accurately do all three in isolation.
Do small business websites need this much process?
The process can be lightweight. A short data-flow table, a few browser tests and named deletion steps are often enough to make a simple site understandable and maintainable.
Official references
- GDPR, including Articles 5 and 25
- EDPB Guidelines on Data Protection by Design and by Default
- European Commission rules on international data transfers
For an evidence-based baseline, run the free website check before and after each release, and read our technical GDPR website audit and the guide to hidden third-party requests.
