Consent must be captured, honoured across every system, and proven to a regulator. How should this be architected, and why do consent implementations usually fail?

What consent must actually do

Not merely be collected. It must be enforced at every point of use, for every purpose, and its state at any past moment must be provable.

That decomposes into four requirements, and implementations usually satisfy only the first:

1. Capture: what was consented to, when, by whom, through what interface, under what wording.
2. Propagation: every system that processes the data must know the current state.
3. Enforcement: processing must actually be prevented where consent is absent.
4. Proof: the state at any past time must be reconstructible, along with the exact wording presented.

The architecture

• A consent service as the authoritative store, holding consent per subject per purpose — because consent is not a boolean. Marketing email, personalisation, analytics and third-party sharing are separate grants, and treating consent as one flag is the most common structural error.
• An immutable consent event log, since proving the state on a past date requires history, and a mutable current-state table cannot provide it. This is a genuine event-sourcing requirement rather than a preference.
• The presented wording versioned and retained, because proving consent means proving what the person was shown — and the interface changed since. Almost nobody retains this, and it is what an inquiry asks for.
• Enforcement at the point of processing, not at the point of collection. A pipeline that sends marketing email checks consent when it sends, since consent may have been withdrawn since the data was collected.
• Propagation to downstream systems — the warehouse, the CRM, the email platform, analytics — with withdrawal propagating quickly and verifiably, because the regulatory exposure is concentrated in the window after withdrawal.
• Purpose recorded on every data flow, so a dataset built for one purpose is not silently used for another — which is the substance of purpose limitation and is the part that architecture can enforce.

Why implementations fail

• Consent as a boolean, so a withdrawal from marketing also disables the analytics the person did not object to, or a marketing consent is treated as permission for everything.
• Checked at collection, not at use, so withdrawal has no effect on data already gathered.
• Not propagated to downstream copies, where the warehouse, the CRM and the email tool each hold their own stale view.
• Current state only, making historical proof impossible.
• Wording not retained, so consent cannot be evidenced even where it was properly obtained.
• Enforcement in the application only, bypassed by every batch job, export and analytical query.
• No verification, so the enforcement is asserted rather than demonstrated.

The test that reveals the truth

"Show me every system that processes this person's data, and prove each one is honouring their current consent state — and show me what they were shown when they consented."

Most implementations cannot answer any part of it, and the gap is not usually in the consent capture — which is well built — but in propagation, enforcement at use, and history, which are the three parts that require architecture rather than a form.