Ransomware readiness: recover from a tested backup, report on time

A ransomware attack tests two things at once: whether you can bring the business back from a clean copy, and whether you can tell the right people the right facts on time. Most teams have thought about one of these. Very few have rehearsed both together, on the same clock, with the same incident record.

Our ransomware readiness work is engineering and security work, done with your IT, security and operations teams and alongside your legal counsel. We design backups that survive an attack, prove that restores work, and build the runbook that carries you from the first alert to the final report. This page explains the obligations, the five steps we follow, and what you get at the end.

Is a ransomware attack a personal data breach?

Usually, yes. Section 2(u) of the DPDP Act defines a personal data breach as any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises its confidentiality, integrity or availability. Ransomware typically hits several of these at once:

• Availability: encrypted systems mean loss of access to customer, patient or employee records, even if nothing leaves your network.
• Confidentiality: many attacks copy data out before encrypting it, then threaten to publish it.
• Integrity: files and databases may be altered or corrupted, so restored data has to be checked, not assumed.

Section 8(6) requires you to intimate every personal data breach to the Data Protection Board and to each affected person, with no materiality threshold. Section 8(5) requires reasonable security safeguards to prevent breaches, and Rule 6(d) lists "measures for continued processing", such as backups, among them. Both apply from 13 May 2027. The security safeguards guide covers the rest of Rule 6.

Which reporting clocks start in a ransomware incident?

Two regimes run in parallel, and one does not replace the other.

CERT-In's directions of 28 April 2022, issued under section 70B(6) of the IT Act, require service providers, intermediaries, data centres, body corporates and government organisations to report the cyber incidents listed in Annexure I within 6 hours of noticing them or being told about them. Annexure I includes malicious code attacks such as ransomware, as well as data breaches and data leaks. This is already in force.

The DPDP Rules then add the Board and the people affected. Rule 7 asks for a notice to each affected person and an initial intimation to the Board without delay, followed by a detailed report to the Board within 72 hours of becoming aware, or longer if the Board allows it on a written request.

The same CERT-In directions require every covered entity to designate a point of contact for CERT-In, to synchronise system clocks with the NTP servers of the National Informatics Centre or National Physical Laboratory (or servers traceable to them), and to keep logs of all ICT systems securely for a rolling 180 days within Indian jurisdiction. From 13 May 2027, DPDP Rule 6(e) and Rule 8(3) add a one-year retention of logs and associated data. Accurate clocks and logs that survive the attack are what let you state a timeline with confidence in every one of these reports.

On the DPDP side, the Board is established but, as of early November 2026, its Chairperson and Members have not been appointed. Before 13 May 2027, confirm the Board's published channel for intimations and test that your team can reach it.

How do we get you ready? The five steps

Every engagement follows the same five steps. Each one produces something your team keeps and can run without us.

1. Prepare: runbooks, contacts and the reporting clocks

We write a ransomware runbook with named owners and decision points: who declares an incident, who isolates systems, who speaks to CERT-In, counsel, customers and the press. Both clocks sit in it from the first page. The runbook records the time you noticed the incident (CERT-In) and the time you became aware of a personal data breach (DPDP), because they may differ and every deadline runs from them.

Alongside it sits a contact sheet that works when email and the directory are down: an out-of-band channel, phone numbers on paper, your CERT-In point of contact, counsel, key processors and any cyber insurer. Notice templates for the Board, affected people and CERT-In are drafted in advance for your counsel to approve, so that on the day you fill in facts rather than draft.

2. Protect backups: immutable and offline copies

Attackers commonly go after backups before they encrypt anything else. We review how your backups are taken, where they live and who can delete them. The design we typically recommend includes:

• At least one immutable copy that cannot be changed or deleted for a set retention period, even by an administrator.
• At least one offline or logically isolated copy, in a separate account with separate credentials and multi-factor authentication.
• Backups of what you need to rebuild, not only data: configurations, identity systems, secrets stores and infrastructure definitions.
• Encryption of backup copies (Rule 6(a) lists encryption among the safeguards), with keys stored away from the systems they protect.
• Logs shipped to a separate store that meets the CERT-In 180-day and DPDP one-year needs.

