All insights
GuideGovernance

Privacy roles and responsibilities under the DPDP Act

A practical guide to assigning DPDP privacy roles across legal, product, security, HR, procurement, support and leadership teams.

Data>Nuance

Privacy responsibility is a team sport that usually starts with everyone pointing politely at legal.

Under the DPDP framework, Indian organisations need more than a policy owner. They need operational owners for data mapping, notices, consent, Data Principal rights, processor oversight, safeguards, retention, grievance handling, incident escalation and evidence. The exact titles will differ by size and sector, but the responsibilities must be visible. Otherwise every request becomes a workshop and every incident becomes a search for the person who once attended a privacy meeting.

What to review

Begin with the organisation's main personal data flows. Who decides why data is collected? Who designs the form, app screen or call script? Who stores the record? Who approves vendors? Who answers correction or erasure requests? Who can delete data, and who can explain why deletion is not possible for a retained record? These questions reveal the real privacy organisation chart.

Legal or compliance teams often interpret the DPDP Act and Rules, maintain policies, review notices and coordinate risk decisions. Product and engineering teams usually control the user journey, consent capture, preference changes, access rules and deletion mechanics. Security owns technical safeguards, incident detection and evidence preservation. Procurement and business owners manage processor instructions. HR owns employee data and workforce training. Customer support and grievance teams handle requests from Data Principals. Finance may also need a place in the matrix where payment records, invoices, refunds or statutory retention shape the answer to a privacy request.

Leadership remains responsible for decisions that require risk acceptance, budget or business change. A privacy lead can recommend action, but cannot alone fix a product workflow, replace a processor, fund tooling or change retention architecture.

Implementation steps

  1. Create a responsibility matrix for each DPDP control area: notices, consent, rights, grievance handling, processors, retention, safeguards, incidents, training and board reporting.
  2. Name one accountable owner and supporting teams for each control. Avoid shared ownership without a decision-maker; it becomes a polite form of delay.
  3. Connect responsibilities to systems. For example, product may own consent design, engineering may own the consent log, marketing may own suppression lists and support may own customer explanations.
  4. Define intake routes. Rights requests, complaints, vendor escalations, product launches and incidents should have clear entry points, not individual inbox archaeology.
  5. Add evidence duties. Owners should know which logs, approvals, screenshots, registers or tickets prove that the control operated.
  6. Include processors. Business owners should know which vendors process personal data, what instructions apply, who can approve new sharing and who checks deletion after exit.
  7. Train by role. Board members, developers, HR, support, sales, procurement and security teams need different examples, not the same generic privacy deck.
  8. Review the matrix every quarter or after major product, vendor, system or legal changes.

Common mistakes

  • Naming a privacy officer but leaving product, engineering, HR, security and procurement responsibilities undefined.
  • Assigning rights requests to support without giving support the authority or system access needed to resolve them.
  • Treating vendor privacy work as a contract exercise while business teams keep adding processors informally.

How DataNuance can help

DataNuance helps organisations convert DPDP obligations into clear operating roles. We design privacy responsibility matrices, RACI charts, launch checklists, vendor escalation paths, rights workflows, grievance playbooks and role-based training. We also test whether the named owners can handle real scenarios, because a tidy matrix that fails on the first request is only stationery. For help assigning practical privacy responsibilities, contact our privacy advisory team.

FAQs

Does every company need a dedicated privacy officer?

Not always in the same form. The organisation needs accountable ownership for DPDP controls, and some entities may have specific contact or grievance responsibilities. Smaller companies can assign roles across existing teams if the duties are clear and resourced.

Can legal own DPDP compliance alone?

Legal can coordinate interpretation and governance, but most controls sit in product, technology, security, HR, procurement, marketing and support. A legal-only model usually fails when operational evidence is needed.

Who should handle Data Principal requests?

Customer support or a grievance function may run intake, but fulfilment often needs product, engineering, records, HR or vendor support. The workflow should name each team and its response timeline.

How often should responsibilities be reviewed?

Review them quarterly and whenever a major product, vendor, system, incident or regulatory change occurs. The matrix should move with the business, not sit untouched after launch.

Sources

This publication is general information and is not legal advice for a specific organisation or matter.

Continue reading

Governance

Board-level DPDP compliance reporting

A practical guide to board-level DPDP reporting for Indian organisations, with metrics, evidence, escalation paths and decision records.

Read insight

Governance

DPDP training plan for Indian organisations

A practical DPDP training plan for Indian boards, founders, legal, compliance, product, HR, security and operations teams.

Read insight

Start with context

Book a focused DPDP Act consultation.

Bring an upcoming launch, notice review, data mapping question, incident readiness issue or implementation deadline. We will help identify the right next step.