Skip to main content

​
India DPDP Act 2023 Posture Guide

India’s Digital Personal Data Protection Act (DPDP) 2023 is the country’s omnibus data-protection law: it governs consent, breach notification, data retention, and the rights of the individual (the “data principal”) whose personal data you process. If you run SMS, voice, or any other channel to Indian recipients, DPDP sits on top of everything you send — separate from, and in addition to, the TRAI DLT telecom registration layer.
Everything below is a tenant-owned control. Orbit ships the surfaces — the consent ledger, Consent-Manager receipts, the DSAR workflow, retention settings, and the audit export — defaults-open; your organization configures them for India. DPDP compliance remains your responsibility, and Indian regulators enforce it regardless of what any toggle says. This page is documentation, not legal advice — have counsel review your consent capture language, notice text, and retention schedule.

​
1. DLT vs DPDP — two separate obligations

India-bound teams routinely conflate the two regimes. They answer different questions: A fully DLT-registered sender can still violate DPDP — the operator delivers your message because the template matches, but DPDP judges whether you had valid consent for that purpose and whether your records survive audit. Treat DLT as the transport checklist and DPDP as the accountable-processing checklist. You need both. DPDP frames every obligation around three roles: the data principal (your recipient), the data fiduciary (you, the organization deciding why and how personal data is processed), and the Consent Manager (a registered intermediary that can issue signed consent receipts on the principal’s behalf). Orbit’s surfaces map onto those roles without deciding the legal posture for you.

​
2. India’s country-rules row

Start where every per-country page starts: the same GET /compliance/country-rules endpoint that powers Country Compliance Requirements. Filter it to India’s APAC row:
Read the country_code: "IN" entry for sender_types, registration, sender_rules, and content_restrictions — these fields describe the telecom layer (DLT registration: required, Headers as the sender identity). The DPDP obligations in the sections below are channel-independent and do not appear in the country-rules row; they attach to the recipient’s data regardless of which channel carries the message.
DPDP consent must be free, specific, informed, unconditional, and unambiguous, given for a specified purpose, with a notice the principal can read (the Act requires the notice in English or any of the 22 languages of the Eighth Schedule). Two DPDP-specific mechanics land on the consent surface: Purpose limitation on the record. Stamp every Indian opt-in with the purpose the principal actually agreed to. The consent record carries purpose and lawful_basis alongside the channel — for India, the lawful basis is nearly always consent (DPDP’s fallback is a narrow “legitimate uses” list, not the broad legitimate-interest doctrine of GDPR):
Keep the notice’s purpose text narrow — “order updates and promotional offers” — so a later audit can match the sending purpose to the recorded one. When purpose changes, re-capture consent; DPDP does not let you stretch a consent across purposes it never named. Signed receipts via Consent Managers. DPDP formalizes the Consent Manager role: a registered intermediary that mints cryptographically signed consent receipts for data principals. Orbit registers the managers your users go through and verifies the receipts they issue — the full register/verify contract is on the Consent Management page:
  • POST /compliance/consent/managers — register the manager and its ECDSA P-256 public key (country_code: "IN").
  • POST /compliance/consent/receipts — store a manager-signed receipt; the signature is verified over the canonicalized payload before anything persists.
  • POST /compliance/consent/receipts/{id}/verify — re-verify a stored receipt during audits against the manager’s current key.
For contacts with no recorded consent, your tenant-owned default decides what a marketing send does: the unknown-consent policy can refuse marketing traffic until a ledger row exists — the deliberate posture for DPDP purposes, not an accident of defaults. Verify before a campaign with GET /compliance/consent/lookup?identifier=%2B919876543210&channel=sms.

​
4. Erasure, retention, and the DSAR clock

DPDP grants the principal rights to access, correction, and erasure, and obliges the fiduciary to answer through a published grievance channel. On Orbit the honouring surface is the data-subject request pipeline:
  1. File with the right jurisdiction. Set applicable_jurisdiction: "dpdp" on intake (or reclassify a generically filed request) so the SLA tracker applies DPDP’s 30-day clock from the start — the jurisdiction table on the DSAR page lists dpdp beside gdpr, ccpa, lgpd, and the rest.
  2. Erasure feeds suppression. When a delete request completes, the outcome flows into your suppression list so the erased contact does not re-enter marketing sends via a later import — see Opt-Out & Suppression.
  3. Retention is your schedule. DPDP requires erasure once the specified purpose is served, unless retention is legally required. Configure the retention policy per data class and let the policy sweep on schedule rather than waiting for individual requests.
The register of what you process and why — the thing a DPDP audit asks for first — is your privacy register, where each activity records its purpose, lawful basis, and retention window. DPDP appears there as a first-class jurisdiction exactly as it does on the DSAR surface.
DPDP also carries a breach-notification duty: the Data Protection Board and affected principals must be intimated of a personal-data breach. Track and time-stamp incidents on the breach incident register so the notification record exists before a Board asks for it.

