DPDP Accountability and Scoping FAQ: Who Is Responsible for What, Across Every Organisation Structure

Yes. The test for Data Fiduciary status is not who physically processes the data — it is who determines the purpose and means of processing. If you decided that customer data should be collected, for what reason, and for what use, you are the Data Fiduciary regardless of whether you handed the actual processing to a vendor, a platform, or a subsidiary.

Yes — this is the joint Data Fiduciary scenario. A joint fiduciary role arises when two entities jointly determine the purpose and means of processing personal data. In co-branded credit card programmes with shared customer data decision-making, co-lending marketplace models, and corporate partnership arrangements involving joint decisions on data use, both parties may qualify as joint fiduciaries. An explicit contractual framework must outline each party's obligations, mechanisms for managing data principal rights, and the allocation of shared accountability. Joint fiduciary arrangements do not dilute each party's individual accountability — both remain independently obligated under the Act.

Three sequential questions map every third party to the correct DPDP role. Ask these questions for each processing activity separately — not for the organisation as a whole. A single third party can be your Processor for one activity and an independent Fiduciary for another.

The bank is the Data Fiduciary. The DSA collects data on the bank's behalf, for the bank's purpose (account opening or loan origination), following the bank's instructions on what to collect. The DSA is a Data Processor.

The bank must give the customer a DPDP-compliant consent notice at or before the point of collection — even though the DSA is the physical point of contact. The bank's Data Processing Agreement with the DSA must include DPDP Rule 6 security obligations, immediate breach notification, and data deletion on contract termination. The DSA cannot use customer data for its own purposes — lead recycling, cross-selling for competing products. If it does, the DSA becomes an independent Data Fiduciary for that processing, and the bank may have a vicarious exposure problem stemming from what it permitted in its agent contract.

The NBFC is the Data Fiduciary. The BC acts as your agent — processing data you have instructed them to collect, for your loan origination and servicing purpose, under your direction. This is Data Processor territory. The DPDP regime overlays and intersects with existing RBI expectations around customer confidentiality, agent conduct, and outsourcing governance. RBI's NBFC directions expressly require agents to observe strict customer confidentiality and prohibit privacy-intrusive collection conduct, including intrusion into the privacy of family members and referees.

DPDP adds a parallel obligation layer. Your agent agreement with the BC must now include DPDP data protection obligations — not just RBI conduct codes. The consent notice shown to the borrower on the tablet is your responsibility. Any data breach at the BC level — a tablet stolen, borrower data synced to a personal device, records shared with third-party agents by the BC without authorisation — triggers your 72-hour DPBI notification clock.

The insurer is the Data Fiduciary. The TPA is processing sensitive personal data — health records — on your instructions, for your claims adjudication purpose. Health data carries heightened sensitivity under DPDP. While the Act does not create explicit special categories as GDPR does, the DPBI will treat data sensitivity as a material factor in penalty determination and in assessing the adequacy of security safeguards.

Your TPA contract must include a DPDP-aligned Data Processing Agreement. A TPA processing health records without explicit data processing scope controls is a significant regulatory exposure. The hospital providing records is not your Processor — it is independently sharing data subject to its own DPDP obligations. Your DPA with the TPA must clearly define what data the TPA may receive and from whom. If the TPA uses health analytics or passes data to a reinsurer, those secondary flows need a documented legal basis and, where required, prior consent from the patient.

Almost certainly not. A fintech platform that applies its own credit scoring model, makes independent decisions about borrower eligibility, and uses data for its own risk management is determining the purpose and means of processing independently. It is a Data Fiduciary for that processing, not your Processor.

You need a data-sharing agreement governing what data you send them, for what purpose, with what retention limits — not a DPA. You are not vicariously accountable for what the fintech does with data in its own credit decisioning layer. However, you are accountable for your own disclosure: did your consent notice tell the customer their data would be shared with the fintech for credit decisioning? If not, you have a consent coverage gap on your side.

The distributor may be a Data Processor for the transaction data passed to the AMC. However, the distributor is simultaneously an independent Data Fiduciary for the customer relationship data it holds and uses for advisory services, cross-selling, or marketing communications. The classification depends on each processing activity, not the organisation as a whole. Map each data flow separately. A single organisation can be a Processor for some activities and an independent Fiduciary for others.

The marketplace is the Data Fiduciary for data collected on its platform. If you designed the checkout flow, define what data is collected, host the transaction, and make the data available to the seller — you are the Data Fiduciary for the collection activity. The seller may be a joint fiduciary for using that data in their own customer relationship management. You cannot disclaim responsibility for data collected on your platform by arguing that sellers are independent businesses.

