Significant Data Fiduciary Under India's DPDP Act: Are You One, and What It Means

What Is a Significant Data Fiduciary Under Section 10?

The DPDP Act applies a baseline set of obligations to every Data Fiduciary, but Section 10 creates a second, heavier tier: the Significant Data Fiduciary. An SDF is not something you become by crossing a bright-line threshold written in the statute. Instead, the Central Government notifies specific Data Fiduciaries or classes of Data Fiduciaries as significant, based on an assessment of factors listed in the Act.

Those factors are: the volume and sensitivity of personal data processed, the risk posed to the rights of Data Principals, the potential impact on the sovereignty and integrity of India, risk to electoral democracy, security of the State, and public order. The breadth of these factors is deliberate. It gives the government flexibility to designate a single large platform, an entire sector, or a class of processors defined by data volume or category.

The practical consequence of designation is a set of additional obligations layered on top of the baseline: appointing a Data Protection Officer based in India, engaging an independent data auditor, and conducting periodic Data Protection Impact Assessments and audits. The government may also prescribe other measures for SDFs through rules, which is where obligations such as algorithmic due diligence and restrictions on transferring certain data categories outside India have been signalled.

For compliance teams, the key mental shift is that SDF status is a regulatory decision, not a self-assessment. You cannot definitively conclude today that you are or are not an SDF. What you can do is assess your likelihood of designation and understand the delta between your current programme and SDF-grade obligations — because once a notification lands, the compliance clock starts running.

How Designation Happens and Who Is Likely to Be Designated

Designation happens by government notification. The Act does not require the government to publish its reasoning, a consultation process, or an appeal mechanism, although designated organisations may make representations through normal administrative channels. This is a meaningful difference from regimes like the EU's Digital Services Act, where the designation of very large platforms follows published user-number thresholds.

While no definitive public list existed as of mid-2026, the factors in Section 10 point clearly at certain profiles. Large consumer internet platforms — e-commerce marketplaces, social media intermediaries, gaming platforms — process personal data at a volume that alone invites scrutiny. Financial services and fintech companies process data whose sensitivity and fraud impact is high. Health-tech platforms combine sensitivity with vulnerable user populations. Telecom operators, credit bureaus, and large employers running HR platforms for hundreds of thousands of employees also fit the profile.

Sector regulators add another dimension. Organisations already subject to RBI, IRDAI, or SEBI data-handling directions are visible to the government as concentrated processors of sensitive data, and inter-regulator coordination makes them natural early candidates. Similarly, the electoral democracy factor suggests that platforms capable of political micro-targeting or large-scale opinion shaping are squarely in scope.

A sensible approach is to score yourself against the Section 10 factors honestly: how many Data Principals do you process data about, how sensitive is that data, what would the blast radius of a breach be, and does your processing touch any of the state-interest factors? Organisations that score high on two or more factors should assume designation is a question of when, not if, and plan accordingly.

Obligation One: A Data Protection Officer Based in India

The first SDF obligation is appointing a Data Protection Officer. The Act is specific on three points: the DPO must be an individual, must be based in India, and must be responsible to the board of directors or similar governing body of the Data Fiduciary. The DPO also serves as the point of contact for the grievance redressal mechanism that every Data Fiduciary must operate.

The India-residency requirement has real organisational consequences for multinationals. A global privacy officer sitting in London or San Francisco cannot double as the DPDP DPO. Groups that run privacy as a global function need to either relocate a senior privacy leader to India or, more commonly, appoint an India-based DPO who plugs into the global privacy organisation while carrying direct accountability to the board for DPDP matters.

The reporting line is worth taking seriously rather than treating as a formality. Responsibility to the board means the DPO needs genuine access to the governing body — a standing agenda item, escalation rights, and the authority to commission remediation. Regulators in other jurisdictions have penalised organisations for appointing DPOs with conflicts of interest or without real independence, and there is little reason to expect the Data Protection Board of India to take a softer view once enforcement matures.

Practically, the DPO also becomes the public face of your compliance programme. Their contact details must be published and included in responses to Data Principals, and grievances flow to them. Staff the role with someone who can handle both regulatory interaction and operational volume, and back them with a team — a lone DPO cannot personally supervise DPIAs, audits, grievance handling, and breach response at SDF scale.

Obligation Two: Independent Data Auditors and Periodic Audits

The second obligation is appointing an independent data auditor to evaluate the SDF's compliance with the Act. This is a distinctive feature of the Indian regime — the GDPR contains no mandatory external audit requirement, leaving verification to supervisory authority investigations and voluntary certification schemes. The DPDP Act instead builds third-party verification into the baseline for its highest-risk tier.

The DPDP Rules require SDFs to conduct a data audit periodically — the government has indicated an annual cadence through the Rules — with the auditor reporting on the fiduciary's compliance across consent, notice, security safeguards, retention, and rights handling. Independence is the operative word: the auditor cannot be an internal function or an entity with a conflicting commercial relationship. Expect an ecosystem of accredited audit firms to consolidate around this requirement, similar to how SOC 2 and ISO 27001 audit practices developed.

