> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# India DPDP Act 2023 Posture Guide

> Map India's Digital Personal Data Protection Act (DPDP) 2023 — consent, breach notice, retention, and localization — onto the consent records, signed receipts, and DSAR surfaces you configure on Orbit, alongside the TRAI DLT registration layer.

# 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.

<Note>
  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.
</Note>

***

## 1. DLT vs DPDP — two separate obligations

India-bound teams routinely conflate the two regimes. They answer
different questions:

| Regime                              | What it governs                                                                                                                           | Where it lives on Orbit                                                                                                                   |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **TRAI DLT** (telecom)              | Whether your SMS *delivers* — Principal Entity, Header, content-template, and consent-template registration enforced at the operator edge | [DLT-India Onboarding](/compliance/dlt-india)                                                                                             |
| **DPDP Act 2023** (data protection) | What you *owe the person* behind each +91 number — consent, purpose limitation, breach notice, erasure, retention                         | This page: [Consent Management](/compliance/consent-management), [DSAR](/compliance/dsar), [retention](/compliance/data-retention-policy) |

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](/compliance/country-requirements).
Filter it to India's APAC row:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms&region=APAC" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

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.

***

## 3. Consent purpose labels and Consent Managers

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):

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "+919876543210",
    "channels": ["sms"],
    "opt_in": true,
    "lawful_basis": "consent",
    "purpose": "Promotional SMS offers the recipient agreed to receive",
    "consent_text_version": "in-promo-notice-v3",
    "consent_proof_url": "https://signup.example.com/consent/evt_4d21f8"
  }'
```

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](/compliance/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](/compliance/consent-default-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](/compliance/dsar):

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](/compliance/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](/compliance/data-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](/compliance/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.

<Note>
  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](/compliance/breach-incident-register) so
  the notification record exists before a Board asks for it.
</Note>

***

## 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](/compliance/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](https://orbit.devotel.io/en/trust);
  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](/compliance/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](/compliance/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](/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.

***

## 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.

***

<Warning>
  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.
</Warning>

***

## Related references

* [DLT-India Onboarding](/compliance/dlt-india) — the TRAI telecom
  registration layer that pairs with this page's DPDP posture.
* [Consent Management](/compliance/consent-management) — the consent
  record contract and the Consent-Manager receipt endpoints.
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the
  erasure/portability surface where `dpdp` and its 30-day clock live.
* [Country Compliance Requirements](/compliance/country-requirements)
  — the per-country row contract behind `GET /compliance/country-rules`.
* [Data Residency Overview](/compliance/data-residency-overview) — the
  residency map per channel.
* [Breach incident register](/compliance/breach-incident-register) —
  recording breach-notification evidence.
* [Compliance evidence binder](/compliance/evidence-binder) — the
  quarterly review artifact.
* [API Reference → Compliance](/api-reference/endpoints/compliance) —
  full request/response schemas (regenerated from the live API).