Rule 4 - Registration and obligations of Consent Manager

Rule 4 creates the legal and supervisory framework for Consent Managers. The simplest way to understand a Consent Manager is as a regulated consent-control platform acting for the Data Principal. It allows an individual to manage permissions concerning her personal data across participating Data Fiduciaries from a single platform, rather than visiting every bank, insurer, hospital, retailer or digital service separately.

The framework is based on Section 2(g) and Sections 6(7) to 6(9) of the DPDPA. The Act defines the Consent Manager, allows the Data Principal to use one, makes it accountable to her and requires registration with the Data Protection Board. Rule 4 and the First Schedule then prescribe the registration process, eligibility standards and continuing obligations.

The functional design described in is generally built around this statutory model. It envisages consent collection, validation, updating, renewal and withdrawal, supported by dashboards, notifications, grievance workflows, retention controls and audit logs. However, the document is a business requirements document, not legislation. Some of its features are useful system-design choices rather than express statutory requirements, and a few require legal qualification to align precisely with the final Act and Rules.

Commencement position: Rule 4 and Section 6(9) are scheduled to commence on13 November 2026. Sections 6(7) and 6(8), which govern the Data Principal’s use of a Consent Manager and the Consent Manager’s accountability to her, are scheduled to commence on13 May 2027. The registration machinery can therefore begin operating before the substantive consent-management framework becomes fully operational.

1. What a Consent Manager actually does

A Consent Manager is not simply a privacy-policy page, cookie banner or database that stores “yes” and “no” selections. It is intended to provide a common, interoperable system through which a Data Principal may:

• receive consent requests from participating Data Fiduciaries;

• review the notice accompanying each request;

• understand the personal data and purpose covered;

• grant or refuse consent;

• see active and historical consents;

• modify permissions where the platform supports granular preferences;

• withdraw consent;

• authorise transfer of personal data from one Data Fiduciary to another;

• obtain a machine-readable record of consent activity; and

• maintain evidence of what was requested, decided and shared.

A useful analogy is a control panel for personal-data permissions. The Consent Manager does not ordinarily become the owner or user of the substantive personal data. It carries the Data Principal’s consent instruction between the relevant parties, records that instruction and allows the Data Principal to change it later.

1.1 Basic example: One dashboard for several services

Assume Neha uses:

• Bank A;

• Insurer B;

• Investment Platform C; and

• Health Application D.

All four are onboarded to a registered Consent Manager.

Instead of separately searching through the settings of every service, Neha can use the Consent Manager’s platform to see:

• Bank A has consent to use specified transaction information for an account-aggregation service;

• Insurer B has consent to use health and identity information for policy underwriting;

• Investment Platform C has consent to use financial information for portfolio analysis; and

• Health Application D has no consent to use consultation data for promotional profiling.

Neha may review the notices that accompanied those requests, see when each choice was made and withdraw a particular consent without automatically affecting unrelated permissions.

The Consent Manager therefore provides central visibility and control. It does not determine whether Bank A, Insurer B, Platform C or Application D has a lawful purpose. Each Data Fiduciary remains responsible for its own processing.

2. Consent Manager as a single point of contact

The statutory definition describes the Consent Manager as a single point of contact for giving, managing, reviewing and withdrawing consent.

This does not mean that the Consent Manager replaces every privacy contact or grievance channel of every Data Fiduciary. It means that consent-related interactions can be centralised through one platform.

The Consent Manager may therefore operate as a coordination layer between:

• the Data Principal making the decision;

• the Data Fiduciary requesting consent;

• another Data Fiduciary holding the requested information; and

• systems that must react when consent is granted or withdrawn.

2.1 Example: Direct permission

Ravi stores verified identity documents in a digital locker. A financial service provider requests access to a specified identity document for a defined service.

Through the Consent Manager:

1. Ravi receives the financial service provider’s consent request.

2. The accompanying notice identifies the document, purpose and service enabled.

3. Ravi accepts or refuses the request.

4. If he accepts, the Consent Manager transmits the permission.

5. The requested document is transferred through the relevant systems.

6. The Consent Manager records the notice, consent decision and sharing event.

7. Ravi can later view that record and withdraw consent for future processing where applicable.

The Consent Manager should facilitate the transaction without reading the contents of the identity document.

2.2 Example: Consent routed through another Data Fiduciary

Meera holds a bank account with Bank B. Lender A seeks her bank statement to assess a loan application.

The process may operate as follows:

1. Lender A sends the consent request through the Consent Manager.

2. Meera receives a notice identifying the particular bank-statement data, assessment purpose and requested period.

3. Meera chooses whether to consent.

4. If she consents, the instruction is routed to Bank B.

5. Bank B supplies the bank statement to Lender A through the authorised channel.

6. The Consent Manager records the consent request, notice, decision and completion of sharing.

7. The statement’s contents remain unreadable to the Consent Manager.

This is the routed model reflected in the First Schedule and illustrated in the Rules.

3. The Consent Manager does not make invalid consent valid

Use of a registered Consent Manager does not automatically prove that the underlying consent is lawful.

