The properties that cannot be retrofitted
Encryption can be added later. Access control can be tightened later. Consent provenance, retention that starts from the right event, and an audit trail of who saw what cannot — because they are statements about the past, and the past has already happened.
This paper is about the ones with a deadline.
1. Minimisation first
Most data protection effort goes on securing information that never needed to exist. Fields arrive through reasonable routes: someone might need it; the old form had it; it makes a report easier; full precision by default — a date of birth where an age band would do.
Each is defensible individually. Together they produce a record far more sensitive than the service requires, and every control afterwards has to cover all of it.
Minimisation is not only a legal position. It is less to secure, a smaller breach if one happens, a shorter subject access response, fewer retention rules, and faster supplier assurance.
Per field, ask: what decision does this change; could a less precise version do; is it needed now or against a future feature; who needs to see it; and how long is it useful for?
Free text is where it accumulates. The notes box exists because structure never covers everything, and it fills with exactly what you were careful not to ask for — medical details, family circumstances, third-party names. It cannot be minimised away, but it can be scoped: narrow to a purpose, labelled plainly, restricted by role, and given a shorter retention than the record it hangs off.
2. Consent is an event, not a setting
The common implementation is one tick box at registration covering everything, stored as a boolean and a timestamp. It fails the first time someone wants to agree to one thing and not another.
Record instead:
- What was agreed to, per permission — contact, imagery, sharing, research.
- The exact wording shown at the time. Wording changes; a record pointing at today’s text does not evidence what was agreed two years ago.
- When, and by whom, including whether it was the data subject or someone acting for them.
- How it was given: a form, a conversation recorded by staff, a migration from a previous system.
- Withdrawal, with the same detail.
Store it append-only. Overwriting the previous value destroys the only evidence of what applied during the period being asked about.
Withdrawal is the part that gets skipped
Systems that capture consent well often have no route to remove it, or one only an administrator can operate. Withdrawal must be as easy as giving it, take effect immediately everywhere, and be visible to the person afterwards.
That means permissions are read at the point of use, every time — not copied into a mailing list or a report when the record was created. Copies do not hear about withdrawal.
3. Children, and the transitions nobody builds
Where a parent or guardian consents on a child’s behalf, record who gave it and their relationship, handle the case where two people with parental responsibility disagree, and plan for the child reaching an age where the decision becomes theirs.
That transition arrives on a schedule you can predict years ahead and is almost never built. When it is not, the platform continues operating on a consent that is no longer valid, and there is no defensible way to invent a replacement retrospectively.
Related: data about children is frequently gathered at speed by people who are not trained data handlers — volunteers, coaches, front-desk staff. Design for that. The control that works is the field that was never offered, not the policy nobody read.
4. Retention that runs on its own
Retention policies are usually well written and have no mechanism. Then you query the database and find nine-year-old records in a three-year category.
Manual deletion never happens: it is nobody’s job, it is irreversible, and it is unrewarded. The gap that results is worse than having no policy, because the policy is evidence of what you knew you should be doing.
- A period attached to each category, in the schema, not a document.
- A scheduled process that enforces it without human initiation.
- A log of what was deleted and when — often the only evidence the policy was honoured.
- Alerting when it does not run. A silently failed job looks exactly like a compliant system.
The details that make it hard
Deletion versus anonymisation. Usually the aggregate is needed and the identity is not. Stripping identifiers must be genuinely irreversible — a pseudonym you hold the key for is still personal data.
Cascades. Deleting a person leaves attendance rows, uploaded files, messages and audit entries. Some must go, some must stay, some contain their name in free text.
Backups. Restoring reinstates deleted records. Either the restore path re-applies retention, or your backup window is your real retention period.
Legal hold. Anything under investigation must survive the schedule — and the override needs an expiry, or it becomes permanent by neglect.
Where the clock starts. Running retention from record creation is the most common design error. It should usually start from an event: membership ended, case closed, last interaction. If nothing marks an account as inactive, nothing can ever expire.
5. Subject access, erasure and portability
These are engineering features, not administrative processes. Built in, a request takes minutes; bolted on, it takes a person several days and produces an incomplete answer.
What is needed: everything held about a person, assembled from every table and file store, exportable in a documented format; erasure that cascades correctly and records what it removed; and the ability to say honestly what was retained and on what basis.
The test is simply to run one, internally, before anyone asks.
6. Visibility follows the role
Least privilege, applied at the field level. The person handling billing should not see medical notes; a coach should not see another team’s records; an administrator should not need to see clinical detail to fix an address.
Two supporting requirements:
- Read access logged, because unauthorised viewing leaves no trace in a change log.
- Views built per role, not one screen with fields hidden. Hiding fields on an administrator’s screen produces a confusing administrator’s screen, not a parent’s.
7. Analytics without spreading identity
Most reporting and model training needs the pattern, not the person. Run them on pseudonymised or aggregated data, hold re-identification keys separately, and log access to them.
Asking which is genuinely required usually shortens the compliance conversation considerably — and it is the same minimisation argument, applied downstream.
A sequence that works
- Cut the dataset. The meetings that remove fields feel unproductive and are the cheapest security work available.
- Model consent as append-only events, with wording captured.
- Read permissions at point of use. No copies.
- Attach retention to categories and automate it, keyed to the right event.
- Build subject access and erasure as features, and test them.
- Log reads, not just writes.
We build platforms holding records about children on this basis — The Performance Centre is the clearest example, where consent, retention, role-based visibility and audit trails are part of the design rather than a later conversation.
Reviewing what your platform holds? Get in touch, or read about our health and life sciences work.