Handle personal data of people in India, and the Digital Personal Data Protection Act, 2023 drops you into one of a few roles. Sorting out which one you are isn't pedantry. It's the first thing that decides who's liable when something goes wrong. So here's each DPDP role in plain English, who actually carries the risk, and how the roles land on a real auth stack.

This is general information, not legal advice. For your specific situation, talk to a qualified lawyer.

What a Data Fiduciary Is

A data fiduciary is the entity that decides why and how personal data gets processed. The DPDP Act, 2023 defines it in Section 2(i) as "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data."

The key word is "determines." If you choose what data to collect, the reason you collect it, and how it is used, you are the fiduciary. In GDPR terms, this is the "data controller." The label is different but the idea is the same: the fiduciary holds the decisions, so the fiduciary holds the duties.

Most product teams reading this are data fiduciaries for their own users. When a user signs up for your app, you decided to collect their email, you decided to verify their phone, and you decided to store a session. That makes you the fiduciary for that data.

The fiduciary carries the bulk of DPDP obligations: getting valid consent, giving notice, honouring data principal rights, keeping data accurate, deleting it when the purpose ends, and reporting breaches. We cover the breach side in DPDP breach notification in 72 hours.

What a Data Processor Is

A data processor is "any person who processes personal data on behalf of a Data Fiduciary" (Section 2(k)). The processor does not decide the purpose. It follows instructions.

Your cloud host, your email-sending vendor, your SMS gateway, and your analytics tool are usually processors. They touch the data, but only to do the job you hired them for, under your contract. A processor cannot lawfully decide to reuse your users' data for its own purposes. The moment it does, it stops acting as a processor for that activity and becomes a fiduciary in its own right, with its own liability.

The Act ties processors to fiduciaries through a contract. Section 8(2) says a fiduciary may engage a processor "only under a valid contract." So the chain is: the fiduciary is accountable to the data principal, and the processor is accountable to the fiduciary.

The line between the two roles is about decision power, not about who has the database open. For how this fits the wider set of obligations, see the DPDP compliance checklist.

Who the Data Principal Is

The data principal is the person the data is about. Section 2(j) defines it as "the individual to whom the personal data relates." Where that individual is a child, it includes the parents or lawful guardian. Where the individual has a disability, it includes the lawful guardian.

So your users are your data principals. Under the DPDP Act they have rights you must serve: the right to access a summary of their data and processing, the right to correction and erasure, the right to grievance redressal, and the right to nominate someone to act for them. The fiduciary, not the processor, answers these requests.

If you want a concrete view of what serving an access request looks like, see DPDP audit trail requirements for engineers. A clean event history is what turns a data-principal request from a fire drill into a query.

Significant Data Fiduciary (SDF)

The Act creates a heavier class called the Significant Data Fiduciary. Under Section 10, the Central Government may notify any fiduciary or class of fiduciaries as significant based on factors such as the volume and sensitivity of personal data processed, risk to data principals, risk to the sovereignty and integrity of India, risk to electoral democracy, security of the State, and public order.

An SDF carries extra duties on top of the normal fiduciary set:

Obligation	Ordinary Data Fiduciary	Significant Data Fiduciary
Consent, notice, breach reporting	Yes	Yes
Appoint a Data Protection Officer in India	No	Yes
Appoint an independent data auditor	No	Yes
Periodic Data Protection Impact Assessment	No	Yes
Periodic audit	No	Yes

The DPO for an SDF must be based in India and be responsible to the board or governing body, and must be the point of contact for grievance redressal. You do not get to self-declare as significant. The classification comes from the government. But if your data volume is large or your data is sensitive, you should plan as if the heavier bar may apply to you.

Who Carries the Liability

This is the part that decides budgets and contracts. Under DPDP, the data fiduciary is primarily accountable. Section 8(1) says the fiduciary is responsible for complying with the Act "irrespective of any agreement to the contrary or the failure of a Data Principal to carry out any duties," and it is responsible for processing done by a processor on its behalf.

Read that twice. You can't contract your way out of accountability by making a processor sign a strong agreement. Your SMS vendor leaks OTPs? The data principal's relationship is with you, the fiduciary, and the regulator looks to you. You may have a contractual claim back against the processor, but that's a separate, private matter.