Consent must still satisfy Section 6. It must be:

• free;

• specific;

• informed;

• unconditional;

• unambiguous;

• expressed through clear affirmative action; and

• limited to personal data necessary for the specified purpose.

If a Data Fiduciary sends a vague or excessive consent request through a technically perfect Consent Manager, the request remains defective.

3.1 Example: Unnecessary contact-list access

A telemedicine provider requests:

• health information necessary for consultation; and

• access to the patient’s entire mobile contact list.

The request is transmitted through a registered Consent Manager, and the patient selects “Allow.”

The Consent Manager’s involvement does not make contact-list access necessary for telemedicine. Under Section 6, consent remains limited to data necessary for the specified purpose. The Data Fiduciary cannot rely on the Consent Manager’s record to justify unnecessary collection.

3.2 Example: Invalid waiver

An insurer asks a customer to consent to policy processing and also “consent” to waive the right to complain to the Board.

Even if the Consent Manager accurately records acceptance, the attempted waiver remains invalid. A Consent Manager records and executes a consent instruction. It does not override the DPDPA or validate an unlawful term.

3.3 The Functional Consent Lifecycle

The lifecycle model in consists of consent collection, validation, updating, renewal and withdrawal. That is a useful way to design the platform, provided each function is aligned with the Act and final Rules.

4. Consent collection

Consent collection begins when a Data Fiduciary proposes processing that relies on consent.

The Consent Manager should receive a structured request containing, at minimum:

• identity of the requesting Data Fiduciary;

• identity or authenticated reference of the Data Principal;

• notice presented by the Data Fiduciary;

• itemised personal data requested;

• specified purpose;

• goods, services or uses enabled;

• duration or validity parameters, where applicable;

• identity of the Data Fiduciary holding the data, if different;

• recipient or transferee Data Fiduciary;

• status of the request; and

• time of submission.

The interface should then present the request in a manner that allows a real choice. Optional purposes should not be silently combined with processing necessary for the requested service.

4.1 Example: Shopping and marketing

An online retailer needs:

• name and delivery address to fulfil an order;

• email address to provide order updates; and

• purchase history for optional personalised promotions.

The Consent Manager should not present one permission stating:

“Allow use of your data for service improvement and related purposes.”

A meaningful architecture would distinguish:

• order fulfilment;

• order communication; and

• optional personalised marketing.

The Data Principal should be able to refuse marketing without necessarily losing the ability to purchase the product, unless the Data Fiduciary can demonstrate a lawful and necessary connection.

4.2 Clear affirmative action

No consent should be recorded merely because the Data Principal:

• opened the page;

• continued browsing;

• remained silent;

• failed to untick a preselected box; or

• did not respond before a timer expired.

The system needs an affirmative event, such as selecting a permission and submitting the choice.

The BRD correctly contemplates unselected defaults, granular choices, purpose-specific requests, language support and consent metadata. Those are appropriate design measures for supporting valid consent.

5. Consent artifact

After a valid instruction is received, the system should create a durable consent record, commonly called a consent artifact.

The Rules do not formally define this expression, but the BRD uses it to describe the technical record of a consent event. The artifact may contain:

• consent identifier;

• pseudonymous or authenticated Data Principal identifier;

• requesting Data Fiduciary;

• data-holding Data Fiduciary, where applicable;

• transferee Data Fiduciary;

• purpose identifier;

• data categories or fields covered;

• relevant notice version;

• date and time;

• language;

• action taken;

• consent status;

• consent method;

• duration, where applicable;

• withdrawal status;

• transfer confirmation; and

• integrity data such as a digital signature or hash.

The artifact is not the same as consent itself. Consent is the Data Principal’s legally valid agreement. The artifact is evidence of that agreement.

A technically valid artifact can still record legally defective consent. For example, it may prove that a person clicked “Agree,” but if the notice concealed behavioural advertising, the record does not prove informed consent to that advertising.

6. Consent validation

Consent validation means checking whether a contemplated processing operation remains covered by an active consent.

The BRD envisages API-based checks using the Data Principal or session identifier, purpose identifier, timestamp and status. This is useful because consent should not be treated as a general permanent permission attached to the person. It must be checked against the particular purpose and data involved.

6.1 Example: Identity verification versus marketing

A customer consents to use of her identity information for account verification.

Three months later, the Data Fiduciary’s marketing system requests permission to use the same identity and demographic data for targeted advertising.

The platform should not return “valid” merely because an active consent record exists for the customer. It should compare the requested purpose with the authorised purpose.

The result should be:

• valid for identity verification within the approved scope;

• invalid for targeted advertising unless a separate valid consent or another lawful ground exists.

6.2 Example: Data outside the approved scope

A user authorises sharing of the previous three months of bank transactions for loan assessment. The recipient requests five years of transactions.

Even though the purpose matches, the requested data exceeds the authorised scope. Validation should fail or require a new consent request covering the enlarged data set and explaining why it is necessary.

6.3 What validation should not do

Consent validation should not become the Consent Manager’s determination that every legal condition for processing has been satisfied. The Consent Manager can validate the recorded instruction against structured parameters. The Data Fiduciary remains responsible for:

