Data principal

The person, not the record

A data principal is the individual to whom personal data relates. The definition sounds trivial until you apply it, because most systems are organised around accounts rather than people. One person can have three email addresses, two phone numbers, a work login and a personal one, and appear in your database as five contacts. A household streaming account covers four principals. A device graph covers nobody in particular until it is resolved to a person, and sometimes it cannot be.

Two exclusions matter. A company is not a principal, so a business email printed on a company website is still personal data about the individual behind it, but the company itself has no rights under the Act. A deceased person is not a principal either, which is why the Act creates nomination: a principal can name someone to exercise rights on their behalf after death or incapacity, and that nominee steps into the same position.

The practical consequence is that identity resolution is a privacy control, not just a marketing convenience. If you cannot say which records belong to one person, you cannot answer an access request completely or an erasure request correctly. Most Indian teams discover this during their first serious request, when the CRM, the support desk, the billing system and the WhatsApp console each return a different subset of the same person.

The five rights, and what each actually produces

The right to access produces a summary of the personal data being processed, the identities of the fiduciaries with whom it has been shared, a description of the processing and the categories of data involved. It is a summary right rather than a data-dump right, which matters because teams often respond with a CSV of every row and call it compliance. The useful deliverable is a readable statement, with the underlying extract available if the principal asks for detail.

The right to correction and completion covers inaccurate data and incomplete data. In practice most correction requests are about contact details, and the work is fan-out: the CRM, the billing system, the support desk, the messaging platform and any partner that received the record. Correcting the source and leaving five downstream copies stale is a partial answer that generates a repeat request next quarter.

The right to erasure is the one that collides with everything else. It applies where the purpose is no longer being served, where consent has been withdrawn and no other basis applies, or where the law requires erasure. It does not apply where retention is required by law or for a legal proceeding. Grievance redressal is the fourth right and it comes with a named officer and a process. Nomination is the fifth, and it is the one most systems have no field for.

Response format matters more than teams expect. A summary written for a non-lawyer, with the purposes in plain language and the vendors named in ordinary terms, resolves most access requests in one exchange. A machine export full of column codes and internal identifiers generates a follow-up, then a grievance, then a Board complaint. The same data can be delivered either way, and the difference in cost is one template and one review step.

Consent seen from the principal’s side

The Act describes consent with five adjectives and each one describes a failure mode. Free means the choice is not bundled with employment, service access or a discount in a way that makes refusal costly. Specific means it is tied to a named purpose rather than to a general agreement to process data. Informed means a notice was actually presented, in a language the person reads, with the rights and the grievance route spelled out.

Unconditional means the consent is not a precondition for something unrelated. A loyalty programme that requires marketing consent to issue a receipt fails this test. Unambiguous means a clear affirmative act: a pre-ticked box, a silent default or a continued-browsing inference does not qualify. Five adjectives, five ways that a form designed by a growth team can go wrong.

Withdrawal is where the design is tested. The Act requires it to be as easy as giving consent, and it places the consequence on the fiduciary: withdrawal cannot be treated as a breach by the principal, and the business has to absorb the operational cost. For a principal this means a STOP keyword, an unsubscribe link or a preference toggle should work without a login, without a survey and without a retention offer that requires three clicks to decline.

Language is the part most Indian programmes get wrong. A notice served only in English to a customer who transacted in Hindi or Tamil is difficult to describe as informed, and the framework expects notices to be available in the languages listed in the Eighth Schedule. Practically that means a translated notice at the point of collection for the languages your customers actually use, with the version recorded in the consent artefact so the exact text can be produced later.

Principal and fiduciary: whose data, whose decision

The relationship is easiest to hold in two sentences. The data is about the principal. The decision about what happens to it belongs to the fiduciary, within the limits the principal has set. The principal grants or refuses permission and can take it back; the fiduciary chooses the purpose, the systems, the vendors and the retention period, and answers for all of them.

What each can demand follows. A principal can demand an explanation, a correction, a deletion where the law allows, and a hearing on a grievance. A principal cannot demand that a processor reply directly, cannot demand the deletion of records a tax law requires, and cannot demand that a business keep providing a service that depends on data it has withdrawn consent for. A fiduciary can demand that a principal verify identity before acting, and can refuse a request that is manifestly unfounded or repetitive, but it has to say why.

