The DPDP Suite — compliance you can prove
Everything the India DPDP Act 2023 asks of a Data Fiduciary, in one multi-tenant platform: capture consent, prove it with tamper-evident receipts, enforce it at processing time, and erase data for real.
The Act, section by section
This is a full implementation of the statutory obligations, not a cookie banner with a compliance label. Each obligation is backed by a verifiable record.
| Obligation | How the suite implements it |
|---|---|
| §5 Notice | Versioned, hashed notices; 22 Eighth-Schedule language coverage tracking; stale-notice gate. |
| §6 Consent | Affirmative-action capture, per-purpose selection, easy withdrawal. Each event is a tamper-evident chain link. The embed never fabricates a §6(10) receipt on reject — reject means no server capture; a non-2xx response is treated as reject. |
| §6(10) Receipts | Hash-chained consent records. Default signer is HMAC (suitable for dev and single-node). Non-repudiable signing is available via AWS KMS: set DPDP_SIGNER=kms and point it at your key. The chain is independently verifiable: fetch the tenant's published JWKS and run the neutral, offline, zero-PII verifier without trusting NoIdMe. |
| §7 Legitimate uses | Explicit lawful-basis taxonomy (consent / §7 legitimate use / §17 exemption), never collapsed to 'consent'. Forged or out-of-range §7/§17 clause codes are rejected against a closed set — the ledger will not record a basis it doesn't recognise. |
| §8(2) Processor / DPA | Click-through DPA acceptance register; NoIdMe acts as your Data Processor. FORCE RLS tenant isolation proven in-process (PGlite + non-superuser role); a fail-closed boot check refuses to start if superuser bypass is possible. |
| §9 Children | Fail-closed §9(3) gate (verified adult only), verifiable parental consent, and a pluggable age-verifier seam (reference verifier today; DigiLocker/UIDAI adapter on the roadmap). |
| §10 SDF | Significant-Data-Fiduciary state: DPO, DPIA register, vendor/processor risk register, audit. Note: data-localisation (§10(2)(c)) is a declared/recorded label — cross-border is flagged in RoPA but transfers are not blocked by the suite today. Hard-localisation enforcement is a roadmap item. |
| §11 Access / correction | Rights act only on a server-VerifiedPrincipal (OTP/passkey session) — not on a caller-supplied id. Built-in OTP providers (SMTP + HTTP/webhook): configure your SMS/email gateway via DPDP_OTP_PROVIDER and the suite routes the one-time code through it. PII-shaped identifiers are rejected before they reach the chain (looksLikePii guard), preventing DSAR-as-exfiltration and erasure-as-DoS. |
| §12 Erasure | Reversible grace window → crash-safe two-phase shred: shred the per-principal DEK first, then write the one-way §12 marker (the marker never attests an erasure that didn't complete). Sticky tombstone: the key cannot be re-minted after shred, and a later write fails closed. Lawful-denial register for §8(7) statutory holds. A runnable reference erasure-connector and DSAR fan-out how-to show how to wire erasure.executed → your own data store; the store and adapter remain the customer's responsibility. |
| §13 Grievance | Grievance redressal with an SLA clock (Rule-13 capped) and a breach-risk queue. |
| §14 Nominee | Per-principal nominee register to exercise rights on death/incapacity. |
| Rule 7 Breach | Tracks the Rule-7 clocks (without-delay / 72h / 6h) + SIEM auto-open, and generates the intimation dossier. The Board-portal submission and email/SMS delivery transport are your wiring — connecting that transport is on our roadmap. |
| Rule 8 Retention | Inactivity/retention sweeps that schedule reversible erasure with the 48h pre-erasure intimation. |
Notice content and translations are counsel/linguist-gated; the suite manages versioning, hashing and language coverage, not legal drafting.
Capture → prove → enforce
Tamper-evident ledger
Per-tenant, append-only hash chain. Every consent / withdrawal / erasure is a signed §6(10) link; break one and the chain fails verification. Reject means no server capture — the suite never fabricates a receipt.
Non-repudiation (KMS)
Sign with HMAC (dev), ECDSA P-256, or a KMS-delegated per-tenant key. The published JWKS lets a regulator or partner verify any chain offline, independently, without trusting NoIdMe.
Crash-safe crypto-shred
§12 erasure is two-phase: shred the DEK first, write the one-way marker after — the marker never attests an erasure that didn't complete. Sticky tombstone prevents silent data resurrection.
FORCE RLS tenant isolation
Postgres FORCE RLS keyed per request; a forgotten tenant scope returns zero rows. Boot check refuses to start if the process runs as a superuser that can bypass RLS — fail-closed by design.
Processing gate
Ask "may I process purpose X for principal Y now?" and get a hard allow/deny with the §6(10) proof. Rights act only on a server-VerifiedPrincipal; PII-shaped IDs are rejected before touching the chain.
Sandbox / live
test vs live data isolation via the key environment. Sandbox traffic never touches production records.
A few lines to check consent before you process
curl -X POST https://api.noidme.com/v1/consent/can-process \
-H "authorization: Bearer sk_live_…" \
-d '{"principalId":"user-123","purpose":"marketing"}'
# → { "allowed": true, "reason": "granted",
# "proof": { "seq": 42, "hash": "9f3c…" } }SaaS, self-host, or on-prem
Managed SaaS
We run it; you integrate. Usage-metered. Fastest path to compliant.
Your cloud (self-host)
Deploy into your AWS/GCP/Azure with a license. Your data never leaves your VPC (Postgres + KMS you control).
Data residency
India-first; bring your own KMS + Postgres. For SDFs, §10(2)(c) data-localisation is declared and recorded in RoPA today — hard enforcement (blocking cross-border transfers) is a roadmap item.
Get DPDP-ready, with evidence
See the suite end-to-end, or start integrating today.