• necessity;

• lawfulness;

• accuracy;

• security;

• retention;

• processor governance;

• compliance with children’s-data rules; and

• consistency between the notice and actual processing.

A “valid” API response means that the relevant consent instruction appears active within the recorded parameters. It does not operate as a regulatory clearance for the Data Fiduciary’s processing.

7. Consent update

An update occurs where the Data Principal changes an existing choice or the Data Fiduciary proposes a material change to the processing.

The system should distinguish between:

• an update initiated by the Data Principal; and

• a new or revised consent request initiated by the Data Fiduciary.

The Data Fiduciary cannot unilaterally update an existing consent to cover a new purpose.

7.1 Example: User-initiated update

An individual has consented to:

• email marketing;

• SMS marketing; and

• personalised recommendations.

She later switches off SMS marketing but retains the other two permissions.

The Consent Manager should:

1. authenticate the instruction;

2. preserve the previous consent record;

3. create a new version or status entry;

4. mark SMS marketing as withdrawn;

5. retain email marketing and recommendations as active;

6. notify the relevant Data Fiduciary;

7. record delivery and acknowledgement; and

8. show the updated state in the dashboard.

This illustrates why purposes must be sufficiently granular. If all marketing activity had been stored as one undifferentiated consent, the platform could not reliably implement a purpose-specific change.

7.2 Example: Data Fiduciary changes purpose

A fitness application originally obtained consent to use activity data to generate personal fitness reports. It later wishes to use the data to train a commercial predictive model.

The application cannot classify this as an administrative update. It must issue a fresh or revised notice explaining:

• the new model-training purpose;

• data involved;

• relevant use;

• any sharing;

• effect on the individual; and

• available choice.

No processing for the new purpose should begin merely because the Data Principal consented to fitness reporting.

8. Consent renewal

The BRD provides a renewal flow for consents having expiry dates. This can be a valuable governance function, but the DPDPA does not state that every consent automatically expires after a universal period or must be renewed annually. “Consent renewal” should therefore be treated as a system feature used where:

• the original consent is expressly time limited;

• a sectoral law requires renewal;

• the purpose or processing context has materially changed;

• the Data Fiduciary adopts periodic refresh as a compliance measure; or

• circumstances indicate that the old consent no longer reliably reflects the Data Principal’s informed choice.

8.1 Example: Time-limited research access

A Data Principal authorises access to specified health records for a six-month research project.

Before expiry, the platform may notify her that the project seeks a further six months. The original consent should not be silently extended. The Data Principal should receive the relevant current information and make a new affirmative choice.

8.2 Example: No artificial renewal needed

A customer gives valid consent to process an address for delivery of an order. Once the order is completed and the purpose is served, the issue is not annual renewal of consent. The Data Fiduciary should determine whether continued retention is permitted or required under the Act or another law.

A system should not use endless renewal reminders to preserve personal data after the specified purpose has ended.

9. Consent withdrawal

Withdrawal is the most important ongoing control provided through a Consent Manager. Section 6 allows the Data Principal to withdraw consent at any time, with ease comparable to that with which consent was given.

A properly designed withdrawal process should:

1. display active consents clearly;

2. allow selection of the relevant purpose;

3. explain genuine service consequences;

4. authenticate the instruction proportionately;

5. record the withdrawal and timestamp;

6. notify the requesting Data Fiduciary;

7. route the change to relevant systems;

8. obtain or monitor acknowledgement;

9. update the dashboard; and

10. preserve the historical record.

9.1 Example: Withdrawal from advertising only

A banking customer withdraws consent for personalised promotions but continues using her account.

The bank may continue processing necessary for:

• account operation;

• legal obligations;

• fraud prevention under an applicable ground; and

• other lawfully supported purposes.

It must stop processing based solely on the withdrawn marketing consent.

Withdrawal is not necessarily deletion of every record. The legal effect depends on whether another provision of the DPDPA or another law requires or permits continued processing.

9.2 Example: Withdrawal affects a service

A user gives consent to process precise location data for live navigation. She later withdraws that consent.

The navigation feature may stop functioning because location processing is necessary for it. The service consequence can be explained, but the platform should not threaten unrelated account deletion or loss of previously purchased products merely to discourage withdrawal.

9.3 Timing qualification

The BRD repeatedly uses expressions such as “immediate cessation” and “real-time withdrawal.” These are desirable operational objectives, but Section 6(6) requires cessation within a reasonable time, subject to processing authorised or required under the Act or another law. A system architecture may aim for real-time propagation, but the legal commentary should not convert that design target into an absolute statutory rule for every downstream system.

9.4 Data Sharing Without Reading the Data

10. Data-blind operation

Part B requires the Consent Manager to ensure that personal data is made available or shared in a way that does not permit the Consent Manager to read its contents.

This is a defining feature of the statutory model.

The Consent Manager should be able to know that:

• a request was made;

• it involved a specified purpose;

• a particular category of data was requested;

• the Data Principal granted or denied consent;

• a transfer instruction was issued; and

• the sharing event was completed.

