What Is a Data FiduciaryUnder India’s DPDP Act?

Section 2 sets out three distinct roles: data fiduciary, data processor, and data principal.

A data processor is “any person who processes personal data on behalf of a Data Fiduciary.” The processor acts on the fiduciary’s instructions; it doesn’t decide why or how the data gets processed[1][2]. A data principal is “the individual to whom the personal data relates,” where that individual is a child, the definition extends to the parents or lawful guardian[1]. And “personal data” itself is defined as “any data about an individual who is identifiable by or in relation to such data.”[1]

[1][2]

Readers familiar with other data-protection regimes will recognise the closest analogue: the “data controller” role under the EU’s GDPR is functionally similar to a data fiduciary. Both describe the entity that determines the purpose and means of processing, as distinct from a processor that only executes it.[2]

A company can be a data fiduciary for some of its processing activities and a data processor for others, depending on the specific activity.[2] What doesn’t change is where accountability sits. A data fiduciary can’t escape responsibility for a data processor’s non-compliance simply by delegating the processing to that processor; the fiduciary remains ultimately responsible.[2]

That’s the practical point for any BFSI institution that engages a data processor: the contract with that processor doesn’t move the compliance burden off the fiduciary’s own books.[4]

Section 8 sets out a data fiduciary’s general obligations[4]:

• •Bears responsibility for compliance and its processor's actions, irrespective of any agreement to the contrary (Section 8(1))
• •May only engage a data processor under a valid contract (Section 8(2))
• •Must ensure the accuracy and completeness of personal data used to make a decision affecting a data principal, or shared with another fiduciary (Section 8(3))
• •Must implement appropriate technical and organisational measures to ensure compliance (Section 8(4))
• •Must implement reasonable security safeguards to prevent a personal data breach (Section 8(5))
• •On becoming aware of a breach, must notify the Data Protection Board and each affected data principal (Section 8(6))
• •Must erase personal data once consent is withdrawn or the specified purpose is no longer being served (Section 8(7)-(8))
• •Must publish the contact details of a Data Protection Officer or other person who can answer processing-related questions (Section 8(9))
• •Must establish an effective mechanism to redress data principals' grievances (Section 8(10))

Two more requirements sit alongside that list. Personal data can only be processed on the basis of consent that is free, specific, informed, unconditional, and unambiguous, given through clear affirmative action, or under one of the “legitimate uses” set out in Section 7: specified employment purposes, medical emergencies, fulfilling a legal obligation, or providing a service the data principal has themselves sought.[5][6] Every consent request needs an itemised notice describing what’s being collected, why, how to withdraw consent, and how to file a complaint with the Data Protection Board.[5]

Under the DPDP Rules, 2025, a data fiduciary that becomes aware of a personal data breach must notify affected data principals without delay and give the Board a detailed report, with the reporting window commonly cited as within 72 hours, or such longer period as the Board allows.[7] Grievances run on their own clock: under Rule 14, a data fiduciary or Consent Manager has 90 days to resolve a data principal’s complaint.[7]

These obligations, along with the children’s-data and cross-border conditions covered below, are among the provisions scheduled to take full legal effect on 13 May 2027, under the Act’s phased rollout.[17] See KYCKART’s DPDP Act guide for the complete phase-by-phase timeline.

“Significant Data Fiduciary” (SDF) is a distinct classification under Section 10: it’s any data fiduciary, or class of data fiduciaries, that the Central Government notifies as such.[1][3]

The Central Government makes that call by weighing factors including the volume and sensitivity of personal data processed, the risk of harm to data principals’ rights, the potential impact on India’s sovereignty and integrity, and the potential impact on India’s democracy, electoral processes, state security, or public order.[3] Sectors commonly cited as likely SDF candidates include BFSI (banks, NBFCs, insurers), healthcare, e-commerce, telecoms, and large IT/SaaS providers, given the volume and sensitivity of the personal data those sectors handle.[3] No source used in researching this piece put a number or percentage on how many BFSI entities are actually expected to be designated.

