Consent Manager Registration Under DPDPA: Technical Requirements and Infrastructure Mandates

Key Takeaways

• The DPDPA creates a wholly new regulated entity type — the Consent Manager — with no direct equivalent in GDPR or CCPA. It is a Board-registered intermediary, not a software product.
• A Consent Manager is accountable to the Data Principal, not to the Data Fiduciaries it serves. This duty is structural and legally binding under Section 6(8), and First Schedule, Part B, Item 8 requires it to act in a fiduciary capacity towards her.
• Registration requires Indian incorporation, a minimum net worth of ₹2 crore, and independent third-party certification of the interoperable platform.
• The zero-knowledge obligation (First Schedule, Part B, Item 2) is the defining architectural constraint: the platform must route consent decisions and data-sharing instructions without ever reading personal data payloads.
• Thirteen ongoing post-registration obligations apply, including 7-year immutable consent record retention, machine-readable data export, and a hard prohibition on sub-contracting any obligation.
• Common myth: a Consent Manager is just a service provider to the Data Fiduciaries it onboards. Its accountability runs to the individual (Section 6(8)), not to the enterprise clients it onboards.
• Rule 4 and Section 6(9) come into force on 13 November 2026. The Board's data protection standards and assurance framework for the certification in Part A, Item 9 were not yet published as of October 2026, but the other registration conditions and the 13 Part B obligations are actionable now.

Key terms: Consent Manager — a Board-registered entity acting as a single point of contact for Data Principals to give, manage, review, and withdraw consent across multiple Data Fiduciaries (Section 2(g), DPDPA 2023). Data Fiduciary — entity that determines the purpose and means of processing. First Schedule — the annex to DPDP Rules 2025 prescribing all Consent Manager registration conditions and operational obligations. Interoperability — the platform requirement ensuring a Consent Manager works across multiple Data Fiduciaries without proprietary lock-in.

Table of Contents

1. The Legal Foundation: What the Act and Rules Actually Say
2. Registration Requirements: First Schedule, Part A
3. The 13 Obligations: First Schedule, Part B
4. The Engineering Translation: Framework Mapping
5. Implementation Guide: Building a Compliant Consent Platform
6. Consent Manager Platform: Privacy Threat Model
7. Downloadable Resources
8. FAQ: Common Questions About DPDPA Consent Manager Registration
9. Key Takeaways
10. Next Steps

Introduction

India's Digital Personal Data Protection Act, 2023 introduces a concept that has no direct equivalent in GDPR, CCPA, or any other major privacy regulation: the Consent Manager. This is not a software product or a feature toggle. It is a legally defined, Board-registered entity type that sits between Data Principals (individuals) and Data Fiduciaries (organisations). Through it, an individual can give, manage, review, and withdraw consent across multiple Data Fiduciaries from one place.

If you are building a consent management platform for the Indian market, evaluating whether your organisation should seek DPDPA consent manager registration, or trying to understand how Consent Managers fit into your data architecture as a Data Fiduciary, this article provides the complete technical and regulatory breakdown.

The specifics are found in two places: Section 6 of the DPDPA 2023 defines the Consent Manager's role and legal basis, and Rule 4 of the DPDP Rules 2025, together with the First Schedule (Parts A and B), prescribes every registration condition and operational obligation. We will work through both, translate the legal language into engineering requirements, and map the obligations to established security frameworks.

This is a blue-ocean regulatory space. As of this writing, the Board has not yet published the "data protection standards and assurance framework" referenced in the First Schedule. That means organisations preparing for registration need to build to the letter of the Rules while anticipating the technical standards that will follow.

The Legal Foundation: What the Act and Rules Actually Say

The legal foundation for the Consent Manager is split across three places: Section 2(g) defines the entity, Section 6 establishes its lifecycle role and accountability, and the First Schedule to the Rules sets every operational obligation. Reading any one without the others gives a misleading picture of the role.

Defining the Consent Manager (Section 2(g))

The DPDPA establishes the Consent Manager as a statutory entity with a precise definition:

"Consent Manager" means a person registered with the Board, who acts as a single point of contact to enable a Data Principal to give, manage, review and withdraw her consent through an accessible, transparent and interoperable platform. -- Section 2(g), DPDPA 2023

