Data Fiduciary Obligations Under the DPDP Act: What Compliance Teams Need to Know

The Digital Personal Data Protection Act, 2023 introduces a formal accountability structure for every entity that determines the purpose and means of processing personal data in India. For compliance teams at regulated enterprises, understanding DPDP Act data fiduciary obligations is not an academic exercise. It is an operational imperative that directly affects how your organization collects consent, responds to breaches, maintains records, and reports to the Data Protection Board of India.

What makes this particularly complex for BFSI, pharma, healthcare, and IT services firms is that these obligations layer on top of existing regulatory requirements from RBI, SEBI, IRDAI, and CERT-In. The DPDP Act does not replace those frameworks. It adds a parallel set of duties that must be reconciled with them. This post breaks down what those duties are, who they apply to, and how compliance teams can operationalize them without building an entirely separate compliance function.

Data Fiduciary vs. Data Processor: Getting the Classification Right

The DPDP Act draws a clear distinction between two roles. A data fiduciary is any person or entity that, alone or in conjunction with others, determines the purpose and means of processing personal data. A data processor, by contrast, processes data on behalf of and under the instructions of a data fiduciary. The obligations under the Act fall almost entirely on the fiduciary.

For most regulated enterprises, the classification is straightforward. If you are a bank collecting KYC data, an insurance company processing policyholder health records, or a pharma firm managing clinical trial participant information, you are the data fiduciary. Your cloud hosting provider, your third-party analytics vendor, and your outsourced payroll processor are data processors.

The practical challenge arises in multi-party arrangements. Consider a mid-sized NBFC that uses a fintech partner’s platform for loan origination. Both entities may independently determine certain processing purposes, making both of them data fiduciaries for different categories of the same individual’s data. Compliance teams need to map these relationships carefully, because fiduciary status carries obligations that cannot be contractually delegated away, even when processing is outsourced.

Why Classification Matters Operationally

Getting this wrong has downstream consequences. If your organization incorrectly treats itself as a data processor when it is actually a fiduciary, you may fail to obtain valid consent, miss breach notification deadlines, or neglect record-keeping requirements. Each of these failures carries potential penalties under the Act, with fines reaching up to ₹250 crore for certain violations.

Compliance teams should conduct a data processing role assessment across all business units and third-party relationships before building out their DPDP compliance workflows. This assessment becomes the foundation on which every other obligation rests.

Significant Data Fiduciary: Elevated Criteria and Additional Obligations

The DPDP Act introduces a tiered accountability model. Beyond the baseline obligations applicable to all data fiduciaries, certain entities will be designated as Significant Data Fiduciaries (SDFs) by the Central Government based on criteria such as volume and sensitivity of data processed, risk of harm to data principals, potential impact on sovereignty and public order, and other factors the government may prescribe.

While the specific thresholds are yet to be notified through rules, it is widely expected that large banks, insurance companies, major healthcare chains, and IT services firms processing data at scale will fall into this category. For compliance leaders at these organizations, planning for SDF designation now is far more prudent than waiting for the notification.

What SDFs Must Do Beyond Baseline Obligations

Significant Data Fiduciaries carry three additional duties that demand dedicated governance infrastructure.

First, they must appoint a Data Protection Officer (DPO) based in India who will serve as the point of contact for the Data Protection Board and for data principals exercising their rights. This is not a nominal appointment. The DPO must have sufficient seniority and authority to influence organizational decisions about data processing.

Second, SDFs must conduct periodic Data Protection Impact Assessments (DPIAs). These assessments must evaluate the risks posed by processing activities to the rights of data principals and document the measures taken to mitigate those risks. For a large private bank processing millions of customers’ financial and biometric data, this is a substantial analytical and documentation exercise.

Third, SDFs must undertake periodic audits of their data processing activities by an independent data auditor. The audit findings, along with the DPIA reports, create a compliance evidence trail that regulated enterprises will need to produce on demand.

