Rule 14 - Rights of Data Principals

Rule 14 creates the operational framework through which Data Principals may exercise their rights under the Digital Personal Data Protection Act, 2023. The Act creates the substantive rights, while Rule 14 requires Data Fiduciaries and, where relevant, Consent Managers to make those rights practically discoverable and usable.

The Rule addresses four connected matters:

• public disclosure of the procedure for exercising rights;

• identification of the Data Principal making the request;

• establishment of an effective grievance-redressal system with a published response period not exceeding ninety days; and

• nomination of another individual to exercise the Data Principal’s rights following her death or incapacity.

Rule 14 should principally be read with Sections 11 to 14 of the DPDPA. Those provisions deal respectively with access to information about personal-data processing, correction and erasure, grievance redressal, and nomination. It must also be read with the rules concerning notices, consent withdrawal, contact information, security, retention and erasure. The final DPDP Rules were notified under G.S.R. 846(E) dated 13 November 2025.

Rule 14 is scheduled to come into force eighteen months after publication of the final Rules, corresponding to 13 May 2027.

1. Rule 14 as an operational rights framework

A statutory right is ineffective if the Data Principal cannot determine:

• where to submit a request;

• what information is needed to identify her;

• which Data Fiduciary is responsible;

• how the request will be authenticated;

• when a response should be expected;

• how an unsatisfactory response may be challenged; or

• how a nominated person can act after death or incapacity.

Rule 14 requires those practical details to be made visible before the Data Principal begins the process.

It does not create a single government-prescribed request form or require all organisations to use identical technology. A Data Fiduciary may provide a rights portal, an in-app mechanism, an authenticated account facility, email, or another suitable channel. The chosen method must nevertheless enable the right in substance. It must not be designed to discourage, confuse or exclude Data Principals.

The Rule should therefore be understood as an obligation of effective rights enablement, not merely an obligation to publish procedural text.

An organisation may formally publish an email address and still fail in substance if:

• the address is unmonitored;

• requests are repeatedly lost;

• the Data Principal is asked for identifiers the organisation never issued;

• verification is disproportionately difficult;

• the portal does not accommodate former users;

• requests concerning Processor-held data are ignored;

• or grievances remain unanswered for the entire published period without meaningful action.

1.1 Relationship with the substantive rights under the Act

2. Access to information about personal-data processing

Section 11 gives a Data Principal the right, subject to the statutory conditions, to obtain specified information from a Data Fiduciary to whom she has previously given consent for processing of her personal data.

The information may concern:

• a summary of the personal data being processed;

• the processing activities undertaken;

• identities of other Data Fiduciaries and Data Processors with whom the personal data has been shared;

• and a description of the personal data shared.

Rule 14 supplies the means by which the request is to be made. It does not reduce the scope of the statutory right to whatever happens to appear in the Data Fiduciary’s customer-facing account.

A meaningful access process must therefore reach relevant processing environments, which may include:

• active customer systems;

• mobile applications;

• internal databases;

• marketing platforms;

• analytics environments;

• identity and verification systems;

• customer-support records;

• relevant archives;

• and information held by Data Processors on the Data Fiduciary’s behalf.

2.1 Illustration: Fragmented customer information

A customer asks an online retailer for information about the personal data being processed. The retailer supplies only the name and address visible in the customer’s online profile.

The retailer also processes:

• order history;

• customer-support correspondence;

• marketing preferences;

• fraud indicators;

• device and login information;

• product recommendations;

• and information through delivery and payment Processors.

A response confined to the visible account profile may not address the processing actually undertaken. Rule 14 requires an operational mechanism capable of supporting the substantive Section 11 response, not merely exporting basic account fields.

2.2 Limits remain relevant

The access right is governed by the Act and cannot be interpreted as an unrestricted entitlement to:

• another person’s personal data;

• security credentials;

• protected investigation information;

• proprietary software;

• source code;

• legally privileged communications;

• or every internal document in which the individual’s name appears.

However, a Data Fiduciary should not use confidentiality or technical complexity as a general reason to refuse useful information about processing. Where information must be withheld or limited, the response should explain the basis in clear terms.

3. Correction, completion and updating

Section 12 enables a Data Principal to request correction of inaccurate or misleading personal data, completion of incomplete data and updating of personal data.

Rule 14 requires the Data Fiduciary to publish the route and identifiers needed to make such a request.

Correction is not limited to changing a name or mobile number in the user profile. Personal data may exist in several connected systems, and an inaccurate record may continue to produce effects even after the visible account information has been corrected.

3.1 Illustration: Address correction across systems