It should not ordinarily be able to read the underlying:

• bank statement;

• medical report;

• identity document;

• insurance record;

• employment file; or

• transaction data.

10.1 Example: Sealed digital envelope

The model may be understood as a sealed digital envelope.

The Consent Manager verifies that the Data Principal has authorised Bank B to send a specified statement to Lender A. It passes the instruction and records the event. The statement itself travels through an encrypted channel that the Consent Manager cannot decrypt.

The Consent Manager sees the permission and routing metadata, not the contents inside the envelope.

10.2 Architectural implications

The platform may use measures such as:

• end-to-end encryption between Data Fiduciaries;

• tokenised references;

• digitally signed consent instructions;

• purpose-bound access tokens;

• short-lived authorisation credentials;

• cryptographic integrity controls; and

• separation between consent metadata and data-transfer infrastructure.

The Act does not mandate one particular technical architecture. The design must achieve the legal result that the contents are not readable by the Consent Manager.

10.3 Role implications

If the Consent Manager reads, analyses or monetises the underlying data, it may:

• breach Part B;

• undermine registration conditions;

• create a personal data breach risk;

• cease acting neutrally;

• assume an additional Data Fiduciary role for its own processing purpose; and

• expose itself to Board action.

10.4 Registration Conditions in Part A

11. Indian incorporated company

Only a company incorporated in India may be registered.

This excludes direct registration of:

• an individual;

• partnership;

• unincorporated association;

• foreign corporation acting only through an overseas entity; or

• limited liability partnership.

An overseas technology provider may supply technology to an eligible Indian applicant, subject to the prohibition on subcontracting regulated obligations and other applicable requirements. The registered entity itself must be an Indian company and must retain responsibility for the regulated function.

12. Technical, operational and financial capability

An applicant must demonstrate sufficient capacity to discharge the role continuously and securely.

12.1 Technical capacity

This may include the ability to provide:

• secure identity and authentication;

• interoperable consent exchange;

• reliable APIs;

• accurate consent-state management;

• withdrawal propagation;

• tamper-evident records;

• availability and resilience;

• incident detection;

• disaster recovery; and

• secure record export.

12.2 Operational capacity

This may include:

• trained personnel;

• support for Data Principals;

• incident response;

• complaint management;

• audit functions;

• governance;

• change control;

• vendor control;

• continuity planning; and

• regulatory reporting.

12.3 Financial capacity

The applicant must show that it can maintain the platform, security and governance obligations without becoming commercially dependent on a Data Fiduciary whose consent requests it is expected to handle independently.

The ₹2 crore minimum net-worth requirement is a threshold, not automatic proof of adequate financial capacity. The Board must also assess capital structure, earning prospects and the likely volume of business.

12.4 Example: Technically strong but undercapitalised applicant

An applicant has an advanced interoperable platform but minimal financial resources and no credible plan for incident response, audits or long-term record retention.

Meeting the technology requirement alone is insufficient. The platform must remain secure and operational over time, including during outages, investigations and business stress.

13. Sound management and integrity

The applicant’s financial condition and management must be sound, and its directors, key managerial personnel and senior management must have reputations and records of fairness and integrity.

The Board may therefore need to consider:

• fraud findings;

• regulatory sanctions;

• corporate-governance failures;

• insolvency history;

• data misuse;

• serious cybersecurity failures;

• undisclosed related-party arrangements; and

• misconduct involving trust or dishonesty.

The nature of the Consent Manager’s function justifies this scrutiny. It will control the instructions that permit or stop personal-data processing across multiple organisations.

14. Corporate constitution

The memorandum and articles of association must embed the conflict-of-interest obligations specified in Part B and require supporting policies and procedures.

Those provisions may be amended only with the Board’s prior approval.

This prevents a Consent Manager from obtaining registration on the strength of a governance commitment and later weakening it through an internal corporate amendment.

15. Independent certification

The applicant’s interoperable platform must be independently certified against the standards and assurance framework published by the Board.

Certification should demonstrate both:

• conformity of the platform with the relevant data-protection and assurance standards; and

• existence of technical and organisational measures supporting the statutory transparency obligations.

The Board’s standards will therefore be important in translating legal requirements into testable technical controls. Registration applicants must monitor the Board’s website because the applicable framework may be published or updated there.

Certification should not be treated as a one-time immunity certificate. The Consent Manager must continue satisfying the conditions of registration and remain subject to audits, information requests and Board directions.

15.1 Continuing Obligations in Part B

16. Seven-year records

The Consent Manager must maintain records of:

• consents given;

• consents denied;

• consents withdrawn;

• notices accompanying or preceding requests; and

• sharing with transferee Data Fiduciaries.

These records must be retained for at least seven years, or longer if:

• agreed between the Data Principal and Consent Manager; or

• required by law.

This is a specific retention rule for consent-management records. It should not be confused with authority to retain the substantive personal data transferred between Data Fiduciaries.

16.1 Why denied consent must be recorded

Suppose an insurer claims that the Data Principal authorised marketing. The Consent Manager’s records show that she expressly denied that purpose.