Three architectural requirements are embedded in this definition: accessible (the platform must be available to all Data Principals, including those with disabilities), transparent (the operations of the Consent Manager must be visible to the Data Principal), and interoperable (the platform must work across multiple Data Fiduciaries without proprietary lock-in).

The Consent Manager's Role in the Consent Lifecycle (Section 6(7)-(9))

Section 6 establishes the legal basis for Consent Managers within the broader consent framework:

The Data Principal may give, manage, review or withdraw her consent to the Data Fiduciary through a Consent Manager. -- Section 6(7), DPDPA 2023

The Consent Manager shall be accountable to the Data Principal and shall act on her behalf in such manner and subject to such obligations as may be prescribed. -- Section 6(8), DPDPA 2023

Every Consent Manager shall be registered with the Board in such manner and subject to such technical, operational, financial and other conditions as may be prescribed. -- Section 6(9), DPDPA 2023

Section 6(8) is critical: the Consent Manager is accountable to the Data Principal, not to the Data Fiduciary. This creates a fiduciary relationship where the Consent Manager's primary duty of care runs to the individual, even though its commercial relationships may be with enterprises.

Grievance Redressal Obligations (Section 13)

The Act explicitly includes Consent Managers in the grievance redressal framework:

A Data Principal shall have the right to have readily available means of grievance redressal provided by a Data Fiduciary or Consent Manager in respect of any act or omission of such Data Fiduciary or Consent Manager regarding the performance of its obligations... -- Section 13(1), DPDPA 2023

Section 13(2) leaves the response period to be prescribed. Rule 14(3) of the DPDP Rules 2025 (in force 13 May 2027) supplies it: every Data Fiduciary and Consent Manager must prominently publish on its website or app the period within which its grievance redressal system responds to Data Principals' grievances, a reasonable period not exceeding ninety days, and implement appropriate technical and organisational measures to make sure the system responds within that period.

Enforcement: The Board's Powers (Section 27(1)(c)-(d))

The Data Protection Board has explicit authority over Consent Managers:

• On a complaint from a Data Principal about a Consent Manager's breach of obligations, the Board may inquire and impose penalties (Section 27(1)(c)).
• On receipt of an intimation of breach of any condition of registration, the Board may inquire and impose penalties (Section 27(1)(d)).

Under the Schedule to the Act, breach of any provision not specifically listed (which includes Consent Manager obligations) carries a penalty that may extend to fifty crore rupees (Schedule, Item 7), imposed under Section 33(1) where the Board finds the breach significant. Note the staggered commencement: Section 6(9), Section 27(1)(d) and Rule 4 apply from 13 November 2026, while Section 27(1)(c) and Section 33 apply from 13 May 2027.

Registration Requirements: First Schedule, Part A

Part A of the First Schedule is the registration gate — nine conditions an applicant must satisfy before the Board grants Consent Manager status. Some conditions are corporate (Indian incorporation, net worth, governance); others are deeply technical (independent platform certification). Each is summarised below with its engineering and operational translation.

1. Indian Incorporation

The applicant is a company incorporated in India. -- First Schedule, Part A, Item 1

This is a hard legal prerequisite. Foreign entities cannot directly register as Consent Managers -- they must establish an Indian subsidiary. The Note to the First Schedule gives "company" the meaning it has in the Companies Act, 2013. (The broader "body corporate" definition in the same Note, which covers firms, financial institutions, scheduled banks and public sector enterprises, applies to the Part B, Item 11(c) shareholding disclosures, not to this condition.)

2. Technical, Operational, and Financial Capacity

The applicant has sufficient capacity, including technical, operational and financial capacity, to fulfil its obligations as a Consent Manager. -- First Schedule, Part A, Item 2

This is an infrastructure assessment gate. The Board will evaluate whether you have the engineering team, operational processes, and financial runway to operate a consent platform at scale. Expect to demonstrate: hosting infrastructure with high availability, a security operations capability, an incident response plan, and sufficient staffing.

3. Sound Financial Condition and Management Character

The financial condition and the general character of management of the applicant are sound. -- First Schedule, Part A, Item 3

This is a corporate governance check. Directors and management must have clean records, and the company's financial statements must demonstrate stability.

4. Minimum Net Worth: Two Crore Rupees