A customer updates her address through a mobile application. The active profile changes, but the old address remains in:

• the delivery-management system;

• the customer-support platform;

• a marketing database;

• and a fraud-detection system.

A properly designed rights process should determine where correction must propagate. Merely updating one interface may leave materially inaccurate personal data in active processing.

3.2 Historical records

Correction does not necessarily require rewriting an accurate historical record.

Suppose a customer changes her address after a transaction. The Data Fiduciary should update the current account information but may need to preserve the earlier address on an invoice as an accurate record of the transaction when it occurred.

The response should distinguish between:

• correcting an inaccurate current record;

• updating a record for future use; and

• preserving an accurate historical or legally required record.

3.3 Inferences and opinions

A Data Fiduciary may process factual information, derived information, opinions, scores or classifications. The extent to which a Data Principal may require a derived assessment to be “corrected” can be more complex than correction of an objective fact.

Example

For example, an individual can demonstrate that:

• her date of birth is wrong;

• a loan is incorrectly marked unpaid;

• an account does not belong to her;

• or an attendance event was attributed to the wrong employee.

Those are factual inaccuracies.

By contrast, disagreement with a properly identified professional opinion or risk assessment does not necessarily make it factually inaccurate. However, the Data Fiduciary should still consider whether:

• the underlying data is accurate;

• the methodology applies correctly;

• the record is misleading without context;

• the opinion has become outdated;

• the individual’s objection should be recorded;

• or continued reliance creates a risk to her rights.

4. Erasure

Section 12 also provides for erasure, subject to retention necessary for the specified purpose or compliance with law.

Rule 14 requires an accessible route to make the request, but it does not mean that every erasure request must result in immediate deletion of every record.

A proper erasure response requires the Data Fiduciary to separate:

• personal data no longer needed for the specified purpose;

• data retained only because law requires it;

• data required for an unresolved transaction or claim;

• records subject to a legal hold;

• security logs required for a prescribed period;

• Processor-held copies;

• active data;

• restricted archives;

• and backup copies.

4.1 Illustration: Closed customer account

A former customer requests erasure after closing an account.

The Data Fiduciary may be able to erase:

• marketing profiles;

• optional preferences;

• abandoned application information;

• behavioural personalisation data;

• and information no longer needed for service delivery.

It may nevertheless need to retain selected:

• invoices;

• transaction records;

• tax records;

• consent-and-withdrawal evidence;

• complaint records;

• or security logs for the applicable legal period.

The response should explain the distinction. Saying only that the request has been “completed” may be misleading if important records remain. Saying only that the request is “rejected due to legal requirements” may be equally inadequate if much of the data can be erased.

4.2 Processor copies

The Data Fiduciary cannot treat its own database as the complete erasure perimeter. Where personal data has been made available to a Data Processor, the Data Fiduciary must cause the Processor to erase it when the statutory erasure requirement applies.

The rights process should therefore integrate with:

• Processor instructions;

• subprocessor arrangements;

• deletion confirmation;

• data-return procedures;

• backup lifecycles;

• and contract termination.

4.3 Publicly explaining how rights may be exercised

5. The published mechanism

Rule 14 requires the Data Fiduciary and, where applicable, the Consent Manager to publish the means by which a Data Principal may request exercise of her rights.

The information should allow an ordinary user to understand:

• where the request may be submitted;

• what rights may be exercised;

• whether login is required;

• whether email or another channel is available;

• how former users may submit requests;

• what identification information is needed;

• whether supporting information may be required;

• what happens after submission;

• and where a grievance may be raised.

A vague statement such as “contact us regarding your privacy rights” may not be sufficient if the contact route is difficult to locate or the support team does not recognise statutory requests.

5.1 Prominence and accessibility

The procedure should be easy to find through the website or application. It should not be buried only in:

• lengthy terms of service;

• a legal-policy archive;

• an unrelated customer-support menu;

• a downloadable document;

• or a page unavailable without login.

Useful locations may include:

• the privacy notice;

• account settings;

• a dedicated privacy or rights centre;

• the consent dashboard;

• the help menu;

• and the grievance page.

Where the Data Fiduciary operates through both a website and an application, publishing through both channels is ordinarily the more reliable approach. A user should not have to leave the principal service environment to discover how to exercise a statutory right.

Accessibility also matters. A process dependent on an inaccessible CAPTCHA, a voice-only helpline or a visual interface incompatible with assistive technology may prevent some Data Principals from exercising rights.

5.2 Illustration: App-only service

A service operates almost entirely through a mobile application. Its rights procedure appears only on the parent company’s corporate website under “Legal Disclosures.”