For organizations already subject to RBI’s cybersecurity framework or IRDAI’s information security guidelines, these SDF obligations create an opportunity to consolidate assessment and audit processes rather than duplicating them. Platforms like eQomply allow compliance teams to map DPIA workflows alongside existing regulatory assessments, maintaining a unified evidence repository that serves multiple compliance mandates simultaneously.

Purpose Limitation and Data Minimization: From Principle to Practice

Section 4 of the DPDP Act mandates that personal data may be processed only for the specific purpose for which consent was obtained or for certain legitimate uses enumerated in the Act. Section 6 further requires that only such data as is necessary for the stated purpose may be collected. These twin principles, purpose limitation and data minimization, are foundational to the Act’s framework.

In theory, they are intuitive. In practice, they create significant operational friction for regulated enterprises that have historically collected broad datasets for potential future use.

What This Looks Like in Regulated Industries

Consider a general insurance company that collects detailed health histories during claims processing. Under the DPDP Act, the data collected must be proportionate to the purpose of processing that specific claim. Retaining granular health data beyond the claim lifecycle “for analytics” or “for future product development” without a separate, specific consent for those purposes would violate the data minimization principle.

Similarly, a capital markets intermediary regulated by SEBI may collect extensive identity and financial data during onboarding under KYC regulations. The DPDP Act does not override SEBI’s KYC requirements, as regulatory compliance is a recognized legitimate use. However, using that same data for cross-selling wealth management products requires a distinct consent tied to that distinct purpose.

Compliance teams must work with business units to build purpose-consent matrices: structured mappings that tie each category of personal data to the specific purpose for which it was collected and the legal basis (consent or legitimate use) that authorizes its processing. This is documentation-intensive work, and it must be maintained as a living artifact as business processes evolve.

Organizations in the banking sector face a particularly layered version of this challenge, where DPDP Act compliance intersects with RBI’s existing data governance expectations in ways that require careful alignment rather than parallel tracking.

Breach Notification: Timelines, Process, and the CERT-In Overlap

Under Section 8(6) of the DPDP Act, every data fiduciary must notify the Data Protection Board of India and each affected data principal in the event of a personal data breach. The specific timelines and format for this notification will be prescribed by rules that are yet to be finalized.

However, regulated enterprises cannot afford to wait for the rules to establish their breach response infrastructure, for two reasons.

First, CERT-In’s 2022 directive already requires reporting of cyber incidents, including data breaches, within six hours of becoming aware of or being notified about the incident. This is among the most aggressive incident reporting timelines globally. Any organization that can meet CERT-In’s six-hour window will likely satisfy the DPDP Act’s notification timeline as well, but the notification recipients and content requirements may differ.

Second, sectoral regulators impose their own breach reporting obligations. RBI’s cybersecurity framework requires banks and NBFCs to report incidents to RBI’s CSITE within specified windows. IRDAI and SEBI have analogous requirements for their regulated entities.

Structuring a Unified Breach Response

This creates a scenario where a single data breach event may trigger three or four parallel notification obligations, each with different recipients, different content requirements, and potentially different timelines. The table below illustrates this overlap for a typical banking institution:

The structural challenge is clear. Without a centralized incident and evidence management system, compliance teams risk missing deadlines, providing inconsistent information across regulators, or failing to document their response adequately. This is where having a purpose-built GRC platform becomes critical infrastructure rather than a nice-to-have. eQomply’s breach response workflows can be configured to trigger parallel notification tracks from a single incident record, ensuring that each regulatory obligation is addressed with the right content at the right time.

Record-Keeping Requirements Under DPDP Act Data Fiduciary Obligations

Section 8 of the DPDP Act places ongoing record-keeping duties on data fiduciaries. These include maintaining records of consent obtained, the purposes for which data is processed, data shared with processors or third parties, and the measures taken to protect personal data. For Significant Data Fiduciaries, DPIA reports and audit findings add to this documentation burden.