The net worth of the applicant is not less than two crore rupees. -- First Schedule, Part A, Item 4

"Net worth" is defined as the aggregate value of total assets reduced by the value of liabilities, per the company's books of accounts. This is a capitalization floor that ensures Consent Managers have financial substance behind their obligations.

5. Adequate Business Viability

The volume of business likely to be available to and the capital structure and earning prospects of the applicant are adequate. -- First Schedule, Part A, Item 5

The Board wants evidence that your Consent Manager business is commercially viable. A registration application from an entity with no revenue model or path to sustainability will face scrutiny.

6. Management Integrity

The directors, key managerial personnel and senior management of the applicant company are individuals with a general reputation and record of fairness and integrity. -- First Schedule, Part A, Item 6

Background checks on key personnel will be part of the evaluation. Criminal records, regulatory sanctions, or a history of data protection violations at previous organisations are likely to weigh against an application (the Rules do not list specific disqualifications).

7. Constitutional Documents

The memorandum of association and articles of association of the applicant company contain provisions requiring that the obligations under items 9 and 10 of Part B are adhered to, that policies and procedures are in place to ensure such adherence, and that such provisions may be amended only with the previous approval of the Board. -- First Schedule, Part A, Item 7

This is unusual and significant: the Board requires that your corporate charter structurally embeds the conflict-of-interest provisions. You cannot amend these provisions without Board approval. This prevents a Consent Manager from quietly loosening its independence requirements after registration.

8. Operations in Data Principals' Interests

The operations proposed to be undertaken by the applicant are in the interests of Data Principals. -- First Schedule, Part A, Item 8

This is a purpose test. Your business model must demonstrably serve the interests of individuals, not just the commercial interests of the Data Fiduciaries you onboard.

9. Independent Certification

It is independently certified that— (a) the interoperable platform of the applicant to enable the Data Principal to give, manage, review and withdraw her consent is consistent with such data protection standards and assurance framework as may be published by the Board on its website from time to time; and (b) appropriate technical and organisational measures are in place to ensure adherence to such standards and framework and effective observance of the obligations under item 11 of Part B. -- First Schedule, Part A, Item 9

This is the most technically demanding condition. You need an independent certification that your interoperable platform is consistent with the data protection standards and assurance framework the Board publishes on its website. As of October 2026, the Board has not yet published these standards, which creates a timing dependency for prospective applicants. However, the requirement to have appropriate technical and organisational measures for observing the transparency obligations (Part B, Item 11) is independently actionable.

The 13 Obligations: First Schedule, Part B

Part B is the operating contract. Once registered, a Consent Manager must comply with 13 ongoing obligations spanning architecture, retention, security, governance, and audit. These are not guidelines — breach of any one can trigger a Board inquiry on a Data Principal's complaint (Section 27(1)(c)) or, where it is also a breach of a registration condition, on intimation (Section 27(1)(d)), and penalties under the Schedule.

Obligation 1: Enable Multi-Fiduciary Consent

The Consent Manager must enable a Data Principal to give consent to any Data Fiduciary onboarded onto the platform, either directly or through another onboarded Data Fiduciary who maintains the Data Principal's personal data.

Engineering implication: Your platform needs a multi-tenant architecture with a Data Fiduciary registry. Each fiduciary must be individually onboarded with its own consent notice templates and purpose specifications. The consent flow must support both direct consent (Data Principal -> CM -> Data Fiduciary) and delegated consent (Data Principal -> CM -> Fiduciary A -> Fiduciary B).

Obligation 2: Zero-Knowledge Data Handling

The Consent Manager shall ensure that the manner of making available the personal data or its sharing is such that the contents thereof are not readable by it. -- First Schedule, Part B, Item 2

Engineering implication: This is the most architecturally significant obligation. The Consent Manager facilitates consent and data portability but must never have access to the personal data itself. This requires end-to-end encryption between the Data Principal and the Data Fiduciary, with the Consent Manager acting as a routing layer that handles metadata (consent status, purpose identifiers, timestamps) without access to the payload.

