Rule 13 - Additional obligations of Significant Data Fiduciary

Rule 13 establishes a higher and more continuous standard of accountability for a Data Fiduciary that the Central Government has notified as a Significant Data Fiduciary. It supplements Section 10 of the Digital Personal Data Protection Act, 2023 by prescribing an annual compliance cycle, direct reporting of significant audit and impact-assessment observations to the Data Protection Board, due diligence concerning technical and algorithmic systems, and a conditional localisation requirement for personal data later specified by the Central Government.

The Rule does not apply merely because an organisation is large, operates digitally, processes sensitive information or considers itself systemically important. The additional obligations begin when the Central Government formally notifies the particular Data Fiduciary or a class to which it belongs as a Significant Data Fiduciary under Section 10(1). Section 10 identifies the relevant designation factors as including the volume and sensitivity of personal data, risk to Data Principal rights, potential impact on sovereignty and integrity, electoral democracy, State security and public order.

Rule 13 is scheduled to come into force on 13 May 2027. However, the designation of a particular entity and some obligations under Rule 13 will depend on later notifications, including any notification specifying personal data that must remain within India.

A drafting correction should also be noted. The relevant Ministry is the Ministry of Electronics and Information Technology, not the “Ministry of Electronics and Technology.”

1. Section 10 and Rule 13 as an integrated accountability framework

Section 10 creates the SDF framework. Once designated, an SDF must:

• appoint a Data Protection Officer based in India who represents the SDF, reports to its board or equivalent governing body and functions as the grievance contact;

• appoint an independent data auditor;

• undertake periodic Data Protection Impact Assessments;

• undergo periodic audits; and

• comply with additional prescribed measures.

Rule 13 supplies the principal detail missing from the Act. It:

• fixes the assessment and audit cycle at once in every twelve months from designation;

• requires significant observations from those exercises to be furnished to the Board;

• imposes risk-oriented due diligence for technical measures, including algorithmic software; and

• introduces a notification-based restriction against transferring specified personal data and associated traffic data outside India.

These obligations are connected. The DPIA identifies risks before or during processing. The audit tests whether the SDF complies in practice. Algorithmic due diligence addresses risks created by the technology through which personal data is handled. Reporting gives the Board visibility into significant problems. The localisation clause allows the Government to impose an additional infrastructure boundary for specified data.

Rule 13 therefore creates a continuing supervisory model rather than a one-time certification exercise.

1.1 Designation as a Significant Data Fiduciary

An organisation becomes subject to Rule 13 only through a Central Government notification. There are two possible forms of designation:

1. the notification may name a particular Data Fiduciary; or

2. it may identify a class of Data Fiduciaries defined by stated characteristics.

A company should not assume that being a market leader, operating at scale or processing consequential information automatically makes it an SDF. Those circumstances may make designation more likely, but the legal status follows the notification.

Conversely, an entity cannot avoid a class-based notification merely because it is not individually named. If the notification describes a class and the organisation objectively falls within it, the Rule applies.

1.2 Illustration: Individually named platform

The Government notifies a particular digital platform as an SDF because of the exceptional volume of personal data processed and the potential risk to Data Principal rights.

The twelve-month compliance cycle begins from the date on which the platform is notified as an SDF, subject to the terms and effective date of the notification.

1.3 Illustration: Notification of a class

The Government notifies a defined class of entities processing a stated category and volume of information as SDFs.

An organisation falling within that class cannot argue that it remains outside Rule 13 merely because the notification does not reproduce its corporate name. It must assess objectively whether it satisfies the class criteria.

1.4 Corporate groups

SDF status should be applied to the legal person or class identified in the notification. If one company within a group is designated, other group companies do not automatically become SDFs unless the notification includes them or they fall within a notified class.

However, group structure cannot be used to narrow the assessment artificially. If the designated company determines the purposes and means of processing carried out across shared group systems, those processing operations may form part of its SDF compliance perimeter.

1.5 Annual Data Protection Impact Assessment and audit

Rule 13 requires an SDF to undertake both a DPIA and an audit once in every twelve-month period beginning from the date of its designation.

This creates a maximum interval, not merely an aspiration to assess compliance “periodically.” The SDF should be able to show that each twelve-month period was covered by completed exercises.

The DPIA and audit are related but perform different functions.

1.6 The DPIA

A DPIA is a structured assessment of processing and its risks to Data Principals. Section 10 describes the process as including:

• a description of the rights of Data Principals;

• the purpose of processing;

• assessment of risks to those rights; and

• management of those risks.

A meaningful DPIA should explain the actual processing rather than reproduce general privacy principles. It should identify:

• the Data Principals affected;

• the personal data involved;

• the stated and actual purposes;

• the legal grounds;