The Act does not specify a retention period for these compliance records, and the rules are expected to provide further clarity. However, the expectation is clear: data fiduciaries must be able to demonstrate compliance at any point when questioned by the Data Protection Board or when a data principal exercises their rights.

The Practical Documentation Challenge

For a mid-to-large regulated enterprise, the volume of compliance documentation is substantial. A bank with 50 million customers will have tens of millions of consent records, each tied to specific processing purposes. Changes in consent, withdrawals, and purpose modifications must all be tracked with timestamps and audit trails.

Most organizations today manage this through a patchwork of spreadsheets, email records, ticketing systems, and departmental databases. This approach creates three structural problems that compliance functions must address.

The first is retrievability. When the Data Protection Board requests evidence that consent was obtained from a specific data principal for a specific purpose, can you produce it within hours rather than weeks? The second is integrity. Can you demonstrate that the records have not been tampered with or retroactively altered? The third is completeness. Across all business units, branches, digital channels, and third-party integrations, are you capturing every consent event and processing activity?

A compliance platform with automated evidence capture and immutable audit trails addresses all three problems. eQomply’s evidence management capabilities are specifically designed for this kind of regulatory documentation requirement, maintaining a centralized, tamper-evident repository that maps directly to the record-keeping obligations under the DPDP Act and coexisting regulatory frameworks.

Mapping DPDP Act Obligations to Existing Compliance Frameworks

For compliance teams at regulated enterprises, the DPDP Act does not exist in isolation. Its obligations intersect with, and in many cases overlap with, requirements that organizations are already managing under sectoral regulations.

Understanding these overlaps is essential for building an efficient compliance architecture rather than a duplicative one. The table below maps key DPDP Act data fiduciary obligations to their closest analogues in existing regulatory frameworks:

Building a Consolidated Compliance Architecture

The mapping reveals significant overlap, which is both an opportunity and a risk. The opportunity lies in building unified controls, assessments, and evidence repositories that satisfy multiple regulators simultaneously. The risk lies in treating these as identical when they are merely analogous, because each regulator may interpret scope, depth, and evidence requirements differently.

A practical approach is to identify the most stringent requirement in each category and build your controls to that standard. For breach notification, CERT-In’s six-hour timeline is the binding constraint. Meet that, and the DPDP Act and RBI requirements are likely satisfied on timing (though content and recipient requirements still need separate attention). For record-keeping, build to the DPDP Act’s evidentiary standard, which requires demonstrable, retrievable proof of compliance, and your sectoral records will likely meet their respective standards as well.

This is exactly the kind of cross-framework compliance mapping that a purpose-built GRC platform handles natively. Rather than running separate compliance tracks for each regulator, organizations can use a unified control framework where a single control implementation, with properly captured evidence, satisfies multiple regulatory obligations.

What Compliance Teams Should Do Now

The DPDP Act’s rules are still being finalized, and enforcement timelines remain uncertain. That uncertainty is not a reason to delay. It is a reason to build flexible compliance infrastructure that can adapt as rules are notified.

Start with a data fiduciary classification exercise across all business units and third-party relationships. Build your purpose-consent matrices. Assess whether your organization is likely to be designated as a Significant Data Fiduciary and plan for the elevated obligations accordingly. Audit your current breach response capabilities against the multi-regulator notification requirements. And critically, evaluate whether your existing record-keeping systems can produce compliance evidence with the speed, integrity, and completeness that the Data Protection Board will expect.

These are not theoretical challenges. They are operational readiness gaps that will determine whether your organization responds to DPDP Act enforcement with confidence or scrambles to catch up. If your compliance team is working through these questions and looking for a platform that consolidates DPDP Act obligations alongside RBI, SEBI, IRDAI, and CERT-In requirements in a single compliance architecture, a walkthrough of eQomply is a good place to start that conversation.