Key DPDP terms explained

Audience: founders, operators, product teams · Last reviewed: March 2026

Most teams lose time because they read legal terms without translating them into workflow language. This page is meant to shorten that gap. The goal is not to replace the official text. It is to help teams understand what the terms usually mean when they show up in product, support, vendor, and governance decisions.

Personal data

In practice, start with a broad operational question: does this information relate to an identifiable person in a way that matters to your systems, communications, service, or records? Teams often underestimate personal data because they focus only on profile fields and ignore support history, CRM notes, analytics linked to accounts, spreadsheets, and vendor exports.

Statutory definition: Section 2(t) — “any data about an individual who is identifiable by or in relation to such data.”

Read: what counts as personal data

Data principal

This is the individual the personal data relates to. In plain business terms, think customer, user, employee, applicant, subscriber, patient, student, or another person whose information sits in the workflow. The useful operational reminder is that the data is not abstract. It belongs to a context involving a real person and real expectations.

Statutory definition: Section 2(j) — where the Data Principal is a child, this includes her parent or lawful guardian, and where she has a lawful guardian due to disability, the guardian acting on her behalf.

Data fiduciary

A data fiduciary is the entity making important decisions about why and how personal data is processed. If your business designs the collection flow, decides the purpose, picks the tools, and benefits from the data use, that is the practical signal to pay attention to. Responsibility usually follows that decision-making role.

Statutory definition: Section 2(i) — “any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data.”

Read: what is a data fiduciary?

Data processor

A processor usually acts in a narrower operational role within someone else’s workflow. Many vendor tools fit here, but the important question is not the label alone. It is who decides purpose and means, who controls access, and what the contract and system reality actually look like.

Statutory definition: Section 2(k) — “any person who processes personal data on behalf of a Data Fiduciary.”

Read: data fiduciary vs processor

Consent

Consent should be understood as more than a screen element. It is a permission path tied to purpose, timing, wording, and recordkeeping. If the business cannot show what was presented to the user and how downstream systems respected that choice, the consent story is weak.

Statutory standard: Section 6(1) — consent must be “free, specific, informed, unconditional and unambiguous with a clear affirmative action.” Section 6(4) adds that withdrawal must be as easy as giving it, and Section 6(6) gives the Fiduciary a reasonable (not fixed) time to stop processing after withdrawal.

Read: consent under DPDP

Lawful use

Not every legitimate workflow is explained only through consent. Teams should still be careful here. “Lawful use” is not a magic excuse for broad processing. It means the business needs a defensible reason grounded in the official framework and a workflow that matches that reason.

Statutory basis: Section 7 lists nine specific grounds (the “certain legitimate uses”) — voluntarily provided data, government benefits, state functions, legal disclosure duties, court orders, medical emergencies, public health, disaster response, and employment purposes. Nothing broader than that list qualifies.

Read: lawful uses under DPDP

Children’s data

Once a workflow involves children, risk tolerance should go down and review discipline should go up. Product teams should not reduce this topic to one line in a policy. Age gating, parental involvement where required, data minimization, and feature design all become more important.

Statutory basis: Section 2(f) defines a child as anyone who has not completed the age of eighteen years. Section 9(1) requires verifiable parental consent, and Section 9(3) bars tracking, behavioural monitoring, and targeted advertising directed at children, with limited exemptions set out in Rule 12 and the Fourth Schedule (healthcare, education, crèche/transport providers, and specific safety purposes).

Read: children’s data rules

Grievance redressal

This is the business process for receiving and addressing complaints or unresolved concerns. Many teams think only about formal privacy requests, but in practice grievance handling matters because confused, frustrated, or dissatisfied users do not always use neat legal labels when they contact you.

Statutory basis: Section 13 gives Data Principals the right to grievance redressal and requires them to exhaust that process before approaching the Board. Rule 14(3) sets the outer limit: a published grievance system that responds within a reasonable period not exceeding 90 days.

Read: grievance redressal under DPDP

Significant data fiduciary

This is a higher-risk or higher-importance classification concept teams should understand without assuming it applies automatically. The key practical lesson is that some organizations may face additional expectations depending on official designation and context.

Statutory basis: Section 10(1) — the Central Government notifies a Data Fiduciary or class as “Significant” based on data volume and sensitivity, risk to Data Principals’ rights, and impact on sovereignty, electoral democracy, state security, or public order. There is no fixed revenue or user-count threshold in the Act or Rules.

Read: significant data fiduciary explained

Why definitions matter operationally

• They determine who owns a workflow.
• They shape what notice, consent, or lawful-use logic is relevant.
• They affect vendor review and processor management.
• They influence how rights, deletion, and grievance handling are built.
• They make it easier to spot when teams are using the wrong label to justify a weak process.

Official and higher-authority sources