When the Business Goes Down: Rethinking Cyber Resilience Beyond Disaster Recovery

Picture the review meeting after a ransomware attack. The backups ran every night. The DR site was contracted and tested annually. The plan was signed off, and the last audit raised no findings. Even so, the business was down for days without its core systems.

The plan wasn’t careless. It was written for a different kind of disaster: a failed data centre, a flood, a long power cut. It never imagined an attacker already sitting inside the network.

This article looks at that gap, using SEBI’s September 2026 consultation paper on BCP and DR for Market Infrastructure Institutions as a current reference.

Same words, different jobs

These four terms are often used as if they meant the same thing. They don’t.

• Business continuity planning (BCP) keeps critical services running, or brings them back to an acceptable level, during a disruption. ISO 22301:2019 is the international standard for business continuity management.
• Disaster recovery (DR) is the technical side: restoring systems, applications and data, usually at a secondary site.
• Incident response (IR) is how an organisation detects, contains and recovers from a security incident. NIST SP 800-61 Revision 3 (April 2025) treats it as part of wider cybersecurity risk management, aligned to the NIST Cybersecurity Framework 2.0.
• Cyber resilience is the result: the ability to anticipate, withstand, recover from and adapt to attacks and other adverse conditions.

Resilience shows up only when the three work together under pressure.

The disaster the plan didn’t imagine

Traditional DR assumes a clean failure. The main site goes dark, the secondary site holds a good copy, and the job is to switch over quickly.

A cyber incident breaks those assumptions in a few ways:

• Replication copies damage. Near-real-time replication is excellent against a hardware fault. Against encryption or corrupted data, it can deliver the problem to the second site just as efficiently.
• The recovery environment may not be clean. If the DR site shares identity services or admin credentials with production, restoring into it can hand the attacker a second home.
• Backups can be reached. An attacker with administrator access may be able to get to backup systems too.
• Timing is a judgement call. Restoring too early can destroy evidence and invite reinfection. Restoring too late stretches the outage. CERT-In’s directions of 28 April 2022 also require covered entities to report specified incidents within six hours of noticing them.

None of this makes DR less important. It means a DR plan needs a cyber scenario written into it.

Original illustration created for this article.

What SEBI is proposing, and what it isn’t

On 15 September 2026, SEBI published a consultation paper on strengthening BCP and DR for Market Infrastructure Institutions (MIIs): stock exchanges, clearing corporations and depositories. Comments are open until 5 October 2026. It is a proposal, not a rule, and it is addressed to MIIs only.

As publicly reported, the current framework expects full-day drills, which SEBI notes can be hard on institutions and market participants alike. The paper proposes:

• DR drills on a non-working day, starting at the primary data centre and switching to the DR site, lasting at least four hours including the switchover.
• Stronger stress testing at the primary site.
• Regular checks that configurations stay aligned across the primary site, the near site and the DR site.
• For stock exchanges, a framework to recover lost trade data from clearing corporations if a disruption also affects replication to the exchange’s own near site and DR site, with procedures agreed between the two institutions.

Separately, SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF), issued on 20 August 2024, is already in force. Its 28 August 2025 clarification states a two-hour recovery time objective and a 15-minute recovery point objective for DR, and expects vendor risk assessment. What applies to a given entity depends on its category.

My reading is that the shorter drill is the least interesting part. The more telling items are configuration drift and a recovery path that doesn’t depend on the replication link that just failed. If your only recovery source can be damaged by the same event, you don’t really have two sources. The paper is about operational disruption, not ransomware; that connection is mine, not SEBI’s.

Start with the business, not the servers

Recovery objectives mean little until you know what the business can least afford to lose. That is what a business impact analysis is for, and business owners, not only IT, should answer it.

It should produce a short list of critical services, how long each can be down before real harm occurs, and how much data loss is tolerable. Then comes the step teams often skip: tracing each service down through what it depends on. A customer payment flow relies on an application, which relies on a database, which relies on identity services, DNS, network paths, key management and a vendor or two. If identity isn’t back, nothing behind it can start. Recovery order is a dependency question, not a ranking of which system feels most important.

When the failure sits with a vendor

In July 2024, a ransomware attack hit C-Edge Technologies, a technology provider serving mainly cooperative and regional rural banks. NPCI temporarily isolated C-Edge from the retail payment systems it operates, and said customers of the banks C-Edge serves would be unable to use those systems during the isolation. Press reports put the number of affected banks at nearly 300.

The point is not any one bank’s DR plan. The point of failure sat outside the banks, in a shared provider, and the recovery clock was not theirs to control.

For RBI-regulated entities, the RBI’s Master Direction on Outsourcing of Information Technology Services (April 2023) and its IT Governance, Risk, Controls and Assurance Practices Directions (issued 7 November 2023, effective 1 April 2024, with a chapter on BCP and DR) already set expectations here. Whatever your regulator, the practical questions are the same:

• What recovery time does the vendor actually commit to, and does it match what your business needs?
• Is there a tested fallback, or only a contract clause?

A plan is a claim. A restore is evidence.

An untested recovery plan is a hypothesis. Teams that have never done a real restore tend to learn on the day that backups were running but not restorable, that recovery took longer than promised, or that a dependency was missing from the runbook.

Testing that produces evidence has a few features:

• Restore, don’t just back up. A successful backup job proves very little. Restore real data into a clean environment and time it.
• Test the bad scenarios. Compromised identity. An unavailable backup catalogue. Primary and secondary sites both affected.
• Put decision-makers in the room. The hardest parts of a major incident are decisions, not commands.
• Record the numbers. Actual recovery time against target, and what you found and fixed.

ISO/IEC 27001:2022 points the same way, with Annex A control 8.13 on information backup and its testing, and control 5.30 on ICT readiness for business continuity. SEBI’s attention to configuration drift is the same idea applied to the DR site: don’t assume it still matches production; check.

Who decides at 3 a.m.?

Governance here means answering hard questions before they become urgent. Who can declare a disaster? Who can order a system isolated, knowing it will halt revenue? Who talks to regulators and customers, and when? Who tells the board?

A resilience programme also needs a risk-based foundation: threat scenarios that include cyber events, a documented link from those scenarios to the business impact analysis, and a board that sees residual risk as business impact. Continuous improvement closes the loop. ISO 22301 expects regular review and improvement, so every exercise, near miss and real incident should change something in the plan. A plan reviewed every year and never altered is a warning sign.

Six questions for your next review

1. Which five services would hurt most if down for 24 hours, and did the business agree to that list?
2. Could an attacker with administrator credentials reach or alter your backups?
3. Does your DR environment share identity, management or network services with production?
4. When did you last measure a real restore time, and how did it compare with the target?
5. Which critical services depend on a vendor, and have you rehearsed their failure?
6. Who is authorised to declare a disaster, and do they know it?

What’s left when the plan meets a bad day

Backups matter, and so does DR. But resilience isn’t a document, a site or a product. It is the demonstrated ability to keep the most important services running, or bring them back in acceptable time, when something goes wrong in a way nobody fully predicted. The proof comes from rehearsal and measurement, not from the plan existing.

About the Author

EdTeam

Administrator

View All Posts