Consent Is Not a Checkbox. It's a Contract You're Already Breaching.

Let me say something that most privacy teams won't put in writing: the way most organisations collect consent today wouldn't survive a serious regulatory audit. Not because they're missing a consent banner. But because they've confused the act of collecting consent with the obligation of honouring it.

The Checkbox Has Made Us Lazy

There's a version of consent that lives inside compliance dashboards: a green tick, a timestamp, an IP address, and a record in a CMP. Technically captured. Legally documented. Operationally meaningless.

The privacy industry spent years fighting for the right to get that tick - battling pre-ticked boxes, buried disclosures, confusing opt-outs. Regulators agreed. GDPR Article 7 codified it. The DPDPA followed. Consent had to be freely given, specific, informed, and unambiguous.

We won that argument. Then we stopped.

Because the harder problem — the one that most organisations haven't solved — isn't collecting consent. It's keeping the promise consent represents.

Consent is not a form-fill event. It's the beginning of a legal and ethical obligation that runs for as long as you hold that person's data. And the moment you touch their data in a way they didn't agree to, you've breached it. Not legally "breached" in the sense of a data incident. Breached in the sense that your end of the contract is already broken.

What Consent Actually Promises

When someone clicks "I agree to receive marketing emails about Product X," they are entering into an implicit agreement. Their side: sharing data. Your side: a set of commitments that most organisations have never fully mapped.

Those commitments include:

How many of those five commitments is your organisation actually keeping? If you're being honest, probably not all of them.

The Silent Breaches Happening in Your Systems Right Now

These aren't hypothetical. I've seen versions of all of these in real privacy programmes.

Consent captured; purpose evolved

Product changes. A feature gets added. A new analytics vendor is onboarded. The marketing team starts using behavioural data for a new campaign. Somewhere in that journey, the original consent scope was quietly outgrown — and no one reprompted. The consent record still shows green. The use case has moved past it.

This is especially common after M&A activity, platform migrations, and product re-platforming. No one sets out to breach consent. The data just moves further than anyone tracked.

Withdrawal honoured in one system, ignored in three others

The user unsubscribes. The ESP records it. But the CRM still has the flag set to active. The analytics platform still fires events. The retargeting pixel still has the cookie. And when the next campaign runs, there's a good chance this person — who explicitly withdrew — ends up in the audience.

This happens because consent is a single record, but data is distributed. Without an operational consent propagation mechanism, withdrawal creates the illusion of compliance rather than the reality.

Consent given for version 1.0 of a product, data used for version 3.0

This is the AI version of the problem. Someone gave consent to use their data for customer support interactions in 2021. In 2024, that historical data became training data for an internal LLM. The consent record is intact. The purpose has fundamentally changed.

GDPR's compatibility assessment under Article 6(4) exists precisely for this reason — but how many teams actually run it before feeding operational data into an AI pipeline?

Child consent treated as adult consent

Under GDPR, Article 8 sets a specific age threshold (16 years, or lower where member states have set it). DPDPA introduces parental consent obligations for children's data. But in practice, most age verification is either absent or checkbox-based ("I confirm I am over 18"). If you can't demonstrate a reasonable mechanism for age verification, the consent you collected from minors isn't valid — and everything built on it isn't either.

Bundled consent mistaken for granular consent

"By signing up, you agree to our Terms of Service and Privacy Policy" has never been valid consent under GDPR. Tying consent to service access is coerced, not freely given. Yet this pattern still appears in onboarding flows — sometimes dressed up as a GDPR-compliant notice, but still a single bundle that covers marketing, analytics, personalisation, and profiling in one sweep.

The GDPR and DPDPA Lens: What the Regulation Actually Requires

GDPR's Bar for Valid Consent (Article 7 + Recital 32, 42, 43)

• Freely given: No power imbalance, no conditioning of service on consent
• Specific: Granular enough to reflect the actual purpose
• Informed: Clear, plain-language notice of who, what, why — before consent is given
• Unambiguous: Affirmative action only — no pre-ticked boxes, no silence
• Withdrawable: At any time, without detriment, as easy as giving consent

The burden of proof sits with the controller. You have to demonstrate valid consent — not just assert it.

India's DPDPA Lens

The Digital Personal Data Protection Act introduces a consent framework that is directionally similar to GDPR but operationally distinct in a few important ways:

• Consent notice must precede consent: The data fiduciary must provide a notice before or at the time of seeking consent, describing the personal data to be processed and the purpose. This is a sequencing requirement — notice first, consent second.
• Consent must be specific, informed, unconditional, and unambiguous: Each of these is separately required. An omnibus consent clause fails the "specific" test.
• Withdrawal must be as easy as giving consent: This is explicit in the Act. If giving consent is a one-click action, withdrawal cannot require a form submission and a 10-day wait.
• Consent managers: The Act introduces the concept of a Consent Manager — a third-party platform registered with the Data Protection Board that can manage consent on behalf of Data Principals. This is a significant operational shift that most organisations haven't started planning for.
• Deemed consent (Section 7): Certain uses are carved out from the consent requirement — but this isn't a free pass. The deemed consent provisions have specific conditions, and misapplying them as a workaround to avoid consent obligations is a compliance risk, not a compliance solution.

What a Real Consent Architecture Looks Like

Consent compliance isn't a UI problem. It's a data architecture problem, an integration problem, and a governance problem. Solving it requires operating at all three levels.

Layer 1: Consent Capture (The Part You've Already Done)

• Valid mechanism with proper notice
• Granular, purpose-specific options
• Record keeping with timestamp, version of notice, method of capture
• Age verification where applicable

Layer 2: Consent Propagation (The Part Most Organisations Skip)

This is where the real operational work happens:

• Consent signals must flow downstream. Every system that processes personal data needs to receive and honour consent updates — not just the system that captured the consent.
• Consent metadata needs to travel with the data. If you're passing data to a processor, the consent scope should be documented in the DPA and technically enforced.
• Withdrawal must trigger deletion or restriction. Not a flag. An action. With a confirmed timestamp and an audit trail.

Layer 3: Consent Validity Monitoring (The Part Nobody Does)

• Purpose drift detection: Are you still using data only for the purpose it was collected?
• Consent expiry: Some purposes have natural time-horizons. Historical consents may not cover new uses.
• Re-consent triggers: When you change your processing significantly, you need to re-seek consent — not just update the privacy policy.
• Consent coverage audits: For any processing activity that relies on consent as its legal basis, can you produce the consent record on demand?

The AI Governance Dimension

This is where the consent problem is about to get dramatically worse.

AI systems - whether built internally or through third-party providers — are hungry for training data, evaluation data, and usage logs. The data that feeds them almost always came from people who gave consent for something else entirely.

The questions privacy and AI governance teams need to be asking:

• Was consent obtained for AI training use cases? Not just data processing in general - specifically for model training or fine-tuning.
• Is the AI provider operating as a processor or a controller? The answer determines whether your consent obligations flow through the DPA or require separate user-facing disclosure.
• What does your privacy notice say about AI? If it says nothing, your consent framework has a gap.
• Are you relying on legitimate interests rather than consent for AI processing? If so, have you documented the LIA, and is it genuinely defensible?

The EU AI Act adds another layer here: for high-risk AI systems, transparency obligations toward affected individuals are separate from — and sometimes in addition to — consent under GDPR. Mapping how these regimes interact is not optional for organisations deploying AI in the EU.

For the Privacy Practitioner: Where to Start

If you're reading this as someone who owns consent compliance, here's a practical diagnostic you can run this week.

Step 1: Audit your consent legal basis inventory. For every processing activity in your RoPA where the legal basis is "consent," pull the corresponding consent record format. Is the consent granular enough to cover what you're actually doing?

Step 2: Map your consent propagation flow. From the point of consent capture to every downstream system that acts on that data — draw it out. How many handoffs exist? Where does the consent signal stop?

Step 3: Test withdrawal end-to-end. Pick one consent-based processing activity. Simulate a withdrawal. Follow it all the way through. Does it propagate? Is the data restricted within the required timeframe? Is there an audit trail?

Step 4: Review your AI and analytics use cases against original consent scope. For any use case involving ML, analytics enrichment, or third-party data sharing — check whether the original consent covers it. If you're relying on compatibility rather than re-consent, document the basis for that assessment.

Step 5: Check your withdrawal mechanism. Open your product and try to withdraw consent. Count the number of clicks. Count the number of days before it takes effect. If the answer to either is "too many," you have a compliance gap.

The Uncomfortable Conclusion

Most organisations are not malicious about consent. They don't set out to breach it. They collect it carefully at the start, then let operational reality erode it over time — through product changes, vendor additions, data reuse, and the quiet drift of purpose.

But intent doesn't feature in a regulatory finding. The GDPR doesn't have a "we meant well" provision. The DPDPA doesn't either.

Consent is a contract. When you collected it, you made a promise. The question is whether your current data operations are keeping it.

And if you haven't recently checked — really checked, end-to-end — the honest answer is probably: not entirely.

That's where the work is.

Devika Subbaiah is a Senior Privacy and AI Governance professional with 15 plus years of actual implementation experience. She writes about privacy operations, privacy engineering, and AI governance for practitioners who want to move from theory to execution.