Although the information technically exists online, it may not be prominently available to the actual users. The service should provide a visible route inside the application.

5.3 Identification of the requester

6. Purpose of the identifier requirement

A Data Fiduciary must be able to identify the Data Principal before disclosing, correcting or erasing account-specific personal data. Otherwise, the rights process itself could create a personal data breach.

Rule 14 permits the Data Fiduciary to specify particulars required to identify the requester under its terms of service. These particulars may include:

• customer identification file number;

• customer acquisition form number;

• application reference number;

• enrolment ID;

• email address;

• mobile number;

• licence number;

• username;

• or another identifier issued or used by the Data Fiduciary.

The identifier connects the request to the correct record. It does not by itself always prove that the person submitting the request is entitled to control that record.

Example

For example, knowledge of a customer number may help locate the account, but the Data Fiduciary may still need reasonable authentication before disclosing personal data.

6.1 Identification and authentication are related but distinct

Identification answers:

Which Data Principal and which records does this request concern?

Authentication answers:

Is the person submitting the request actually that Data Principal or someone lawfully entitled to act for her?

A rights workflow must address both questions in proportion to the risk.

6.2 Illustration: Profile correction

A securely logged-in customer asks to correct a spelling error in her address. Existing account authentication may be sufficient.

6.3 Illustration: Complete access request by email

A person sends an email requesting a complete summary of another customer’s financial processing and provides that customer’s publicly visible email address.

The address identifies the account but does not authenticate the requester. Further verification is necessary before disclosure.

7. Proportionate verification

Rule 14 should not be treated as authority to demand excessive identity documents from every requester.

Verification should be proportionate to:

• the nature of the right;

• sensitivity of the data;

• consequences of unauthorised disclosure or alteration;

• authentication already available;

• reliability of the communication channel;

• and evidence of impersonation risk.

If a Data Principal is already securely logged into her account, requiring a fresh copy of a passport or Aadhaar document may be excessive unless there is a specific heightened risk.

Conversely, a request to change an account’s registered mobile number, disclose financial records or erase an account containing valuable assets may justify stronger authentication.

The Data Fiduciary should seek additional information only where necessary and should explain why it is required.

7.1 Illustration: Excessive identification demand

A newsletter subscriber asks to withdraw consent and erase her email address. The Data Fiduciary requires a government identity document, a selfie and proof of address.

The organisation already knows the subscriber only through the email address and can send a confirmation link to that address. Collecting extensive identity evidence may create more privacy risk than the request itself and may unjustifiably obstruct the right.

7.2 Illustration: High-risk account takeover concern

A person asks a financial platform to change the registered email, mobile number and bank details and then erase the account history.

Because the request would alter all recovery channels and affect consequential information, stronger verification may be reasonable.

8. The Data Fiduciary cannot create arbitrary identifiers as barriers

The particulars required must be ones capable of identifying the person under the Data Fiduciary’s service arrangement.

A Data Fiduciary should not reject a request solely because the Data Principal cannot provide an obscure internal number that:

• was never communicated to her;

• is not readily available;

• has changed;

• or is not necessary to locate the record.

Alternative identifiers should be available where reasonably possible.

8.1 Illustration: Former customer without account access

A former customer no longer has access to the mobile number originally registered with the Data Fiduciary. She can provide her old number, customer reference, transaction information and current verified identity.

A rights process that insists on OTP verification through the inactive number and offers no alternative could make the right impossible to exercise.

The Data Fiduciary must balance fraud prevention with a realistic recovery and verification procedure.

8.2 Unknown or incomplete identifiers

A person may know that the organisation processes her data but may not know the relevant account number. This can occur where:

• an application was abandoned;

• data was collected offline;

• a lead was received from another person;

• the individual is included in CCTV footage;

• an employee record predates current systems;

• or a service provider holds the record under another identifier.

The organisation should make reasonable efforts to locate the information using the particulars available. Rule 14 should not be used to deny rights merely because the Data Principal does not know the Data Fiduciary’s internal data architecture.

8.3 Requests are directed to a Data Fiduciary previously given consent

9. The consent-based formulation

Rule 14(2) states that the Data Principal may make a request to the Data Fiduciary to whom she previously gave consent for processing.

This reflects the drafting of the substantive access and correction framework. It ensures that the request is directed to the Data Fiduciary responsible for the consent-based processing rather than to any entity that may incidentally hold the information.

However, the provision should not be read to mean that all processing outside consent is immune from every Data Principal right or grievance. The scope of each substantive right must be determined from the relevant section of the Act.

Example

For example:

• Section 11 describes access rights in relation to processing based on consent or certain legitimate uses;

