# DPDPA Consent Manager Registration Resources

**Production-ready resources for building and registering a Data Protection Board-compliant Consent Manager platform.**

This resource package accompanies the article **[Consent Manager Registration Under DPDPA: Technical Requirements and Infrastructure Mandates](./article.md)** and provides actionable deliverables for platform architects, consent management SaaS providers, fintech platforms, and legal teams navigating DPDPA Section 6 and the First Schedule of the DPDP Rules 2025.

---

## 📦 What's Included

| Resource | Format | Purpose | Size |
|----------|--------|---------|------|
| **Registration Checklist** | Markdown | 9-condition pre-application audit against First Schedule Part A | 300+ lines |
| **Implementation Plan** | Markdown | 16-week phased platform build: zero-knowledge architecture, consent ledger, interoperability layer | 450+ lines |
| **Quick Reference Card** | Markdown | 1-page printable: 9 registration conditions, 13 obligations, penalty exposure | Printable |
| **API Specification** | OpenAPI 3.1 | RESTful consent platform API with fiduciary onboarding, consent routing, and DSAR endpoints | 600+ lines |
| **Database Schema** | SQL (PostgreSQL) | Immutable consent event store with 7-year retention, trigger-based integrity enforcement | 250+ lines |
| **Architecture Diagrams** | Mermaid | Zero-knowledge consent flow, E2E encryption model, multi-tenant fiduciary routing | 3 diagrams |
| **Constitutional Template** | Markdown | MoA/AoA amendment language for conflict-of-interest embedding (Part A, Item 7) | Legal template |

---

## 🎯 Who Should Register as a Consent Manager?

The DPDPA Consent Manager is a **regulated entity type** with substantial compliance obligations and penalty exposure (up to ₹50 crore). Registration makes sense for:

| Use Case | Rationale | Timeline |
|----------|-----------|----------|
| **Consent Management SaaS** | You operate a multi-tenant consent platform serving Data Fiduciaries across industries | Start now — certification lead time |
| **Account Aggregators (RBI)** | You already hold RBI-NBFC-AA license and want to expand to DPDPA consent scope beyond financial data | Natural extension |
| **Unified Consent Hub (Enterprise)** | Large group company wants a centralized consent service for subsidiaries | Reduces per-fiduciary overhead |
| **Privacy Platform Vendors** | You build consent infrastructure as a product offering | Product-market differentiation |

### When NOT to Register

- **Single Data Fiduciary** — If you only process consent for your own organization, implement Section 6 consent requirements directly. Do not register as a Consent Manager.
- **Consent Management Software** — Selling consent management software to Data Fiduciaries does **not** require CM registration. Registration is for operating the consent platform as a service.
- **Low Transaction Volume** — The ₹2 crore net worth minimum, no sub-contracting rule, and independent certification costs create a break-even point. If your volume is low, registration may not be economically viable.

---

## 📚 Resource Details

### 1. Registration Readiness Checklist

**File:** `registration/registration-checklist.md`

**What It Does:**
- Pre-application self-audit against all 9 conditions in First Schedule, Part A
- Evidence requirements for each condition
- Common failure points based on regulatory patterns (drawn from RBI account aggregator, SEBI intermediary registration precedents)
- Board submission package outline

**Key Sections:**
- **Corporate Structure** — Indian incorporation, MoA/AoA amendment for conflict-of-interest embedding (Item 7)
- **Financial Capacity** — Net worth calculation template (Item 4), business viability model (Item 5)
- **Management Integrity** — Director background check requirements (Item 6)
- **Technical Certification** — Independent auditor selection criteria (Item 9)

**Decision Tree:** Includes a "Go/No-Go" assessment framework to determine if your organization should proceed with registration.

### 2. Implementation Plan (16-Week Build)

**File:** `implementation-checklist.md`

**Structure:**
- **Phase 0: Pre-Registration Foundation** (Weeks 1-2) — Corporate setup, capitalization, MoA/AoA amendments
- **Phase 1: Zero-Knowledge Architecture** (Weeks 3-6) — E2E encryption, metadata-only routing, cryptographic integrity layer
- **Phase 2: Consent Ledger & 7-Year Retention** (Weeks 7-9) — Immutable event store, machine-readable export API, retention enforcement
- **Phase 3: Interoperability Layer** (Weeks 10-12) — Data Fiduciary onboarding, OAuth integration, standardized consent schemas
- **Phase 4: Grievance & Audit Systems** (Weeks 13-14) — Rule 14(3) grievance intake, Part B Item 12 audit dashboards
- **Phase 5: Certification & Submission** (Weeks 15-16) — Independent audit, Board application package, control transfer governance