The asymmetry is the point. Rights attach to the person because the data is about them; duties attach to the business because it chose the processing. A business that frames privacy as a customer courtesy rather than a duty will design for convenience and lose the argument the first time a principal escalates. A business that frames it as an obligation builds the plumbing once and stops improvising.

Children, and the consent that is not theirs to give

The Act treats a person under eighteen as a child and requires verifiable parental consent before processing their personal data. It also bars tracking, behavioural monitoring and targeted advertising directed at children. Those two rules together rule out a large class of default product behaviour: an edtech app that profiles a sixteen-year-old’s engagement to decide which upsell to show is doing exactly what the Act prohibits.

Verifiable is doing real work in that sentence. A checkbox that says I am a parent is not verification. A DigiLocker-backed check, a payment instrument in the parent’s name, a signed declaration with a callback or a school-issued credential are the kinds of evidence that can be defended. The verification has to be proportionate: an edtech platform needs stronger evidence than a free worksheet download, and the record of the verification is itself an artefact that should be retained.

There are exemptions, including for certain classes of fiduciary and for health and safety purposes, and they are narrower than product teams hope. The safe default for an Indian consumer product is to treat anyone whose age is unknown as potentially a child, avoid behavioural advertising on that segment, and put a real verification gate in front of any feature that profiles. Retrofitting that after a grievance is far more expensive than designing for it.

Design the age signal to fail closed. If the product cannot establish that a user is an adult, treat the account as a child account until verification arrives: no behavioural advertising, no profiling, limited retention and a clear path to a parent. That default is uncomfortable for growth teams and far cheaper than a retrospective clean-up of profiles built on data that should never have been collected. Document the decision, because the absence of a decision is what a regulator will ask about.

Identity, nominees and the authorised representative

A rights request begins with verification, and verification is where most programmes either build trust or create friction. The right level depends on the sensitivity of the data and the consequence of the action. Sending a summary to the email address already on file is reasonable for a marketing preference. Deleting an account, or disclosing a call recording, warrants a stronger check such as a one-time code to a verified number plus a knowledge factor.

Nomination is a small clause with large operational implications. A principal can nominate another individual to exercise rights in the event of death or incapacity. That means the data model needs a nominee field, a verification path for the nominee, and a rule about what evidence triggers the transfer of authority. Most CRMs have nowhere to store this, which is why teams end up handling it by email and losing the record.

Authorised representatives add a third path. A lawyer, a family member or a consumer group may act for a principal with authority. The workflow needs to accept a delegation, verify it, and record who acted. Without that, a support agent either refuses a legitimate request or acts on an unverified one, and both are failures with different costs.

Grievance: the route that keeps complaints small

Every fiduciary has to publish a grievance officer and a way to reach them. The mechanism is not decoration; it is the pressure-release valve that stops a service complaint from becoming a regulatory one. A principal whose messages will not stop and whose emails go unanswered has two options, and one of them involves the Board.

A workable mechanism has four properties. It is easy to find from the privacy page in one click. It produces a ticket with an owner and a clock. It acknowledges receipt immediately and gives a substantive answer within the period the Rules prescribe. And it records the outcome in a form that feeds back into the product, so the same complaint does not arrive fifty times. The last property is the one that distinguishes a real mechanism from an inbox.

Escalation should be designed rather than resisted. If a principal is not satisfied, they can complain to the Data Protection Board, and the Board’s involvement is far more expensive than an internal second look. A tier-two review by someone senior, with authority to reverse a decision, resolves most disputes before they leave the building. Publishing that route signals confidence and reduces escalation.

Volume is usually small enough that a spreadsheet would work, which is exactly why the mechanism decays. Give it a ticketing tool with a clock and an owner, and review the reasons monthly rather than the count. A grievance about message frequency is a marketing setting; a grievance about a call after an opt-out is an integration bug; a grievance about one person’s data appearing in another’s account is a security incident. Classifying the reason is what turns a queue into a fix.

Fulfilling a request inside an agent stack

