DPDP Rules 2025, Rule 6(1)(d): What “Continued Processing” and Data Backups Actually Require

Part of a series on DPDPA Section 8(5) and DPDP Rules 2025, Rule 6. Read the pillar post first if you haven’t.

The Clause, Verbatim

“(d) reasonable measures for continued processing in the event of confidentiality, integrity or availability of such personal data being compromised as a result of destruction or loss of access to personal data or otherwise, such as by way of data-backups;”

DPDP Rules 2025, Rule 6(1)(d)

This clause is about resilience, not prevention. Rule 6(1)(a) through (c) are largely aimed at stopping or catching unauthorised access. Rule 6(1)(d) assumes something has already gone wrong, data destroyed, access lost, integrity compromised, and asks what happens next. It also explicitly names all three pillars of the classic confidentiality-integrity-availability security triad, not just availability, which is easy to miss if you read “backups” and stop thinking about the rest of the sentence.

What It Technically Requires

Data backups. Regular, automated backups of personal data, stored separately from the primary system (so the same failure or attack that compromises production doesn’t also destroy the backup), and covering the databases and file stores that actually hold personal data, not just the systems that are easiest to snapshot.

Backup integrity verification. Backups that exist but have never been tested for restorability aren’t a continuity measure, they’re an assumption. Periodic restore testing confirms the backup actually works and actually restores the data in usable form.

Defined recovery objectives. A stated Recovery Point Objective (how much data loss is acceptable, phrased as a time window, such as “no more than 1 hour of data”) and Recovery Time Objective (how long restoration is allowed to take) for systems processing personal data, sized to the sensitivity and volume of that data.

Integrity controls beyond backup. Checksums, versioning, or audit trails that let you detect when personal data has been altered, not just destroyed, since the clause covers integrity compromise as well as loss of access.

Incident-triggered continuity plan. A documented process for what happens operationally when confidentiality, integrity, or availability is compromised: who initiates recovery, from what backup, verified how, communicated to whom.

Where This Gets Subjective

How fast is “reasonable”? The clause requires “reasonable measures for continued processing,” which implies some expectation of speed, processing needs to continue, not just eventually resume, but specifies no RTO or RPO threshold. A daily backup with a 24-hour potential data-loss window and a two-day restoration process is a “measure for continued processing.” So is hourly backup with automated failover and a 15-minute RTO. Both technically satisfy the clause’s language. They represent very different actual resilience, and the gap between them is exactly the kind of thing that only becomes visible after an incident, when it’s too late to close it.

Backup frequency proportional to data sensitivity. Nothing in the clause ties backup frequency to how sensitive or how quickly-changing the underlying data is. A system holding financial transaction data changing every second arguably needs a materially tighter RPO than a system holding rarely-updated profile data, but the clause doesn’t distinguish between them, leaving that calibration entirely to the Data Fiduciary’s own risk judgment.

Restore testing cadence, and whether it happens at all. The clause requires the capability to continue processing, which implicitly requires backups that actually work, but says nothing about verification. An organisation that has never once tested a restore is relying entirely on the untested assumption that its backup process is sound. That gap, backups exist versus backups are proven to work, is one of the most common places continuity programmes look compliant on paper and fail during an actual incident.

What the Breakdown Really Means

A backup strategy built for “the server crashed” doesn’t automatically cover “an attacker deleted or encrypted our data and we need to know our backups weren’t touched too.” The clause’s phrase “reasonable measures for continued processing” is asking whether your organisation could actually keep operating, not just eventually recover a copy of the data.

Vimalendukumar Dwivedi is Co-founder of Scrutora, a Code Compliance Platform.