Consent Management under India’s DPDP Act: A CRM Perspective
Over the past few months, conversations around India’s Digital Personal Data Protection Act, 2023 have intensified. For many organisations, the discussion has centred on compliance checklists — documentation, policies, notices.
But for brands operating customer engagement systems at scale, DPDP introduces a more fundamental question:
Where does consent actually live inside the systems that make daily decisions?
Because once enforcement begins, this will not be a policy discussion. It will be a systems test
Consent is no longer a record. It’s a Runtime Condition.
For years, consent behaved like a stored attribute. Captured once. Archived. Rarely interrogated. That model survived because systems were never required to prove — in real time — that consent actively governed behaviour. DPDP changes that expectation.
Consent must now:
- Withstand audits
- Hold during execution
- Trigger immediate behavioural change
- Prevent actions — not merely document permission
This shifts consent from documentation into architecture.
Under DPDP, the question will not be: “Did you capture consent?”
It will be:
“When consent changed, did system behaviour change immediately?”
If enforcement is delayed, it is indistinguishable from non-enforcement.
Where most systems break
The uncomfortable reality is that most enterprise stacks were never designed for real-time consent arbitration.
- Transaction Systems (POS)
POS systems record outcomes. They are not designed to arbitrate permissions.
Consent validation often happens after the transaction — which, under DPDP, is already too late.
- Fragmented Tool Stacks
In many organisations:
- POS captures one version of consent
- Marketing tools store another
- Loyalty systems interpret it differently
Each operates independently. This creates multiple truths.
Under DPDP, inconsistency is not operational noise. It is regulatory exposure.
- Marketing Automation Platforms
Marketing systems optimise for velocity. They assume consent already exists upstream. Enforcement logic is loosely integrated. Permissions sync asynchronously.
DPDP does not allow consent to be inferred or assumed. If enforcement depends on downstream reconciliation, the system is structurally misaligned.
- Chatbots
Chatbots capture intent within narrow conversational environments.
But they:
- Reach only subsets of users
- Bind consent to context
- Cannot govern cross-channel enforcement
They capture signals. They do not own governance.
- Intermediary & Checkout Platforms
Intermediary platforms introduce subtle risks. Consent may be given to the platform — not the brand. Yet under DPDP, accountability rests with the Data Fiduciary. Authority and execution cannot diverge.
What DPDP will actually test
DPDP will not test documentation. It will test outcomes.
Regulators will implicitly ask:
- When consent was withdrawn, did communication stop instantly?
- When purpose expired, did processing halt?
- If data moved, was live permission evaluated first?
If a system sends a message after withdrawal — even by seconds — that is a design failure, not an operational accident.
DPDP does not penalise intent. It exposes architecture.
The Architectural Shift: Enter OneConsent by Zence
This is where OneConsent by Zence becomes structurally different. DPDP requires consent to function as a real-time control layer — embedded inside the execution path of customer engagement. OneConsent is designed not as a passive consent repository, but as a decision-layer engine.
Zence already operates at the intersection of:
- Customer identity
- Engagement orchestration
- Real-time decision-making
When consent is governed inside this layer:
- Every campaign trigger is evaluated before execution
- Every interaction checks live permission status
- Consent updates propagate instantly across channels
- There is no dependency on downstream syncs
- No lag between intent and enforcement
Consent becomes a runtime condition — not a stored field. Consent managers can provide oversight and authoritative records.
OneConsent ensures enforcement happens at the exact moment of action. That distinction matters.
The Real Risk is false confidence
The most dangerous scenario under DPDP is not non-compliance. It is the illusion of compliance. Systems that store consent but cannot enforce it in real time will appear compliant — until enforcement exposes behavioural gaps.
DPDP will not evaluate whether consent was captured. It will evaluate whether consent could stop an action — and whether it actually did. That is the shift. Consent is no longer a stored record. It is a system condition.
Final Thought
Brands that treat DPDP as a documentation exercise will struggle. Brands that redesign architecture around enforceable consent will lead. OneConsent exists at that enforcement layer — inside the decision path, not outside it. When consent changes, behaviour changes. Immediately. Provably. At scale. And under DPDP, that is the only definition that matters.