The denial record is therefore as important as the record of consent. It protects the Data Principal and assists in resolving disputes.

16.2 Why the notice must be preserved

A timestamp showing “consent granted” is insufficient without evidence of what the Data Principal was told.

The preserved notice helps show:

• requested data;

• specified purpose;

• goods, services or uses described;

• rights information;

• language;

• version; and

• terms presented when the choice was made.

Still, the record proves presentation, not legal adequacy. A vague or misleading notice remains defective even if perfectly archived.

17. Data Principal access and machine-readable export

The platform must allow the Data Principal to access her consent history and, on request and in accordance with its terms of service, obtain the record in machine-readable form.

A proper dashboard should show:

• requesting Data Fiduciary;

• purpose;

• covered data;

• notice;

• date;

• status;

• previous changes;

• withdrawal;

• recipient Data Fiduciary; and

• sharing history.

The BRD proposes search, filtering and export through formats such as PDF and CSV. Search and filtering are useful. For statutory machine readability, a structured format such as CSV or JSON is generally more suitable than an image-only PDF.

The terms of service may regulate authentication and delivery, but should not impose charges, delays or technical restrictions that make access ineffective.

18. No subcontracting or assignment of obligations

The Consent Manager cannot subcontract or assign performance of its statutory obligations.

This is stricter than an ordinary vendor-management rule. The registered company must remain the entity actually performing and controlling the regulated function.

It may still be practically necessary to use:

• data-centre infrastructure;

• cloud hosting;

• cybersecurity tools;

• telecommunications;

• independent auditors; or

• ordinary professional services.

But it should not transfer the core statutory role, including:

• receipt and execution of consent instructions;

• maintenance of statutory records;

• withdrawal management;

• fiduciary decisions;

• conflict management;

• transparency duties; or

• regulatory accountability.

Example

A registered Consent Manager contracts another company to run the entire platform, manage consent records, execute withdrawals and communicate with Data Principals, while the registered company exists only on paper.

That arrangement is likely inconsistent with the prohibition because the statutory obligations have effectively been outsourced.

19. Security safeguards

The Consent Manager must maintain reasonable security safeguards.

Even though it should not read the transferred data, it holds extremely sensitive control information. An attacker who compromises the platform could:

• fabricate consent;

• redirect data transfers;

• change recipient identities;

• suppress withdrawal;

• create false historical records;

• impersonate Data Principals; or

• monitor relationships between individuals and services.

The BRD appropriately proposes:

• role-based access;

• multifactor authentication;

• audit trails;

• encryption;

• tamper detection;

• cryptographic hashes;

• event logging; and

• secure grievance submission.

However, no single technology mentioned in the BRD should be treated as universally mandated by Rule 4. For example, TLS 1.3 is a sensible design standard, but Rule 4 does not expressly prescribe that protocol version. The legal obligation is to maintain reasonable safeguards appropriate to the risks, while applicable Board standards may provide greater specificity.

20. Fiduciary responsibility to the Data Principal

The Consent Manager must act in a fiduciary capacity.

In simple terms, it must act loyally for the Data Principal and must not exploit its position to favour a Data Fiduciary or itself.

This requires more than technical accuracy. It affects:

• interface design;

• business incentives;

• prioritisation of instructions;

• conflict management;

• use of metadata;

• commercial partnerships;

• notifications;

• complaint handling; and

• withdrawal execution.

20.1 Example: Biased interface

A Consent Manager receives a higher fee whenever users grant marketing consent. Its interface displays “Accept and continue” prominently but hides “Deny” behind several screens.

Even if consent events are accurately recorded, the business model and interface undermine neutrality and may conflict with the fiduciary obligation.

20.2 Example: Neutral interface

A compliant interface presents:

• grant;

• deny; and

• review details with comparable visibility. It explains the service effect neutrally and does not repeatedly pressure users who refuse optional processing.

21. Conflict-of-interest controls

A Consent Manager must avoid conflicts with Data Fiduciaries, including conflicts involving promoters and key managerial personnel.

It must prevent conflicts arising from its directors, senior management and key managerial personnel holding:

• directorships;

• employment;

• financial interests;

• beneficial ownership; or

• material pecuniary relationships in or with Data Fiduciaries.

21.1 Example: Bank-controlled Consent Manager

A bank establishes or controls a Consent Manager that handles requests from competing banks. Its management has financial incentives to favour its parent bank, delay rival requests or steer users toward affiliated products.

Part B is designed to prevent precisely this type of compromised neutrality.

21.2 Required governance

A robust conflict framework should include:

• ownership screening;

• declarations of interests;

• beneficial-ownership checks;

• related-party registers;

• pre-appointment diligence;

• periodic certifications;

• recusal;

• restrictions on commercial incentives;

• independent compliance oversight; and

• escalation to the Board where necessary.

22. Public transparency

The Consent Manager must publicly disclose:

• promoters;

• directors;

• key managerial personnel;

• senior management;

• shareholders holding more than two per cent;

• specified corporate interests of promoters and management; and

• other information directed by the Board.

These disclosures allow Data Principals and the Board to understand who owns and influences the platform.

