Consent Management
Capturing, storing, honouring and evidencing a data subject's permissions for specific processing purposes, including withdrawal.
Consent is one lawful basis among several and often not the strongest — contract or legitimate interest frequently fit better and are more robust, because consent can be withdrawn at any time and must be as easy to withdraw as to give.
Where consent is genuinely the basis, the engineering requirements are more demanding than the consent banner suggests:
Granularity per purpose. A single blanket acceptance does not satisfy the standard; consent is per processing purpose.
Evidence. You must be able to demonstrate, later, exactly what was consented to, when, and what the wording said — which means versioning the consent text and storing the version with the record.
Withdrawal must propagate. This is the hard part architecturally. Withdrawal has to reach every downstream system, derived dataset, analytics copy and third-party processor — and it must take effect promptly rather than at the next batch cycle.
Honoured at the point of use, not only at collection. Consent state changes, so a pipeline must check current state when processing rather than relying on a flag set when the record was created.
The design that makes this tractable is the same one that makes erasure tractable: a central consent service consulted at processing time, with propagation events for withdrawal. Consent flags copied into every dataset become stale immediately and cannot be corrected reliably.