Rule 13 — Additional Obligations of Significant Data Fiduciary

Section 10 of the Act lets the Central Government notify any Data Fiduciary, or class of Data Fiduciaries, as a Significant Data Fiduciary — based on factors like the volume and sensitivity of data processed, risk to Data Principals' rights, and impact on sovereignty, electoral democracy, State security or public order. Section 10(2) then requires that SDF to appoint a India-based Data Protection Officer and an independent data auditor, and to undertake periodic DPIAs and audits. Rule 13 is where the Rules turn those Act-level requirements into an operating cadence, and adds two obligations the Act text doesn't spell out on its own: algorithmic due diligence and data localisation.

13(1) — DPIA and audit, once every twelve months

Rule 13(1) requires a Significant Data Fiduciary to undertake a Data Protection Impact Assessment and an audit once in every twelve-month period, counted from the date it was notified as an SDF (or included in a notified class). Both exercises have one stated purpose: to ensure effective observance of the Act and the rules made under it. That framing matters — it's not asking whether policies exist on paper, but whether the organisation's actual practice holds up against what the Act and Rules require. This isn't a one-time readiness exercise done ahead of notification; it's an annual accountability cycle that keeps running for as long as SDF status lasts.

13(2) — findings go to the Board, not just the file

Rule 13(2) requires the SDF to cause whoever carries out the DPIA and audit to furnish the Board with a report containing significant observations from both exercises. The finding doesn't stay an internal management document — it's a regulator-visible artefact. That has two practical consequences: the DPIA and audit have to be substantive enough to surface real weaknesses (an exercise that only validates existing practice produces nothing worth reporting, which is itself a red flag), and the person carrying them out needs genuine independence, since their observations are what the Board sees.

13(3) — algorithmic due diligence across the data lifecycle

Rule 13(3) requires an SDF to observe due diligence to verify that the technical measures it adopts — explicitly including algorithmic software — for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data are not likely to pose a risk to Data Principals' rights. The list of covered activities is deliberately broad — essentially the full lifecycle a piece of personal data passes through inside a system. And the standard is prospective: this is about verifying a system isn't likely to cause harm before or as it operates, not investigating after something has already gone wrong. Any system that profiles users, automates a decision about them, or shapes what content reaches them is squarely what this sub-rule is aimed at.

13(4) — data and traffic-data localisation for specified categories

Rule 13(4) requires an SDF to ensure that personal data the Central Government specifies — acting on the recommendation of a committee it constitutes — is processed subject to a restriction: that data, and the traffic data pertaining to its flow, is not transferred outside India's territory. Two details are easy to miss here. First, the restriction only bites once the government actually specifies which personal data it covers — Rule 13(4) itself doesn't localise anything by default; it's the mechanism that gives effect to a future notification. Second, the restriction explicitly reaches "traffic data pertaining to its flow," not just the personal data itself — so metadata about how and where that data moves is in scope too, not only its storage location.

Rule 13(5) defines the committee that recommends which data gets specified: a body the Central Government constitutes for this purpose, which must include officials from the Ministry of Electronics and Information Technology and may include officials from other ministries or departments.

Why this matters in practice

The grey-zone pattern across all four obligations is the same shape: doing the exercise in a way that's built to pass rather than built to test. A DPIA and audit that only confirm what the organisation already believed isn't compliant with 13(1)'s "effective observance" standard — it's a paperwork exercise wearing the DPIA's name. Assuming a cloud vendor's general compliance posture satisfies 13(4)'s localisation restriction is a similar substitution — localisation is about where specified data and its flow metadata actually sit, not about which vendor's certifications are on file.

Illustration: a large social media platform notified as an SDF runs its annual DPIA and audit, and the auditor flags that a recommendation algorithm is amplifying content in ways that disproportionately affect younger users — a finding squarely within 13(3)'s territory. Under 13(2), that observation goes to the Board as part of the audit report, not just into an internal risk register. Separately, if the government has specified certain categories of that platform's user data as subject to localisation under 13(4), the platform has to keep both that data and the metadata describing its cross-border flow inside India — regardless of where its infrastructure is otherwise hosted.

How Rule 13 connects to the rest of the Rules and the Act

Rule 13 layers on top of Section 8's general obligations and Section 10's SDF framework — every SDF still owes everything Section 8 requires, plus the DPO appointment, auditor appointment and periodic-assessment duties Section 10(2) states, plus what Rule 13 adds. Rule 13(4)'s localisation restriction is distinct from Rule 15's cross-border transfer conditions and Section 16's country-level transfer restrictions — Rule 13(4) is a category-specific localisation duty that applies only to SDFs and only once the government specifies the covered data, while Rule 15 and Section 16 govern outbound transfer conditions more broadly across all Data Fiduciaries.