An agent stack makes rights requests harder in one way and easier in another. Harder because the same person appears in the CRM, the email platform, the WhatsApp console, the call recordings, the vector index behind a retrieval system, the analytics warehouse and the logs. Easier because a well-built runtime already has a tool layer, and deletion can be implemented as a tool that every system must expose rather than a script written per incident.

The workflow has five stages. Resolve the person to a canonical identifier. Discover every system that holds data against that identifier, using a registry rather than an engineer’s memory. Execute the correct action per system: delete, correct, export or restrict. Verify by querying again and comparing counts. Then reply with a plain statement of what was done, what was kept and on what legal basis.

Two systems deserve special handling. Retrieval indexes hold embedded chunks that may contain the person’s text without an obvious identifier, so deletion has to run at the document level and reindex. Logs hold request payloads for debugging, and a log that retains a full support ticket for two years is a copy of the data whether or not anyone thinks of it that way. Both are routinely missed, and both are exactly what an audit sample will find.

Speed is a design property, not a virtue. A request that takes three weeks usually spends most of that time waiting for a human to remember which systems exist. A registry with an owner per system, a scripted action per system and a default response when a system is unavailable collapses the wait to the slowest vendor. The target should be days, not weeks, and the measure should be the slowest system rather than the average.

The limits: when the answer is not yes

A principal’s rights are strong and not absolute. Erasure yields to a legal obligation to retain, to a legal proceeding, and in some cases to the establishment or defence of legal claims. Access can be refused where it would disclose another person’s data, and it can be delayed where a criminal investigation requires it. A business that never refuses is probably not checking, and a business that refuses everything is inviting the Board to check for it.

The civil-service style of refusal, a template that cites a clause and stops, is the worst option. The defensible refusal names the specific obligation, the data it covers, the period, and what was done with everything outside that scope. If the invoice must be kept for eight years, say so, keep the invoice, delete the marketing profile, and confirm both actions. That answer is auditable and it is also more likely to end the dispute.

Sector rules add their own floors. A lender cannot delete know-your-customer records on request. A hospital cannot delete a medical record that a clinical regulation requires. A telecom operator has retention duties that predate the Act. The practical approach is a retention matrix that names the law behind each floor, reviewed with the person who owns the sector relationship rather than with the privacy team alone.

Measuring how well you serve the person

Four numbers tell you whether the rights programme works. Time to first response, measured from receipt to acknowledgement, should be hours rather than days. Time to resolution, measured to a substantive answer, should be inside the period the Rules set with margin. Completion rate is the share of requests closed with a verified action across every system rather than a partial fix in one. Repeat rate is the share of principals who come back with the same complaint, which is the clearest signal that the fix did not fan out.

Add a fifth that is harder to compute and more useful: coverage of the discovery registry. For a sample of closed requests, ask how many systems were searched against how many actually held the person’s data. A registry that covers 60% of the estate produces confident answers that are wrong, and the gap is invisible unless someone measures it deliberately.

Review the numbers monthly with the support lead, the privacy owner and one engineer. The conversations are short because the volumes are small, and the value is in the pattern: a spike in correction requests usually means an upstream data quality problem, and a spike in erasure requests usually means a frequency or relevance problem in marketing. Both are cheaper to fix at the source than in the workflow.

A worked example: a subscription request that became three

A customer of an Indian meal-kit service emails to ask what data is held and to stop marketing messages. The support agent finds the account, exports the order history and turns off marketing in the CRM. Two weeks later the customer writes again, angry, because WhatsApp messages continue and a call centre rang on a Sunday. The first request was answered in one system, and the person exists in four.

The post-mortem finds three gaps. The WhatsApp opt-out was stored in the messaging console and never written to the central ledger, so the CRM change did not propagate. The dialler pulled its list from a nightly export that had been paused during a migration and was serving a three-week-old file. And the access response omitted the call recordings because nobody thought of the telephony vendor as a system holding personal data.

The fix has three parts and none of them are exotic. A single consent ledger that every channel reads at send time. A discovery registry that lists telephony and messaging vendors as data systems with an owner and a deletion path. And a request workflow that refuses to close until each registered system confirms an action. The next request of the same shape closes in two days with five confirmations, and the repeat rate for that quarter is zero.