Business Impact Analysis: Setting RTO and RPO You Can Actually Meet After Ransomware
Most recovery objectives were written for an outage, not an intrusion. How to run a business impact analysis, set maximum tolerable downtime, RTO and RPO with the business, map the identity dependencies everyone forgets, and test the numbers before ransomware does.
Business Continuity
Most recovery time and recovery point objectives were written for a failed server or a lost data centre. Ransomware is a different kind of outage: the replica is encrypted too, the backups may be the attacker's first target, and nobody restores anything until they know which restore point is clean. A business impact analysis is how you set objectives that survive that, and this is how to run one.
In short. The business decides how long each process can be down and how much data it can lose; IT then has to prove it can recover inside those limits. A business impact analysis turns interviews with process owners into a maximum tolerable downtime per process, then recovery time and recovery point objectives per system. For ransomware, add three things most analyses leave out: the time to find a clean restore point, the identity systems everything else depends on, and a restore test measured end to end rather than a failover test.
The numbers, and who owns each one
NIST's contingency planning guide, SP 800-34 Revision 1, defines the three figures most continuity plans use. They are worth quoting exactly, because most arguments about recovery come from people meaning different things by them.
| Figure | NIST SP 800-34 Rev. 1 definition | Who sets it |
|---|---|---|
| Maximum tolerable downtime (MTD) | "The amount of time mission/business process can be disrupted without causing significant harm to the organization's mission." | The business, process by process |
| Recovery time objective (RTO) | "The overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission or mission/business processes." | IT, inside the limit the MTD sets |
| Recovery point objective (RPO) | "The point in time to which data must be recovered after an outage." | The business and the data owners |
The relationship is the point. MTD belongs to a business process; RTO belongs to a system that supports it, and has to be short enough that recovering the system does not push the process past its MTD, with time left over to restart the work itself. RPO is a statement about data loss, and it is what decides your backup frequency, not the other way round. ISO 22301 uses a closely related concept, the maximum tolerable period of disruption, and requires a business impact analysis; ISO/TS 22317 gives guidance on carrying one out.
Why ransomware breaks objectives written for outages
A traditional disaster recovery design assumes the primary is unavailable and the copy is good. Ransomware violates the second assumption, and a plan built on the first alone will miss its numbers.
- Replication is not a backup. Synchronous or near-real-time replication to a DR site copies encrypted data as faithfully as it copies good data. Failing over to the DR site can mean failing over to the same damage.
- Backups are a target. Attackers commonly look for backup consoles and online backup stores before they encrypt, so the backup you planned to restore may be deleted, encrypted or untrustworthy. Only copies the attacker could not reach should count towards your RPO.
- The clock starts later than you think. Before anything is restored, someone has to scope the intrusion, preserve evidence and decide which restore point predates the attacker's access. That time is not in an RTO measured from a failover test.
- The real RPO is the last clean point. If the attacker was inside for weeks before encrypting, the most recent backup may contain their persistence. The restore point you can use may be much older than the one your backup schedule implies.
- Everything depends on identity. If the directory and authentication services are compromised, no restored application can be used safely until they are rebuilt and trusted again.
Running the analysis
A business impact analysis is mostly structured conversation. The technical work comes after, when the answers are turned into system objectives and tested. This is the order that keeps it from turning into an IT inventory exercise.
Step 1 — List the business processes, not the systems
Taking payments, onboarding customers, running payroll, dispatching orders, settling with partners. Start with the processes a regulator, a customer or the board would notice stopping. Systems come later, as dependencies.
Step 2 — Ask how the impact grows over time
For each process, interview the person who runs it: what happens after an hour, four hours, a day, three days, a week? Ask about money, customers, regulatory obligations, contractual penalties, safety and reputation separately. The point where the answers become unacceptable is the maximum tolerable downtime.
Step 3 — Ask how much data the process can lose
Could the team re-key the last hour's transactions from another source? The last day's? Some processes can rebuild from partners or paper; others cannot lose a single record. That answer is the recovery point objective.
Step 4 — Map the dependencies
For each process: the applications, the data stores, the infrastructure, the third-party services, the people and the identity systems it needs. Include what the dependency itself depends on. A payments process that needs an application that needs a database that needs the directory to start is a chain, and the chain recovers at the speed of its slowest link.
Step 5 — Cascade into system objectives
Each system's RTO is set by the shortest MTD of the processes that depend on it, minus the time needed to resume the work after the system is back. Each system's RPO is set by the most demanding process it serves. A shared system inherits its strictest dependant.
Step 6 — Compare against what you can actually do
Put the required objective next to the demonstrated recovery time and restore point from your last real test. The gap between them is the output that matters: it is a list of investments, decisions or accepted risks for the board, not a document for the shelf.
Step 7 — Approve and schedule the review
The objectives are business decisions and should be approved as such. Review them at least annually and whenever a process, a key system or a major supplier changes.
An impact-over-time worksheet
The heart of the interview is a simple grid. The example below is illustrative, for a fictional online payments process, to show the shape of the answers rather than real figures for any organisation.
| Impact type | 1 hour | 4 hours | 24 hours | 72 hours |
|---|---|---|---|---|
| Customers | Retries, some abandoned purchases | Complaints, social media attention | Customers move to competitors | Lasting loss of trust |
| Financial | Lost revenue for the hour | Lost revenue, overtime | Partner penalties begin | Material loss |
| Regulatory | Incident logged | Regulator notification likely required | Supervisory attention | Formal action possible |
| Verdict | Tolerable | Tolerable with workarounds | Unacceptable | Unacceptable |
In this example the maximum tolerable downtime falls somewhere between four and twenty-four hours, and the follow-up questions narrow it. The worksheet also tells you something else: the regulatory column usually turns earlier than people expect, because notification deadlines are measured in hours, not days.
The dependency nobody puts in the BIA
Ask a process owner what their process depends on and they will name their applications. They will almost never name the directory, the DNS, the certificate authority, the key management service, the backup console, the endpoint security console or the single sign-on provider. In a ransomware recovery those are first in the queue, because nothing else can be brought back safely without them.
Two consequences follow. First, identity and core infrastructure need their own recovery objectives, set by the strictest process that depends on them, which usually makes them the most demanding objectives in the organisation. Second, they need their own recovery procedure for the case where they are compromised rather than merely down. Restoring a directory the attacker controls from a backup the attacker had access to puts them back in charge. An Active Directory security assessment before an incident tells you how hard that rebuild will be, and our Active Directory hardening guide covers what reduces it.
Turning objectives into recovery capability
The objectives are only as good as the capability behind them. The US Cybersecurity and Infrastructure Security Agency's #StopRansomware Guide sets out the backup and restoration practices that make a ransomware recovery possible at all:
- Offline, encrypted backups of critical data, with the availability and integrity of those backups tested regularly in a disaster recovery scenario.
- Golden images of critical systems, maintained and regularly updated, so systems can be rebuilt from a known-good configuration rather than restored with whatever was on them.
- Infrastructure as code for cloud resources, with the templates themselves backed up offline.
- Restoration by priority: reconnect systems and restore data based on a prioritisation of critical services, and take care not to re-infect clean systems during recovery.
The business impact analysis is what gives that last point its order. Without it, recovery priority is decided under pressure by whoever is loudest. With it, the sequence is agreed in advance and the people restoring systems know which ones to bring back first.
Testing the numbers
An RTO that has never been tested is a hope. Three kinds of test, run on a schedule, turn it into a measurement.
| Test | What it proves | What it does not |
|---|---|---|
| Isolated restore test | That a specific backup can be restored, and how long it takes from decision to usable system | That the restored system works with everything around it |
| DR drill with live switch-over | That the alternate site can run the business, including batch jobs, interfaces and people | That you could recover if the replica were encrypted too |
| Ransomware tabletop exercise | That decisions get made in time: who declares, who restores what first, who reports to whom | That the technology performs; it tests the people and the plan |
Regulators are moving the same way. Under RBI's 2026 Directions, commercial banks must run DR drills for critical information systems at least half-yearly, with switch-over to the DR site run as the primary for at least a full working day; our guide to RBI's 2026 Cybersecurity Directions covers the detail. A tabletop exercise built on the BIA's recovery order is the cheapest way to find out whether the drill will pass before you run it.
What to put in front of the board
The output of the analysis that matters to directors is not the worksheets. It is one table per critical process: the maximum tolerable downtime the business set, the recovery time and point objectives that follow, the result of the last real test, and the gap. A gap is a decision for the board: invest to close it, change the process, or accept the risk explicitly. All three are legitimate. Not knowing is not.
Report it the same way every quarter, so movement is visible. Our board reporting and security KPI and KRI work builds recovery objectives and test results into the same set of measures the board already reviews.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is the difference between RTO and RPO?
RTO is about time: how long a system can be in recovery before the business is harmed. RPO is about data: the point in time to which data must be recovered, which decides how much work since the last good copy can be lost. They are set separately and tested separately.
QHow does maximum tolerable downtime relate to RTO?
Maximum tolerable downtime belongs to a business process; RTO belongs to a system that supports it. The RTO has to be short enough that recovering the system, and then resuming the work, keeps the process inside its maximum tolerable downtime.
QWho should set recovery objectives, IT or the business?
The business sets how long each process can be down and how much data it can lose. IT translates those limits into system objectives and proves, by testing, whether it can meet them. When IT sets the objectives alone, they describe what the infrastructure does rather than what the business needs.
QWhy does ransomware make our existing RTO unrealistic?
Because objectives written for outages assume the copy is good. In a ransomware incident replication may have copied the encryption, backups may have been targeted, and time must be spent scoping the intrusion and finding a clean restore point before recovery starts. None of that is measured by a failover test.
QIs a DR site enough to recover from ransomware?
Not on its own. Replication copies encrypted data as faithfully as good data. You also need backups the attacker could not reach, such as offline or immutable copies, a way to verify a restore point is clean, and a procedure for rebuilding identity systems that may have been compromised.
QWhat should be recovered first?
Usually identity and core infrastructure: the directory, DNS, authentication and the tools needed to run the recovery itself, because nothing else can be restored safely without them. After that, the order the business impact analysis set by process priority.
QHow often should a business impact analysis be updated?
At least annually, and whenever a critical process, a key system or a major supplier changes. Objectives that were right for last year's architecture can be wrong after a migration to the cloud or a change of payment provider.
QWhich standards describe a business impact analysis?
NIST SP 800-34 Revision 1 describes the process for information systems and defines MTD, RTO and RPO. ISO 22301 requires a business impact analysis as part of a business continuity management system, and ISO/TS 22317 gives guidance on carrying one out.
QHow do we test our RTO without disrupting the business?
Start with isolated restore tests of individual systems, timed from the decision to restore to a usable system. Add tabletop exercises that rehearse the decisions. Run live switch-over drills on a schedule, planned with the business, for the systems where the objectives are most demanding.
QWhat if the analysis shows we cannot meet our objectives?
That is the most useful thing it can show. Each gap becomes a decision: invest to close it, change the process so it tolerates a longer outage, or accept the risk explicitly at the right level. All three are legitimate. Finding out during an incident is not.
Related reading
For the full ransomware picture, prevention and response as well as recovery, see our ransomware defence playbook for India. For the incident response side of the same event, our SOC incident management playbook covers detection, triage and escalation. For the regulatory drill standard in Indian banking, our guide to RBI's 2026 Cybersecurity Directions.
About Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India. Our continuity work starts from the attacker's side: we test how systems are broken into, so the recovery plans we help write are built for an intrusion, not only an outage.
What we can do for you:
- A business impact analysis. Our business impact analysis runs the interviews, maps dependencies including identity and core infrastructure, and sets process and system objectives the business signs off.
- Plans and readiness for the cyber case. BCDR planning with a recovery path for compromised systems, not only failed ones, and a ransomware readiness assessment that tests whether your backups and restore procedures would hold up.
- Rehearsal and response. Tabletop exercises that walk leaders through a ransomware recovery against the agreed order, and an incident response retainer so forensic help is already contracted when the clock starts.
Sources
- NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems; definitions of maximum tolerable downtime, recovery time objective and recovery point objective via the NIST CSRC glossary.
- CISA and partners, #StopRansomware Guide, September 2023 update.
- Reserve Bank of India, Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, for the DR drill standard.
- ISO 22301, Security and resilience – Business continuity management systems – Requirements, and ISO/TS 22317, Guidelines for business impact analysis.
Adayptus Consulting
Resilience and Continuity, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, building continuity and recovery plans for intrusions, not only outages.
On This Page
- The numbers, and who owns each one
- Why ransomware breaks objectives written for outages
- Running the analysis
- An impact-over-time worksheet
- The dependency nobody puts in the BIA
- Turning objectives into recovery capability
- Testing the numbers
- What to put in front of the board
- Frequently Asked Questions
- Related reading
- About Adayptus
- Sources