​
5. Data localization posture

DPDP Section 16 permits cross-border transfer except to countries the central government restrict-notifies — but sectoral rules (RBI payment-data localization, telecom licence conditions) and your own contracts may impose stricter residency. “Where does India-bound data live?” has the same per-channel answer map as every jurisdiction:
  • Voice — pin the resident region directly per workspace; see Voice data residency.
  • SMS, email, WhatsApp, RCS, and the audit trail — covered by the platform geography Devotel publishes through the subprocessor registry in the Trust Center; no tenant-side region pin applies to messaging channels.
  • DSAR exports — the export artifact’s residency scope is fixed when the export is produced.
The full map is the Data Residency Overview; declare India’s residency answer in your privacy register citing the subprocessor registry entry, not a per-channel guess.

​
6. Audit-ready by construction

DPDP positions the fiduciary as the accountable party of record — the practical response is to keep evidence assembled before anyone asks. Two surfaces carry the work:
  • Consent proof of record. Export the ledger with GET /compliance/consent/export (owner/admin) — every row carries lawful_basis, purpose, consent_text_version, consent_proof_url, and grant/revoke timestamps, the columns a DPDP purpose-limitation review reads first. Covered in Consent Management.
  • The evidence binder. A quarterly consent-review ritual exports the binder instead of ad-hoc CSVs: POST /compliance/binder/generate assembles the consent records, retention settings, breach counts, and access reviews into one signed pack (PDF for the reviewer, ZIP for a GRC import), downloaded over a 24-hour signed link. Run it quarterly, store the artifact in your own records, and reference the file in your privacy register as the quarter’s review evidence. See Compliance evidence binder.
A fiduciary posture that holds up is built from defaults-open controls you deliberately configured — not from a claim the platform makes on your behalf.

​
Number purchase documents

India is a regulated number-purchase market: the Numbers wizard gates every IN order on an approved phone_number_purchase compliance profile for country_code: "IN" before the number activates. The profile is tenant-owned — you assemble the packet, submit it, and the carrier or regulator decides. An order placed while the profile is absent or still pending_review answers the same 422 as a missing profile, so file the packet before you plan the purchase, not after. The Indian packet is the shared regulated-purchase base — business identity (legal name, registration number, address, contact), the business website, and the use-case description with sub-allocation disclosure — plus three required document roles (business_doc, address_proof, id_proof) and two India-specific required structured fields: gstin, the 15-character GST registration number, and pan, the 10-character Permanent Account Number. The purchase gate reads the profile as satisfied only once both fields are present. Upload a certificate of incorporation or VAT certificate as business_doc, a utility bill, bank statement, or lease as address_proof, and a passport or national ID as id_proof; the accepted-type list and the full worked example live in Regulated Number-Purchase Packets — India. Create the profile with the complete packet:
Read the profile back with GET /compliance/compliance-profiles/{id} and wait for status: "approved" before you order, and run the regulatory preview with country=IN to confirm compliance_profile_satisfies ahead of the purchase instead of discovering the gap at checkout.
The DLT Principal Entity record’s optional pan_or_gstn (DLT-India Onboarding) does not substitute for the purchase packet’s required gstin and pan fields — the two surfaces are separate records and validate independently. The same uploaded document can back both, though: attach the same doc_… id wherever the role and country line up, per the reuse matrix in the KYC submission runbook.
Orbit prompts the fields and submits the packet; the carrier decides. This page is documentation, not legal advice.

​
Frequently asked questions

Does DLT registration satisfy DPDP? No. DLT proves the sender is registered with the operators; DPDP judges the consent, purpose limitation, and record-keeping behind every send. You need both — DLT so the message delivers, DPDP posture so delivery is lawful. Which lawful basis should India-bound sends carry? Nearly always consent. DPDP’s “legitimate uses” fallback is a narrow statutory list (state functions, emergencies, a few others), not a general-purpose marketing basis. Capture an explicit opt-in with a narrow purpose statement and stamp both on the record. Does Orbit decide my DPDP posture? No. Orbit ships defaults-open controls — the consent ledger, Consent-Manager receipts, the DSAR pipeline, retention settings — for your organization to configure. The compliance rule is the same one stated on every per-country page: tenant-owned posture, explicitly. What clock does an India data-subject request carry? 30 days — file or reclassify with applicable_jurisdiction: "dpdp" and the SLA tracker applies the statutory clock. Pair that with opt-out keywords in-market: a recipient-initiated STOP flow must work on every sender you run in India.
This page is documentation, not legal advice — an engineering map of the Orbit surfaces, not a legal opinion. DPDP carries penalties graded up to ₹250 crore per classes of breach by the Data Protection Board; have counsel review your notice language, consent capture, and retention schedule before you send to Indian recipients.