• Section 12 governs correction and erasure in the statutory context stated there;

• Section 13 provides grievance redressal concerning acts or omissions of a Data Fiduciary or Consent Manager;

• and Rule 14(1) requires rights procedures to be published for Data Principals generally.

The legal basis for a particular processing operation should therefore be identified before deciding whether and how a right applies.

9.1 Requests should follow the responsible Data Fiduciary

Where a Data Processor receives a request directly, it should ordinarily:

• avoid making unauthorised disclosures;

• authenticate or route the request according to instructions;

• inform the responsible Data Fiduciary promptly;

• preserve relevant records;

• and assist the Data Fiduciary in fulfilling the request.

The Processor should not reject the request on the simplistic basis that “we are only a vendor” if its contract requires assistance. Nor should it disclose personal data without the Data Fiduciary’s authority.

9.2 Illustration: Payroll provider

An employee sends an access request directly to the employer’s payroll provider.

The employer is ordinarily responsible for deciding the response where the provider processes the information on the employer’s behalf. The provider should route the request and supply the employer with relevant payroll data and processing information in accordance with the contract.

9.3 The role of the Consent Manager

A Consent Manager does not replace the Data Fiduciary’s responsibility for the underlying processing.

Its role is to enable the Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform. Where the right or request concerns management of consent through that service, Rule 14 requires the Consent Manager to publish the applicable mechanism.

A Data Principal may therefore interact with:

• the Consent Manager regarding the giving, management, review or withdrawal of consent; and

• the Data Fiduciary regarding access, correction, erasure, processing explanations and grievances connected with the underlying processing.

The two should coordinate where a consent instruction sent through the Consent Manager affects processing by the Data Fiduciary.

9.4 Illustration: Withdrawal not implemented

A Data Principal withdraws marketing consent through a Consent Manager. The Consent Manager records and transmits the instruction, but the Data Fiduciary continues sending advertisements.

The grievance may involve both:

• whether the Consent Manager properly transmitted the instruction; and

• whether the Data Fiduciary properly acted upon it.

Each entity must maintain a clear procedure for the part of the process for which it is responsible.

The Data Principal should not be trapped between the two, with each directing her to the other without investigating its own role.

9.5 Grievance redressal

10. The published response period

Every Data Fiduciary and Consent Manager must publish the period within which it will respond to Data Principal grievances.

The period must be:

• reasonable in light of the organisation and grievance process; and

• no longer than ninety days.

Ninety days is therefore an outer ceiling, not a standard period that every organisation may automatically adopt for every grievance.

A simple complaint concerning failure to recognise consent withdrawal may require action much sooner. A complex grievance involving several Processors, historical systems and disputed facts may reasonably require more time.

The Data Fiduciary should establish service standards that account for urgency and complexity.

10.1 Illustration: Continuing marketing after withdrawal

A customer complains that promotional messages continue after consent withdrawal.

Waiting ninety days while advertisements continue would be difficult to justify merely because the published maximum is ninety days. The organisation should suppress the disputed processing promptly while investigating the cause.

10.2 Illustration: Complex historical sharing dispute

A former customer alleges that information collected several years ago was shared through multiple Processor chains and asks for investigation.

The grievance may require review of archived contracts, logs and system records. A longer response period may be reasonable, but it still cannot exceed the published period or the ninety-day statutory ceiling.

11. “Responding” requires a meaningful outcome

Rule 14 uses a period for responding to grievances. A purely automated acknowledgement sent immediately should not be treated as the completed grievance response if the issue remains unexamined.

A meaningful response should ordinarily:

• identify the grievance;

• state what was examined;

• explain the findings;

• describe action taken;

• state whether processing was corrected, stopped or retained;

• explain any refusal;

• provide the relevant privacy contact;

• and identify the available escalation mechanism.

An acknowledgement and a substantive response perform different functions.

The Data Fiduciary may acknowledge quickly and complete the investigation later within the published period. It should not close the grievance merely because a ticket number was generated.

11.1 Interim communication

If the investigation cannot be completed immediately, the organisation should provide reasonable updates, particularly where:

• the request concerns ongoing unauthorised processing;

• identity fraud is suspected;

• inaccurate information affects an important service;

• a Processor has not responded;

• or there is a risk of continuing harm.

Rule 14 does not expressly prescribe periodic updates, but effective grievance redressal may require them in serious cases.

11.2 Technical and organisational measures for grievance handling

Rule 14 expressly requires appropriate technical and organisational measures to ensure that grievances are answered within the published period.