• how data is collected, generated, inferred, shared and erased;

• Data Processors and other recipients;

• systems, models and technologies involved;

• risks to individuals;

• existing safeguards;

• unresolved risks;

• persons responsible for remediation; and

• the basis on which any remaining risk was accepted.

The focus is not limited to cybersecurity. Risks to Data Principal rights may arise from:

• processing without valid consent or another lawful ground;

• misleading notices;

• excessive collection;

• inaccurate information;

• improper denial of rights;

• excessive retention;

• unauthorised sharing;

• discriminatory or materially inaccurate algorithmic outputs;

• profiling;

• inability to withdraw consent;

• dependence on an opaque Processor;

• or failure to erase data from linked systems.

1.7 Illustration: Credit-assessment system

An SDF uses an algorithmic system to assist credit decisions. The system processes transaction records, account history, repayment behaviour, device information and derived risk indicators.

The DPIA should not merely state that the system uses encryption and access control. It should examine:

• whether each data category is necessary;

• whether the information is accurate and current;

• whether the model uses inappropriate proxies;

• whether errors can materially affect applicants;

• whether an individual can correct inaccurate source data;

• whether the model is monitored for degradation;

• whether the vendor independently uses the information;

• and how the organisation will manage an unjustified outcome.

1.8 The audit

The audit examines whether the SDF actually observes the Act and Rules. It should test implementation rather than accept policy statements at face value.

The auditor should compare:

• documented purposes against real system use;

• approved access against actual permissions;

• stated retention periods against live databases and archives;

• consent records against current processing;

• contractual restrictions against Processor practices;

• security policies against technical configurations;

• rights procedures against completed cases;

• and impact-assessment commitments against actual remediation.

1.9 Illustration: Retention policy and system reality

An SDF’s retention schedule says inactive customer profiles are erased after the applicable period. The audit discovers that profiles are deleted from the customer application but remain indefinitely in analytics warehouses and vendor platforms.

The existence of the policy does not establish compliance. The audit should identify the discrepancy, assess its significance and require accountable remediation.

1.10 The DPIA and audit are separate exercises

Rule 13 requires both. An SDF should not merge them so completely that one of their functions disappears.

The DPIA is generally:

• risk-focused;

• processing-centred;

• anticipatory as well as retrospective;

• directed towards the effects on Data Principals; and

• concerned with whether risks are identified and managed.

The audit is generally:

• evidence-focused;

• compliance-centred;

• retrospective at the time of testing;

• directed towards whether legal and organisational controls operate; and

• concerned with deviations, failures and remediation.

The same professional or team may potentially contribute to both, subject to independence and conflict considerations. But a single questionnaire labelled “DPIA and audit” will be inadequate if it neither analyses processing risk nor independently tests compliance.

1.11 Timing of the annual cycle

The twelve-month period begins from the date on which the Data Fiduciary is notified individually or becomes included in a notified class.

If designation occurs on 1 October 2027, the first DPIA and audit must be undertaken within the twelve-month period beginning on that date, subject to any specific transition direction in the notification.

The SDF should not automatically align the first exercise to its next financial year, corporate audit calendar or global privacy review if that would exceed the statutory period.

After the first cycle, each following twelve-month period must be covered. An assessment completed once every two years would not satisfy the Rule merely because the organisation conducts internal reviews in the intervening period.

1.12 Completion, not commencement

A defensible reading requires the SDF to complete the DPIA and audit within each period. Starting an audit shortly before the period ends but completing it months later could defeat the annual requirement.

The organisation should plan sufficient time for:

• scoping;

• evidence collection;

• interviews;

• control testing;

• technical testing;

• reporting;

• management response;

• and submission of significant observations to the Board.

1.13 Additional assessments during the year

The annual cycle is the minimum recurring requirement. It does not mean that an SDF can wait until the next annual DPIA after introducing a materially different high-risk processing operation.

Additional assessment may be needed when the SDF:

• launches a new large-scale platform;

• deploys consequential algorithmic software;

• introduces biometric processing;

• materially changes its purpose;

• combines previously separate databases;

• appoints a critical new Processor;

• expands into a new category of Data Principals;

• suffers a major personal data breach;

• or identifies an unexpected risk to rights.

1.14 Illustration: New AI deployment after annual DPIA

An SDF completes its annual DPIA in June. In September, it deploys an AI system that analyses customer behaviour and changes eligibility for important services.

The organisation should not avoid assessment until the following June merely because it completed the annual exercise. The new processing creates a distinct risk introduced after the assessment.

1.15 Scope of the annual DPIA and audit

Rule 13 refers to observance of the Act and Rules. The annual exercises should therefore cover the SDF’s relevant personal-data processing comprehensively.