The two per cent threshold is intentionally low. A person need not possess control before disclosure is required.

Disclosures should be:

• easy to find;

• current;

• understandable;

• historically traceable where changes occur; and

• updated through a defined governance process.

The final corrigendum corrected the Companies Act reference in the Schedule from “18 or 2013” to “18 of 2013.” The corrected final legal text should be used.

23. Audits

The Consent Manager must maintain effective audit mechanisms and report audit outcomes to the Board periodically and whenever directed.

Audit coverage must include:

• technical and organisational controls;

• systems and procedures;

• safeguards;

• registration conditions; and

• compliance with the Act and Rules.

A meaningful audit would examine:

• whether consents can be fabricated or altered;

• whether withdrawals are transmitted and acknowledged;

• whether notice versions are preserved;

• whether shared data remains unreadable;

• whether statutory records are complete;

• whether conflicts are identified;

• whether public disclosures are accurate;

• whether access rights are functioning;

• whether retention and deletion rules operate correctly;

• whether system administrators can alter records improperly;

• whether incidents are detected and handled;

• whether the platform remains interoperable; and

• whether Board directions have been implemented.

The BRD’s immutable logging model can support these obligations. Its proposed metadata includes user ID, purpose ID, action, timestamp, status, initiator, source IP and integrity hash. This is a valuable starting point, but audit architecture should also record notice versions, Data Fiduciary identifiers, transfer instructions, acknowledgements, failures, retries, administrative changes and security events.

24. Change of control

The Consent Manager cannot transfer control through sale, merger or another arrangement without the Board’s prior approval.

This allows the Board to examine whether the incoming controller continues to satisfy:

• Indian-incorporation requirements;

• financial soundness;

• integrity;

• independence;

• conflict standards;

• security expectations;

• technical capability; and

• Data Principal interests.

Example

An independent Consent Manager agrees to be acquired by a large Data Fiduciary onboarded to its platform.

The acquisition cannot simply close under ordinary corporate approvals. The Board’s prior approval is required because the transaction may fundamentally affect the Consent Manager’s neutrality.

The Board may approve, reject or impose conditions, including structural separation, governance protections or divestment of conflicting interests.

24.1 Board Supervision

25. Corrective directions

If the Board believes that a Consent Manager is not adhering to its conditions or obligations, it may:

• give it an opportunity of being heard;

• identify the non-adherence; and

• direct corrective measures.

Corrective measures may address:

• defective interfaces;

• incomplete records;

• unprocessed withdrawals;

• weak security;

• inaccurate public disclosures;

• conflicts;

• audit failures;

• platform outages; or

• non-compliance with certification standards.

The hearing allows the Consent Manager to explain the facts, dispute the finding or propose remediation.

26. Suspension or cancellation

Where necessary to protect Data Principals, the Board may suspend or cancel registration after hearing the Consent Manager and recording reasons.

Suspension may be appropriate where the risk can be contained during remediation. Cancellation may be appropriate where the Consent Manager:

• lacks continuing financial capacity;

• loses required certification;

• suffers serious governance failure;

• conceals conflicts;

• repeatedly fails to execute withdrawals;

• misuses metadata;

• reads underlying personal data;

• disregards Board directions; or

• cannot safely continue operating.

The Board may also issue directions to protect Data Principals.

Those directions could address:

• preservation of records;

• continued access to consent history;

• processing of pending withdrawals;

• suspension of new consent requests;

• migration to another registered platform;

• notification to onboarded Data Fiduciaries;

• secure transfer or deletion of records; and

• continuity during exit.

Cancellation should not cause consent records to disappear or leave Data Principals unable to establish what permissions they granted or withdrew.

27. Board information requests

The Board may require any information necessary for administering Rule 4.

A Consent Manager should therefore be able to produce:

• corporate and ownership information;

• financial records;

• certifications;

• audit reports;

• incident records;

• consent statistics;

• withdrawal-performance data;

• complaint records;

• conflict declarations;

• service-availability statistics;

• subcontractor and infrastructure information;

• change-management records; and

• evidence of compliance with Board directions.

Regulatory reporting should be supported by reliable records generated through ordinary operations rather than assembled only after a Board request.

27.1 Relationship with Other Participants

28. Continuing responsibility of Data Fiduciaries

A Data Fiduciary remains responsible for compliance even where consent is managed through a registered Consent Manager.

The Consent Manager does not assume responsibility for:

• identifying the correct lawful basis;

• deciding the purpose;

• limiting collection to necessary data;

• ensuring processing accuracy;

• maintaining the Data Fiduciary’s security;

• selecting and controlling Processors;

• satisfying children’s-data requirements;

• responding to Data Principal rights; or

• deleting data when required.

A Data Fiduciary cannot answer a regulatory inquiry merely by saying:

“The Consent Manager approved the processing.”

The Consent Manager does not approve the processing. It communicates and records the Data Principal’s consent decision.

29. Relationship with Data Processors

The BRD frequently refers to direct notifications from the CMS to Data Processors. This may be useful for system design, but the legal allocation of responsibility requires care.

