Data protection roles and responsibilities (DPDP)

Audience: privacy leads, legal ops, GRC, product and engineering owners · Last reviewed: March 2026

See also: Compliance portal · Official resources · Guides index

India’s Digital Personal Data Protection Act, 2023 speaks in statute roles—especially data fiduciary, data processor, and data principal. Your company still has to translate those into named people and teams with clear accountability. This page connects legal vocabulary to operating reality, adds a RACI-style matrix you can adapt, and points to workflow guides for consent, notices, vendors, and rights.

Statute roles in plain English

Data fiduciary

The entity that determines the purpose and means of processing digital personal data in scope of the Act—typically your company when you collect data for your own business purposes. The fiduciary carries the core bundle of duties: fairness, purpose limitation, collection limitation, security safeguards, grievance handling in line with the law, and alignment of processing with notices and consents (where applicable), among others detailed in the statute.

Practical note: “Fiduciary” is not a job title. It is a legal role your organization holds. Someone inside the company still needs operational ownership of the program that evidences those duties.

Read next: Duties of data fiduciaries (checklist-oriented), Fiduciary vs processor in vendor scenarios

Data processor

A processor processes personal data on behalf of the fiduciary. Processors act under the fiduciary’s direction and contract; they do not “own” the purpose the way the fiduciary does. Mis-labeling a strategic vendor as a mere processor (when they actually co-determine purposes) is a common governance failure.

Read next: Vendor and processor checklist

Data principal

The individual whose data is processed. Their rights and duties under the Act drive request handling, transparency expectations, and design of choices (including consent and withdrawal) in product and support workflows.

Read next: Data principal rights explained

“DPO,” privacy counsel, and accountable owners

Many teams borrow the label “DPO” from GDPR. Under India’s DPDP framework, do not assume that importing a European title alone satisfies local obligations. The Act and rules may require specific contacts or appointments (for example grievance pathways and, where applicable, expectations tied to scale or classification such as Significant Data Fiduciary contexts). Use neutral internal language—“privacy program owner,” “privacy office,” “data protection lead”—unless counsel confirms a statutory title for your entity.

Enterprise framing: DPDP for enterprises

Enterprise governance tie-ins

At scale, roles collapse without three rails:

• Intake: one visible path for new processing, vendors, and data-driven launches—so “shadow” systems do not bypass review.
• Evidence: versioned records (not Slack opinions) for notices, consent logic, retention, vendor risk tiers, and rights responses.
• Rhythm: recurring privacy reviews that include spot checks on high-traffic journeys; bake scope into the compliance checklist so cadence does not depend on heroics.

Boards and committees rarely want every operational detail—they want defensible assurance that the fiduciary’s duties are owned, tested, and documented. Map your RACI before you scale headcount; swapping owners later is expensive.

RACI-style accountability (appendix)

Adapt this to your org chart. R = responsible (does the work), A = accountable (single approver), C = consulted, I = informed. Many mature programs split A between business and privacy/legal depending on risk tier—your counsel can help define the split.

┌────────────────────────────────────┬─────┬─────┬─────┬─────┐
│ Activity / deliverable             │  R  │  A  │  C  │  I  │
├────────────────────────────────────┼─────┼─────┼─────┼─────┤
│ Privacy notice & journey copy      │ PM  │ PRA │ LEG │ SUP │
│ Consent UX + logging               │ ENG │ PRA │ LEG │ MKT │
│ DPIA / risk memo (where used)      │ PRA │ LEG │ SEC │ EXE │
│ Vendor onboarding privacy review   │ PRC │ PRA │ LEG │ ENG │
│ Data map / RoPA-style inventory    │ PRA │ OPS │ ENG │ LEG │
│ Rights requests (access/erase/…)   │ SUP │ PRA │ LEG │ ENG │
│ Retention & deletion jobs          │ ENG │ PRA │ LEG │ OPS │
│ Breach / incident playbooks        │ SEC │ EXE │ LEG │ COM │
│ Training & attestations          │ PRA │ HR  │ LEG │ MGR │
└────────────────────────────────────┴─────┴─────┴─────┴─────┘

Legend (examples — rename to match your company):
  PM = Product/UX    ENG = Engineering    MKT = Marketing
  PRC = Procurement  PRA = Privacy office / program lead
  LEG = Legal        OPS = Operations    SUP = Support/CS
  SEC = Security     HR  = People team   EXE = Executive sponsor
  COM = Communications / PR

The point is not perfect letters; it is that every recurring obligation has a non-empty R and exactly one A per decision type, so work does not vanish between functions.

Where to go next on this site

• Consent under DPDP — collection and consent mechanics.
• Privacy notice checklist — customer-facing transparency.
• Vendor and processor checklist — third-party accountability boundary.
• Data principal rights — request landscape for ops and product.
• DPDP Act chapter map — statute structure for deeper reads.
• Templates — turn governance into artifacts teams reuse.