This does not necessarily mean every low-risk processing operation must receive identical depth. A risk-based structure can apply deeper testing to:

• large-scale databases;

• children’s information;

• financial, health, identity or biometric information;

• algorithmic decision systems;

• high-volume consumer platforms;

• critical Processors;

• cross-border processing;

• and operations attracting repeated complaints or incidents.

Lower-risk activities may receive proportionate review. But the SDF should maintain a complete processing inventory so that material operations are not omitted merely because no business unit disclosed them to the audit team.

1.16 Newly acquired business

If the SDF acquires a company whose systems are integrated into its processing, the DPIA and audit scope should reflect the actual post-acquisition position. The SDF cannot omit inherited databases indefinitely by labelling them “legacy systems.”

1.17 Shared group systems

Where the designated SDF uses a group-wide customer database, cloud environment or analytics platform, the assessment should examine the portion of the system relevant to processing for which the SDF determines the purpose and means.

1.18 Independence and competence

Section 10 expressly requires an SDF to appoint an independent data auditor. Rule 13 also refers to the person carrying out the DPIA and audit.

Independence is not satisfied merely through a job title. The auditor should be able to evaluate compliance without being required to defend the systems, decisions or controls being audited.

A person responsible for designing and operating a control may provide evidence and explanations, but should not be the sole person deciding whether that same control is effective.

Relevant threats to independence may arise where:

• the auditor designed the processing system under review;

• fees depend on a favourable conclusion;

• management can suppress findings;

• the audit team lacks access to records;

• critical findings are removed without justification;

• or a Processor audits its own compliance and the SDF accepts the report without review.

The auditor must also be competent. The work may require combined capability in:

• the DPDPA and Rules;

• privacy governance;

• cybersecurity;

• system architecture;

• algorithmic systems;

• data governance;

• contract and Processor management;

• and sector-specific regulation.

A financial audit qualification alone does not necessarily establish competence to examine algorithmic risks or personal-data architecture.

1.19 Reporting significant observations to the Board

Rule 13 does not merely require the SDF to retain its DPIA and audit internally. The person conducting those exercises must furnish the Board with a report containing the significant observations.

This creates direct regulatory visibility into material weaknesses and risks.

1.20 What counts as significant

The Rule does not exhaustively define “significant observations.” Significance should be evaluated by substance, not by whether the organisation labels a matter “high,” “medium” or “low.”

An observation may be significant because of:

• the number of Data Principals affected;

• the nature of the personal data;

• the seriousness or likelihood of harm;

• the duration of the failure;

• systemic or repeated non-compliance;

• ineffective consent;

• large-scale excessive retention;

• inability to honour rights;

• weak safeguards;

• major Processor dependence;

• undisclosed secondary use;

• algorithmic risk;

• localisation failure;

• or non-compliance affecting children or vulnerable persons.

A control weakness affecting a relatively small number of individuals may still be significant if the likely consequence is severe. Conversely, a high-volume administrative inconsistency may not always be significant if it creates no meaningful rights risk, though it should still be corrected internally.

1.21 Illustration: Rights requests

An audit finds that a minor template error affected three responses but was corrected immediately. That may not necessarily be significant.

If the audit finds that the SDF systematically closes access and erasure requests without searching its analytics systems or Data Processors, the observation is likely significant because the failure is structural and affects the exercise of statutory rights.

1.22 Reporting cannot be confined to favourable findings

The SDF should not interpret “significant observations” as meaning only positive achievements. The report must communicate material adverse observations as well.

The person conducting the assessment or audit should not be required to omit a significant finding because management disputes it. Management may include its response, factual correction, mitigation or disagreement, but the integrity of the auditor’s finding must be preserved.

1.23 Report content

Although Rule 13 does not prescribe a complete form, a useful report should communicate:

• the processing or system examined;

• the observation;

• the legal requirement involved;

• affected Data Principals and personal data;

• risk or actual consequence;

• supporting evidence;

• the SDF’s response;

• corrective measures;

• responsible owner;

• target date;

• residual risk;

• and status of earlier significant findings.

The Board needs enough information to understand why the observation matters. A report containing only a statement such as “some control improvements are recommended” would not provide meaningful regulatory visibility.

1.24 Who submits the report

Rule 13 requires the SDF to cause the person carrying out the DPIA and audit to furnish the report to the Board.

This wording is important because it gives the report a degree of separation from management editing. The person who conducted the exercise must furnish the significant observations rather than merely send an internal report to management and rely on the SDF to decide what reaches the Board.

The SDF remains responsible for ensuring submission. It cannot defend a failure by saying that the auditor neglected to file the report.

The appointment terms should therefore address:

• duty to report;

• submission method;

• timing;

• protection of audit independence;

