DPDPA Section 15: The Duties of the Data Principal

Privacy laws usually feel like a one-way street. The business carries the burden of compliance, and the user holds all the rights. But DPDPA Section 15 flips the script. It outlines the explicit duties of the data principal DPDP enforces, setting bright lines on what users are actually permitted to do.

For operators, this section is not just a list of rules,it is your legal shield against weaponized privacy requests. It tells you exactly when you can, and should, say no.

Scope and Position in the Act

Sections 4 to 14 of the DPDPA hand out the rights: consent withdrawal, access, correction, erasure, grievance redressal, and nomination. Section 15 is the counterweight. It applies whenever a Data Principal interacts with a Data Fiduciary or the Board, restricting the misuse of rights, protecting legal processes, and maintaining data accuracy.

Good faith is the dividing line here. Section 15 targets intentional abuse, not honest mistakes. That distinction changes exactly how you evaluate complaints, identity submissions, and erasure requests.

Duty 15(a): Comply with Applicable Laws

What it says: A Data Principal must comply with all applicable laws when exercising DPDPA rights.

What it means: You cannot use a privacy law to hide from a tax audit. DPDPA rights do not override legal holds, statutory retention, criminal procedure, or sectoral obligations. Requests that would obstruct investigations, destroy evidence, or violate regulatory retention must be denied.

Practical implications:

• Map your legal retention and legal hold scenarios. Tag the data sets where erasure is simply not permitted.
• Build refusal templates that cite the specific legal bases for denial.
• Document requests that appear designed to evade the law. Examples include attempts to erase financial records during tax or enforcement proceedings, or “correcting” KYC data to mask an identity,actions that trigger laws like IPC Section 201, PMLA, and KYC regulations.

Duty 15(b): No False or Frivolous Grievances

What it says: Do not register a false or frivolous grievance or complaint with a Data Fiduciary or the Board.

False vs. mistaken:

• False means the complainant knows the allegation is untrue and files it anyway.
• Mistaken means a good faith belief that turns out to be wrong. Honest mistakes are not violations.

Frivolous indicators:

• Spamming duplicate complaints without introducing new facts.
• Demanding the legally impossible, like deleting entries required for tax records.
• Expressing vague dissatisfaction without alleging a specific DPDPA breach.
• Refiling after an issue is demonstrably resolved.

Practical implications:

Introduce grievance triage. Screen for specificity, supporting facts, and legal basis. Rate-limit or consolidate duplicates, and keep an audit trail. When you dismiss a claim as false or frivolous, state your reasons. Complainants who cross this line face defamation exposure and Board-level pushback against vexatious filing.

Duty 15(c): No Impersonation

What it says: Do not impersonate another person when providing personal data for any document, unique identifier, proof of identity, or proof of address.

What it means: Identity claims must be genuine. Submitting someone else’s Aadhaar, PAN, or address proof is prohibited. This ties directly to offences such as IPC Sections 416 to 419 and IT Act Section 66C.

Legitimate edge cases:

Using a nickname, maiden name, or a professional stage name is generally not impersonation if it still refers to the same person. However, using someone else’s identity documents,even a family member’s,is always impersonation.

Practical implications:

Strengthen identity verification at intake and before allowing account changes. Use multi-factor checks for sensitive actions like data access or changes to identity attributes. If you suspect an identity mismatch or impersonation, suspend processing and escalate.

Duty 15(d): No Suppression of Material Information

What it says: Do not suppress material information while providing personal data for documents or identity proofs if such suppression is prohibited by law.

What it means: If a law or regulation requires disclosure, withholding significant facts is a violation. “Material” means information that actually affects a decision. Examples include hiding criminal records for law enforcement roles, burying financial liabilities during credit decisions, omitting medical history for insurance underwriting, or hiding conflicts for government clearance.

This duty does not convert general interactions into compelled disclosure. Refusing to share your income with a shopping website is not suppression.

Practical implications:

Align your data collection forms to your legal bases. Ask only what is needed and legally required. Give clear notices on legally required fields and the consequences of non-disclosure. Where suppression is suspected in a regulated context, pause processing, seek clarification, and record the rationale.

Duty 15(e): Provide Verifiably Authentic Information

What it says: When exercising the right to correction or erasure, furnish only information that is verifiably authentic.

What it means: The Data Principal must support correction or erasure requests with truthful, provable evidence. You correct a name with a government ID reflecting the correct spelling. You correct a birth date with a birth certificate or passport. You correct a transaction status with bank statements and confirmations.

Fabricated or unsupported claims must be denied. You cannot use the right of erasure to deny a documented loan default, or to erase a conviction within a legal retention window.

Practical implications:

Define evidence checklists per attribute type. Validate documents for authenticity, including tamper checks. If statutory retention applies, deny the erasure even if they provide supporting documents, and cite the retention authority.

The Consequences of Violating Duties

Immediate outcomes under the DPDPA framework are entirely operational: denial of rights requests that conflict with law, dismissal of frivolous complaints, service refusal for impersonation, and rejection of unsupported correction requests.

Depending on the conduct, users also face exposure under other laws,including IPC provisions on defamation, cheating, personation, furnishing false information, and IT Act identity theft. In repeated or vexatious cases, the Board may resist future complaints.

But good faith matters. Honest mistakes, administrative errors in documents, or reasonable misunderstandings of legal requirements are not violations. Your job is to maintain records that show exactly how you assessed intent and evidence.

How to Operationalize Section 15

• Map legal retention and holds: Connect them directly to erasure denial logic in your workflows.
• Standardize grievance triage: Require specifics, check for duplicates, and track outcomes with reasons.
• Strengthen identity verification: Apply risk-based MFA and documentary review before processing sensitive changes or disclosures.
• Define evidence standards: Build attribute-by-attribute checklists with acceptable proofs, authenticity checks, and fallback procedures.
• Detect abuse patterns: Set thresholds for repetitive, meritless filings and route them to a structured review.
• Train teams on intent: Teach the difference between false vs. mistaken, and frivolous vs. persistent. Use real examples and decision trees.
• Build clear refusal templates: Cite Section 15 clauses and any applicable law when denying a request.
• Keep an auditable trail: Record requests, evidence, evaluation notes, decisions, and communications.

Defensibility is a System, Not a Guess

Section 15 is not theory. It shapes frontline decision-making, from helpdesk responses to identity reviews to data deletion gates. The hard part is applying it consistently under time pressure.

At Regodit, we did not start by asking how to build a better dashboard. We started by asking how to codify rules, evidence standards, and decision logs so your teams can act fast and stay defensible. If you want a practical review of your current request handling and denial criteria, let’s look at how to translate Section 15 into clear workflows and audit-ready records.