[3][7][8]

Anyone who hasn’t completed 18 years counts as a “child” under the Act, and a data fiduciary needs verifiable parental or lawful-guardian consent before processing a child’s personal data. Data fiduciaries are barred outright from tracking, behavioural monitoring, or targeted advertising directed at children.[9]

The DPDP Act’s cross-border transfer model, under Section 16, is a “blacklist” approach: transferring personal data outside India is permitted by default to any country or territory, except the ones the Central Government specifically restricts by notification. That’s a different model from GDPR’s adequacy-decision and mechanism-based approach.[10][11]

That default permissiveness isn’t absolute for financial institutions. RBI’s 2018 circular on Storage of Payment System Data requires payment-system transaction data to be stored exclusively in India, an absolute localisation mandate. Where a stricter law provides more protection than the DPDP Act’s own permissive default, that stricter law takes precedence. A data transfer that satisfies the DPDP Act’s cross-border rule can still violate RBI’s localisation requirement for payment data.[12]

The DPDP Act’s penalty Schedule, adjudicated by the Data Protection Board of India, sets several distinct tiers tied specifically to a data fiduciary’s own conduct:

[15]

That last row is a separate, much smaller tier that applies to the data principal. Section 15 sets out a data principal’s own duties: complying with applicable laws while exercising rights under the Act, not impersonating another person when providing personal data for a specified purpose, not suppressing material information when applying for a State-issued document or proof of identity, not filing false or frivolous grievances, and furnishing only verifiably authentic information when exercising the right to correction or erasure.[16]

Banks and other regulated financial entities operating in India, including scheduled commercial banks, cooperative banks, regional rural banks, and foreign bank branches, are data fiduciaries under the DPDP Act. They determine the purpose and means of processing customer personal data, KYC documents, Aadhaar and PAN details, credit information, income and property records, guarantor details, and more, collected during onboarding, underwriting, and servicing accounts.[12][14]

That puts BFSI entities in a dual-compliance position: DPDP obligations run alongside existing RBI, SEBI, and IRDAI rules, and the two sets of rules create tension in specific spots[12][13][14]:

• •RBI's KYC-record-retention requirements, commonly cited as five years or more, can conflict with the DPDP Act's principle that data should be erased once its processing purpose is no longer being served.
• •SEBI-regulated entities often process data under statutory or regulatory mandate rather than purely on consent, which can constrain a data principal's ability to withdraw DPDP consent where continued processing is required for regulatory compliance.
• •A data breach can trigger separate, differently-timed notification obligations to CERT-In, the relevant sectoral regulator, and the Data Protection Board, on top of notifying affected data principals - duplicative reporting for a single incident.

Read together, three points made above suggest the same operational conclusion for a BFSI compliance function.

First, the dual-compliance tension isn’t symmetrical. RBI’s KYC-retention rules, commonly cited as five years or more, can conflict with the DPDP Act’s principle that data should be erased once a stated purpose is no longer being served.[12][13][14]The practical implication is that a bank’s data-retention policy needs to document which specific regulatory obligation applies to each category of data it continues to hold past the point DPDP’s own erasure principle would otherwise apply, rather than relying on one general “retained for compliance” justification across all data categories.

Second, RBI’s payment-data localisation mandate and the DPDP Act’s own rule that a stricter sector-specific law takes precedence over its permissive cross-border default[12]mean a BFSI institution can’t treat DPDP’s Section 16 blacklist test as the only check that matters. A transfer that clears that test can still fail a sector regulator’s own, tighter requirement, so a cross-border data flow involving a BFSI institution needs both layers checked independently.

Third, the accountability rule under Section 8(1)[4] and the SDF-designation factors that name BFSI as a likely candidate sector[3] point toward the same conclusion from different angles. A bank that engages a data processor doesn’t reduce its own compliance exposure by doing so[2][4], and if that bank is later designated a Significant Data Fiduciary, the additional Section 10 obligations and the higher ₹150 crore penalty tier for breaching them are added on top of its baseline Section 8 exposure.[3][15]