This means that publishing “we respond within ninety days” is not enough. The organisation must build a system capable of meeting that commitment.

A functioning process should ensure that:

• grievances are captured regardless of entry channel;

• duplicate requests are identified without being discarded;

• dates and deadlines are recorded;

• urgent matters are prioritised;

• requests are assigned to accountable personnel;

• responsible departments and Processors are involved;

• identity verification is completed proportionately;

• overdue matters are escalated;

• responses are quality-reviewed;

• and closure is recorded.

11.3 Technical measures

Suitable technical arrangements may include:

• a case-management or ticketing system;

• automated deadline calculation;

• reminders and escalation;

• secure document submission;

• authentication controls;

• role-based access;

• audit trails;

• integration with consent and customer systems;

• Processor communication workflows;

• and status tracking.

11.4 Organisational measures

Suitable organisational arrangements may include:

• documented procedures;

• trained personnel;

• defined ownership;

• escalation to the DPO or privacy function;

• involvement of legal, security and business teams;

• Processor-assistance clauses;

• quality review;

• management reporting;

• and root-cause remediation.

11.5 Illustration: Decentralised complaints

A Data Principal sends her grievance through customer support. The customer-support employee treats it as an ordinary service complaint and closes it without informing the privacy team.

The organisation’s website may display the correct grievance period, but the internal measures are ineffective because the complaint was not identified or routed correctly.

Staff should be trained to recognise the substance of a privacy grievance even when the Data Principal does not use statutory terminology.

11.6 Relationship between a rights request and a grievance

A rights request and a grievance are not the same.

A rights request seeks an action or information, such as:

• access;

• correction;

• updating;

• completion;

• erasure;

• or nomination.

A grievance normally concerns dissatisfaction with an act or omission, such as:

• failure to respond;

• refusal without adequate basis;

• incomplete search;

• continued processing after withdrawal;

• inaccurate information not corrected;

• improper sharing;

• excessive verification demands;

• or failure to honour nomination.

The same communication can contain both.

Illustration

A Data Principal asks the organisation to correct an inaccurate date of birth and complains that two earlier requests were ignored.

The correction component should be handled as a Section 12 request. The ignored earlier requests and service failure should be addressed through the grievance process. The organisation should not require the individual to submit two entirely separate communications unless operationally necessary and clearly explained.

11.7 Exhaustion before approaching the Board

Section 13 requires the Data Principal to exhaust the Data Fiduciary’s or Consent Manager’s grievance-redressal opportunity before approaching the Board.

This gives particular importance to the Rule 14 grievance system. If the internal mechanism is inaccessible, ineffective or excessively delayed, the Data Principal’s ability to approach the Board may also be obstructed.

The grievance process should not be designed as a procedural barrier. It should provide a real opportunity to resolve the issue within the published period.

11.8 Relationship with Rule 9

Rule 9 requires publication of contact information for the DPO, where applicable, or another person capable of answering questions about processing. It also requires that information to appear in every response to a communication for exercising rights.

Rule 14 requires publication of:

• the means of exercising rights;

• the identifiers required;

• and the grievance-response period.

The provisions should operate together.

A complete privacy-rights interface should therefore tell the Data Principal:

• what rights are available;

• where to submit a request;

• what identifier is needed;

• how identity will be verified;

• whom to contact with processing questions;

• where to raise a grievance;

• and when a grievance response is expected.

Rule 9 provides the accountable human or institutional contact. Rule 14 provides the operational procedure.

11.9 Nomination

12. Nature and purpose of nomination

Section 14 permits a Data Principal to nominate another individual who may exercise her rights in the event of death or incapacity.

Rule 14 enables the nomination to be made using the process and particulars required by the Data Fiduciary, consistently with:

• the Data Fiduciary’s terms of service; and

• other applicable law.

Nomination is not the same as:

• sharing an account password;

• appointing an ordinary account user;

• creating a nominee for financial assets;

• making a will;

• granting a power of attorney;

• appointing a guardian;

• or identifying an emergency contact.

Its statutory purpose is to identify a person who may exercise the Data Principal’s DPDPA rights after the triggering event.

12.1 One or more nominees

Rule 14 permits nomination of one or more individuals.

The Data Fiduciary’s process should therefore consider how multiple nominations operate. Possible structures may include:

• nominees acting jointly;

• nominees acting separately;

• a primary and alternate nominee;

• different nominees for different accounts or processing activities;

• or an order of priority.

The terms should be stated clearly. If multiple nominees give conflicting instructions, the Data Fiduciary will need a procedure consistent with the nomination, its terms of service and applicable law.

12.2 Illustration: Primary and alternative nominee