• access to relevant evidence;

• factual-review procedures;

• treatment of management disagreement;

• confidentiality;

• and preservation of working papers.

1.25 Timing uncertainty

Rule 13 requires annual DPIA and audit and requires reporting of significant observations, but the quoted text does not prescribe a separate number of days after completion for furnishing the report.

The safer approach is prompt submission after finalisation, not retention until the end of a later compliance cycle. Any Board-prescribed digital filing procedure, notification or direction must also be followed when operational.

1.26 Confidentiality and sensitive content in Board reports

A DPIA or audit report may contain:

• system architecture;

• security weaknesses;

• details of personal data breaches;

• source-code or model information;

• vendor vulnerabilities;

• legal analysis;

• commercial information;

• and evidence concerning employees or attackers.

The SDF must provide sufficient information to comply with Rule 13 but should structure the report carefully to avoid unnecessary disclosure of:

• personal data unrelated to the finding;

• exploitable technical detail;

• privileged legal advice;

• credentials;

• or complete copies of high-risk datasets.

Confidentiality does not justify withholding a significant observation. It affects how the observation and evidence are presented.

1.27 Remediation and continuing accountability

Submitting a significant observation to the Board does not complete the SDF’s responsibility. The underlying problem must be managed.

The SDF should establish:

• an accountable remediation owner;

• a realistic deadline;

• interim risk controls;

• management escalation;

• verification of closure;

• and inclusion in the next audit where appropriate.

1.28 Illustration: Weak authentication

An audit finds that privileged users can access a high-volume customer database without multifactor authentication.

Merely reporting this to the Board does not satisfy the SDF’s security obligation. It must implement effective remediation, restrict risk in the interim and verify that stronger authentication operates across relevant systems.

1.29 Repeated findings

If the same significant finding appears in successive annual reports, the Board may reasonably question whether:

• management gave sufficient priority to remediation;

• funding or ownership was inadequate;

• risk was knowingly accepted without justification;

• the auditor’s recommendations were ignored;

• or the organisation’s governance was ineffective.

Annual repetition converts the process from a discovery mechanism into evidence of unresolved non-compliance.

1.30 Algorithmic and technical due diligence

Rule 13 extends beyond annual assessments. It requires ongoing due diligence to verify that technical measures, including algorithmic software, used across personal-data operations are not likely to pose a risk to Data Principal rights.

This is broader than a narrow rule concerning artificial intelligence. It can cover software used for:

• hosting;

• display;

• uploading;

• modification;

• publishing;

• transmission;

• storage;

• updating;

• and sharing of personal data.

The provision can therefore apply to:

• recommendation systems;

• automated eligibility tools;

• fraud-detection systems;

• content-ranking systems;

• customer segmentation;

• identity matching;

• biometric systems;

• automated moderation;

• data-sharing engines;

• workflow software;

• storage infrastructure;

• cloud platforms;

• search systems;

• and access-control technologies.

The focus is not whether the software is branded “AI.” The relevant question is whether a technical measure participating in personal-data processing is likely to create a risk to Data Principal rights.

1.31 “Not likely to pose a risk” is not a zero-risk guarantee

Every substantial technical system creates some possibility of error or misuse. Rule 13 should not be interpreted as demanding mathematical proof that no risk can ever arise.

Its practical meaning is that the SDF must:

1. identify foreseeable rights risks;

2. test whether the system produces or enables those risks;

3. introduce appropriate safeguards;

4. determine whether residual risk is acceptable under the Act;

5. monitor performance and changes;

6. respond when risks materialise; and

7. preserve evidence of the due-diligence process.

An SDF should not deploy a system where material rights risks remain unmanaged merely because the vendor describes it as accurate or secure.

1.32 Rights risks created by technical systems

Technical risk under Rule 13 is not confined to hacking or data leakage.

A system may pose a risk to Data Principal rights where it:

• processes data without the applicable consent or lawful ground;

• collects more information than necessary;

• publishes personal data to an incorrect audience;

• shares data with unauthorised recipients;

• prevents withdrawal of consent;

• fails to propagate corrections;

• retains information after the purpose ends;

• produces materially inaccurate inferences;

• unfairly disadvantages individuals;

• bypasses access restrictions;

• prevents exercise of rights;

• or makes it impossible to identify and delete personal data across linked systems.

1.33 Illustration: Recommendation engine

An SDF uses a recommendation system that analyses customer activity. The system begins using browsing data collected for service security to personalise commercial offers.

The principal risk is not necessarily model accuracy. It is unauthorised purpose expansion. Algorithmic due diligence should examine data provenance, permitted purpose and downstream use, not merely technical performance.

1.34 Illustration: Automated eligibility tool