Under the DPDPA, a Data Processor acts on behalf of a Data Fiduciary. The Data Fiduciary remains responsible for ensuring that processing undertaken on its behalf complies with the Act.

A Consent Manager may technically alert Processors where the operational arrangement permits it. However:

• the Data Fiduciary must ensure that its Processors stop consent-based processing when required;

• the Consent Manager should not be treated as assuming the Data Fiduciary’s responsibility;

• Processor instructions should remain governed by the Data Fiduciary’s authority and contract; and

• acknowledgements should flow back so the Data Fiduciary can verify cessation.

The cleaner operational model may be:

1. Consent Manager records withdrawal.

2. Consent Manager notifies the relevant Data Fiduciary.

3. The Data Fiduciary propagates the instruction to its Processors.

4. Processors confirm implementation.

5. The Data Fiduciary updates the Consent Manager or compliance record.

Direct automated routing to Processors may supplement this chain, but should not obscure legal accountability.

29.1 Assessment of the Proposed CMS Functions

30. User dashboard

The BRD’s dashboard concept aligns strongly with the statutory scheme. A well-designed dashboard should allow the Data Principal to see:

• pending requests;

• active consents;

• denials;

• withdrawals;

• expired or time-limited consents;

• notices;

• Data Fiduciaries involved;

• purposes;

• information-sharing events;

• status of withdrawal;

• export functions; and

• complaints concerning the Consent Manager.

The dashboard should not combine every privacy right against every Data Fiduciary unless the participating systems and legal responsibilities support that function.

31. Grievances and rights requests

The BRD proposes using the CMS dashboard for:

• access;

• correction;

• erasure;

• grievance submission;

• tracking; and

• escalation.

This is potentially useful, but the statutory Consent Manager role is specifically centred on consent. Rule 4 does not automatically make a Consent Manager the universal grievance authority for every onboarded Data Fiduciary.

A correct system should distinguish:

• a complaint about the Consent Manager, such as failure to process withdrawal;

• a consent instruction for a Data Fiduciary;

• a Data Principal rights request directed to a Data Fiduciary;

• a grievance against a Data Fiduciary; and

• a complaint to the Board after the applicable statutory process.

The Consent Manager may route or facilitate these matters if properly designed, but the responsible Data Fiduciary or Board remains the legal decision-maker.

32. Cookie consent

The BRD includes a cookie-consent module with essential, performance, analytics and marketing categories. This may be integrated into a broader consent platform, but not every cookie automatically involves personal data or requires consent under the DPDPA. The legal analysis depends on:

• whether the cookie data relates to an identifiable individual;

• which entity determines the purpose and means;

• the purpose of processing;

• the applicable ground under the DPDPA; and

• other applicable laws.

Where consent is used, optional analytics and marketing technologies should not ordinarily activate before valid consent is obtained. Necessary technologies should be described accurately and not used as a category into which unrelated tracking is placed.

Cookie management is a useful CMS capability, but it is not the defining statutory function of a registered Consent Manager.

33. Notifications and alerts

The BRD proposes notifications for:

• consent grants;

• denials;

• updates;

• withdrawals;

• renewal reminders;

• data requests;

• processor alerts; and

• unacknowledged actions.

A robust notification system should distinguish:

• confirmation that the Consent Manager recorded an instruction;

• confirmation that the Data Fiduciary received it;

• confirmation that operational implementation occurred; and

• failure or delay requiring escalation.

Example

For example, telling a Data Principal that withdrawal is “complete” immediately after recording her click may be misleading if the instruction has not reached the Data Fiduciary. The platform should display accurate status labels such as:

• withdrawal submitted;

• delivered to Data Fiduciary;

• acknowledged;

• implementation confirmed; or

• escalation required.

34. Retention configuration

The BRD contemplates configurable retention policies and automatic deletion. This is appropriate, but the system must distinguish several types of records:

• seven-year Consent Manager records;

• security and audit logs;

• complaint records;

• temporary routing metadata;

• substantive personal data, which should ordinarily remain unreadable;

• records subject to legal hold; and

• records whose longer retention is required by another law.

Automatic deletion should not erase statutory consent records before the seven-year minimum. Conversely, the seven-year rule should not be treated as authority to retain all personal data passing through the ecosystem for seven years.

34.1 Important Legal Qualifications to the BRD

The BRD provides a useful model, but the following points should be corrected or treated carefully:

1. “Consent Management System” and “Consent Manager” are not interchangeable. A system may be used internally by a Data Fiduciary without the operator becoming a registered Consent Manager. The statutory title applies only after Board registration.

2. Consent renewal is not universally mandated. It is appropriate for expiring or materially changed consent, but not every consent requires periodic renewal under a general statutory timetable.

3. Consent does not necessarily have a fixed duration. Validity depends on purpose, scope, notice, withdrawal and applicable circumstances.

4. Withdrawal need not erase every record immediately. Consent-based processing must cease within a reasonable time, but processing required or permitted by another provision or law may continue.

5. The Consent Manager cannot itself stop every Processor by legal command. Operational alerts may be automated, but the Data Fiduciary retains accountability for its Processors.