A Data Principal names her spouse as the primary nominee and her sibling as the alternative if the spouse cannot act.

The Data Fiduciary should record the priority and should not permit both to issue conflicting instructions simultaneously unless the nomination terms allow joint authority.

13. Incapacity

The Act explains incapacity for nomination purposes by reference to inability to exercise rights because of unsoundness of mind or infirmity of body.

Rule 14 does not prescribe a single universal form of proof. The appropriate evidence may depend on:

• the right being exercised;

• the nature of the service;

• the sensitivity of the data;

• applicable law;

• and the risk of fraudulent invocation.

The Data Fiduciary should not make nomination unusable by demanding disproportionate or impossible evidence. At the same time, it must protect the Data Principal against a false assertion of incapacity.

13.1 Illustration: Temporary physical incapacity

A Data Principal is hospitalised and unable to use the service interface. A valid nominee seeks correction of inaccurate health-insurance contact information.

The Data Fiduciary should verify:

• the nomination;

• the nominee’s identity;

• the triggering incapacity;

• and the scope of the requested action.

It should avoid demanding evidence unrelated to those matters.

13.2 Illustration: Ordinary assistance without incapacity

An elderly person asks a family member to help complete an online form but remains capable of making her own decisions.

That assistance does not necessarily activate the statutory nomination. The family member may assist the Data Principal while the principal continues exercising her own right.

14. Death of the Data Principal

After a Data Principal’s death, a valid nominee may exercise the rights contemplated by Section 14.

This does not necessarily mean that the nominee acquires ownership of every account, communication, digital asset or item of information associated with the deceased.

The nominee’s authority concerns exercise of rights under the DPDPA. Separate laws and contractual rules may govern:

• inheritance;

• succession;

• financial assets;

• fiduciary duties;

• intellectual property;

• confidentiality of communications;

• jointly held information;

• and access to digital content.

14.1 Illustration: Social-media account

A nominee asks the platform to erase the deceased person’s account.

The platform should verify the nomination and death. It must also consider:

• information relating jointly to other users;

• legal retention requirements;

• pending claims;

• account memorialisation choices;

• and the scope of the available DPDPA right.

The nominee’s authority should not automatically permit unrestricted reading or downloading of every private communication, especially where those communications contain personal data of living third parties.

14.2 Illustration: Financial account

A nominee under the DPDPA requests correction of inaccurate contact information and information about processing after the account holder’s death.

That nomination does not necessarily make the person the nominee or beneficiary of funds held in the account. Financial succession and privacy-rights nomination perform different legal functions.

15. Verification of the nominee

When the right is invoked, the Data Fiduciary should verify:

• the identity of the nominee;

• the validity of the recorded nomination;

• the identity of the relevant Data Principal;

• the occurrence of death or incapacity;

• the scope or priority of the nomination;

• and any requirements under applicable law.

The nomination record itself should be protected against unauthorised alteration.

A malicious person who gains access to an account should not be able to change the nominee immediately before attempting to invoke the right. Stronger authentication, confirmation through a registered channel and logging may therefore be appropriate.

15.1 Modification and revocation

Although Rule 14 does not separately describe modification or revocation, an effective nomination mechanism should ordinarily allow the Data Principal to:

• add a nominee;

• remove a nominee;

• change priority;

• update nominee contact information;

• and review the current nomination.

The Data Principal’s latest valid instruction should ordinarily govern, subject to applicable law and sufficient evidence.

15.2 Children and persons acting through representatives

Where the Data Principal is a child, the statutory definition includes the parent or lawful guardian. Where a person with disability has a lawful guardian acting on her behalf, Rule 11 governs verification of that guardian.

The rights system must therefore accommodate:

• the Data Principal acting directly;

• a parent acting for a child;

• a lawful guardian acting within verified authority;

• and a nominee acting after death or incapacity.

These roles should not be conflated.

Example

For example:

• a parent of an adult is not automatically a lawful guardian;

• a lawful guardian is not automatically a nominee after the guardianship ends;

• a nominee does not necessarily become a legal heir;

• and a person assisting with accessibility is not automatically an authorised representative.

The Data Fiduciary must verify the relevant legal capacity without making the procedure unnecessarily intrusive.

15.3 Rights requests involving third-party data

Personal records often contain information about more than one individual.

Example

Examples include:

• email correspondence;

• family accounts;

• joint financial records;

• workplace investigations;

• CCTV footage;

• complaint records;

• medical family histories;

• and social-media messages.

The Data Fiduciary should fulfil the requesting person’s right while protecting other individuals’ personal data.

Possible methods may include:

• redaction;

