# DPDPA Consent Manager Implementation Checklist

**16-week phased platform build and registration roadmap for DPDPA Section 6 and First Schedule compliance.**

---

## Pre-Assessment Questionnaire

**Complete this assessment to determine your starting point and implementation track.**

| Question | Your Answer | Track Recommendation |
|----------|-------------|---------------------|
| 1. Is your company incorporated in India? | ☐ Yes ☐ No | **No = BLOCKER**. Foreign entities must establish Indian subsidiary first. |
| 2. Does your company have a net worth of at least ₹2 crore? | ☐ Yes ☐ No | **No = BLOCKER**. Capitalization required per Part A, Item 4. |
| 3. Do you currently hold RBI-NBFC-AA (Account Aggregator) license? | ☐ Yes ☐ No | **Yes = Accelerated Track**. Use Path 2 in README.md. |
| 4. Do any directors/KMP/senior management hold a directorship, financial interest, employment or beneficial ownership in Data Fiduciaries, or have a material pecuniary relationship with them? | ☐ Yes ☐ No | **Yes = Governance Risk**. Put conflict-of-interest measures in place before registration (Part B, Items 9-10). |
| 5. Do you currently operate a consent management platform? | ☐ Yes ☐ No | **Yes = Adaptation Track**. Focus on gaps (zero-knowledge, 7-year retention). |
| 6. Have you identified an independent auditor for Part A, Item 9 certification? | ☐ Yes ☐ No | **No = Begin sourcing now**. 3-4 week lead time for engagement. |
| 7. Can you build the platform in-house (no sub-contracting)? | ☐ Yes ☐ No | **No = BLOCKER**. Part B, Item 6 prohibits sub-contracting. |
| 8. Does your business model serve Data Principals' interests? | ☐ Yes ☐ No | **No = Re-evaluate**. Part A, Item 8 + Part B, Item 8 require fiduciary capacity. |

**Scoring:**
- **0-1 Blockers:** Proceed with registration preparation
- **2+ Blockers:** Address foundational issues before continuing
- **Accelerated Track:** If Q3 = Yes, reduce timeline to 12 weeks (skip Phase 2 consent ledger if AA infrastructure reusable)

---

## Phase 0: Foundation & Pre-Registration (Weeks 1-2)

**Objective:** Establish corporate prerequisites and confirm registration eligibility.

### Week 1: Corporate Structure & Capitalization

**Deliverables:**

- [ ] **Indian Incorporation Confirmation** (Part A, Item 1)
  - Certificate of Incorporation under Companies Act, 2013
  - If foreign entity: subsidiary incorporation complete with local directors
  - _Evidence for Board:_ Certificate + RoC company profile

- [ ] **Net Worth Verification** (Part A, Item 4)
  - Audited balance sheet showing net worth ≥ ₹2 crore
  - Net worth calculation: `Total Assets - Total Liabilities` per books of accounts
  - _Evidence for Board:_ CA-certified statement of net worth

- [ ] **Management Background Checks** (Part A, Item 6)
  - Police verification certificates for all directors and KMPs
  - CIBIL/credit check for key personnel
  - Regulatory sanctions search (SEBI, RBI, MCA databases)
  - _Evidence for Board:_ Background verification report + declarations

**Tools & Resources:**
- MCA21 portal for incorporation/RoC filings
- CIBIL/Experian for credit checks
- Third-party verification agencies for background checks

**Exit Criteria:** All Part A Items 1, 4, 6 evidence packages ready.

---

### Week 2: Governance & Constitutional Amendments

**Deliverables:**

- [ ] **MoA/AoA Amendment Drafting** (Part A, Item 7)
  - Add "Consent Manager operations" to Main Objects clause
  - Embed conflict-of-interest provisions (Part B, Items 9-10):
    - Avoid conflict of interest with Data Fiduciaries, including their promoters and KMP (Item 9)
    - 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)
  - Lock-in clause: "These provisions may be amended only with prior approval of the Data Protection Board"
  - _Template:_ `registration/moa-aoa-amendment-template.md`

- [ ] **Board of Directors Resolution**
  - Approve MoA/AoA amendments
  - Authorize Consent Manager registration application
  - Appoint Compliance Officer for Board liaison