Preparing for an audit you have never undergone is the hard part. The audit will test evidence, not intentions: consent records that can be produced for specific Data Principals, notices in the required languages, documented retention schedules with proof of deletion, breach registers, DSR logs with timestamps, and processor contracts containing the required clauses. Organisations whose compliance lives in policy documents rather than systems will struggle to produce this evidence on demand.

The pragmatic preparation step is a readiness assessment run to the same standard: pick a quarter, attempt to produce the evidence an auditor would request, and log every gap. Most organisations discover that their biggest weaknesses are not policy gaps but evidence gaps — the process happened, but nobody can prove it. Closing those gaps requires instrumenting consent, DSR, and retention workflows so that audit trails are generated automatically as a by-product of operations.

Obligation Three: Periodic Data Protection Impact Assessments

The third obligation is conducting periodic Data Protection Impact Assessments. The Act defines a DPIA as a process comprising a description of the rights of Data Principals and the purpose of processing, an assessment and management of the risk to those rights, and such other matters as prescribed. The DPDP Rules pair the DPIA with the audit on a periodic cadence, and significant observations from both must be reported to the Data Protection Board.

The framing differs subtly from GDPR Article 35. Under GDPR, a DPIA is triggered by specific high-risk processing activities — you assess a project. Under the DPDP Act, the DPIA is a standing obligation of the organisation — you assess your processing estate on a recurring schedule. In practice, mature programmes will converge on doing both: a periodic organisation-wide assessment to satisfy the DPDP obligation, plus project-level assessments embedded in product development so that new high-risk processing is caught before launch.

A defensible DPDP DPIA needs a current inventory of processing activities as its foundation. You cannot assess risk to Data Principals if you do not know what data you hold, where it flows, which processors touch it, and what purposes it serves. This is where organisations with automated data mapping have a structural advantage — a DPIA built on a live data map can be refreshed each cycle, while one built on interviews and spreadsheets goes stale before it is signed off.

Structure the output for two audiences. The board and the Data Protection Board of India need a risk-ranked summary with remediation commitments; your engineering and operations teams need specific findings tied to systems and owners. A DPIA that produces only a compliance narrative, with no actionable backlog, will satisfy neither the auditor nor the regulator when the same risks appear unremediated in the next cycle.

Other Measures: Algorithmic Due Diligence and Transfer Restrictions

Section 10 empowers the government to prescribe additional measures for SDFs, and the DPDP Rules have used this power in two notable directions. The first is algorithmic due diligence: SDFs are expected to observe due diligence to verify that the algorithmic software they deploy for processing personal data is not likely to pose a risk to the rights of Data Principals. The second is data localisation by exception: the government may, on the recommendation of a committee, specify categories of personal data that SDFs may not transfer outside India.

The algorithmic due diligence obligation is drafted broadly, and its enforcement contours are still forming. Read practically, it requires SDFs to maintain an inventory of algorithmic systems that process personal data — recommendation engines, credit scoring models, fraud detection, ad targeting, AI features — and to assess each for risks to Data Principal rights. Organisations already building EU AI Act compliance will find substantial overlap: model documentation, risk classification, and monitoring processes serve both regimes.

The targeted localisation power is narrower than the blanket localisation mandates in earlier drafts of the legislation, but it is more potent for the organisations it touches. If a category of data your business depends on — say, certain financial or health data — is notified as non-transferable, your architecture must be able to confine that category to Indian infrastructure while the rest of your stack remains global. Category-level data residency is significantly harder than tenant-level residency, because it requires classification at the field level and routing controls in every pipeline that moves data across borders.

The planning implication is architectural: SDF candidates should ensure their platforms can identify and segregate data categories, not just customer tenants. Building that capability after a notification lands, under a compliance deadline, is the expensive path.

A Practical Readiness Checklist: Prepare Before You Are Designated

The organisations that will handle SDF designation well are the ones that treat it as a foreseeable event rather than a surprise. A readiness programme has five workstreams, none of which is wasted effort even if designation never comes.

First, run the designation risk assessment. Score your organisation against the Section 10 factors, document the conclusion, and revisit it annually or when your data footprint changes materially. This analysis also tells you which parts of your processing drive the risk — which is exactly where a regulator will look first.

Second, close the governance gap. Identify who your India-based DPO would be, define the board reporting line, and stand up the grievance mechanism to a standard that could absorb SDF-level volume. If your current privacy lead sits outside India, start the hiring or restructuring conversation now rather than under a notification deadline.

Third, build the evidence layer. Instrument consent records, DSR handling, retention enforcement, and breach logs so that audit-grade evidence is produced automatically. This is the workstream with the longest lead time, and it is also the one that pays off immediately in baseline DPDP compliance regardless of SDF status.

Fourth, establish the DPIA muscle. Run an organisation-wide assessment on a defined cadence and embed project-level assessments into your development lifecycle. Fifth, prepare the architecture: inventory your algorithmic systems, and verify that your platform can segregate data categories for potential localisation requirements. Organisations that complete these five workstreams will find that formal designation changes their reporting obligations, not their operating reality — which is precisely the position you want to be in when the notification arrives.