The common implementation is one tick box during registration, covering everything the platform might ever do, stored as a single boolean and a timestamp.
It is quick to build, it looks like compliance, and it fails the first time somebody wants to agree to one thing and not another.
One flag cannot answer the questions
A platform holding sensitive data will be asked things like: can this person be contacted by email? Can their photograph appear publicly? Can their information be shared with a third party? Can it be used for research?
Those are separate decisions with separate answers. Collapsed into one agreement, the system can only say that somebody once ticked a box, which means either over-restricting — nobody can be contacted about anything — or over-reaching, which is the actual risk.
What has to be recorded
Consent is an event, not a setting:
- What was agreed to, specifically, per permission.
- 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. The history matters, not just the current state.
Store it as an append-only record. 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 have one that only an administrator can operate.
Withdrawal has to be as easy as giving it, has to take effect immediately across every process that reads it, and has to be visible to the person afterwards. “Withdrawn but still receiving the emails” is worse than never having asked.
That means permissions being read at the point of use, every time, rather than copied into a mailing list or a report when the record was created. Copies do not hear about withdrawal.
Where a parent consents for a child
Youth programmes, junior memberships and paediatric contexts add a layer. Consent is usually given by a parent or guardian, which means recording who gave it and their relationship, handling the case where two people disagree, and dealing with the child reaching an age where the decision becomes theirs.
That transition is almost never built, and it arrives on a schedule you can predict years in advance.
Building it in
We build consent per permission rather than as a blanket agreement, with retention rules that run on their own and visibility that follows the role, on platforms holding records about children — The Performance Centre does exactly this, gathered by volunteers and coaches rather than by trained data handlers.
Retrofitting it is considerably harder, because the historic records have no provenance and there is no defensible way to invent one.
If your consent model is a single flag, get in touch, or read about our health and life sciences work.