How does a consent record work?
When someone opts in — ticks a box, confirms a double opt-in email, or submits a form — you capture a snapshot of that moment, not just a true/false flag. The record binds the person's identity to the exact purpose they agreed to, the wording they were shown, and the timestamp. If the purpose changes later, the old consent does not stretch to cover it: you collect fresh consent and log a new record.
What fields should a consent record store?
- Who: a stable identifier — user ID, email, or session ID — for the person who consented.
- When: an exact timestamp, and for oral consent, a dated note.
- How: the channel and mechanism — checkbox, confirmation link, signed form.
- What they saw: a copy of the consent wording and any privacy notice shown at the time.
- Purpose: the specific processing the consent covers — marketing email, analytics, profiling.
- Withdrawal: if and when consent was revoked, logged the same way it was granted.
Why does immutable history matter?
Consent is not a single boolean you overwrite. A person can grant it, withdraw it, and grant it again — and you may need to prove the state at any past date, for example the day you sent a given campaign. Store consent the way you would store an audit log: append-only, each grant and withdrawal a timestamped event. Overwriting the last value destroys the evidence GDPR expects you to keep.
Why it matters for a two-person team
Article 7(1) puts the burden of proof on you, whatever your headcount. If a subscriber complains or a regulator asks, a checkbox state proves nothing — you need the timestamped record. Building this in from the first signup is far cheaper than reconstructing it later, and it is one reason to keep consent data on infrastructure you control. See the deep guide on GDPR and self-hosting for how consent records, suppression, and residency fit together.