# Architectural pattern: Zero-knowledge consent routing
class ConsentManagerRouter:
    """
    Routes consent decisions and data-sharing instructions between
    Data Principals and Data Fiduciaries without accessing personal data.
    Implements First Schedule, Part B, Item 2.
    """

    def route_consent_grant(
        self,
        principal_id: str,
        fiduciary_id: str,
        purpose_id: str,
        encrypted_consent_token: bytes  # Encrypted by Data Principal's key
    ) -> ConsentRecord:
        # CM records the consent metadata -- NOT the personal data
        record = ConsentRecord(
            principal_id=principal_id,
            fiduciary_id=fiduciary_id,
            purpose_id=purpose_id,
            action="GRANT",
            timestamp=datetime.now(timezone.utc),
            # Store encrypted token for audit -- CM cannot decrypt
            consent_token_hash=sha256(encrypted_consent_token).hexdigest()
        )
        self.consent_store.persist(record)

        # Forward the encrypted token to the Data Fiduciary
        # CM never sees the decrypted consent payload
        self.fiduciary_gateway.forward(
            fiduciary_id=fiduciary_id,
            encrypted_token=encrypted_consent_token
        )
        return record

    def route_data_share(
        self,
        principal_id: str,
        source_fiduciary_id: str,
        target_fiduciary_id: str,
        encrypted_payload: bytes  # E2E encrypted -- CM cannot read
    ) -> ShareRecord:
        # CM records the sharing event metadata
        share_record = ShareRecord(
            principal_id=principal_id,
            source=source_fiduciary_id,
            target=target_fiduciary_id,
            timestamp=datetime.now(timezone.utc),
            payload_hash=sha256(encrypted_payload).hexdigest()
        )
        self.consent_store.persist(share_record)

        # Route without decrypting
        self.fiduciary_gateway.transfer(
            target=target_fiduciary_id,
            encrypted_payload=encrypted_payload
        )
        return share_record

Obligation 3: Comprehensive Consent Record-Keeping

The Consent Manager must maintain records of:

• (a) Consents given, denied, or withdrawn by the Data Principal
• (b) Notices preceding or accompanying requests for consent
• (c) Sharing of personal data with a transferee Data Fiduciary

Engineering implication: This is an immutable audit log requirement. Every consent event -- grant, denial, withdrawal -- must be recorded with full provenance. Every notice served must be archived. Every data-sharing event must be logged with source and destination identifiers.

Obligation 4: Access, Export, and 7-Year Retention

• (a) Give the Data Principal platform access to the consent records
• (b) On request, provide records in machine-readable form
• (c) Maintain records for at least seven years, or longer as agreed or required by law

Engineering implication: Your consent data store must support a 7-year retention policy with full queryability. The machine-readable export requirement means you need a structured export format (JSON, CSV, or a standardized consent schema). This maps to NIST Privacy Framework CT.DP-P4 (data portability) and SOC 2 P6.1 (disclosure and portability).

# Consent record export schema (machine-readable, per Part B Item 4b)
consent_export:
  format: "application/json"
  schema_version: "1.0"
  data_principal:
    identifier: "pseudonymised_id"  # Not PII in the export metadata
  records:
    - type: "CONSENT_GRANT"
      fiduciary_id: "fiduciary_abc"
      purpose: "Marketing communications"
      timestamp: "2026-01-15T10:30:00Z"
      notice_reference: "notice_hash_xyz"
    - type: "CONSENT_WITHDRAWAL"
      fiduciary_id: "fiduciary_abc"
      purpose: "Marketing communications"
      timestamp: "2026-06-20T14:15:00Z"
    - type: "DATA_SHARE"
      source_fiduciary: "fiduciary_abc"
      target_fiduciary: "fiduciary_def"
      timestamp: "2026-03-10T09:00:00Z"
      payload_hash: "sha256:a1b2c3..."
  retention:
    minimum_years: 7
    policy: "immutable_append_only"

Obligation 5: Website or App as Primary Access

The Consent Manager must develop and maintain a website or app as the primary means through which Data Principals access its services.

Obligation 6: No Sub-Contracting

The Consent Manager shall not sub-contract or assign the performance of any of its obligations under the Act and these rules. -- First Schedule, Part B, Item 6

Engineering implication: You cannot outsource your core consent management operations. Your platform, your infrastructure, your support -- all must be operated by the registered entity. This has direct implications for cloud architecture: while you can use cloud infrastructure (IaaS), you cannot delegate the consent management logic or data handling to a third-party SaaS provider.