- [ ] **RoC Filing (Form MGT-14)**
  - Submit amended MoA/AoA to Registrar of Companies
  - Obtain updated Certificate of Incorporation reflecting amendments
  - _Timeline:_ 2-3 weeks for RoC processing

- [ ] **Business Viability Model** (Part A, Item 5)
  - Revenue projections for 3 years
  - Customer pipeline (Data Fiduciaries committed to onboarding)
  - Capitalization plan and burn rate analysis
  - _Evidence for Board:_ Financial model + cap table

**Stakeholders:** Legal counsel, Board of Directors, CFO, Company Secretary

**Exit Criteria:** MoA/AoA amendments filed with RoC; business viability model approved by Board.

---

## Phase 1: Zero-Knowledge Architecture (Weeks 3-6)

**Objective:** Build end-to-end encryption infrastructure ensuring the Consent Manager cannot read personal data (Part B, Item 2).

### Week 3: Cryptographic Design

**Deliverables:**

- [ ] **E2E Encryption Architecture Document**
  - Key management: Data Principals and Data Fiduciaries hold private keys; CM never has access
  - Encryption protocol: TLS 1.3 for transport + application-layer E2E (NaCl/libsodium or PGP)
  - Metadata routing: CM processes `principal_id`, `fiduciary_id`, `purpose_id`, `payload_hash` only
  - _Reference:_ [article.md:160-219](../article.md#L160-L219) for architectural pattern

- [ ] **Threat Model (LINDDUN)**
  - Linkability: Minimize metadata correlation across fiduciaries
  - Detectability: Encrypt consent store at rest (AES-256-GCM)
  - Disclosure: Payload never decrypted by CM
  - _Output:_ Threat model document + mitigation mapping

- [ ] **Key Management Strategy**
  - Data Principal: Keys generated client-side (browser/mobile app)
  - Data Fiduciary: Public keys registered at onboarding
  - CM: Zero-knowledge — stores public keys only, never private keys
  - _Implementation:_ AWS KMS / Azure Key Vault for CM's own operational keys (database encryption, API signing) — NOT for Data Principal/Fiduciary keys

**Tools:**
- libsodium (NaCl) for sealed box encryption
- OpenSSL for TLS 1.3
- HashiCorp Vault for CM operational secrets (not DP/DF keys)

**Exit Criteria:** Cryptographic design peer-reviewed; threat model validated.

---

### Weeks 4-6: Zero-Knowledge Routing Implementation

**Deliverables:**

- [ ] **Consent Routing Service** (Code)
  ```python
  # ConsentManagerRouter class per article.md:161-219
  # Methods:
  #   - route_consent_grant(principal_id, fiduciary_id, purpose_id, encrypted_token)
  #   - route_consent_withdraw(principal_id, fiduciary_id, purpose_id)
  #   - route_data_share(principal_id, source_fid, target_fid, encrypted_payload)
  ```
  - CM records SHA-256 hash of encrypted payload, not the payload itself
  - Forward encrypted token to Data Fiduciary without decryption
  - _Test:_ Unit tests confirming CM code never calls decrypt() on personal data

- [ ] **Payload Integrity Verification**
  - SHA-256 hashing for audit trail
  - HMAC signing for non-repudiation (CM signs metadata, not payload)
  - _Compliance:_ Part B, Item 3 (record-keeping) + Part B, Item 2 (zero-knowledge)

- [ ] **Logging & Audit Controls**
  - Log: `principal_id`, `fiduciary_id`, `action`, `timestamp`, `payload_hash`
  - **Never log:** decrypted personal data, encryption keys, plaintext PII
  - _Validation:_ Log analysis to confirm zero personal data exposure

- [ ] **TLS 1.3 Enforcement**
  - All API endpoints require TLS 1.3 minimum
  - Cipher suites: `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`
  - _Config:_ Use NGINX/HAProxy templates from `../dpdpa-encryption-requirements/tls-configs/`

**Validation:**
- **Penetration Test:** Engage third party to attempt payload extraction from CM infrastructure
- **Code Review:** Independent review confirms no decrypt() calls on Data Principal/Fiduciary data

**Exit Criteria:** Zero-knowledge routing live in staging; penetration test report confirms no data leakage.

---

## Phase 2: Consent Ledger & 7-Year Retention (Weeks 7-9)

**Objective:** Build immutable consent event store with Part B Items 3, 4 compliance.

### Week 7: Database Schema Implementation

**Deliverables:**

- [ ] **PostgreSQL Consent Ledger Deployment**
  - Schema: `database/consent-ledger-schema.sql`
  - Tables: `consent_events`, `fiduciary_registry`, `consent_notices`, `grievances`, `audit_log`
  - Triggers: `prevent_consent_modification()` — raises exception on UPDATE/DELETE
  - _Compliance:_ Part B, Item 4(c) (7-year immutability)

- [ ] **Partitioning Strategy**
  - Partition `consent_events` by year for retention management
  - Automated purge for records >7 years (unless extended by law or agreement)
  - _Tool:_ PostgreSQL native partitioning or pg_partman extension

- [ ] **Backup & Recovery**
  - Daily encrypted backups (pgBackRest or AWS RDS automated backups)
  - Backup retention: 7 years (matches ledger retention)
  - _Test:_ Restore drill to validate 7-year recovery capability

**Database Configuration:**
- Encryption at rest: AES-256 (AWS RDS encryption, Azure TDE, or PostgreSQL pgcrypto)
- Replication: Multi-AZ for high availability
- Access controls: Least-privilege IAM roles (CM application service account only)

**Exit Criteria:** Schema deployed to staging; trigger tests confirm immutability; backup/restore validated.

---

### Weeks 8-9: Record-Keeping & Export Compliance

**Deliverables:**

- [ ] **Consent Record Persistence** (Part B, Item 3)
  - (a) Record all consent grants, denials, withdrawals with timestamp
  - (b) Archive consent notices served (store SHA-256 hash + full notice text)
  - (c) Log all data-sharing events with source/target fiduciary IDs
  - _Validation:_ Audit query confirming 100% event coverage

- [ ] **Machine-Readable Export API** (Part B, Item 4(b))
  - Endpoint: `GET /export/{principal_id}` per `api-spec/consent-manager-api.yaml`
  - Format: JSON per schema in [article.md:238-263](../article.md#L238-L263)
  - Fields: `type`, `fiduciary_id`, `purpose`, `timestamp`, `notice_reference`, `payload_hash`
  - _Test:_ Export for sample principal_id; validate JSON schema compliance

- [ ] **Data Principal Platform Access** (Part B, Item 4(a))
  - Web UI: Consent history dashboard
  - Mobile app: Optional (if Part B, Item 5 implemented as app vs. website)
  - Authentication: Multi-factor (Aadhaar OTP + PIN, or equivalent)
  - _Compliance:_ 7-year queryability requirement

- [ ] **Retention Policy Automation**
  - Cron job / AWS Lambda: Identify records >7 years
  - Check for extension flags (`retention_extended` boolean column)
  - Purge if not extended; log purge event to audit_log
  - _Schedule:_ Monthly execution

**Validation Tests:**
- Query all consent events for a principal over 7-year period
- Export to JSON and validate against schema
- Trigger retention purge for test records >7 years; confirm deletion
- Attempt UPDATE on consent_events; confirm trigger blocks modification

**Exit Criteria:** Export API returns valid JSON; 7-year retention validated; immutability confirmed.

---

## Phase 3: Interoperability Layer (Weeks 10-12)

**Objective:** Implement Data Fiduciary onboarding and standardized consent APIs (Part A, Item 9).

### Week 10: OpenAPI Specification Implementation

**Deliverables:**

- [ ] **API Deployment** (`api-spec/consent-manager-api.yaml`)
  - Endpoints:
    - `POST /fiduciaries` — Onboard Data Fiduciary
    - `POST /consent/grant` — Route consent grant
    - `POST /consent/withdraw` — Route withdrawal
    - `POST /data-share` — Route encrypted personal data
    - `GET /export/{principal_id}` — Machine-readable export
    - `POST /grievances` — Grievance intake (Section 13)
  - _Framework:_ FastAPI (Python), Express (Node.js), or Spring Boot (Java)

- [ ] **OAuth 2.0 Integration**
  - Authorization server: Keycloak, Auth0, or AWS Cognito
  - Scope-based access control:
    - `consent:grant` — Data Fiduciary can receive consent grants
    - `consent:withdraw` — Data Fiduciary receives withdrawal notifications
    - `export:read` — Data Principal can export records
  - _Compliance:_ Interoperability via standard OAuth flows

- [ ] **API Rate Limiting**
  - Per-fiduciary rate limits (e.g., 1000 req/min)
  - DDoS protection (AWS WAF, Cloudflare)
  - _Resilience:_ Prevent single fiduciary from overloading platform

**Tools:**
- Swagger UI for API documentation
- Postman collections for integration testing
- Newman for automated API test execution

**Exit Criteria:** All API endpoints live in staging; OAuth flows tested; rate limiting validated.

---

### Weeks 11-12: Fiduciary Onboarding & Webhook Integration

**Deliverables:**

- [ ] **Data Fiduciary Onboarding Workflow**
  - Self-service portal: Fiduciary submits company details, callback URLs, public keys
  - KYC verification: Validate GSTIN, CIN, PAN for corporate identity
  - Sandbox environment: Test consent flows before production activation
  - _Output:_ Fiduciary onboarded with `fiduciary_id`, API credentials, status = `ACTIVE`

- [ ] **Webhook Event Notifications**
  - Events: `consent.granted`, `consent.withdrawn`, `data_share.completed`
  - Delivery: HTTPS POST to fiduciary-registered callback URL
  - Retry logic: Exponential backoff (3 retries over 1 hour)
  - _Compliance:_ Real-time consent status propagation (Part B, Item 1)

- [ ] **Purpose Registry**
  - Fiduciaries define consent purposes (e.g., "Marketing", "Credit Assessment")
  - Purpose stored with consent event for granular tracking
  - _Interoperability:_ Standardized purpose taxonomy (align with Board standards when published)

- [ ] **Consent Notice Templates**
  - Fiduciaries upload notice templates (plain language + legal text)
  - CM archives SHA-256 hash + full text per Part B, Item 3(b)
  - _Validation:_ Notice text includes all Section 6 mandatory elements

**Integration Testing:**
- Onboard 3 test fiduciaries
- Simulate consent grant → webhook delivery → withdrawal → webhook delivery
- Validate end-to-end latency <500ms

**Exit Criteria:** Fiduciary onboarding live; webhooks delivering events reliably; purpose registry operational.

---

## Phase 4: Grievance & Audit Systems (Weeks 13-14)

**Objective:** Deploy Rule 14(3) grievance redressal and Part B, Item 12 audit mechanisms.

### Week 13: Grievance Redressal System

**Deliverables:**

- [ ] **Grievance Intake Portal** (Rule 14(3))
  - Web form: Publicly accessible at `https://yourplatform.com/grievances`
  - Fields: Data Principal ID, grievance type, description, contact email
  - API endpoint: `POST /grievances` for programmatic submission
  - _Timeline:_ Live at registration (Section 13(1) requires readily available grievance redressal); Rule 14(3) applies from 13 May 2027

- [ ] **Tracking & Acknowledgement Workflow**
  - Auto-acknowledgement: Email sent within 24 hours with ticket ID
  - Status tracking: `SUBMITTED → IN_REVIEW → RESOLVED → CLOSED`
  - SLA: Response within your published period, not exceeding 90 days (Rule 14(3))
  - _Database:_ `grievances` table in consent ledger

- [ ] **Audit Trail for Grievances**
  - Log all grievances received, actions taken, resolution outcomes
  - Queryable by Data Protection Board for inspections
  - _Retention:_ 7 years (align with consent record retention)

- [ ] **Public Disclosure** (Rule 14(3))
  - Publish grievance system details on website/app
  - Include: submission process, response period (not exceeding 90 days), escalation path
  - _Compliance:_ "Prominently published" requirement

**Validation:**
- Submit 10 test grievances; confirm acknowledgement within 24h
- Verify status tracking updates correctly
- Board inspector role-play: query grievance audit trail

**Exit Criteria:** Grievance system live and publicly accessible; SLA tracking operational.

---

### Week 14: Audit Mechanisms & Compliance Monitoring

**Deliverables:**

- [ ] **Compliance Dashboard** (Part B, Item 12)
  - Metrics monitored:
    - (a) Technical controls: TLS 1.3 usage %, encryption failures, API error rates
    - (b) Registration conditions: Net worth (monthly check), director integrity (annual check)
    - (c) Obligation adherence: Consent event volume, export requests fulfilled, grievance SLA %
  - _Tool:_ Grafana, Datadog, or CloudWatch dashboards

- [ ] **Automated Control Testing**
  - Daily: Verify `prevent_consent_modification()` trigger active
  - Weekly: Test zero-knowledge — attempt payload decryption (should fail)
  - Monthly: Retention policy execution log review
  - _Output:_ Control test results log

- [ ] **Internal Audit Schedule**
  - Quarterly: Internal compliance review (self-assessment)
  - Annually: Independent audit for Part A, Item 9 re-certification
  - _Deliverable:_ Audit report for Board submission (if requested)

- [ ] **Incident Response Plan**
  - Data breach (the CM is the Data Fiduciary for its own users' account and contact data): Section 8(6) + Rule 7 two-clock intimation: affected Data Principals and the Board "without delay" (Rule 7(1), 7(2)(a)), then the detailed Board report within 72 hours of becoming aware (Rule 7(2)(b)), extendable on written request
  - Control failure: Immediate remediation + Board notification
  - _Integration:_ Use templates from `../dpdpa-breach-notification/`

**Stakeholders:** Compliance Officer, CISO, Head of Engineering

**Exit Criteria:** Compliance dashboard live with real-time metrics; quarterly audit schedule approved.

---

## Phase 5: Certification & Board Submission (Weeks 15-16)

**Objective:** Obtain independent certification (Part A, Item 9) and submit registration application.

### Week 15: Independent Audit Preparation

**Deliverables:**

- [ ] **Select Independent Auditor** (Part A, Item 9)
  - Criteria: ISO 27001 ISMS auditor OR equivalent cybersecurity certification body
  - Engagement: Statement of work for platform assessment against:
    - (a) Data protection standards (when published by Board)
    - (b) Technical and organisational measures for Part B, Item 11 transparency obligations
  - _Timeline:_ 3-4 week audit cycle

- [ ] **Evidence Package Preparation**
  - Architecture diagrams: Zero-knowledge flow, multi-tenant routing (`architecture/`)
  - Policies: Conflict-of-interest, sub-contracting prohibition, fiduciary capacity
  - Technical documentation: Database schema, API spec, cryptographic design
  - Test results: Penetration test report, control test logs, grievance SLA metrics
  - _Format:_ Indexed binder + digital repository for auditor access

- [ ] **Audit Execution**
  - Auditor reviews: Architecture, code (sampling), policies, test evidence
  - Interviews: Compliance Officer, CISO, Lead Architect
  - Gap identification: Remediate findings before certification
  - _Output:_ Independent certification report

**Audit Scope:**
- Interoperability: API standardization (OAuth, OpenAPI), multi-fiduciary support
- Zero-knowledge: Code review confirms no decrypt() on DP/DF data
- Retention: 7-year immutability enforced
- Conflict-of-interest: MoA/AoA embedding verified

**Exit Criteria:** Independent auditor issues certification letter for Board submission.

---

### Week 16: Board Application Submission

**Deliverables:**

- [ ] **Board Application Package** (Rule 4)
  - Form: Application for Consent Manager registration (format TBD by Board)
  - Part A Evidence:
    - Item 1: Certificate of Incorporation
    - Item 2: Technical capacity (architecture docs), operational capacity (org chart, runbooks), financial capacity (audited financials)
    - Item 3: Financial statements + management character declarations
    - Item 4: Net worth certificate (CA-certified)
    - Item 5: Business viability model
    - Item 6: Background verification reports for directors/KMP
    - Item 7: Amended MoA/AoA with RoC filing confirmation
    - Item 8: Business model narrative (fiduciary capacity justification)
    - Item 9: Independent certification report
  - Part B Readiness:
    - Item 2: Zero-knowledge architecture certification
    - Item 4: Consent ledger + export API live
    - Item 6: Sub-contracting prohibition policy
    - Item 7: Security safeguards implementation (ISO 27001 controls)
    - Items 9-10: Conflict-of-interest MoA/AoA clauses
    - Item 11: Transparency disclosures (website published)
    - Item 12: Audit mechanisms operational

- [ ] **Application Submission**
  - Submit to Data Protection Board via portal (URL TBD)
  - Application fee: [Amount TBD by Board]
  - _Timeline:_ Board review period unknown — estimate 3-6 months

- [ ] **Post-Submission Monitoring**
  - Board may request additional information or audits
  - Maintain "audit-ready" state throughout review period
  - _Outcome:_ Registration certificate OR rejection with reasons

**Stakeholders:** CEO, Compliance Officer, Legal Counsel

**Exit Criteria:** Board application submitted; acknowledgement received.

---

## Post-Registration Compliance (Ongoing)

**Once registered, the following obligations are continuous:**

### Daily Operations

- [ ] **Zero-Knowledge Routing** — Every consent event routed without payload decryption
- [ ] **Consent Event Logging** — All grants/denials/withdrawals persisted to immutable ledger
- [ ] **Webhook Delivery** — Real-time notifications to Data Fiduciaries within 500ms

### Monthly

- [ ] **Retention Policy Execution** — Purge records >7 years (unless extended)
- [ ] **Net Worth Verification** — Confirm net worth ≥ ₹2 crore (Part A, Item 4 ongoing)
- [ ] **Compliance Dashboard Review** — Board-level review of Part B, Item 12 metrics

### Quarterly

- [ ] **Internal Compliance Audit** — Self-assessment against all 13 Part B obligations
- [ ] **Conflict-of-Interest Review** — Verify no new director/KMP conflicts with Data Fiduciaries
- [ ] **Grievance SLA Report** — Percentage of grievances resolved within SLA

### Annually

- [ ] **Independent Re-Certification** (Part A, Item 9) — Auditor confirms continued compliance
- [ ] **Director Background Checks** (Part A, Item 6) — Re-verify clean records for all directors/KMP
- [ ] **Board Report** — Submit annual compliance report to Data Protection Board (if required)
- [ ] **MoA/AoA Review** — Confirm no unauthorized amendments to conflict-of-interest clauses

### Trigger Events

- [ ] **Control Transfer** (Part B, Item 13) — Obtain **Board approval** before any sale, merger, or change of control
- [ ] **Material Change** — Notify Board of: director changes, net worth drop below ₹2 crore, security breach (good practice: the Rules set no general notification duty, but Part B, Item 12 requires reporting audit outcomes, including on continued fulfilment of registration conditions, and Rule 4(6) lets the Board call for information)
- [ ] **Grievance Escalation** — Severe or systemic grievances reported to Board within 48 hours (internal policy, not a Rules requirement)

---

## Deliverables Matrix

| Phase | Deliverable | Owner | Format | Evidence for Board |
|-------|-------------|-------|--------|-------------------|
| **Phase 0** | Certificate of Incorporation | Legal | PDF | ✅ Part A, Item 1 |
| | Net worth certificate | CFO | CA-certified | ✅ Part A, Item 4 |
| | Amended MoA/AoA | Legal | RoC filing | ✅ Part A, Item 7 |
| | Business viability model | Strategy | Excel + narrative | ✅ Part A, Item 5 |
| **Phase 1** | Zero-knowledge architecture doc | Architect | Markdown + diagrams | ✅ Part A, Item 9(b) |
| | Penetration test report | Security | PDF | ✅ Part B, Item 7 |
| | Threat model (LINDDUN) | Security | Markdown | ✅ Part B, Item 2 |
| **Phase 2** | Consent ledger schema | Engineering | SQL | ✅ Part B, Items 3, 4 |
| | Machine-readable export API | Engineering | OpenAPI | ✅ Part B, Item 4(b) |
| | Retention policy automation | Engineering | Code + cron config | ✅ Part B, Item 4(c) |
| **Phase 3** | OpenAPI specification | Engineering | YAML | ✅ Part A, Item 9(a) |
| | OAuth integration | Engineering | Config + docs | ✅ Interoperability |
| | Fiduciary onboarding portal | Product | Web UI | ✅ Part B, Item 1 |
| **Phase 4** | Grievance redressal system | Product | Web UI + API | ✅ Rule 14(3) |
| | Compliance dashboard | Compliance | Grafana/Datadog | ✅ Part B, Item 12 |
| | Internal audit schedule | Compliance | Policy doc | ✅ Part B, Item 12 |
| **Phase 5** | Independent certification | Auditor | Certificate | ✅ Part A, Item 9 |
| | Board application package | Compliance | PDF bundle | ✅ Rule 4 submission |

---

## Implementation Tracks

### Track 1: Greenfield (16 weeks)

**For:** Organizations building a Consent Manager platform from scratch.

**Timeline:** Full 16-week plan as outlined above.

**Team:** 5-7 engineers, 1 compliance lead, 1 product manager, legal counsel (external).

**Budget Estimate:**
- Engineering: ₹40-60 lakh (salaries + infrastructure)
- Independent audit: ₹15-25 lakh
- Legal (MoA/AoA, RoC): ₹5-10 lakh
- **Total:** ₹60-95 lakh + ₹2 crore capitalization

---

### Track 2: Account Aggregator Extension (12 weeks)

**For:** RBI-NBFC-AA license holders extending to DPDPA scope.

**Accelerations:**
- **Skip Phase 0 (Weeks 1-2):** Corporate structure, net worth, governance already compliant
- **Adapt Phase 2 (Weeks 7-9):** Extend existing AA consent ledger schema for non-financial purposes
- **Reuse Phase 4 (Weeks 13-14):** Grievance system likely already deployed per RBI requirements

**Timeline:** 12 weeks (Phases 1, 2 [adapted], 3, 5)

**Focus Areas:**
- Zero-knowledge validation for non-financial data (AA already does this for financial data)
- Interoperability extension beyond RBI-defined financial information types
- Conflict-of-interest verification (AA regulations may already satisfy)

---

### Track 3: Platform Adaptation (14 weeks)

**For:** Existing consent management SaaS adapting to DPDPA compliance.

**Accelerations:**
- **Partial Phase 0:** Corporate setup likely complete; focus on MoA/AoA amendments only
- **Partial Phase 3:** APIs likely exist; adapt to OpenAPI spec and OAuth standards

**Risk Areas:**
- **Zero-knowledge gap:** Most consent platforms log full consent interactions. Refactor to metadata-only.
- **Sub-contracting risk:** If platform uses third-party services for core logic, violates Part B, Item 6. Must in-source.

**Timeline:** 14 weeks (Phase 0 [partial], Phases 1-5)

---

## Sign-Off

**This implementation plan has been reviewed and approved for execution.**

| Role | Name | Signature | Date |
|------|------|-----------|------|
| **Chief Executive Officer** | | | |
| **Chief Technology Officer** | | | |
| **Chief Financial Officer** | | | |
| **Compliance Officer** | | | |
| **Legal Counsel** | | | |

**Board Resolution Number:** _______________

**Effective Date:** _______________

---

## Appendix: Regulatory Timeline

| Milestone | Timeline | Regulatory Source |
|-----------|----------|------------------|
| MoA/AoA filing with RoC | 2-3 weeks | Companies Act, 2013, Section 14 |
| Rule 4 and Section 6(9) in force | **13 November 2026** | DPDP Rules 2025, Rule 1(3) |
| Grievance response period | Published period, **not exceeding 90 days** (from 13 May 2027) | DPDPA 2023, Section 13; DPDP Rules 2025, Rule 14(3) |
| Consent record retention | Minimum **7 years** | First Schedule, Part B, Item 4(c) |
| Breach intimation (the CM's own users' account data, as a Data Fiduciary) | **Without delay** to affected Data Principals and the Board; detailed Board report **within 72 hours** of becoming aware, extendable on written request | DPDPA 2023, Section 8(6); DPDP Rules 2025, Rule 7(1), 7(2)(a), 7(2)(b) |
| Independent certification renewal | **Annually** (recommended) | Part A, Item 9 (ongoing validity) |
| Board approval for control transfer | **Before** sale/merger | First Schedule, Part B, Item 13 |

---

## Questions?

For implementation support or Board submission strategy, contact:

**StateCheck Security**
DPDPA Consent Manager Consulting
[https://statechecksecurity.com/consent-manager-audit](https://statechecksecurity.com/consent-manager-audit)