DPDP Compliance, mapped section by section.
Five built-in modules
1. Eighth Schedule notice generator Section 5 + Rule 3
Section 5(1) requires that, at or before the moment a Data Principal gives consent, the Data Fiduciary delivers an itemised notice describing the personal data, the purpose, and the means of exercising rights. Rule 3 further requires the notice to be in English or one of the languages set out in the Eighth Schedule to the Constitution of India, presented separately from any other information, and clear, plain and understandable.
Auto-generated itemised list
The SDK reads your registered purposes (analytics, marketing-email, marketing-sms, third-party-sharing, cross-border-transfer, ...) and renders the Section 5(1) items - personal data, purpose, lawful basis, and consequence of refusal - as a structured list, never a wall of prose.
Demo: GET /framework returns the requirement IDs the SDK will surface.
22 Eighth-Schedule languages
The SDK ships notice text in English plus the 22 Eighth Schedule languages (Hindi, Bengali, Marathi, Telugu, Tamil, Gujarati, Urdu, Kannada, Odia, Malayalam, Punjabi, Assamese, Maithili, Santali, Kashmiri, Nepali, Sindhi, Konkani, Dogri, Manipuri, Bodo, Sanskrit). Tenants override per-purpose copy without rebuilding the SDK.
Demo: bilingual EN + Hindi privacy notice live at /privacy.html.
2. Consent ledger Section 6 + Rule 4 hooks
Section 6(1) requires consent to be free, specific, informed, unconditional, unambiguous, given by clear affirmative action. Section 6(4) requires withdrawal to be as easy as the granting was. We capture every grant and every withdrawal with cryptographic evidence so an audit can reconstruct the Data Principal's choices to the millisecond.
Per-purpose grants, no bundling
Each Section 5 purpose is captured as a discrete consent row, not bundled. Pre-ticked checkboxes are blocked at the SDK level - we refuse to render an opt-out checkbox to keep customers Section 6(1)-compliant by construction.
Demo: POST /consent/event { purpose, status: 'granted' }
One-click withdrawal
Withdrawal uses the same SDK call with status: 'withdrawn'. The audit-log entry is tagged consent.withdraw so a regulator query can isolate Section 6(4) signals from grant noise.
Demo: GET /consent/:externalId returns active and historical state.
CM hooks, not CM ourselves
Rule 4 requires a registered Consent Manager to be Indian-incorporated with Rs 2 crore net worth - we are not registered. We expose Section 6(7) hooks so customers plug a registered Consent Manager when one is appointed, without rip-and-replace.
7-year audit ledger
Every grant, withdrawal, erasure, breach event and admin action is appended to audit_log with tenant, action, resource, IP and UA. Retention is 7 years per industry practice (DPDP itself sets no duration).
Demo: GET /tenant/audit-log
3. Erasure workflow Section 12 + Rule 13
Section 12 creates the right to correction and erasure. Rule 13 ties retention to defined retention periods, with the Third Schedule imposing specific timelines on e-commerce, social-media intermediary and online-gaming Data Fiduciaries with more than 2 crore users (which trips the SDF threshold under Section 10).
dpToken-bound submission
The Data Principal's request comes through the customer's UI. That UI mints a short-lived HMAC dpToken bound to the logged-in DP, and submits to POST /erasure/request. A stolen API key alone cannot forge a request.
Demo: POST /tenant/dp-token then POST /erasure/request
Configurable SLA + reminders
Default 7-day SLA, configurable per tenant via ERASURE_SLA_DAYS. T-72h, T-24h and T-0 reminders fire to the Customer's webhooks. Overdue requests flip status to overdue and surface in the audit report.
Demo: erasure cron runs every 60 seconds; live timer in the dashboard.
4. Breach notification (72-hour clock) Section 8(6) + Rule 7
Section 8(6) requires the Data Fiduciary to "give the Board and each affected Data Principal" intimation of a personal data breach. Rule 7 sets the 72-hour clock and the form of notification.
Automatic timer
POST /breach/incident records the incident, computes notification_due_at = detected_at + 72h, and surfaces an "overdue" flag if the deadline passes without a POST /breach/:id/notify call.
Demo: POST /breach/incident
Pre-filled Board template
Generates the Rule 7(2) content fields: nature of the breach, categories, approximate number of Data Principals, likely consequences, mitigations, single point of contact - ready to copy into the DPB submission portal.
Demo: GET /breach/:id/template
5. DPO console Section 8(9) + 10(2)(a) + Rule 14
Section 8(9) requires the Data Fiduciary to publish the contact information of a person able to answer questions about processing. Section 10(2)(a) requires Significant Data Fiduciaries to appoint an India-based DPO. Rule 14 sets the grievance officer's response time at 30 days.
Auto-published DPO card
The dashboard captures DPO name, email, phone, India address, grievance email, response days. GET /dpo/:tenantId returns the public card the SDK embeds in every notice surface.
Demo: GET /dpo/public/:tenantId
Grievance SLA timer
Grievance tickets get a 30-day clock by default. Overdue tickets flag in the audit report and trigger an SLA-breach webhook to the Customer's incident channel.
Section-by-section coverage
| DPDP source | Obligation | DPDP Bridge feature | Demo / API |
|---|---|---|---|
| Sec 4 | Lawful basis (consent or legitimate use) | Per-purpose registration with lawful-basis annotation | GET /framework |
| Sec 5(1) | Itemised notice content | Notice generator (module 1) | §1 |
| Sec 5(3) + Rule 3 | Eighth Schedule languages | 22 languages, override per purpose | EN + Hindi sample |
| Sec 6(1) | Free, specific, informed consent | No bundled consent at SDK level | POST /consent/event |
| Sec 6(3) | Plain-language requirement | SDK strips legalese; tenant copy reviewed against a readability target | SDK config |
| Sec 6(4) + (5) | Withdrawal as easy as granting | Same SDK call, status='withdrawn' | POST /consent/event |
| Sec 6(7) + Rule 4 | Consent Manager hooks | Section 6(7) plug-in points; we are NOT a CM | §2 |
| Sec 7 | Documented legitimate uses | Per-purpose lawful-basis tagging | GET /framework |
| Sec 8(1) | Accountability | Append-only audit ledger, 7-year retention | GET /tenant/audit-log |
| Sec 8(3) | Accuracy and completeness | Section 12 correction flow | POST /erasure/request |
| Sec 8(5) | Reasonable security safeguards | Schedule III TOM checklist | DPA §4 |
| Sec 8(6) + Rule 7 | 72-hour breach notification | Module 4 with auto-timer | §4 |
| Sec 8(7) | Erasure on purpose-end | Rule 13 retention timer | §3 |
| Sec 8(9) | Grievance officer publication | DPO console (module 5) | GET /dpo/public/:tenantId |
| Sec 8(10) | Contact-of-DPO disclosure | Same as 8(9) plus card embed in SDK notice | §5 |
| Sec 9(1) + Rule 10 | Verifiable parental consent | Children-mode SDK config (DigiLocker-ready) | SDK config |
| Sec 9(3) | No targeting / behavioural tracking of children | Children-mode disables marketing purposes by construction | SDK config |
| Sec 10 - SDF | SDF threshold detection | Waitlist captures Estimated DAU; system flags >2 crore users for SDF review | SDF note |
| Sec 10(2)(a) | India-based DPO | DPO config requires dpo_address_india | POST /dpo/config |
| Sec 10(2)(c) | DPIA | DPIA template (Pro plan) | Dashboard |
| Sec 11 | Right to access | Consent / audit export per DP | GET /consent/:externalId |
| Sec 12 | Right to correction and erasure | Module 3 erasure workflow | §3 |
| Sec 13 | Grievance redressal | DPO console SLA timer | §5 |
| Sec 14 | Right to nominate | Customer-managed (we don't store nominees) | Customer flow |
| Sec 16 | Cross-border transfer | Mumbai default region; restricted-country watch | DPA §6 |
| Rule 13 + Third Schedule | Retention timetable | Per-tenant retention with reminders | §3 |
| Rule 14 | 30-day grievance response | Default grievance_response_days = 30 | POST /dpo/config |
A note on Significant Data Fiduciary thresholds
Section 10(1) empowers the Central Government to designate a Data Fiduciary as a Significant Data Fiduciary (SDF) considering volume and sensitivity of personal data, risk to Data Principal rights, potential impact on the sovereignty and integrity of India, risk to electoral democracy, security of the State, and public order. The Act itself does not publish a numeric DAU threshold. The 2-crore-user trigger appears in Rule 13 and the Third Schedule for retention-rule purposes; whether the same threshold is used in a future SDF designation notification is at the Government's discretion.
DPDP Bridge therefore flags but does not auto-classify. The waitlist asks for Estimated DAU and Industry; tenants exceeding 2 crore users in e-commerce, social-media or online-gaming are surfaced for the customer's counsel to review. SDF designation, when made, is recorded in the tenant record (df_class = 'significant-data-fiduciary') and unlocks the DPIA template plus stricter DPO controls. We deliberately do not call a tenant an SDF on our own initiative — that is a regulator-only decision.
Print this page as Annex C of your dossier.
Spin up a tenant in under 5 minutes. Drop the SDK in one line. Ship audit-ready evidence by Friday.
Start 14-day Free Trial Read the DPA