If a vendor hosts or runs your backups, it is a processor for DPDP purposes. Section 8(1) keeps you responsible for its processing, and Rule 6(f) expects safeguards to be written into the contract, including prompt notice to you of any incident.

3. Detect and contain

Rule 6(c) expects visibility of access through logs, monitoring and review, so that you can detect, investigate and remediate. We tune detection for the signs that usually come before encryption: new administrator accounts, attempts to delete backups or shadow copies, unusual mass file changes and large outbound transfers. The containment playbooks set out how to isolate hosts and network segments, revoke and reset credentials, and preserve evidence before anything is wiped, so that the facts needed for the 72-hour report survive.

4. Recover: a restore you have already tested

We agree recovery priorities with the business: which systems come back first, how much data loss is tolerable (recovery point objective) and how much downtime (recovery time objective). Then we test. A restore test rebuilds systems from the protected copies into a clean environment, checks the data for completeness and tampering, and records how long each step took against the target. Where the measured time misses the target, the gap becomes a ticket with an owner, not a footnote.

On the day, recovery means rebuilding from known-clean images and restoring from a point before the compromise, not decrypting in place and hoping. Restored personal data is checked for integrity, because alteration is itself part of a breach under section 2(u).

5. Report and learn: Board, affected people, CERT-In and the review

The runbook carries the reporting steps through to the end: the CERT-In report within 6 hours, the Board intimation and the notices to people without delay, and the 72-hour report to the Board. Log every notice to people as it goes out (channel, time, template version, delivery status), because the 72-hour report must include a report on those intimations. The breach notification guide sets out each notice's contents in full.

After recovery, a blameless post-incident review records the cause, what worked, what did not, and the remedial measures. Those measures feed the "remedial measures to prevent recurrence" that Rule 7(2)(b) asks for, and they update the runbook, backups and detection for next time.

What does an engagement look like, and what do you get?

A typical engagement starts with discovery: interviews with IT, security, operations and the people who own customer-facing systems, plus a review of your current backups, logging and incident documents. We then design and build with your team, run at least one restore test and one tabletop exercise, and hand over. Scope varies with the size of your estate and how much already exists, and we agree it with you at the start.

We aim to leave you with controls your own team runs and evidence that they work. We do not give legal opinions: decisions on notifications, regulators and, if it arises, any ransom demand sit with your business and its counsel (and, for a ransom, law enforcement). We do not promise that an attack will be prevented. What good preparation gives you is a faster, more orderly recovery and reports built on facts you can stand behind.

Why does this matter for DPDP penalties?

Under the Schedule to the Act, failing to take reasonable security safeguards to prevent a breach can attract a penalty of up to ₹250 crore, and failing to intimate a breach to the Board or affected people up to ₹200 crore. Section 33(2) lists the factors the Board weighs, including the gravity and duration of the breach and whether you took mitigation steps and how quickly. Tested backups, a working runbook and timely notices are the kind of evidence that speaks to those factors. The penalties guide has the full Schedule.

Ransomware readiness also sits naturally with our other work: privacy engineering for the wider DPDP programme, API security for the routes attackers often use to get in, and data localisation where logs and backups need to stay in India. The full list is on the services page.

How to start

1. List the systems that hold personal data and the business processes that stop if they go down.
2. Check who can delete your backups today, and whether any copy is immutable or offline.
3. Confirm your CERT-In point of contact, your log retention and your clock synchronisation.
4. Put the 6-hour CERT-In step and the Rule 7 steps into one incident runbook.
5. Run a restore test and a ransomware tabletop exercise before 13 May 2027, then repeat them on a schedule.

These steps also appear in the DPDP compliance checklist and the implementation roadmap. If you would like us to review your backups, run the first restore test and write the runbook with your team, book a scoping call.