An SDF uses software to determine whether customers qualify for an important service. The system relies on outdated address and income records and rejects individuals automatically.

The technical measure may pose risks to accuracy, correction and fair access to the service. Due diligence should examine source-data quality, update mechanisms, error rates, override processes and whether an individual can correct information affecting the outcome.

1.35 Illustration: Publishing tool

A platform modifies its privacy settings and accidentally changes old private posts to public visibility.

The relevant software is not necessarily an AI model. It is a technical measure governing display and publishing of personal data. Rule 13’s language is broad enough to require due diligence concerning this risk.

1.36 Due diligence across the system lifecycle

Algorithmic due diligence should not begin only after deployment.

1.37 Before acquisition or development

The SDF should understand:

• the intended purpose;

• personal data required;

• source and quality of data;

• model or system functionality;

• vendor role;

• known limitations;

• explainability appropriate to the use;

• security;

• retention;

• and ability to support rights.

If the vendor refuses to disclose enough information for the SDF to assess material risks, the SDF must consider whether deployment is compatible with Rule 13.

1.38 Before deployment

The system should be tested in the actual intended context.

Relevant testing may examine:

• false positives and false negatives;

• reliability across affected user groups;

• unauthorised data exposure;

• permission enforcement;

• output accuracy;

• data drift;

• adversarial manipulation;

• model memorisation;

• deletion capability;

• correction propagation;

• and logging.

Testing on a generic vendor dataset may not reveal risks arising from the SDF’s own population, system integration and business rules.

1.39 During operation

Risk can change because:

• input data changes;

• source data becomes stale;

• the user population expands;

• the model is retrained;

• the purpose is broadened;

• new integrations are added;

• a vendor changes its terms;

• employees use outputs differently;

• or the software’s performance degrades.

The SDF therefore needs monitoring, incident escalation and periodic reassessment.

1.40 At retirement

The SDF should determine:

• what personal data remains;

• whether models or outputs retain identifiable information;

• whether the Processor keeps copies;

• whether access credentials have been revoked;

• whether legal retention applies;

• and how secure erasure will occur.

A technical system should not remain connected to live data merely because it is no longer actively used.

1.41 Vendor-supplied algorithms and software

An SDF cannot transfer Rule 13 responsibility to a technology provider.

Vendor assurance may support due diligence through:

• technical documentation;

• independent testing;

• audit reports;

• security certification;

• performance information;

• subprocessor details;

• contractual restrictions;

• incident history;

• and change notifications.

But vendor statements such as “industry-leading,” “bias-free,” “privacy-safe” or “fully compliant” are not substitutes for the SDF’s own contextual assessment.

1.42 Illustration: Recruitment system

An SDF purchases software that ranks job applicants. The vendor reports high overall accuracy but does not explain:

• the training data;

• variables used;

• treatment of missing information;

• error distribution;

• ability to correct source data;

• or whether applicant records are used to train the vendor’s general model.

The SDF cannot rely only on the product brochure. It must assess how the system affects applicant rights in its own deployment.

1.43 Contractual protection

Contracts should address:

• permitted use of personal data;

• prohibition or control of vendor model training;

• technical documentation;

• testing rights;

• audit cooperation;

• material system changes;

• security safeguards;

• incident reporting;

• subprocessor use;

• data location;

• localisation compliance;

• retention;

• deletion;

• and assistance with Data Principal rights.

If the vendor becomes unable to meet a notified localisation restriction, the SDF remains responsible for changing the architecture, limiting the service or replacing the provider.

1.44 Algorithmic due diligence and human involvement

Rule 13 does not expressly create a general right against automated decision-making equivalent to Article 22 of the GDPR. It should not be rewritten to create one.

However, meaningful human review may be an appropriate safeguard where an algorithmic system creates a material risk to Data Principal rights.

Human involvement is useful only if the reviewer:

• understands the system’s role;

• can access relevant information;

• can identify obvious errors;

• can consider contrary evidence;

• has authority to change the result;

• and does not merely approve the automated output routinely.

1.45 Illustration: Fraud detection

An SDF’s fraud model freezes customer accounts. The model sometimes treats travel, disability-related transaction patterns or shared family devices as fraud indicators.

A human review process that simply repeats the model score offers little protection. A meaningful process should allow examination of the underlying events and correction of inaccurate information before prolonged deprivation of service.

Human review is one possible safeguard. The SDF may also need improved data quality, model testing, threshold adjustment, monitoring and accessible grievance mechanisms.

1.46 Data localisation under Rule 13(4)

Rule 13 empowers the Central Government to specify personal data that must be processed subject to a restriction preventing transfer outside India of:

• the specified personal data; and

• traffic data pertaining to its flow.

This is not a universal localisation requirement for all personal data processed by every SDF.