• extraction of the requester’s information;

• summarisation of processing;

• restricted viewing;

• separation of records;

• or withholding only the portion that cannot lawfully be disclosed.

15.4 Illustration: CCTV access

A Data Principal requests information concerning CCTV footage in which she appears. The footage also shows employees and visitors.

The Data Fiduciary should not automatically refuse the request merely because other people appear. It should assess whether it can:

• provide relevant information about the processing;

• isolate the relevant segment;

• blur other persons;

• permit controlled viewing;

• or provide another appropriate form of response.

At the same time, the request does not necessarily entitle the individual to an unredacted copy exposing everyone visible in the footage.

15.5 Rights involving automated and AI-assisted systems

A rights process must reflect the actual systems through which personal data is processed. This includes AI and algorithmic environments.

A Data Principal may seek correction of source data used by:

• a fraud model;

• recommendation engine;

• recruitment tool;

• customer-risk system;

• educational analytics platform;

• or automated identity-matching process.

Correcting the visible profile may be insufficient if the old information continues to influence active downstream processing.

15.6 Illustration: Incorrect fraud classification

A customer is wrongly classified as high-risk because another person’s transaction was linked to her account.

The Data Fiduciary should correct the source record and determine whether:

• the fraud classification must be recalculated;

• account restrictions should be removed;

• downstream recipients received the incorrect information;

• a Processor must correct its records;

• and the error affected other decisions.

15.7 Model-level complexity

Where personal data has been used in model training, erasure can be technically complex. The Data Fiduciary should determine:

• whether the model contains or can reproduce personal data;

• whether the information exists in retrieval databases;

• whether future use can be prevented;

• whether unlearning, retraining or output controls are appropriate;

• and whether continued retention has a lawful basis.

The existence of technical difficulty does not by itself extinguish the right. However, the legal response must remain tied to the precise statutory scope of erasure and the technical nature of the processing.

15.8 Repetitive, abusive or fraudulent requests

The Act imposes duties on Data Principals, including not registering false or frivolous grievances and not impersonating another person.

This does not give Data Fiduciaries a broad power to dismiss inconvenient or repeated requests automatically.

A repeated request may be legitimate because:

• the earlier response was incomplete;

• processing has changed;

• new data has been collected;

• a Processor failed to comply;

• the Data Principal did not understand the explanation;

• or a continuing violation remains unresolved.

The Data Fiduciary should distinguish:

• genuine repeat requests;

• clarification requests;

• grievances about earlier handling;

• automated abuse;

• impersonation;

• and manifestly false claims.

Any restriction or refusal should be reasoned and documented.

15.9 Security of the rights process

Rights systems handle substantial personal data and can become targets for identity theft and account takeover.

Appropriate controls may include:

• secure authentication;

• role-based access;

• encryption;

• restricted handling of identity documents;

• malware scanning;

• audit logs;

• case-management controls;

• segregation of duties;

• monitoring for fraudulent requests;

• controlled exports;

• and secure deletion of verification data.

A Data Fiduciary should not solve an access request by emailing a complete unencrypted personal-data file to an address that has not been verified.

15.10 Illustration: Wrong delivery address

A Data Principal submits an access request from a new email address. The Data Fiduciary sends the complete response to that address without checking whether it belongs to the account holder.

The rights process itself may create a personal data breach. Identification and secure delivery are essential parts of rights enablement.

15.11 Retention of rights and grievance records

The Data Fiduciary may need to retain records showing:

• the request received;

• requester verification;

• searches undertaken;

• decisions made;

• Processor instructions;

• response;

• grievance outcome;

• nomination;

• and deletion or correction completed.

These records support accountability, dispute handling and proof of compliance.

They should not be retained indefinitely by default. The Data Fiduciary should establish a justified period based on:

• applicable law;

• Rule 8 requirements;

• claims and limitation considerations;

• audit;

• security;

• and the nature of the request.

Identity documents submitted solely for verification should not automatically remain attached to the case forever if a limited verification record is sufficient.

15.12 Effectiveness metrics

Rule 14 requires technical and organisational measures ensuring that grievances are answered within the published period. This implies the need for practical oversight.

A Data Fiduciary should monitor more than whether a ticket was closed. Useful indicators may include:

• time to acknowledgement;

• time to substantive response;

• overdue grievances;

• verification delays;

• Processor response delays;

• repeat grievances;

• reopened cases;

• incomplete system searches;

• correction failures;

• deletion exceptions;

• and recurring root causes.

Metrics should not create incentives to close cases prematurely. A grievance closed in one day with no meaningful investigation is not evidence of an effective mechanism.