Obligation 7: Reasonable Security Safeguards

Part B, Item 7 uses the same words as Section 8(5) for Data Fiduciaries: "reasonable security safeguards to prevent personal data breach". The Rules do not spell out a separate list for Consent Managers, so the practical benchmark is Rule 6(1)(a)-(g), which lists the minimum safeguards for Data Fiduciaries (encryption or masking, access control, logging and monitoring, backups, one-year log retention, processor contracts, and organisational measures).

A Consent Manager is also a Data Fiduciary in its own right for its users' account and contact data: it decides why and how that data is processed (Section 2(i)). Treat the Data Fiduciary duties in Section 8 as applying to that data, including breach intimation under Section 8(6) and Rule 7. Its role as the Data Principal's agent (Section 6(8)) covers the consent artefacts it handles, and the Part B, Item 7 safeguards duty applies to everything.

Obligation 8: Fiduciary Capacity

The Consent Manager must act in a fiduciary capacity in relation to the Data Principal. This is a legal duty of care, not a technical control. It means the Consent Manager must prioritise the Data Principal's interests above its own commercial interests or those of the Data Fiduciaries it works with.

Obligations 9-10: Conflict of Interest Provisions

These are structural independence requirements:

• The Consent Manager must avoid conflicts of interest with Data Fiduciaries, including in respect of the Data Fiduciaries' promoters and key managerial personnel (Item 9). Its own directors, key managerial personnel and senior management are covered by Item 10.
• The Consent Manager must have measures in place to ensure that no conflict of interest arises from its directors, key managerial personnel or senior management holding a directorship, financial interest, employment or beneficial ownership in Data Fiduciaries, or having a material pecuniary relationship with them.

Engineering implication: This is a governance control, but it has a technical dimension. Your system must enforce logical separation between the consent management function and any Data Fiduciary operations. If your parent company is a Data Fiduciary, the Consent Manager subsidiary must have technically isolated infrastructure.

Obligation 11: Transparency Disclosures

The Consent Manager must publish:

• (a) Promoters, directors, key managerial personnel, and senior management
• (b) Every person holding shares in excess of 2% of the company
• (c) Every body corporate in which any promoter, director, key managerial personnel or senior management of the CM holds more than 2% of the shares, as on the first day of the preceding calendar month
• (d) Other information as the Board may direct

Obligation 12: Effective Audit Mechanisms

The Consent Manager must have effective audit mechanisms to review, monitor and evaluate the following, and must report the outcome to the Board periodically and whenever the Board directs:

• (a) Technical and organisational controls, systems, procedures, and safeguards
• (b) Continued fulfilment of registration conditions
• (c) Adherence to obligations under the Act and Rules

This maps directly to ISO 27001:2022 A.5.35 (Independent review of information security) and SOC 2 CC4.1 (Monitoring activities).

Obligation 13: Board Approval for Control Transfer

The control of the registered Consent Manager company cannot be transferred by sale, merger, or otherwise without prior Board approval.

The Engineering Translation: Framework Mapping

The framework mapping is the bridge between the First Schedule's plain-language obligations and the control taxonomies your auditor already understands. Every major Consent Manager obligation aligns to specific ISO 27001:2022, SOC 2 TSC, and NIST CSF 2.0 controls — letting an existing certification programme absorb DPDPA without parallel evidence.

Key gaps: Conflict of interest controls and transparency disclosures have no direct ISO 27001 equivalent. These are governance requirements that must be implemented through corporate policies and Board-level controls rather than technical security measures.

Implementation Guide: Building a Compliant Consent Platform

The implementation guide turns Part B's 13 obligations into a five-step engineering plan: zero-knowledge routing, immutable consent ledger, interoperability layer, grievance redressal, and audit. Sequencing matters — the zero-knowledge architecture is the load-bearing constraint that the rest of the stack inherits.

Step 1: Establish the Zero-Knowledge Architecture

The most technically challenging requirement is Part B, Item 2: ensuring that personal data routed through your platform is not readable by you. This requires:

• End-to-end encryption between Data Principals and Data Fiduciaries, with keys managed outside the Consent Manager's control
• Metadata-only processing at the CM layer: consent decisions, purpose identifiers, timestamps, and routing information, but never personal data payloads
• Cryptographic integrity proofs (hashes) stored for audit purposes without revealing content

