Consent Propagation

Capturing consent is the visible part and the easy part. The obligation is that processing dependent on consent stops when consent is withdrawn — everywhere, including in systems the organisation does not operate.

Most implementations capture well and propagate poorly. The banner works, the record exists, and the analytics platform and advertising stack keep processing.

What consent has to be, architecturally

Specific, informed, freely given, and as easy to withdraw as to give. Each is a design constraint rather than a legal footnote:

• Specific means per purpose, so the data model is per-purpose state, not a single flag.
• As easy to withdraw means the same number of interactions, which rules out a one-click accept and a multi-screen reject.
• Freely given means the system must function with everything declined — a real engineering requirement, not a hypothetical.

Implementation patterns

• Consent state per subject, per purpose, with a timestamp and the version of the notice shown. Proving consent later requires knowing exactly what the person saw, so notice versions become retained artefacts.
• A consent state service consulted before processing, rather than each surface holding its own copy that drifts.
• Checked at processing time, not only at collection time, because withdrawal happens in between.
• Fanout to every downstream system and third party, with acknowledgement, so completion is provable rather than assumed.
• An audit trail of every state change, retained as long as the processing it authorised is relevant.
• Cross-surface identity handled deliberately — unlinked profiles make consent inconsistent, and linking them is itself processing that needs a basis.

Industry example

Publishers and consumer platforms running advertising, analytics and personalisation face the hardest version of this, because the processing is distributed across many third parties with their own systems and their own latency. A withdrawal that stops first-party analytics and does not reach the advertising stack is a partial implementation that will not survive scrutiny.

The same shape appears in [[deletion-propagation]]: the state change is easy in the primary system and hard everywhere else, and the property that distinguishes a real implementation is acknowledgement per recipient, so the organisation can demonstrate the change actually took effect.

Failure scenarios

• Capture without propagation, the dominant failure.
• A single accept-all flag, which is not specific consent.
• Pre-ticked defaults, which are not consent at all.
• Consent checked only at collection, so withdrawal has no effect on in-flight processing.
• No acknowledgement from recipients, leaving compliance as a belief.
• The product not functioning when consent is declined, which makes the consent not freely given.

Trade-offs

Per-purpose consent with genuine propagation reduces the data available for analytics and personalisation, which has a measurable revenue cost, and building the propagation is real engineering across systems the organisation may not control.

The framing that makes it tractable is that the alternative is a control that will fail an examination, and that a demonstrable implementation is what allows the remaining processing to be defended. The measure of a working system is not consent captured but withdrawal propagating everywhere within a stated time, evidenced.

Interview question

"A user withdraws consent for advertising in your mobile app. Trace what has to happen, in which systems, within what time — and tell me how you would prove it happened."