Every data protection law has someone at its centre whom it is designed to protect. Under the DPDP Act, that person is the data principal — the individual whose personal data is being processed. Understanding this role is essential, because the entire architecture of notice, consent and rights is built around serving and respecting the data principal.
The concept is simple but consequential. If you are a customer, an employee, a user or a website visitor whose data an organisation holds, you are a data principal in that relationship, and the law gives you a set of enforceable rights over how your data is used.
This guide explains who the data principal is, the rights they hold, the duties the Act unusually places on them, and how children and their guardians fit into the picture.
Who is a data principal
A data principal is the individual to whom the personal data relates. In ordinary commercial life, your customers, employees, job applicants and app users are all data principals when you process their data. The role is relational: a single person can be a data principal in many different contexts at once.
Importantly, the data principal is always a natural person. Companies and other organisations are not data principals, which is why information about a business entity, as opposed to an individual, falls outside the Act's core protections.
Because the role is relational, the same individual generates obligations for you in multiple capacities — as a customer, perhaps also as a newsletter subscriber and a job applicant. Mapping these relationships helps ensure each one is supported by the right notice, basis and rights handling.
Children and persons with disabilities
The definition extends in important ways. Where the data principal is a child — anyone under eighteen — the term includes the parent or lawful guardian who acts on the child's behalf. Where the principal is a person with a disability who has a lawful guardian, the term includes that guardian.
This matters because it determines who exercises rights and gives consent. For a child, it is the parent or guardian, and processing a child's data requires verifiable parental consent. Organisations whose services reach minors must build for this from the outset.
For services that may be used by minors, this extension is not a corner case but a design requirement. Age assurance and a parental-consent pathway need to be built into onboarding, because processing a child's data without verifiable parental consent is a serious breach.
The rights the Act grants
The DPDP Act gives data principals a focused set of rights. The right of access lets a person obtain a summary of the personal data being processed and the identities of others with whom it has been shared. The right to correction and erasure lets them fix inaccurate data and have data deleted once its purpose is served.
There is a right to grievance redressal — a route to complain to the fiduciary and, if unresolved, to the Data Protection Board — and a distinctive right to nominate another person to exercise these rights in the event of death or incapacity. Building responsive workflows for these rights is a core part of dpdp compliance.
Each of these rights translates into a concrete capability your systems must support — the ability to compile a data summary, to correct or delete records across stores, and to log and resolve complaints. Designing for them upfront is far easier than retrofitting later.
How rights are exercised
Rights are exercised through the fiduciary in the first instance. A data principal makes a request — for access, correction or erasure — and the fiduciary must respond within the period the Rules prescribe. Only after exhausting the fiduciary's grievance mechanism can the principal escalate to the Board.
For organisations, this means rights are operational obligations, not abstractions. You need a clear intake channel, an identity-verification step, a defined turnaround time, and a record of how each request was handled.
A practical tip is to publish a simple, findable route for rights requests — a form or dedicated address — and to track each request to closure. The ease with which a person can exercise their rights is itself a signal of how seriously you take the Act.
The duties of a data principal
A feature that distinguishes the DPDP Act from many other privacy laws is that it places duties on the data principal too. Individuals must not file false or frivolous complaints, must not impersonate others, and must provide authentic information when exercising their rights or, for example, when registering for a service that requires identity documents.
This two-way framing reflects the Act's balanced design. Rights come with responsibilities, and misuse of the complaint mechanism can itself attract consequences. For organisations, it offers some reassurance that the rights regime is not intended to be weaponised.
These duties also protect organisations from abuse of the rights regime, but they should be applied sensibly. Treating a genuine, if imperfect, request as frivolous risks both a poor customer experience and a complaint to the Board, so judgement matters.
Consent and the data principal
The data principal is the source of consent. Because consent must be free, specific, informed and unambiguous, the Act effectively requires fiduciaries to treat the principal as an informed decision-maker rather than a passive subject. The principal can also withdraw consent as easily as it was given.
When consent is withdrawn, the fiduciary must stop the relevant processing and, where appropriate, erase the data. This makes consent a living relationship that the principal controls, not a one-time checkbox captured and forgotten.
Operationally, withdrawal of consent should be as engineered as the capture of it. A withdrawal that is acknowledged but not actually propagated to downstream systems leaves you processing data without a basis — a quiet but real compliance failure.
Free resource
The Ultimate Guide to the DPDP Act
A practical, plain-English handbook to the DPDP Act & 2025 Rules — scope, roles, consent, safeguards and a readiness path.
Why the role matters for businesses
Seeing your customers and employees as data principals with enforceable rights changes how you design systems. It pushes you toward clear notices, easy consent withdrawal, responsive rights handling, and honest data practices — because the person on the other side now has a legal claim to transparency and control.
Organisations that embrace this perspective tend to build better products and stronger relationships, treating the rights regime as a trust-building feature rather than a compliance burden to minimise.
Framing customers as rights-holders also tends to improve product decisions. Teams that ask how a feature looks from the data principal's perspective build more transparent defaults and fewer dark patterns, which pays off in trust as much as in compliance.
The bottom line
The data principal is the individual at the heart of the DPDP Act, equipped with rights to access, correct, erase and complain, and with the unusual ability to nominate someone to act for them. Children and protected persons act through guardians, and everyone carries a duty to use the system honestly.
For any organisation, the practical takeaway is to design every data interaction as if the person on the other side knows their rights — because, increasingly, they will.
In short, the safest design assumption is an informed, empowered data principal. Build for the person who knows they can ask what you hold, correct it, delete it and complain — and your systems will be ready for the regime the Act creates.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.