The restriction becomes operative for particular data only when the Central Government specifies that data on the basis of recommendations from the committee constituted under Rule 13.

The correct present legal structure is therefore:

• SDF designation does not automatically mean that all its personal data must remain in India;

• Rule 13 creates the mechanism for later specification;

• the Government must identify the personal data concerned;

• the corresponding traffic data is also protected;

• and the notified SDF must then implement measures preventing transfer outside India.

Until such specification applies, Rule 13(4) should not be described as a general and immediate storage-localisation obligation covering every SDF dataset.

1.47 Meaning and scope of the transfer restriction

The Rule does not merely say that the primary database must be stored in India. It says that the specified personal data and traffic data pertaining to its flow must not be transferred outside India.

Accordingly, an SDF should examine more than the location of its principal server.

Potential transfer pathways include:

• cloud storage;

• disaster-recovery sites;

• database replication;

• remote support;

• global security-monitoring systems;

• content-delivery systems;

• email;

• collaboration tools;

• overseas analytics;

• vendor ticketing systems;

• log aggregation;

• backups;

• AI model training;

• telemetry;

• and access from foreign locations.

1.48 Illustration: Indian primary server, foreign backup

An SDF stores the specified personal data on a server in India but replicates the database nightly to a disaster-recovery centre outside India.

The primary system’s Indian location does not cure the overseas transfer. The architecture must prevent the specified data from leaving India.

1.49 Illustration: Overseas support access

The database remains physically in India, but a foreign support team can remotely view and download the specified personal data.

Depending on the technical arrangement and interpretation of “transfer,” this creates a serious localisation concern. The SDF should not treat physical server location as the only relevant factor.

1.50 Illustration: Security logs

The SDF keeps customer records in India but sends detailed access logs containing user identifiers, IP addresses and transaction references to a global security-monitoring centre.

Because Rule 13 expressly includes traffic data pertaining to the flow of specified personal data, the SDF must assess whether those logs are covered and whether overseas transfer is prohibited.

1.51 Traffic data pertaining to the flow

Traffic data may reveal how personal data moves through systems even where it does not reproduce the full content.

Depending on the architecture, it may include:

• source and destination;

• user or account identifiers;

• IP addresses;

• timestamps;

• routing information;

• session details;

• transfer records;

• volume;

• system endpoints;

• and communication metadata.

This information can reveal:

• who communicated;

• when processing occurred;

• which system received the information;

• where the user or service was located;

• and how data moved.

Rule 13’s inclusion of traffic data prevents an SDF from formally keeping the underlying record in India while exporting detailed metadata capable of revealing the record’s flow and associated activity.

The exact boundary will depend on the Government’s specification and any accompanying notification or guidance. The SDF should map traffic and telemetry architecture rather than assume all metadata is outside the restriction.

1.52 Processing versus storage localisation

The Rule states that specified personal data must be processed subject to the restriction that it and related traffic data are not transferred outside India.

This is broader than a requirement to keep one stored copy in India. “Processing” under the DPDPA includes a wide range of operations, such as collection, storage, use, sharing, retrieval, organisation and dissemination.

An SDF should therefore consider whether the notified restriction affects:

• storage;

• access;

• analysis;

• transmission;

• support;

• backup;

• model training;

• sharing;

• and deletion operations.

An architecture in which a database is stored in India but analysed through an overseas AI service may be inconsistent with the restriction if the personal data is transmitted outside India for that analysis.

1.53 Relationship with Section 16

Section 16 authorises the Central Government to restrict transfer of personal data outside India to notified countries or territories. Rule 13(4) adds a different and more specific mechanism for SDFs.

The two mechanisms should not be conflated.

Section 16 concerns restrictions based on the destination country or territory.

Rule 13(4) concerns specified categories of personal data and related traffic data that must not be transferred outside India at all.

An SDF may therefore need to comply with:

• general cross-border restrictions under Section 16;

• stricter Rule 13 localisation for specified data;

• sectoral localisation requirements;

• and any other Indian law providing a higher degree of protection.

A destination permitted under Section 16 would not necessarily become permissible for data localised under Rule 13(4).

1.54 The committee

The Central Government must constitute a committee for the purpose of recommending the personal data to which localisation should apply.

The committee must include officials from the Ministry of Electronics and Information Technology and may include officials from other Central Government ministries or departments.

This allows sector-specific and public-interest expertise to inform the recommendation. For example, other ministries may have relevant knowledge concerning:

• finance;

• health;

• telecommunications;

• infrastructure;

• national security;

• transport;

• or another regulated domain.

The committee’s recommendation is not itself the operative restriction. The Central Government must specify the personal data to which the restriction applies.

This institutional sequence matters:

1. the committee considers the matter;

2. it makes recommendations;

3. the Central Government specifies the relevant personal data;

4. the notified SDF implements the restriction.

1.55 Implementing a localisation notification

An SDF cannot implement Rule 13(4) through a contract alone. It requires technical control over the complete data path.

A sound implementation would begin by identifying:

• the specified personal data;

• systems containing it;

• derived copies;

• traffic data;

• Data Processors and subprocessors;

• locations;

• remote-access paths;

• backups;

• logs;

• analytics tools;

• development environments;

• and disaster-recovery systems.

The SDF must then apply controls preventing prohibited transfer.

1.56 Data classification

Systems must be able to recognise the specified data. If it is mixed with unrestricted data in a common database, pipeline or log, the SDF must determine whether segregation, filtering or architectural redesign is necessary.

1.57 Processor contracts

Contracts should require:

• processing in approved Indian locations;

• restrictions on overseas access;

• control of subprocessors;

• local backup and recovery;

• notification before location changes;

• audit rights;

• deletion from prohibited locations;

• and evidence of compliance.

1.58 Technical controls

Depending on the architecture, controls may include:

• India-only cloud regions;

• geo-restricted storage and processing;

• blocking foreign replication;

• locally operated security monitoring;

• access restrictions based on location;

• prevention of overseas downloads;

• local key control;

• data-loss prevention;

• monitoring of outbound transfers;

• and local backup arrangements.

1.59 Verification

The SDF should not rely solely on a vendor’s contractual statement that data “resides in India.” It should verify:

• actual hosting regions;

• support access;

• subprocessors;

• diagnostic collection;

• telemetry;

• recovery locations;

• and administrative tools.

1.60 Interaction with resilience and security

Localisation must not be implemented in a way that weakens Rule 6 security and continuity.

If an SDF previously relied on an overseas disaster-recovery arrangement, a localisation notification may require creation of an equivalent recovery environment within India.

The organisation should maintain:

• redundancy;

• backups;

• continuity;

• incident response;

• security monitoring;

• and recoverability, while ensuring that the protected data and traffic data do not leave India.

Localisation is not a substitute for security. Data can be stored entirely in India and remain vulnerable because of weak access control, poor encryption, excessive privileges or inadequate monitoring.

1.61 Governance role of the DPO and governing body

Section 10 requires the SDF’s DPO to be based in India, represent the SDF, report to the board or equivalent governing body and serve as the grievance contact.

Rule 13 makes that governance relationship operationally important.

The DPO should have sufficient access and authority to:

• oversee the DPIA programme;

• coordinate with the independent auditor;

• escalate unresolved risks;

• monitor significant observations;

• advise on algorithmic systems;

• review localisation controls;

• coordinate Data Principal grievances;

• and report material concerns to the governing body.

The DPO need not personally perform every assessment or technical test. But the role should not be ceremonial.

The board or equivalent governing body should receive material information concerning:

• unresolved significant findings;

• algorithmic risks;

• major breaches;

• overdue Processor remediation;

• localisation readiness;

• and compliance resources.

A DPO who lacks access to senior management or cannot obtain evidence from business units cannot effectively fulfil the governance role contemplated by Section 10.

1.62 Relationship with Rule 6 and Rule 7

Rule 13 does not replace the general obligations applicable to all Data Fiduciaries.

1.63 Security

An SDF remains subject to Rule 6 concerning reasonable security safeguards. The annual audit should test whether:

• personal data is appropriately protected;

• access is controlled;

• logs are maintained and reviewed;

• incidents can be investigated;

• backups can be restored;

• Processor security is contractually and operationally managed;

• and technical and organisational measures operate effectively.

1.64 Breach notification

An SDF remains subject to Rule 7. A significant breach may also require:

• reassessment of the relevant DPIA;

• review of algorithmic or technical due diligence;

• audit follow-up;

• Board reporting;

• and corrective action.

A breach does not automatically prove that the annual audit was inadequate. But an audit that repeatedly overlooked obvious weaknesses may itself become evidence of ineffective compliance.

1.65 Relationship with Processor accountability

An SDF remains responsible for processing undertaken on its behalf by a Data Processor.

Its enhanced status does not make every vendor an SDF. However, the SDF must ensure that its own Rule 13 obligations extend effectively through outsourced processing.

A Processor may need to support:

• DPIAs;

• audits;

• evidence collection;

• algorithmic testing;

• rights fulfilment;

• breach investigation;

• localisation;

• traffic-data controls;

• and remediation.

1.66 Illustration: Cloud AI provider

An SDF sends customer information to an AI provider for automated analysis.

The provider must supply enough information for the SDF to understand:

• data use;

• model operation relevant to rights risk;

