Consent Artefact

Nearly every consent implementation assumes the organisation captures consent in its own user interface and owns the record. A consent-manager regime breaks that assumption. The person grants permission through a registered intermediary, and what reaches you is a signed artefact stating who consented, to which purposes, for which recipient, and when. You are no longer the source of truth; you are a verifier of somebody else's statement.

India's Digital Personal Data Protection Rules, notified in November 2025, create this role formally: a consent manager registered with the Data Protection Board, required to run interoperable platforms and to keep records of consents and data sharing. Commencement is phased, with the consent-manager provisions taking effect a year after publication and most remaining rules at eighteen months, so the dates should be checked against the current notification rather than assumed.

Why it matters

The inversion changes three things in the architecture, and each one is a place implementations fail.

• Validation moves onto the read path. A permission is now a claim with a signature, an issuer and an expiry, so something has to check it before processing proceeds.
• Withdrawal arrives from outside. It is pushed to you, out of order, possibly retried, and a push you never received is silent, which is the worst property a compliance signal can have.
• Interoperability becomes a contract. Purpose identifiers have to mean the same thing to the manager and to your jobs, or a permission for "service communications" will be read by one side as transactional email and by the other as marketing.

Implementation patterns

• Verify, then project. Check the signature and expiry on receipt, then write a local projection of current permissions keyed by subject and purpose, because no batch job can call the manager per row.
• Give the projection a short, explicit staleness bound. A bound of 5 to 15 minutes for marketing-style purposes, measured in minutes rather than days, so that reconciliation catches a missed withdrawal inside one processing cycle.
• Make the inbound withdrawal endpoint idempotent and ordered, keyed on artefact id with a monotonic sequence or timestamp, so a replayed or late message cannot resurrect a withdrawn permission.
• Reconcile on a schedule against the manager's current state, and alert on any divergence. Divergence count is the metric that tells you the integration is healthy.
• Keep the artefacts themselves, not just the projection, because the artefact is the evidence and the record-keeping obligations attached to consent run to years.
• Fail closed for consent-based purposes. If verification is unavailable, marketing does not send. Processing on other lawful bases carries on, which is why purposes must be separable.

Industry example

The architectural pattern predates the Indian rules: account aggregator frameworks and open banking consent flows already work this way, with a signed consent object issued by one party, verified by another, and revocable through the issuer rather than the data user. The recurring production failure in those ecosystems is not cryptographic; it is semantic - two parties disagreeing about what a purpose code covers, or a data user treating a cached consent as durable after the issuer revoked it.

Failure scenarios

• Cache as truth. The projection is treated as durable, a withdrawal push is lost, and processing continues against a stale permission with a clean-looking local record.
• Out-of-order withdrawal followed by a re-grant replay that reinstates the wrong state.
• Signature verification skipped under load, which turns the whole model into an unauthenticated API accepting permission claims.
• Purpose mapping drift after the manager adds a purpose code nobody mapped, so grants arrive and are silently ignored.
• Artefacts discarded once projected, leaving no evidence of what was consented to at the time.

Trade-offs

The person gains a single place to withdraw everything, which is the point of the regime. You pay an integration whose failure mode is silence, so the reconciliation job is not optional engineering.

When not to use it

Where the regime does not require it and the data flows are simple, a first-party consent store with use-time checks is less machinery and fewer failure modes - and inventing an artefact format nobody else speaks buys nothing. The pattern earns its cost when permissions must be portable across organisations, when a regulator requires a registered intermediary, or when the same person's consent has to be honoured by several independent data users. Consent itself should also stay out of this path entirely where the lawful basis is contract or legal obligation, since a withdrawable artefact cannot govern processing you are required to carry out.

Interview question

Q: Your consent now arrives as a signed artefact from a registered external consent manager, and withdrawals are pushed to you. Design the handling, and tell me the failure mode you are most worried about and how you would detect it.

What a strong answer covers: verification on receipt and a local projection with a short staleness bound; an idempotent ordered withdrawal endpoint keyed on artefact id; scheduled reconciliation with divergence as the health metric; retaining artefacts as evidence against multi-year record-keeping duties; failing closed for consent-based purposes only, which requires purposes to be separable by lawful basis; and naming the lost-withdrawal push as the dangerous case because its symptom is silence.

Quick check

Quiz: What is the dangerous failure mode of an externally issued consent artefact? A withdrawal push you never received, because the local projection still looks correct and nothing errors - which is why reconciliation against the issuer is mandatory.

Flashcard: What changes in your design when consent is issued by an external consent manager rather than captured in your own UI? You become a verifier: signature and expiry checks on receipt, a short-lived local projection, an idempotent inbound withdrawal endpoint, and scheduled reconciliation with the issuer.