Quick answer: From 13 November 2026, Phase II of India's Digital Personal Data Protection Act moves the Consent-Manager framework into enforcement. For a business sending A2P SMS into India, the practical consequence is that consent for messaging is expected to arrive as a cryptographically signed receipt issued by a registered Consent Manager — verifiable on demand, attributable, and revocable — rather than as a row in your own database asserting that a user once ticked a box. The Devotel Orbit platform already ships the surface this lands on: register the Consent Managers your users go through, store and verify their signed receipts over the consent API, and the receipts become auditable consent records. The registration and collection side — choosing a manager, wiring it into your signup flows — remains yours, as it should.
This post covers what Phase II makes mandatory, how the Consent-Manager model works in plain terms, and what an Indian-A2P sender or DLT-registered entity should have in place before the deadline.
What Phase II of the DPDP makes mandatory on 13 November 2026
India's Digital Personal Data Protection Act is being phased in, and 13 November 2026 is the date the Consent-Manager chapter stops being architecture and becomes operation. The DPDP frames the individual (the "data principal") as the owner of their personal data, and any business processing it (a "data fiduciary") as accountable for the lawful basis. Consent under the Act has to be specific, informed, unconditional, and unambiguous — and, critically for messaging, it has to be as easy to withdraw as it was to give.
Phase II operationalizes the Consent Manager: a registered, accountable intermediary that sits between the data principal and the businesses that want to process that principal's data. Instead of every individual company building its own consent UX and its own proof trail, the principal grants, reviews, and withdraws consent through the Consent Manager — and the Consent Manager issues a signed consent receipt: a tamper-evident, cryptographically signed statement of what was consented to, for what purpose, by whom, and until when.
For senders of business messaging into India — OTP, transactional alerts, promotional SMS — this changes what "we have consent" means. A self-asserted database flag stops being persuasive evidence the moment a standardized, verifiable format exists. If a regulator, a DLT scrub, or a dispute asks for proof, the answer is now expected to be a signed receipt issued through a registered Consent Manager — not a screenshot of a signup form.
How the Consent-Manager model actually works, in business language
Three roles, one artifact:
- The data principal (your end user) grants or withdraws consent in a Consent Manager's interface — a registered intermediary accountable to the Data Protection Board of India for running that flow correctly.
- The Consent Manager issues a signed receipt for each grant. The signature is a standard digital signature (ECDSA over the receipt's canonical contents): anyone holding the manager's published public key can check that the receipt is genuine and untampered, without calling the manager.
- The business (you, the data fiduciary) collects the receipts, stores them against the contacts they cover, and re-verifies a stored receipt when an audit asks — against the manager's current key, so a key rotation or deactivation is visible rather than silent.
The property worth internalizing: verification is offline and durable. Once a receipt is signed and you hold the manager's public key, the proof travels with the document. That is what makes receipts credibly portable across vendors and defensible years later — no live dependency on the issuer's uptime at audit time.
What Devotel Orbit ships for this — and what remains yours
Devotel Orbit shipped its India DPDP Consent-Manager surface under the consent API, ahead of the Phase II date:
- Register the managers you work with — store the manager's identity and published public key so every receipt it issues can be verified:
POST /consent/managers. - Store a signed receipt as consent — submit a manager-signed receipt and the platform checks the signature against the registered manager's key before it is persisted as a consent record for the contact and channel:
POST /consent/receipts. A bad signature or an unknown manager is refused withCONSENT_RECEIPT_INVALID, so an invalid receipt never silently becomes "consent." - Re-verify a stored receipt on demand — during an audit, confirm a receipt still validates against the manager's current key:
POST /consent/receipts/:id/verify.
The full request and response shapes are in the Consent Management docs. Note the deliberate division of responsibility: Orbit provides the verification surface — it confirms that a receipt's signature is genuine and records the result as consent. It does not require that your messaging flow uses receipts, and it does not obtain consent for you. Choosing a Consent Manager, registering that manager with the platform, collecting receipts in your own signup flows, and deciding which sends should be gated on a valid receipt are tenant-owned controls. The platform is the verifiable system of record; the compliance posture is yours.
Who is affected, and what to do before 13 November 2026
Three populations should treat this as their deadline:
- Indian A2P SMS senders — any business messaging Indian numbers, domestic or international. Consent proof for messaging into India is moving to the receipt model.
- DLT-registered entities — if you completed TRAI DLT registration (Principal Entity, headers, templates), your registration gets you carriage; DPDP receipts are what substantiates the consent behind the sends. The two regimes complement each other — the DLT-India onboarding docs cover the registration side.
- Platforms and aggregators operating sender accounts — if you collect consent on behalf of businesses sending into India, your stored artifacts are what gets audited.
A practical pre-deadline sequence:
- Identify where consent for Indian recipients is currently captured, and what proof you would actually produce if asked today.
- Select a registered Consent Manager (or the manager your customers already use) and register it with your messaging platform — on Orbit,
POST /consent/managerswith the manager's published public key. - Wire receipt collection into your consent flows so grants arrive as signed receipts and are stored against the contact and channel (
smsfirst) from day one. - Drill the audit path: pick a stored receipt and re-verify it. A verification flow nobody has rehearsed is a control that exists on paper only.
- Handle pre-existing consent explicitly. Consent captured before your receipt flow goes live does not retroactively become signed receipts — keep your existing trail, and run a re-permission campaign where the risk warrants it.
Frequently asked questions
What is a DPDP Consent Manager?
A Consent Manager is a registered intermediary under India's Digital Personal Data Protection Act that manages consent on behalf of the individual: presenting the request, recording the grant or withdrawal, and issuing cryptographically signed receipts that businesses can independently verify and store as their proof of consent.
When does DPDP Phase II take effect for consent receipts?
13 November 2026 is the Phase II deadline that brings the Consent-Manager framework into enforcement. Businesses sending A2P SMS into India should treat that as the date by which consent for messaging should be backed by verifiable, signed consent receipts rather than self-asserted internal records.
Does using Devotel Orbit make me DPDP compliant?
No platform can make that claim. Devotel Orbit ships the verification surface — register Consent Managers, store signed receipts as verifiable consent records, and re-verify receipts during an audit. Obtaining valid consent, choosing a registered Consent Manager, collecting receipts in your flows, and deciding what your send gates require remain your responsibility as the data fiduciary.
How are Orbit consent receipts verified?
A receipt carries a digital signature over its canonicalized contents. Orbit verifies that signature against the registered manager's published public key before a receipt is stored, and can re-verify a stored receipt against the manager's current key on demand. Receipts that fail verification are refused, so an invalid artifact never silently becomes consent.
Do TRAI DLT registration and DPDP consent receipts overlap?
They complement each other. DLT registration establishes who you are and which headers and templates you send; DPDP consent receipts establish proof that the recipient consented. DLT-registered entities sending A2P SMS into India should have both in place — DLT-India onboarding covers the registration track.
What happens to consent captured before I adopt receipts?
Pre-existing consent records remain your historical trail, but they are not signed receipts. Keep them, and where exposure warrants it, run a re-permission campaign so affected contacts re-consent through a Consent Manager and generate signed receipts going forward.
The takeaway
India's DPDP Phase II deadline of 13 November 2026 converts consent for business messaging into India from an internal assertion into a verifiable artifact: signed consent receipts from a registered Consent Manager. The businesses ahead of this are the ones that treat it as plumbing, not paperwork — choose a manager, register it, collect receipts in the flows where consent actually happens, and rehearse re-verification before an audit does it for you. The shipped Devotel Orbit surface — POST /consent/managers, POST /consent/receipts, POST /consent/receipts/:id/verify, documented in Consent Management — makes the verification and storage side an API call; the rest is, rightly, yours.