Data Protection Decisions to Make Before You Build

Design decisions, not paperwork

Data protection is often treated as a document produced after the build. In practice several requirements are architectural: deletion, access control, retention and residency all affect how the system is built.

None of what follows is legal advice. It is the set of questions we work through before writing code, because getting them wrong is costly.

1. Collect less than you can

The strongest position is not holding data you do not need. Every field is something to secure, retain, and eventually delete.

• Do we need date of birth, or is over-18 enough?
• Do we need full address, or is a postcode sufficient for what we do?
• Do we need to keep the document after verifying it, or just the result?
• Do we need this at signup, or could we ask when it becomes relevant?

Each question removed is a permanent reduction in risk and in work.

2. Decide retention before launch

How long is each category kept, and what happens then? Build deletion as a feature rather than an intention, because manual deletion processes do not happen consistently.

A useful design test: if a customer asks tomorrow for their data to be erased, can you do it across the database, file storage, backups, logs and any third-party service? If the answer needs a caveat, the design is not finished.

3. Access control that reflects reality

Who can see what, enforced by the system rather than by convention. “Everyone in the office can see everything” is common in small businesses and becomes a problem as you grow, and an embarrassment if there is ever an incident.

Role-based access plus an audit log of who viewed sensitive records covers most needs and is far easier to build in than to add later.

4. Know where processing happens

For each third-party service — hosting, email, analytics, model providers, error monitoring — know which region processes the data and what the contract says. Error monitoring is the one most often overlooked, and it captures request contents.

Most providers offer regional options. Choosing them at setup costs nothing; changing later means a migration.

5. Be able to export

Individuals can request their data. Build an export that produces a complete, readable record rather than a developer running queries by hand each time.

This is a small piece of work at build time and a recurring cost forever if it is manual.

The artefacts to have

1. A record of what personal data you hold, why, and on what lawful basis
2. A data flow diagram showing what goes where, including third parties
3. Retention periods per category, implemented not just documented
4. Processor agreements with each supplier in the chain
5. A privacy notice that describes what actually happens
6. A DPIA where the processing is high risk

Frequently asked questions