• retention;

• model training;

• access;

• subprocessors;

• locations;

• security;

• and deletion.

If notified data must remain in India, the provider’s architecture must also prevent prohibited movement of the data and related traffic information.

The SDF cannot avoid Rule 13 by claiming that the model is proprietary and controlled by the vendor.

1.67 Common misinterpretations

1.68 “Every large company is automatically an SDF”

Incorrect. Formal designation by Central Government notification is required.

1.69 “The annual DPIA is enough, so no project-level review is required”

Incorrect. The annual DPIA is the minimum recurring cycle. Material new processing may require assessment before the next anniversary.

1.70 “The DPIA and audit are the same exercise”

Incorrect. They may be coordinated, but risk assessment and independent compliance testing perform distinct functions.

1.71 “Only the final audit report needs to remain internally”

Incorrect. Significant observations must be furnished to the Board by the person conducting the assessment and audit.

1.72 “Only AI systems are covered by Rule 13(3)”

Incorrect. The provision covers technical measures generally and expressly includes algorithmic software. Ordinary software governing storage, publication, modification, transmission or sharing may also create rights risks.

1.73 “Any algorithmic error breaches Rule 13”

Not necessarily. The Rule requires due diligence directed at systems likely to pose a risk to rights. The quality of design, testing, monitoring and remediation matters.

1.74 “Rule 13 creates a universal human-review right”

The text does not expressly create such a universal right. Human review may nevertheless be an appropriate control where automated processing creates material rights risks.

1.75 “Every SDF must immediately store all personal data only in India”

Incorrect. The localisation obligation applies to personal data specified by the Central Government following the committee process.

1.76 “Keeping the main database in India is sufficient”

Not necessarily. Backups, remote access, logs, traffic data, overseas support, analytics and Processor systems may also involve offshore transfer.

1.77 “Certification proves Rule 13 compliance”

Incorrect. Certification or external assurance may provide evidence, but it does not replace the statutory DPIA, independent audit, algorithmic due diligence, reporting or localisation duties.

1.78 Enforcement consequences

Section 10 and Rule 13 do not have a separately named high-value penalty entry equivalent to the specific penalty categories for security safeguards, breach notification or children’s obligations. A significant contravention may therefore fall within the residual Schedule category for breach of another provision of the Act or Rules, carrying a maximum penalty of up to ₹50 crore.

The maximum is not automatic. The Board must conduct the statutory inquiry, give the SDF an opportunity of being heard and apply the Section 33 factors.

Depending on the facts, a Rule 13 failure may overlap with other contraventions carrying different ceilings. For example:

• an audit may reveal failure to maintain reasonable security safeguards;

• an algorithmic system may process data without valid consent;

• a localisation failure may also violate another sectoral requirement;

• excessive retention may breach the general erasure framework;

• and failure to notify an associated breach may engage Section 8(6).

Potentially serious Rule 13 failures include:

• failing to complete the annual DPIA or audit;

• using a non-independent auditor;

• excluding major processing systems from review;

• suppressing significant observations;

• failing to ensure that the auditor reports to the Board;

• repeatedly ignoring significant findings;

• deploying consequential algorithmic systems without meaningful due diligence;

• failing to monitor a system after material changes;

• continuing use of a system known to create serious rights risks;

• transferring specified personal data outside India;

• exporting associated traffic data despite a restriction;

• or relying on vendor assurances without verifying actual location and processing architecture.

1.79 Overall interpretation

Rule 13 changes the compliance model for an SDF from ordinary organisational responsibility to structured and recurring regulatory accountability.

Its four central obligations are:

1. Annual assessment: the SDF must undertake a DPIA and compliance audit within every twelve-month period following designation.

2. Regulatory reporting: the person conducting those exercises must furnish the Board with significant observations.

3. Technical and algorithmic accountability: the SDF must verify through continuing due diligence that the technologies used to process personal data are not likely to pose unmanaged risks to Data Principal rights.

4. Conditional localisation: personal data later specified by the Central Government, together with traffic data concerning its flow, must not be transferred outside India.

These obligations should operate as one system.

The DPIA should identify serious risks before they mature. The audit should determine whether controls work. The DPO and governing body should ensure ownership and remediation. The auditor should report material observations to the Board. Technical and algorithmic systems should be tested throughout their lifecycle. If localisation is notified, the SDF should control the entire infrastructure chain, not merely the address of the primary server.

Key point

Rule 13 requires an SDF to know its processing, test its compliance, examine how technology affects Data Principal rights, disclose significant weaknesses to the Board and maintain effective control over any personal data required to remain in India. It is not an annual paperwork obligation. It is a continuing governance framework intended for processing whose scale, sensitivity or public consequence justifies heightened supervision.