Quick answer: From 13 November 2026, Phase II of India's Digital Personal Data Protection Act (DPDP) moves the Consent-Manager framework into enforcement. For a business sending A2P SMS into India on the basis of consent, the practical consequence is that consent is expected to arrive as a cryptographically signed receipt issued by a registered Consent Manager — verifiable on demand, attributable, and revocable — not as a flag in your own CRM asserting a user once ticked a box. Devotel Orbit already ships the platform side of that flow: register the Consent Managers your users consent through, submit the signed receipts those managers mint, and re-verify any stored receipt on demand. The selection and collection side stays with you, where the Act puts it.
Updated 2026-09-04: this post consolidates the two earlier 2026-09-02 explainer posts on the same deadline — one canonical anchor replaces three overlapping pages. The removed URLs redirect here.
What Phase II makes mandatory on 13 November 2026
India's DPDP Act was notified in 2023 with a phased rollout; 13 November 2026 is the date the Consent-Manager chapter stops being architecture and becomes operational mandate. The Act frames the individual (the data principal) as the owner of their personal data and the business processing it (the data fiduciary) as accountable for the lawful basis. Consent under the Act has to be specific, informed, unconditional, and unambiguous — and, critically for messaging, as easy to withdraw as it was to give. The penalty scale reaches INR 250 crore for violations, and under the Act the data fiduciary — the sending business — remains responsible for proving consent. Nobody's DLT onboarding, operator chain, or platform relationship transfers that responsibility.
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 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.
This lands on top of an existing regime. India already runs A2P SMS through TRAI's DLT registration: the sender's Principal Entity, every sender header, and every content template are registered artifacts, and consent templates were part of that registration already. Phase II raises the consent template into a live receipt flow: DLT registration proves the sender exists and the template was approved; the DPDP receipt proves the recipient agreed. The two regimes stack — neither one covers the other.
How the Consent-Manager model works, in business terms
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 P-256 curve, against the receipt's canonical contents): anyone holding the manager's published public key can check the receipt is genuine and untampered, without calling the manager. The same mechanism signs withdrawals — an unsigned "the user unsubscribed" from the sender stops carrying weight.
- 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 — re-checkable at audit time, including in legal or regulatory discovery, with no live dependency on the issuer's uptime. The business-language summary: the Consent Manager is a licensed notary for consent, and the signed receipt is the notarized record. Everyday consent capture keeps working the way it already does on your own surfaces; the DPDP flow is the India-facing evidence layer on top.
What a signed consent receipt is — and what it is not
A consent receipt is a signed statement, issued by a registered Consent Manager, of what a data principal agreed to — purpose, scope of permitted processing, issue time, identifiers of the parties — plus an ECDSA P-256 signature over the receipt's canonical form. Canonicalization (a sorted-key, whitespace-normalized JSON form modelled on JCS/RFC 8785) makes receipts comparable: rewrite one purpose string and the signature stops verifying, so the stored artifact is byte-stable regardless of intermediate serializers.
Two boundaries keep the term honest:
- A signed receipt is verifiable evidence the sender can store and re-verify on demand — proof, not a pointer into the sender's own logs.
- A signed receipt is not the legal basis itself. The receipt is the evidence; the per-contact consent records and your own send-gate policy still define who you may actually message. Storing receipts does not make a sender compliant — obtaining valid consent, choosing lawful purposes, and gating sends on them remain the data fiduciary's obligations under the Act.
What Devotel Orbit ships for this — and what remains yours
Devotel Orbit ships the India DPDP Consent-Manager surface under the consent API, rooted at POST /api/v1/compliance/consent/...:
- Register the managers you work with — store the manager's identity, endpoint, and published public key (ECDSA P-256, SPKI PEM) so every receipt it issues can be verified:
POST /consent/managers(admin/owner scoped).GETlists registered managers;PUTupdates or deactivates one. - Store a signed receipt as consent — submit a manager-signed receipt and the platform verifies the signature against the registered manager's key before anything is persisted as a consent record for the contact and channel:
POST /consent/receipts. A bad signature or an unregistered or inactive manager is rejected withCONSENT_RECEIPT_INVALID— refuse at the boundary rather than persist an artifact that falls apart during an audit. - Re-verify a stored receipt on demand — during an audit, confirm a receipt still validates against the manager's current key (and that the manager is still active):
POST /consent/receipts/:id/verify.
The full request and response shapes, the canonicalization rules your Consent Manager must sign against, and the manager lifecycle are in the Consent Management docs. The DLT side of the same story — entity and template registration, the scrub that runs against them — is the DLT-India onboarding 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 gate India-bound sends on receipts, it does not require that your messaging flow uses them, 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 same split as every other Orbit compliance surface. The platform is the verifiable system of record; the compliance posture is yours.
Who must act
Three populations should treat 13 November 2026 as their deadline:
- A2P senders into India relying on consent — any business messaging Indian numbers where consent is the stated lawful basis, which is most A2P marketing, re-engagement, and re-permission traffic. Pure transactional flows (order confirmations, OTPs) ride on a different basis and are outside the Consent-Manager mandate; the mandate binds when consent is what you claimed.
- 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 track.
- Platforms and aggregators operating sender accounts — if you collect consent on behalf of businesses sending into India, your stored artifacts are what gets audited. On 13 November, "consent flag in the CRM" stops carrying weight as an audit artifact.
The 30/60/90-day pre-deadline checklist
A practical sequence into November — the surface is small enough that most senders finish the platform side well inside a sprint:
- 30 days out — inventory and pick. Confirm your DLT posture (Principal Entity, headers, and content/consent templates current). Identify which of those templates say consent is the lawful basis — if that set is non-empty, Phase II applies to you. Then pick 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. - 60 days out — wire capture into consent flows. Where a Consent Manager issues a signed receipt, deposit it into
POST /consent/receiptsas it is minted — the signature is verified at intake, so only verifiable receipts enter the ledger. Prove the pipeline now; the morning of 13 November is the wrong time to exercise it for the first time. - 90 days out — rehearse the audit path and handle pre-existing consent. Receipts sit next to ordinary consent records, so your existing consent export and history reads cover them; re-verify stored receipts on schedule via
POST /consent/receipts/:id/verify. Consent captured before your receipt flow went live does not retroactively become signed receipts — keep your existing trail, and run a re-permission campaign where exposure warrants it. And if you are not yet DLT-registered, schedule that separately; Phase II presupposes DLT, it does not replace it.
Frequently asked questions
Which senders are affected by Phase II?
Senders into India whose lawful basis for a send is consent — most A2P marketing, re-engagement, and re-permission traffic terminating on Indian numbers, plus the DLT-registered Principal Entities behind them. Pure transactional flows (order confirmations, OTPs) ride on a different basis and are outside the Consent-Manager mandate; the mandate binds where consent is what you claimed.
Is a DPDP Consent Manager the same as existing DL CPP or wallet equivalents?
No. India's account-aggregator and wallet ecosystems (including DL CPP and wallet-style consent proxies) are aggregation utilities for data access, not registered intermediaries under the DPDP's own Consent-Manager definition. A Consent Manager is registered with and accountable to the Data Protection Board of India for presenting the consent request, recording the grant or withdrawal, and issuing the signed receipt. Aggregation infrastructure can complement that flow; it is not a substitute for registering with the manager your users actually consent through.
What is the post-deadline enforcement posture?
The practical reading: from 13 November 2026, consent-based sends into India are expected to be backed by signed receipts when a regulator, a Data Protection Board inquiry, or a DLT scrub asks. Devotel Orbit's role stays constant on both sides of the date — the Consent-Manager surface remains an optional, tenant-owned capability; Orbit does not gate outbound on a receipt check, and DLT registration is enforced by the Indian operators at the network layer, not by the platform. What enforcement posture applies to a specific traffic profile is determined by your DLT template classifications and your stated lawful basis, and failing to hold valid consent carries a penalty scale up to INR 250 crore under the Act.
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 treat it as plumbing, not paperwork — pick a manager, register it, collect receipts 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 — makes the verification and storage side an API call; the rest is, rightly, yours.