6. A consent-validation response is not a legal clearance. It confirms the platform’s recorded consent state, not compliance with every DPDPA obligation.

7. A stored artifact does not cure invalid consent. The quality of the notice and consent request remains decisive.

8. The seven-year period concerns specified consent-management records. It does not permit readable storage of the substantive data being shared.

9. “Immutable” should not mean incapable of lawful correction. Historical records should be tamper-evident and append-only, while an erroneous entry may be corrected through a traceable new entry rather than silently overwritten.

10. Specific technical controls in the BRD are design recommendations unless prescribed elsewhere. Features such as TLS 1.3, real-time synchronisation and cryptographic erasure are valuable, but should not automatically be presented as verbatim Rule 4 requirements.

34.2 End-to-End Example

Consider a Consent Manager called CM-One, registered with the Board.

A Data Principal, Asha, uses CM-One. Three Data Fiduciaries are onboarded:

• Bank P;

• Insurer Q; and

• Financial Advisor R.

Financial Advisor R requests access to six months of Asha’s transaction information from Bank P to prepare a financial plan.

The compliant flow is:

1. Request creation: R creates a consent request identifying the transaction data, six-month period, financial-planning purpose and service enabled.

2. Notice presentation: CM-One displays R’s notice in Asha’s selected language.

3. Data Principal decision: Asha reviews the request and positively grants consent.

4. Artifact creation: CM-One records the notice version, purpose, data scope, parties, timestamp and consent status.

5. Instruction routing: CM-One sends the signed instruction to Bank P.

6. Data-blind transfer: Bank P sends the encrypted data directly to R through an architecture under which CM-One cannot read it.

7. Sharing record: CM-One records that the sharing event occurred.

8. Dashboard access: Asha can view the active consent, notice and sharing details.

9. Validation: If R later seeks updated data for the same purpose, it checks whether the consent remains active and within scope.

10. Purpose expansion rejected: If R attempts to use the information for insurance advertising, the existing consent does not cover that purpose.

11. Withdrawal: Asha withdraws the financial-planning consent through CM-One.

12. Propagation: CM-One records the withdrawal and notifies R and, as necessary, Bank P.

13. Cessation: R stops consent-based processing within a reasonable time and instructs its Processors accordingly, unless retention of particular records is required by law.

14. Evidence: CM-One preserves the notice, grant, sharing and withdrawal records for at least seven years.

15. No content access: Throughout the process, CM-One manages permission but never reads Asha’s transaction entries.

This example captures the central legal model: the Consent Manager controls the permission pathway, not the substantive commercial purpose or the underlying personal data.

34.3 Enforcement and Exposure

A Consent Manager may face several forms of regulatory action:

• corrective directions under Rule 4;

• requests for information;

• suspension;

• cancellation;

• protective directions for Data Principals; and

• penalty proceedings for a significant breach of the Act or Rules.

A significant breach of Rule 4 or the First Schedule may fall within the residual penalty entry in the DPDPA Schedule, carrying a maximum of ₹50 crore. The amount is not automatic. The Board must follow the statutory inquiry process and apply Section 33’s penalty factors.

Failure may be particularly serious where the Consent Manager:

• fabricates or alters consent;

• fails to process withdrawals;

• exposes consent records;

• reads underlying personal data;

• conceals ownership conflicts;

• misleads Data Principals;

• transfers control without approval;

• subcontracts its regulated function;

• loses required certification;

• disobeys Board directions; or

• cannot produce reliable statutory records.

34.4 Concluding Commentary

Rule 4 creates a specialised, Board-regulated institution intended to restore practical control over consent to the Data Principal.

The Consent Manager’s role is to operate a central and interoperable platform through which the Data Principal can:

• understand requests;

• grant or deny consent;

• review active and historical permissions;

• authorise controlled sharing;

• change or withdraw consent; and

• obtain reliable records of those events.

It must perform that role without reading the contents of the personal data being transferred and without becoming commercially aligned with the Data Fiduciaries whose requests it carries.

The statutory framework supports trust through:

• Indian incorporation;

• minimum financial strength;

• management integrity;

• independent certification;

• data-blind technology;

• seven-year records;

• machine-readable access;

• security;

• fiduciary responsibility;

• conflict prevention;

• ownership transparency;

• audits;

• Board supervision;

• controlled changes in ownership; and

• suspension or cancellation where necessary.

The most important allocation of responsibility is:

• the Data Principal makes the consent decision;

• the Consent Manager communicates, manages and records that decision;

• the Data Fiduciary determines the processing purpose and remains legally accountable for the processing;

• the Data Processor acts on the Data Fiduciary’s instructions; and

• the Board registers and supervises the Consent Manager.

A Consent Manager is therefore neither a data marketplace nor an approval authority for processing. It is a regulated fiduciary infrastructure through which the Data Principal’s choices are expressed and operationalised.

Key point

The defining idea of the Consent Manager framework is simple: one trusted platform should allow an individual to control permissions across many Data Fiduciaries, while the platform itself remains neutral, auditable, interoperable and unable to read the personal data whose sharing it facilitates.