15.13 Practical illustrations of the Rule as a whole

15.14 Illustration 1: Former e-commerce customer

A former customer no longer has access to her old mobile number. She asks what information the marketplace still processes and requests erasure.

The marketplace should provide an alternative means of authentication using proportionate information. It should search relevant systems, identify Processor-held data and separate:

• records that can be erased;

• records required for legal retention;

• account-access information;

• transaction evidence;

• and security logs.

If she disputes the result, she should be able to use the published grievance process, and the organisation must respond within its published period, which cannot exceed ninety days.

15.15 Illustration 2: Employee correction request

An employee discovers that the HR system contains an incorrect date of joining, affecting benefits calculations.

The employer should correct the source record, consider downstream payroll and benefits systems, and instruct any Processor to update relevant copies. If the employer delays or refuses, the employee may use the grievance mechanism.

The response should not merely modify the visible employee portal while leaving the inaccurate date active in payroll.

15.16 Illustration 3: Consent Manager dispute

A customer withdraws consent through a Consent Manager, but the relevant Data Fiduciary continues processing.

The Consent Manager should be able to show whether and when the withdrawal instruction was transmitted. The Data Fiduciary should investigate whether it received and implemented the instruction.

Each must provide a grievance mechanism for its own act or omission. The customer should not be indefinitely redirected between them.

15.17 Illustration 4: Nomination after death

A Data Principal has nominated her sibling to exercise DPDPA rights after death. The sibling requests erasure of an inactive digital account.

The Data Fiduciary should verify the nominee, nomination and death. It should then assess the erasure request while accounting for:

• statutory retention;

• jointly held information;

• personal data of living users;

• contractual digital-asset rules;

• and the limited nature of the nominee’s DPDPA authority.

15.18 Illustration 5: Impersonated access request

An attacker knows a customer’s email address and submits an access request seeking account data.

The email address identifies the customer but does not authenticate the attacker. The Data Fiduciary should use proportionate verification before disclosure. The rights framework must protect the Data Principal as well as enable her rights.

15.19 Enforcement implications

Rule 14 does not have a separately identified penalty category comparable to the specific entries for security safeguards, breach notification or children’s obligations. A significant breach may therefore fall within the residual Schedule category for breach of another provision of the Act or Rules, carrying a maximum monetary penalty of up to ₹50 crore.

The maximum penalty is not automatic. The Board must follow the statutory inquiry process, provide an opportunity of hearing and apply the factors in Section 33.

A failure may be more serious where the Data Fiduciary or Consent Manager:

• publishes no means of exercising rights;

• maintains a non-functioning portal;

• demands excessive identity information systematically;

• makes the procedure more burdensome than necessary;

• fails to search Processor or downstream systems;

• ignores correction or erasure requests;

• publishes a grievance period exceeding ninety days;

• treats automated acknowledgement as final grievance resolution;

• repeatedly misses the published deadline;

• obstructs nomination;

• discloses information to an impersonator;

• or prevents the Data Principal from exhausting the internal grievance process before approaching the Board.

Other contraventions may arise from the same conduct. For example:

• insecure delivery of an access response may breach Rule 6;

• disclosure to an impersonator may trigger Rule 7;

• continued processing after withdrawal may breach Section 6;

• failure to erase data may engage Section 8(7);

• and inaccurate data left uncorrected may engage Section 8(3) or Section 12.

Conclusion

Rule 14 converts the Data Principal’s statutory rights into an operational responsibility for Data Fiduciaries and Consent Managers.

It requires them to make the procedure visible, state the identifiers genuinely needed to locate and authenticate the requester, operate an effective grievance system within a published period not exceeding ninety days, and provide a workable nomination mechanism for death or incapacity.

The Rule should not be implemented as a single web form disconnected from the organisation’s actual data environment. Effective compliance requires coordination across:

• privacy;

• customer support;

• legal;

• technology;

• security;

• records management;

• business functions;

• Data Processors;

• and Consent Managers.

A compliant system should be able to receive the request, identify and authenticate the Data Principal proportionately, locate the relevant processing, act across connected systems and Processors, explain limitations, address grievances within the stated period, secure the response and preserve appropriate evidence.

Key point

Rule 14 requires rights to be usable rather than merely declared. The Data Principal must be able to find the correct process, identify herself without disproportionate barriers, obtain action across the real processing environment, challenge deficient handling through an effective grievance system and nominate another individual to act after death or incapacity. The quality of compliance is therefore measured not by whether a rights page exists, but by whether the organisation can reliably convert a valid request into a secure, accurate, reasoned and timely outcome.