**Tracks:**
- **Greenfield Build** — Starting from zero
- **Account Aggregator Extension** — Already hold RBI-NBFC-AA license, extending to DPDPA scope
- **Platform Reuse** — Adapting existing consent management SaaS to DPDPA compliance

**Deliverables Matrix:** Maps each phase to technical artifacts (APIs, schemas, Terraform configs) and governance deliverables (policies, audit reports, Board submission documents).

### 3. Quick Reference Card

**File:** `quick-reference-card.md`

**Contents:**
- **9 Registration Conditions** (Part A) — Checklist with pass/fail criteria
- **13 Ongoing Obligations** (Part B) — Operational compliance requirements post-registration
- **Penalty Exposure** — Section 27(1)(c)-(d), Schedule Item 7 (₹50 crore max)
- **Critical Timelines** — Rule 4 in force 13 Nov 2026 (Rule 1(3)), grievance response within a published period not exceeding 90 days (Rule 14(3), from 13 May 2027), 7-year record retention (Part B Item 4c)
- **Technical Constraints** — Zero-knowledge (Part B Item 2), no sub-contracting (Part B Item 6), fiduciary capacity (Part B Item 8)
- **Common Pitfalls** — Sub-contracting cloud operations, payload access logging, conflict-of-interest blind spots

**Format:** Print-ready 2-page reference. Suitable for lamination and desk placement.

### 4. API Specification

**File:** `api-spec/consent-manager-api.yaml`

**OpenAPI 3.1 Specification**

**Endpoints:**
- **Fiduciary Onboarding:**
  - `POST /fiduciaries` — Register Data Fiduciary on platform
  - `GET /fiduciaries/{id}` — Retrieve fiduciary metadata
  - `PATCH /fiduciaries/{id}/status` — Activate/suspend fiduciary
- **Consent Routing:**
  - `POST /consent/grant` — Data Principal grants consent (metadata-only, encrypted token forwarding)
  - `POST /consent/withdraw` — Withdraw consent for a purpose
  - `GET /consent/{principal_id}` — Query consent status (Data Principal access per Part B Item 4a)
- **Data Sharing:**
  - `POST /data-share` — Route encrypted personal data (zero-knowledge, payload hash only)
  - `GET /data-share/{principal_id}/audit` — Export sharing history
- **DSAR (Data Principal Rights):**
  - `GET /export/{principal_id}` — Machine-readable consent record export (Part B Item 4b)
  - `DELETE /principal/{id}` — Right to erasure (after 7-year retention ends)
- **Grievance (Section 13):**
  - `POST /grievances` — Submit grievance
  - `GET /grievances/{id}` — Track grievance status

**Security:**
- OAuth 2.0 for fiduciary authentication
- TLS 1.3 only (per DPDPA encryption requirements)
- API rate limiting and DDoS protection
- Request signing for non-repudiation

