SUMMARY: A consent receipt is a durable record of what a person agreed to, the interface and policy version they saw, and the route available for changing that decision later.
Most digital consent is remembered by the system but not by the person. A database stores a timestamp and a boolean value. The user remembers a screen, a rushed choice, and perhaps a sentence about why access was needed. Months later, the service can prove that a box was checked while neither side can reconstruct the exact scope that appeared reasonable at the time.
This asymmetry matters because permission changes after it is granted. A feature expands, a vendor joins the processing chain, a retention period lengthens, or a new model begins using old activity as training material. The original click remains in the ledger even when the practical meaning of the click has moved.
What the Receipt Must Preserve
Purpose: describe the task the permission was meant to support without hiding behind a broad category such as improvement or personalization.
Scope: name the data, actions, systems, and recipients covered by the choice.
Version: preserve the language, interface state, and policy identifier presented when consent was collected.
Duration: record when the permission expires, when it will be reviewed, and what survives withdrawal.
Control path: provide a direct route to inspect, narrow, or revoke the grant.
A Receipt Is Not a Defense
A receipt does not make an unfair request legitimate. It makes the request reviewable. If the record shows that the purpose was vague, withdrawal was impractical, or refusal carried an unrelated penalty, the evidence may expose weak consent rather than validate it.
Consent drift describes how permission changes meaning over time. The receipt provides the reference point needed to detect that movement. Pair it with a revocation map so the documented control path is tested against the systems that actually retain access.
Field assessment: consent that cannot be reconstructed by the person who gave it is closer to a system claim than a shared agreement.
Consent Receipt Management Lifecycle
Consent receipt management continues after the collection screen. The receipt must remain linked to the systems using the permission, the policy version that justified it, and the controls that can narrow or withdraw it. A receipt that cannot trigger operational change is only historical evidence.
- Issue: give the person a readable copy with purpose, scope, recipients, duration, and control path.
- Version: preserve the exact language and interface state behind the decision.
- Review: compare current use with the granted purpose before new processing begins.
- Expire: use an expiration clock where permission should not continue indefinitely.
- Withdraw: follow the revocation map through every system retaining access.
- Correct: use a correction cascade when a receipt, purpose, or downstream record is wrong.
Measure completion from the participant’s view: the permission display, service behavior, exports, and downstream records should agree. The management lifecycle closes only when the current state can be reconstructed by both the system and the person affected.