The Act does not prescribe an internal ownership structure for non-SDF Data Fiduciaries. Three models work in practice:

Model A — DPO-led (appropriate for larger organisations, likely SDFs): A dedicated Data Protection Officer with a direct line to the Board. Legal, IT, and business functions report data processing changes to the DPO. The DPO owns the ROPA, breach notification process, and DSAR handling.

Model B — Compliance-led with CISO partnership (mid-size organisations): The Compliance function owns the regulatory obligation mapping and ROPA. The CISO owns security safeguards and the technical component of breach notification. Shared ownership of vendor oversight — Compliance for DPA adequacy, CISO for security evidence.

Model C — Business owner accountability with central coordination (smaller organisations): Each business unit owns the consent and notice obligations for its own customer interactions. A central coordinator in Legal or Compliance maintains the ROPA and handles DSAR escalations. IT owns security safeguards centrally.

Legal or Compliance owns the Data Processing Agreement remediation programme governance. But practical accountability must span procurement (who controls the vendor relationship), IT (who can assess security safeguard clauses), and the business unit (who understands what data the vendor actually processes). This is a cross-functional remediation sprint, not a single department's problem. Prioritise by vendor tier — Tier 1 processors first, working down.

No. For Significant Data Fiduciaries, the DPO's reporting line to the Board hardwires privacy into governance. Even non-SDF organisations should expect DPDP incidents to escalate to Board and regulatory scrutiny. Common Board-level breach narratives under comparable frameworks include weak consent trails, repeated agent misconduct, poor vendor governance, and delayed breach response. In the event of an enforcement action, the DPBI will examine whether the Board was adequately informed and whether governance structures were adequate to the risk. Boards should receive periodic DPDP compliance reporting, approve the data governance policy, and be briefed on any breach incidents above a defined threshold.

Prioritise by enforcement exposure, not by size or revenue. Three workstreams in order:

Priority 1 — Breach notification readiness. The 72-hour DPBI notification clock is the hardest operational requirement to meet from a standing start. Map your breach detection capabilities, your vendor notification SLAs, and your internal escalation chain now — not after an incident.

Priority 2 — Consent and notice for new data collection. Every touchpoint collecting new personal data after May 2027 must have a compliant consent notice. Start with your highest-volume touchpoints — mobile app onboarding, loan application forms, KYC flows, point-of-sale data collection.

Priority 3 — DPA remediation for Tier 1 processors. Your highest-risk vendors — KYC processors, call centres, DSA networks, CBS vendors — need DPDP-aligned DPAs in place before enforcement begins. Work from your current vendor register and classify first, then remediate.

No. DPDP obligations map significantly onto existing BFSI regulatory requirements. Security safeguards align with RBI cybersecurity frameworks. Vendor DPA requirements overlap with RBI outsourcing governance. Breach notification aligns with CERT-In requirements — though timelines and recipients differ. Running DPDP as an overlay on your existing programme, identifying genuine gaps rather than rebuilding from scratch, is the most efficient and board-credible approach.

One programme with four implementation workstreams. The Data Fiduciary is the legal entity. The ROPA, breach notification process, DPO (if SDF), and data governance policy are enterprise-wide. Consent notice implementation, data mapping, and vendor DPA remediation will necessarily be done at the business-unit level because data flows differ. Governance is central; execution is distributed.

Not automatically. Data collected under pre-existing contractual or regulatory obligations may fall under legitimate use provisions in §7. However, if you intend to use legacy data for new purposes — analytics, cross-selling, behavioural profiling — each new purpose requires fresh consent. Conduct a purpose audit: map what data you hold, what it was collected for, and what you currently use it for. Any gap between original collection purpose and current use is a consent deficit that must be resolved before May 2027.

Only once digitised. The DPDP Act applies to digital personal data — data collected digitally, or collected in non-digital form and subsequently digitised. The Act does not apply to personal data in its non-digitised state. However, virtually all paper KYC is now scanned and entered into digital systems — DPDP applies from the point of digitisation. If you are digitising historical paper records, your DPDP scope includes those records from the moment they enter digital form.

Yes — provided loan servicing was a separately disclosed purpose with its own legal basis. The key DPDP principle is that each processing purpose needs its own legal basis. Marketing may rest on consent; loan servicing and regulatory compliance obligations may rest on legitimate use under §7. Withdrawal of marketing consent does not automatically require you to cease all processing — only the processing activities whose legal basis was the withdrawn consent. Maintaining this distinction in your consent records and your processing activity documentation is essential for demonstrating compliance when a withdrawal is exercised.