**Machine-Readable Export Schema:** Implements the YAML example from [article.md:283-308](./article.md#L283-L308) as a JSON export format.

### 5. Database Schema

**File:** `database/consent-ledger-schema.sql`

**PostgreSQL Implementation**

**Tables:**
- `consent_events` — Immutable append-only ledger (implements [article.md:374-420](./article.md#L374-L420))
  - Trigger-based UPDATE/DELETE prevention
  - 7-year retention policy enforcement
  - SHA-256 integrity hashing for audit
- `fiduciary_registry` — Onboarded Data Fiduciaries with status tracking
- `consent_notices` — Archived consent request notices (Part B Item 3b)
- `grievances` — Section 13 grievance intake and tracking
- `audit_log` — Part B Item 12 compliance monitoring events

**Features:**
- **Immutability:** `prevent_consent_modification()` trigger raises exception on UPDATE/DELETE
- **Partitioning:** Year-based partitioning for efficient 7-year retention management
- **Indexes:** Optimized for Data Principal record access (Part B Item 4a) and export queries
- **Retention:** Automated purge policy for records >7 years (configurable extension for "as required by law")

**Migration Scripts:** Included for both fresh deployment and account aggregator schema extension.

### 6. Architecture Diagrams

**Files:**
- `architecture/zero-knowledge-flow.mmd` — Mermaid sequence diagram showing E2E encryption between Data Principal and Data Fiduciary, with Consent Manager handling metadata only
- `architecture/multi-tenant-routing.mmd` — Platform architecture for multi-fiduciary consent routing
- `architecture/data-flow.mmd` — LINDDUN privacy threat model overlay on consent platform data flows

**Use Cases:**
- Board submission package (demonstrate interoperability architecture)
- Independent auditor briefing (Part A Item 9 certification)
- Technical due diligence for investors

### 7. Constitutional Amendment Template

**File:** `registration/moa-aoa-amendment-template.md`

**Legal Template for Part A, Item 7**

Provides draft language for embedding conflict-of-interest provisions (Part B Items 9-10) into Memorandum of Association and Articles of Association, with Board approval lock-in.

**Includes:**
- Main Objects clause addition for Consent Manager operations
- Article restricting director/KMP shareholding in Data Fiduciaries
- Article requiring Board approval for amendment of conflict-of-interest provisions
- Resolution template for Board of Directors approval
- Registrar of Companies (RoC) submission checklist

**Note:** This is a technical template. Engage counsel for finalization and RoC filing.

---

## 🏗️ Implementation Approach

### Zero-Knowledge Architecture (Critical Constraint)

**Part B, Item 2** is the defining technical requirement: the Consent Manager **must not** be able to read personal data it routes.

**Implementation Pattern:**
```
Data Principal (encrypts with Fiduciary's public key)
  → Consent Manager (stores payload_hash, routes encrypted blob)
    → Data Fiduciary (decrypts with private key)
```

**What the CM Records:**
- `principal_id` (pseudonymised)
- `fiduciary_id`
- `purpose_id`
- `event_type` (GRANT/DENY/WITHDRAW/SHARE)
- `payload_hash` (SHA-256 of encrypted blob)
- `timestamp`

**What the CM NEVER Sees:**
- Aadhaar number
- PAN
- Financial data
- Health records
- Any personal data payload

### Immutable Consent Ledger (Compliance Core)

**Part B, Items 3 & 4** require append-only record-keeping for 7 years with machine-readable export.

**Technology Options:**
| Technology | Suitability | Notes |
|------------|-------------|-------|
| **PostgreSQL + Triggers** | ✅ Recommended | Our reference implementation; trigger prevents UPDATE/DELETE |
| **Amazon QLDB** | ✅ Good fit | Managed ledger DB with cryptographic verification |
| **Apache Kafka** | ⚠️ Possible | Requires log compaction disabling + retention tuning |
| **Blockchain** | ❌ Overkill | Adds complexity without regulatory benefit |

**Export Format:** JSON per the schema in `api-spec/` (implements [article.md:283-308](./article.md#L283-L308)).

### Interoperability Layer (Certification Dependency)

**Part A, Item 9** requires independent certification that the platform is "consistent with such data protection standards and assurance framework as may be published by the Board."

**Current Status (October 2026):** The Board has **not yet published** these standards.

**Recommendation:** Build to established standards now:
- **ISO 27001:2022** — Baseline security controls
- **OAuth 2.0 / OpenID Connect** — Authentication/authorization
- **OpenAPI 3.1** — API standardization for fiduciary integration
- **JSON Schema** — Consent record format

When the Board publishes standards, you'll adapt from a compliant baseline rather than starting from scratch.

---

## ⚠️ Compliance Gotchas

### 1. No Sub-Contracting (Part B, Item 6)

**You cannot outsource:**
- Consent routing logic
- Data Principal support
- Grievance redressal
- Consent record custody

**You CAN use:**
- Cloud infrastructure (AWS, Azure, GCP) as IaaS
- Email/SMS vendors for notifications (transactional only)
- Security tools (SIEM, WAF) operated by your team

**Test:** If a third party makes decisions or has custodial access to consent records, it's likely prohibited sub-contracting.

### 2. Conflict of Interest Structural Lock-In (Part A, Item 7)

**Your MoA/AoA must:**
- Embed the conflict-of-interest provisions from Part B, Items 9-10
- Require Board approval to amend these provisions

**This means:**
- Avoid conflicts of interest with Data Fiduciaries, including in respect of their promoters and KMP (Item 9)
- Have measures so that no conflict arises from directors/KMP/senior management holding a directorship, financial interest, employment or beneficial ownership in Data Fiduciaries, or having a material pecuniary relationship with them (Item 10)
- The 2% figure in the Rules is a disclosure threshold (Item 11(b)-(c)), not a safe harbour

**Post-Registration:** Breaching these provisions can be a breach of a registration condition (Part A, Item 7) → Section 27(1)(d) inquiry → penalty up to ₹50 crore (Schedule, Item 7; Section 33 applies from 13 May 2027).

### 3. Fiduciary Capacity (Part B, Item 8)

**The Consent Manager's duty of care runs to the Data Principal**, not the Data Fiduciary.

**Practical Impact:**
- When Data Fiduciary interests conflict with Data Principal interests, **prioritize the Data Principal**
- Your revenue model cannot create incentives to deny consent withdrawals or obfuscate DSAR fulfillment
- Board audits will examine whether your commercial arrangements (e.g., transaction fees from fiduciaries) compromise Data Principal interests

### 4. Grievance Timeline (Section 13 + Rule 14(3))

Section 13(1) gives Data Principals the right to readily available grievance redressal from a Consent Manager, so the system should be live at registration. Rule 14(3) (from 13 May 2027) requires you to publish the period within which you respond, **not exceeding 90 days**, and to put technical and organisational measures in place to meet it.

**Requirements:**
- Publicly accessible intake (web form + API)
- Acknowledgement workflow
- Tracking/status updates for Data Principals
- Audit trail for Board inspection

**Penalty Risk:** No grievance mechanism, or responses outside the published period, breaches Section 13 read with Rule 14(3) → Schedule Item 7 → ₹50 crore max.

---

## 📊 Timeline & Effort Estimates

### Registration Preparation

| Activity | Duration | Owner | Deliverable |
|----------|----------|-------|-------------|
| Corporate incorporation (India) | 2-4 weeks | Legal | Certificate of Incorporation |
| Capitalization (₹2 crore minimum) | Concurrent | Finance | Audited financials |
| MoA/AoA amendment (conflict provisions) | 3-4 weeks | Legal | RoC filing confirmation |
| Director background checks | 2-3 weeks | Compliance | Clean records declaration |
| Business viability model | 2 weeks | Strategy | Revenue projections, cap table |

**Total:** 8-12 weeks

### Platform Build (Greenfield)

| Phase | Duration | Team Size | Key Deliverables |
|-------|----------|-----------|------------------|
| Zero-knowledge architecture | 4 weeks | 3 engineers | E2E encryption, metadata routing |
| Consent ledger | 3 weeks | 2 engineers | PostgreSQL schema, triggers, 7-year retention |
| Interoperability API | 3 weeks | 3 engineers | OpenAPI spec implementation, OAuth |
| Grievance system | 2 weeks | 2 engineers | Intake form, tracking workflow |
| Audit dashboards | 2 weeks | 2 engineers | Part B Item 12 compliance monitoring |
| Independent audit prep | 2 weeks | 1 compliance lead | Evidence packages, control documentation |

**Total:** 16 weeks

### Independent Certification (Part A, Item 9)

| Activity | Duration | Cost (Estimate) | Outcome |
|----------|----------|-----------------|---------|
| Auditor selection (ISO 27001 or equivalent) | 2 weeks | — | Engagement letter |
| Platform assessment | 3-4 weeks | ₹15-25 lakh | Gap report |
| Remediation | Variable | — | Audit-ready state |
| Certification issuance | 1-2 weeks | — | Certificate for Board submission |

**Total:** 8-12 weeks (assumes minimal remediation)

---

## 🚀 Quick Start Paths

### Path 1: Greenfield Consent Manager

**You are:** Building a consent platform from scratch.

**Start Here:**
1. Read the [Implementation Checklist](./implementation-checklist.md) → Phase 0
2. Use the [Registration Checklist](./registration/registration-checklist.md) to confirm eligibility
3. Review [Database Schema](./database/consent-ledger-schema.sql) for data model understanding
4. Study [API Specification](./api-spec/consent-manager-api.yaml) for interoperability design

**Critical Path:** Corporate setup → Platform build → Independent certification → Board application

**Timeline:** 6-9 months (registration + build + certification)

### Path 2: Account Aggregator Extension

**You are:** Already hold RBI-NBFC-AA license and want to extend to DPDPA scope.

**Start Here:**
1. Map existing AA infrastructure to DPDPA requirements (see [Quick Reference Card](./quick-reference-card.md))
2. Identify gaps: zero-knowledge applies to financial data (AA) but DPDPA scope is broader
3. Review conflict-of-interest provisions — AA regulations may already satisfy Part B Items 9-10
4. Extend consent record schema for non-financial purposes

**Advantages:** Corporate structure, capitalization, grievance system likely already compliant. Focus on technical extensions.

**Timeline:** 3-4 months (incremental build + Board application)

### Path 3: Platform Vendor Evaluating Registration

**You are:** Consent management SaaS provider assessing whether to register.

**Start Here:**
1. Complete the "Go/No-Go" decision tree in [Registration Checklist](./registration/registration-checklist.md)
2. Model the economics: ₹2 crore minimum net worth + no sub-contracting = higher operational overhead than SaaS model
3. Consider alternative: operate as **software vendor** to Data Fiduciaries who implement Section 6 directly (no registration required)

**Decision Point:** If transaction volume justifies captive infrastructure, register. If serving long-tail customers with lower volumes, software licensing may be more viable.

---

## 🔗 Related Resources

This package integrates with other DPDPA compliance resources:

- **[DPDPA-ISO 27001 Mapping](../dpdpa-iso-27001-mapping/)** — Control framework for security safeguards (Part B Item 7)
- **[Encryption Requirements](../dpdpa-encryption-requirements/)** — TLS 1.3 configs for API endpoints, database encryption for consent ledger
- **[CI/CD Privacy Gates](../dpdpa-cicd-privacy/)** — Pipeline integration for continuous compliance (Part B Item 12)
- **[Breach Notification](../dpdpa-breach-notification/)** — Incident response for consent platform breaches (Section 8(6) + Part B Item 7)

---

## 📞 Support

**Questions on Consent Manager registration?** StateCheck Security provides:
- Registration readiness assessments (9-condition audit against First Schedule Part A)
- Platform architecture reviews (zero-knowledge validation, interoperability certification prep)
- Board submission package preparation

**[Request a DPDPA Consent Manager Consultation](https://statechecksecurity.com/consent-manager-audit)**

---

## ⚖️ Legal Disclaimer

These resources are technical guidance for engineering and compliance teams. They do not constitute legal advice. Engage qualified Indian legal counsel for:
- MoA/AoA amendments and RoC filings
- Board application strategy
- Conflict-of-interest governance design
- Regulatory interpretations

The Data Protection Board's standards and assurance framework referenced in Part A, Item 9 have not been published as of October 2026. Requirements may change when these standards are released.

---

## Legal review notes

Citations re-checked on 2026-10-17 against the notified DPDP Rules 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)) and the India Code text of the Act. `check.mjs` reports 0 violations on every `.md` in this package. Points for a human legal reviewer:

- **Is a Consent Manager a Data Fiduciary for its own users' data? Resolved and accepted (owner sign-off by StateCheck, 2026-10-17; not an external counsel review).** Yes, for its users' account and contact data (S.2(i)). The package now says S.8 duties, including S.8(6) and Rule 7, apply to that data, while S.6(8) agency covers consent artefacts.
- **Part B, Item 9 wording: resolved 2026-10-17.** "Their" refers to the Data Fiduciaries (the nearest plural antecedent); Item 10 separately covers the Consent Manager's own directors, KMP and senior management. The article, which had said "its promoters", and the MoA FAQ are corrected.
- **MoA/AoA template 2% cap: resolved and accepted (owner sign-off by StateCheck, 2026-10-17; not an external counsel review).** Removed. The MoA clause and AoA Article [Z.3] now mirror Part B, Item 10: no size threshold, every holding disclosed (Article [Z.5]) and assessed, and any conflicting holding prohibited. 2% stays only as the Item 11 disclosure threshold. The Companies Act points remain for corporate counsel.
- **Commencement:** Rule 4 and S.6(9) apply from 13 Nov 2026, but S.27(1)(c) and S.33 (penalties) apply from 13 May 2027 (India Code footnote; check G.S.R. 843(E)). The articles state this split.
- **"As of October 2026" status of the Board's Part A, Item 9 standards** re-verified on 2026-10-17 against secondary sources: still not published.
- **Companies Act references** in `registration/` (Section 14, Form MGT-14 timing, "void ab initio" lock-in) are outside this citation audit and were not checked.
- **OG image** `image/dpdpa-consent-manager-registration-1.png` carries the label "DPDPA 2023 · First Schedule · Rule 4"; the First Schedule belongs to the Rules, not the Act. `image-prompt.md` is corrected; the PNG needs regenerating.