sequenceDiagram
    participant DP as Data Principal
    participant CM as Consent Manager
    participant DF as Data Fiduciary

    DP->>CM: Grant consent for Purpose X
    Note over CM: Records: principal_id, fiduciary_id,<br/>purpose_id, timestamp, action=GRANT
    CM->>DF: Forward consent grant (metadata only)
    DF->>DP: Request personal data (direct channel)
    DP->>DF: Provide personal data (E2E encrypted)
    Note over CM: CM never sees personal data payload

    DP->>CM: Withdraw consent for Purpose X
    Note over CM: Records: action=WITHDRAW, timestamp
    CM->>DF: Forward withdrawal notification
    DF->>DF: Cease processing, initiate erasure

Alt Text: Sequence diagram showing the consent lifecycle flow through a DPDPA Consent Manager, illustrating how the Consent Manager handles only consent metadata while personal data flows directly between the Data Principal and Data Fiduciary via an end-to-end encrypted channel.

Step 2: Design the Immutable Consent Ledger

Part B, Items 3 and 4 require a consent record store that is:

• Append-only: Consent events are never modified or deleted (for at least 7 years)
• Queryable: Data Principals must be able to view their records via the platform
• Exportable: Machine-readable export on request
• Auditable: The audit mechanism under Item 12 must be able to verify record integrity

Consider an event-sourced architecture backed by an append-only data store. Technologies like Apache Kafka (with log compaction disabled for consent topics), Amazon QLDB, or a PostgreSQL table with row-level immutability constraints are suitable foundations.

-- Immutable consent event store (PostgreSQL)
-- Supports Part B Items 3, 4(a), 4(b), 4(c)
CREATE TABLE consent_events (
    event_id        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    principal_id    VARCHAR(255) NOT NULL,
    fiduciary_id    VARCHAR(255) NOT NULL,
    event_type      VARCHAR(50) NOT NULL
                    CHECK (event_type IN (
                        'CONSENT_GRANT', 'CONSENT_DENY',
                        'CONSENT_WITHDRAW', 'NOTICE_SERVED',
                        'DATA_SHARE'
                    )),
    purpose_id      VARCHAR(255) NOT NULL,
    notice_hash     VARCHAR(64),    -- SHA-256 of the served notice
    payload_hash    VARCHAR(64),    -- SHA-256 of shared data (for DATA_SHARE)
    metadata        JSONB,          -- Additional structured context
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),

    -- Immutability: no UPDATE or DELETE allowed via application-level
    -- RBAC. Enforce at database level with a trigger:
    CONSTRAINT no_future_dates CHECK (created_at <= NOW())
);

-- Prevent any UPDATE or DELETE on consent_events
CREATE OR REPLACE FUNCTION prevent_consent_modification()
RETURNS TRIGGER AS $$
BEGIN
    RAISE EXCEPTION
        'Consent records are append-only (DPDP Rules 2025, '
        'First Schedule, Part B, Items 3 and 4(c)). '
        'Records must be retained for at least 7 years.';
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER enforce_immutability
    BEFORE UPDATE OR DELETE ON consent_events
    FOR EACH ROW
    EXECUTE FUNCTION prevent_consent_modification();

-- Index for Data Principal record access (Part B, Item 4(a))
CREATE INDEX idx_consent_principal
    ON consent_events (principal_id, created_at DESC);

-- Retention policy: partition by year for efficient 7-year management
-- (Implementation depends on PostgreSQL partitioning strategy)

Step 3: Implement the Interoperability Layer

The interoperability requirement in Section 2(g) and Part A, Item 9 means your platform must support multiple Data Fiduciaries without proprietary lock-in. Design your API surface with:

• Standardised consent request/response formats (anticipate that the Board's forthcoming standards will likely mandate a common schema)
• OAuth 2.0 or equivalent for Data Fiduciary authentication and authorisation
• Webhook-based event notification for real-time consent status changes
• RESTful APIs with versioning for forward compatibility

Step 4: Build the Grievance Redressal System

Section 13(1) gives Data Principals the right to readily available means of grievance redressal from a Consent Manager. Rule 14(3) (in force 13 May 2027) requires you to publish your response period, which may not exceed 90 days, and to put technical and organisational measures in place to meet it. Build:

• A publicly accessible intake mechanism (web form, API endpoint, or both)
• Tracking and acknowledgement workflow
• Response within your published period, not exceeding 90 days (Rule 14(3))
• An audit trail of all grievances received and actions taken

Step 5: Establish the Audit and Compliance Function

Part B, Item 12 requires effective audit mechanisms covering technical controls, registration conditions, and ongoing obligations. Implement:

• Automated compliance monitoring dashboards
• Periodic internal audits (quarterly recommended)
• Annual independent audit aligned with the registration certification requirement
• Board reporting capability for audit outcomes

Consent Manager Platform: Privacy Threat Model

A Consent Manager platform is a high-value target by design — it holds consent metadata across potentially millions of Data Principals and hundreds of Data Fiduciaries, even when the underlying personal data is encrypted away from it. The LINDDUN privacy threat model gives a structured way to enumerate the risks and trace each one back to a specific obligation that mitigates it.

Documentation & Planning

• README — Resource overview, quick start paths (greenfield, AA extension, platform adaptation)
• Implementation Checklist — 16-week phased platform build (zero-knowledge, ledger, interoperability, grievance, certification)
• Quick Reference Card — Printable 2-page desk reference: 9 registration conditions, 13 obligations, penalty exposure
• Registration Readiness Checklist — Pre-application self-audit against First Schedule Part A

Technical Resources

• API Specification — OpenAPI 3.1 spec: fiduciary onboarding, consent routing, DSAR, grievance endpoints
• Database Schema — PostgreSQL immutable consent ledger with 7-year retention, trigger-based integrity enforcement
• Zero-Knowledge Flow Diagram — Mermaid sequence diagram: E2E encryption, metadata-only routing
• Multi-Tenant Architecture — Platform architecture for multi-fiduciary consent routing
• LINDDUN Threat Model — Privacy threat analysis with DPDPA mitigations

Legal & Governance

• MoA/AoA Amendment Template — Constitutional embedding of conflict-of-interest provisions (Part A Item 7)

Related DPDPA Resources

• DPDPA-ISO 27001 Mapping — Control framework for Part B, Item 7 security safeguards
• Encryption Requirements — TLS 1.3 configs, database encryption for consent ledger
• CI/CD Privacy Gates — Pipeline integration for Part B, Item 12 continuous compliance
• Breach Notification — Section 8(6) incident response for consent platform breaches

FAQ: Common Questions About DPDPA Consent Manager Registration

What makes a Consent Manager different from a Data Fiduciary?

A Data Fiduciary determines the purpose and means of processing personal data and is directly accountable for that processing. A Consent Manager must not be able to read the personal data it helps make available or share — under First Schedule, Part B, Item 2, the contents must not be readable by it. It does still hold its users' account details and the consent records required by Part B, Item 3, and must protect them with reasonable security safeguards (Item 7). The Consent Manager's accountability runs to the Data Principal (Section 6(8)), and it acts in a fiduciary capacity towards her (Part B, Item 8), not on behalf of the enterprise clients it onboards. It is a Board-registered intermediary with no direct GDPR equivalent.

What are the technical requirements to register as a Consent Manager under DPDPA?

The primary technical requirement is independent third-party certification of your interoperable platform against the Board's data protection standards and assurance framework (First Schedule, Part A, Item 9). The platform must support multi-fiduciary consent routing, end-to-end encryption (zero-knowledge architecture), immutable consent record storage with 7-year retention, machine-readable data export, and a grievance redressal system that responds within a published period not exceeding 90 days (Rule 14(3), from 13 May 2027). The Board's data protection standards and assurance framework had not been published as of October 2026; applicants should align with ISO 27001 and SOC 2 as a demonstrable baseline in the interim.

What is the minimum net worth required for Consent Manager registration?

The minimum net worth is two crore rupees (approximately USD 240,000), defined as the aggregate value of total assets reduced by liabilities as appearing in the company's books of accounts (First Schedule, Part A, Item 4). This is a capitalization floor, not a recurring financial metric — it must be met at the time of registration and maintained thereafter.

What does 'zero-knowledge data handling' mean in the context of Consent Managers?

First Schedule, Part B, Item 2 requires that the manner of making personal data available or sharing it must be such that "the contents thereof are not readable" by the Consent Manager. In practice, this means the platform must act as an encrypted routing layer: it records consent metadata (who gave consent, for what purpose, when) but never receives, stores, or processes the underlying personal data payload. End-to-end encryption between Data Principals and Data Fiduciaries — with keys controlled outside the Consent Manager's infrastructure — is the only viable architectural pattern.

How does DPDPA's Consent Manager model compare to GDPR?

GDPR has no equivalent entity type. Under GDPR, consent is a bilateral relationship between the data subject and the data controller; there is no statutory intermediary. The DPDPA Consent Manager introduces a tripartite structure: Data Principal, Consent Manager, and Data Fiduciary. The Consent Manager is a legally distinct, Board-registered entity with its own obligations, its own penalty exposure (up to ₹50 crore), and a fiduciary duty owed to the individual rather than the enterprise. Organisations operating in both jurisdictions must maintain parallel consent architectures — the DPDPA model cannot be collapsed into a GDPR consent management system.

Can a Consent Manager sub-contract its platform operations to a third party?

No. First Schedule, Part B, Item 6 explicitly prohibits sub-contracting or assignment of any Consent Manager obligation under the Act and Rules. This means the registered entity must directly operate its platform, infrastructure, and support functions. Cloud IaaS (compute, storage, networking) is permissible, but delegating the consent management logic, data handling, or operational obligations to a third-party SaaS provider is not.

What happens if the Board has not yet published the interoperability standards?

The independent certification requirement (Part A, Item 9) references standards "as may be published by the Board on its website from time to time." Until these are published, applicants should build to the letter of the Rules and align with established standards (ISO 27001, SOC 2) as a demonstrable baseline. Rule 4 comes into force one year after the Rules were published in the Official Gazette (Rule 1(3)), that is, on 13 November 2026; Section 6(9) of the Act commences on the same date.

Key Takeaways

• Consent Managers are a regulated entity type with no GDPR or CCPA equivalent. Registration with the Data Protection Board requires meeting nine conditions including Indian incorporation, a two crore rupee net worth minimum, and independent platform certification.
• The zero-knowledge obligation (Part B, Item 2) is the defining architectural constraint. Your platform must route consent decisions and data-sharing instructions without ever accessing the personal data itself. End-to-end encryption between Data Principals and Data Fiduciaries is the only viable pattern.
• Thirteen ongoing obligations govern post-registration operations, including 7-year consent record retention, machine-readable data export, a prohibition on sub-contracting, structural conflict-of-interest controls, and mandatory audit mechanisms.
• The interoperability standards have not yet been published by the Board. This is both a risk (certification dependency) and an opportunity (early movers can shape market expectations). Build to the Rules now and be ready to certify when standards arrive.
• The conflict-of-interest provisions are structurally embedded -- they must be written into your MoA/AoA and can only be amended with Board approval. This is a corporate governance commitment, not just a policy.
• Penalty exposure is real: breach of Consent Manager obligations falls under Schedule Item 7, which carries a penalty extending to fifty crore rupees. The Board also has the power to suspend or cancel registration under Rule 4(5).

Next Steps

Building or evaluating a Consent Manager platform? StateCheck Security provides technical architecture reviews for organisations preparing for DPDPA Consent Manager registration. We assess your platform against every First Schedule condition, identify control gaps mapped to ISO 27001 and SOC 2, and deliver an audit-ready compliance roadmap.

Request a DPDPA Compliance Audit

Related Articles

• The DPDPA to ISO 27001 Mapping Guide -- Understand how ISO 27001 Annex A controls map to DPDPA obligations, including the security safeguard requirements that apply to Consent Managers under Part B, Item 7.
• SOC 2 Privacy Criteria vs. DPDPA -- If your organisation holds SOC 2 Type II, this guide shows how the Privacy and Common Criteria controls overlap with DPDPA requirements relevant to Consent Manager operations.
• Engineering Privacy by Design: DPDPA at the CI/CD Pipeline -- Implement the technical controls required for Consent Manager infrastructure through automated pipeline checks and deployment gates.
• Implementing Cryptographic Controls for DPDPA -- Deep dive into the encryption safeguards in Rule 6(1)(a), the practical benchmark for Consent Managers' reasonable security safeguard obligation (Part B, Item 7).