Penalties under the DPDP Act run up to 250 crore rupees per instance for failure to take reasonable security safeguards, as set out in the Schedule to the Act. The Data Protection Board of India adjudicates and imposes them. The processor is not off the hook either, since a contract and Section 8(5) security duties bind it, but the front-line liability and the public-facing duties sit with the fiduciary.

The practical takeaways:

Pick processors who can actually meet your security bar, because their failure is your liability.
Put a real DPDP-aware contract in place, covering purpose limitation, security, breach notice to you, and deletion on termination.
Keep evidence. If you cannot show consent, notice, and a breach timeline, you cannot show you met your duties.

How the Roles Map to Your Stack

Now make it concrete. Say you run a consumer app in India and you use NamoID as your identity layer.

You are the data fiduciary. You decided to collect emails, run KYC, and keep sessions. The duties to your users are yours.
NamoID is built to act as a data processor for the identity data it handles on your behalf, under your instructions and your contract. It does not decide why your users' data exists.
Your users are the data principals. Their rights run to you.

NamoID is built so the processor side of that contract is easy to honour. A few examples of how the design lines up with DPDP duties:

Audit trail for free. Every state change appends to an immutable events table, which is what a fiduciary needs to prove notice, consent, and timelines. A DSAR-style export endpoint is built to return a user's full event history plus connected providers, so you can answer a data-principal access request without reverse-engineering logs.
Deletion that leaves a record. Deletion cascades a soft-delete plus a tombstone event, so you can show when erasure happened without keeping the erased data.
Security by default. Provider tokens are encrypted at rest with AES-256-GCM. JWTs are RS256-signed and only the public key is exposed via JWKS. Refresh tokens rotate, and reuse of an old refresh token revokes the whole chain. PKCE is enforced on every OAuth 2.1 flow. These map to the "reasonable security safeguards" duty that the largest penalties attach to.
India data in India. A per-organization data-residency hint is built to keep India data in India, which matters as the residency rules under DPDP Rule 15 take shape.

Here is the kind of access request your fiduciary duty produces, served against a single issuer URL:

curl -X GET "https://issuer.example.com/v1/audit/export" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}"

{
  "data_principal": "user_8f2a...",
  "events": [
    {"type": "user.registered", "at": "2026-03-01T09:12:04Z"},
    {"type": "provider.connected", "provider": "digilocker", "at": "2026-03-01T09:13:40Z"},
    {"type": "consent.recorded", "scope": "kyc", "at": "2026-03-01T09:13:41Z"}
  ],
  "connected_providers": ["digilocker", "google"]
}

The fiduciary still owns the decision to disclose and the response to the user. The processor's job is to make the underlying record complete and accurate. That is the division of labour the DPDP roles describe.

FAQ

In practice, yes. The DPDP Act renames the "controller" idea as the data fiduciary, the party that determines the purpose and means of processing. The duties are similar in spirit, though the texts differ on consent, breach timelines, and penalties, so do not copy a GDPR program word for word.

Can one company be both a data fiduciary and a data processor?

Yes. A company is a fiduciary for its own users and a processor for the clients it serves. A SaaS vendor is the fiduciary for its employee data and a processor for its customers' end-user data. The role is per dataset and per purpose, not per company.

Does using a processor reduce my liability under DPDP?

No. Section 8(1) keeps the fiduciary accountable for processing done on its behalf, regardless of any agreement to the contrary. A good contract gives you a claim against the processor, but the data principal and the regulator still look to you first.

How do I know if I am a Significant Data Fiduciary?

You do not self-declare. The Central Government notifies fiduciaries as significant under Section 10, based on data volume, sensitivity, and risk factors. If your data is large or sensitive, plan for the heavier duties, a DPO in India, audits, and impact assessments, in case the classification applies to you.

See Where You Fit

Mapping the fiduciary-versus-processor line onto your own stack is the fastest way to find your real DPDP exposure. If you want to walk through where NamoID sits as a processor in your architecture, and how its audit trail and security defaults support your fiduciary duties, book a demo at https://calendly.com/polymindslabs/30min or reach us at hello@namoid.in.