Business Impact Analysis vs Cyber Risk Assessment: how to join impact, likelihood and recovery targets

Most organisations run a business impact analysis and a cyber risk assessment as separate exercises, owned by different teams, scored on different scales, and never reconciled. The result is a risk register that rates an outage of the payments platform as "medium" while the continuity team has signed off a four hour maximum tolerable downtime for the same service. This guide explains what each exercise is for, why they are complements rather than alternatives, and how to join their outputs so that impact, likelihood and recovery targets tell one consistent story. It is written for risk managers, continuity leads, CISOs and auditors. For running each exercise in full, use the Business Impact Analysis Template and the NIST SP 800-30 Risk Assessment Guide; this page covers the seam between them.

Key takeaways

• They answer different questions. A BIA asks "what must go right, and how long can we survive without it?"; a risk assessment asks "what might go wrong, and how likely is it?", the framing NIST IR 8286D uses for the two halves of enterprise risk.
• The BIA owns impact, the risk assessment owns likelihood. Impact ratings in the risk register should be read from the BIA for the affected service, not re-estimated by whoever writes the risk entry.
• Recovery targets are controls, not risks. MTD, RTO and RPO come out of the BIA as requirements; the risk assessment then tests whether current capability meets them and records the gap as a risk.
• Join them with a shared service key and a shared impact scale. One service catalogue, one set of impact thresholds approved by the executive, and a field in every risk entry that names the BIA service it threatens.
• Disagreement between the two is a finding. When the risk register says low and the BIA says the service is critical with a short MTD, one of them is wrong, and resolving it is usually the most valuable output of either exercise.

Short answer: complements, not alternatives

A business impact analysis (BIA) characterises the consequences of disruption to business processes over time and turns them into recovery requirements. NIST SP 800-34 Rev. 1 describes three steps: determine mission and business processes and recovery criticality, identify resource requirements, and identify recovery priorities for system resources. ISO/TS 22317:2021 gives guidance for a structured BIA process and is explicit that it does not prescribe a uniform method.

A cyber risk assessment identifies threats, vulnerabilities and conditions, and combines the likelihood of a harmful event with its impact to rank risks for treatment. NIST SP 800-30 Rev. 1 defines risk as typically a function of the adverse impact if an event occurs and the likelihood of it occurring, and sets out four steps: prepare, conduct, communicate and maintain.

The overlap is impact. Both exercises need to know how bad a loss would be. The BIA studies that question deeply for a defined set of services; the risk assessment needs an answer for every scenario it rates. If the risk assessment estimates impact from scratch, the two drift apart. NIST SP 800-30 itself points at the join: it notes that a BIA identifies high-value assets and adverse impacts, that system criticality may be identified in BIAs, and that a mission or business impact analysis can be the starting point for an asset and impact oriented risk analysis.

Side by side

What each one protects against: the threat model

BIA. The BIA does not model attackers. Its implicit threat is "the service is unavailable, corrupted or exposed", whatever the cause. That is a strength: it forces planning for scenarios nobody predicted, such as a supplier outage or a containment decision that takes healthy systems offline. When ransomware hit Colonial Pipeline's IT systems in May 2021, the company shut the pipeline itself down as a containment decision for about six days; the Colonial Pipeline ransomware attack shows why a BIA has to map the IT dependencies of operational services, not only the operational systems themselves.

Risk assessment. The risk assessment does model attackers and conditions. The NCSC basic method scores threats on capability and motivation, scores vulnerabilities on ease of exploitation and exposure, and combines them to estimate likelihood. This is what tells you that a dormant VPN account without MFA is a more probable route to an outage than a data centre fire, and so where control spending should go. Its weakness is the reverse of the BIA's: scenarios nobody wrote down get no rating at all.

Together they cover each other's blind spot. The BIA guarantees every critical service has a recovery target regardless of cause; the risk assessment guarantees the most likely causes are being reduced before the recovery plan is needed.

How each works in practice

The BIA pipeline

1. Service catalogue: list products and services, then the processes and activities that deliver them.
2. Impact over time: for each service, rate impact at fixed intervals (for example 1 hour, 4 hours, 1 day, 1 week) against approved categories.
3. Tolerance point: the interval at which impact becomes unacceptable sets the MTD (ISO 22301 calls it the maximum tolerable period of disruption).
4. Dependencies: people, sites, applications, data, identity services and suppliers each service needs.
5. Derived targets: NIST SP 800-34 requires the RTO to be shorter than the MTD, with any time needed to reprocess data added to the RTO; the RPO is set separately from tolerable data loss and is not part of the MTD.

The risk assessment pipeline

1. Context and scope: business priorities, legal obligations and the organisation's risk appetite (NIST CSF 2.0 GV.RM-02).
2. Threats and vulnerabilities: identified and recorded (ID.RA-03), using threat intelligence, attack trees or MITRE ATT&CK.
3. Likelihood and impact: estimated and recorded for each scenario (ID.RA-04).
4. Risk determination and prioritisation: combined into a rating that informs response (ID.RA-05).
5. Response: chosen, planned and tracked (ID.RA-06), then maintained as conditions change.

Step 3 of the risk pipeline and steps 2 to 4 of the BIA pipeline describe the same impact. That is the join.

Joining the outputs: the integration model

NIST IR 8286D (update 1, February 2025) sets out the direction of flow: leaders issue risk appetite and tolerance, those directives feed the BIA, and system owners use the BIA to categorise assets, assign impact values and set protection requirements, which then support integration of cybersecurity risk management with enterprise risk management. In practice that means five joins.

Two further rules make the join hold. First, availability is only one impact. The BIA scale built for downtime rarely captures a quiet data theft, so NIST IR 8286D's broader view of loss, and the confidentiality and integrity ratings from FIPS 199 style categorisation (which SP 800-34 names as the basis for the BIA), should sit alongside the time based ratings. Second, duration drives impact: a ransomware scenario does not have one impact value, it has the BIA value at the outage duration your tested recovery actually achieves. That is how recovery investment shows up as risk reduction.

Worked scenario: one service, both lenses

A retailer's online order service has a BIA that rates impact as Minor at 4 hours, Major at 24 hours and Severe at 3 days. The business owner signs off an MTD of 24 hours. Order data cannot be reconstructed from the payment provider beyond 15 minutes, so the RPO is 15 minutes, and after allowing time for activation and backlog processing the order platform's RTO is 8 hours.

1. Risk assessment scenario: ransomware encrypts the order platform and its backups via a compromised administrator account. Threat capability is high, the admin account uses push MFA and the backup console is on the same directory. Likelihood is rated Medium for the year, with the uncertainty recorded as a range rather than a single point, as the NCSC method recommends.
2. Impact, read from the BIA: the last restore test took 40 hours because backups had to be validated as clean. At 40 hours the BIA rating is Major, rising towards Severe. So impact is Major, not the Moderate the security team first guessed.
3. Risk rating: Medium likelihood times Major impact lands in the high band of the shared matrix, above appetite.
4. Gap risk: separately, "order platform cannot meet its 8 hour RTO" is raised against the service owner, because tested recovery (40 hours) misses both RTO and MTD. NIST SP 800-34 says a plan of action and milestones should be started where the RTO cannot be met and the MTD is fixed.
5. Treatment: phishing-resistant MFA and a separate identity domain for backup administration lower likelihood; immutable backups and a pre-staged clean recovery environment cut recovery to under 8 hours, which lowers impact to Minor or Moderate on the BIA curve. Both changes show up in the residual rating.

Without the join, the risk register would have carried a Medium risk and the continuity plan an untested 8 hour RTO, and neither would have revealed that the business was exposed to a multi-day outage. The Jaguar Land Rover cyberattack, which halted production for more than five weeks in 2025, shows how far real outages can run past any one-day planning assumption.

Decision guidance: what to do first and how far to go

• Small organisations: one workshop can do both. List five to ten services, rate impact over time, set MTD and RPO, then list the three to five most likely ways each could be disrupted. One spreadsheet, one scale.
• Large organisations: keep separate owners but one data model. The continuity team owns the service catalogue and impact curves; the risk function owns scenarios and likelihood; the GRC tool links the two by service ID.
• When not to merge: do not fold the BIA into the risk register as a column. The BIA's time dimension, dependency map and recovery order are lost, and continuity teams stop maintaining it.
• Quantification: where you express risk as money, the BIA's impact curve becomes the loss magnitude distribution by outage duration. See the Cyber Risk Quantification Guide and Quantitative vs Qualitative Cyber Risk.

Where identity fits

Identity services are the dependency most often missing from both exercises. Every critical service depends on a directory, an identity provider, privileged access tooling, certificates and service account credentials, yet few BIAs list them and few risk registers rate them as shared assets. Applying join 5 gives the identity provider the impact of the most critical service that relies on it, which usually makes it the highest impact asset in the estate. Machine credentials matter too: a backup job's service account or an expired certificate can stop recovery as surely as a failed server. See Recovering IAM and PAM After Ransomware or Domain Compromise.

Detection and measurement

Integration is measurable. Track these in the GRC tool or risk register:

• Service linkage rate: percentage of risk entries linked to a BIA service ID (target close to 100 percent, excluding explicit enterprise wide risks).
• Impact agreement rate: percentage of availability risks whose impact rating matches the BIA rating at the expected outage duration, or records a justified difference.
• Recovery gap count: number of critical services where the last tested recovery time exceeds RTO, or achieved data loss exceeds RPO, and the age of each gap.
• BIA freshness: percentage of critical services whose BIA was reviewed in the last 12 months or after a significant change.
• Dependency coverage: percentage of shared dependencies from the BIA (identity, DNS, certificates, key suppliers) that appear as assessed assets in the risk register.
• Incident calibration: after each significant incident, compare actual duration and impact with the BIA curve and the risk rating, and record the variance.

Common failure patterns

• Two scales: the BIA uses 1 to 5 with financial thresholds; the risk matrix uses Low, Medium, High with different thresholds. Ratings cannot be compared, and the board sees contradictory pictures. NCSC warns that matrices mislead unless scales and labels are clearly defined.
• Impact re-estimated per risk: each risk author guesses impact, usually lower than the business owner would, and the risk register understates the exposure of critical services.
• Recovery targets never tested against risk: the BIA sets an RTO, nobody checks whether ransomware scenarios could meet it, and the gap appears only during an incident.
• Availability only: the BIA rates downtime well but misses confidentiality and integrity loss, so a data theft from a "non-critical" system is rated low despite regulatory exposure.
• Systems instead of services: the BIA is done per application, so shared dependencies and the services that really matter to customers are never visible.
• Stale BIA, live risk register: services and dependencies change, the BIA does not, and risk impact values drift from reality.

Framework mapping

ISO 22301 places BIA and risk assessment side by side in the same clause for a reason: the standard expects both to inform the choice of continuity strategy. See the ISO 22301 Business Continuity Guide.

Implementing the join: a phased approach

1. Agree the service catalogue (weeks 1 to 4): one list of business services with IDs and owners, used by both teams. Start with the services the board would recognise.
2. Agree one impact scale (weeks 2 to 6): merge the BIA categories and the risk matrix impact axis into one approved table, with financial, customer, legal, safety, reputation and data rows.
3. Pilot on three services (weeks 6 to 10): run the BIA, then the risk assessment for those services using BIA impact values. Record every disagreement and how it was resolved.
4. Add the fields (weeks 8 to 12): service ID and BIA impact reference on every risk entry; recovery gap risks raised automatically from restore test results.
5. Re-map the register (quarter 2): link existing risks to services, re-rate impact from the BIA, and report the movement to the risk committee as a one-off recalibration rather than a sudden change in exposure.
6. Close the loop (ongoing): after each incident or recovery test, update the BIA curve and the risk rating together. Roll back by keeping the old ratings alongside the new ones for one review cycle so changes can be explained.

Practitioner checklist

• Confirm both exercises use the same service catalogue and service IDs.
• Replace the separate BIA and risk matrix impact scales with one executive approved scale.
• Require every risk entry to name the BIA service it affects.
• Read availability impact from the BIA at the tested outage duration, not a guessed one.
• Raise a risk wherever tested recovery misses an RTO or RPO, owned by the service owner.
• Add identity providers, privileged access, certificates and key suppliers to the BIA dependency map and to the risk asset list.
• Extend the BIA beyond downtime to confidentiality and integrity loss for services holding regulated data.
• Review both after significant incidents and at least annually, and report linkage and gap metrics to the risk committee.

Standards and references

• NIST: IR 8286D Using Business Impact Analysis to Inform Risk Prioritization and Response
• NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
• NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
• ISO: ISO/TS 22317:2021 Guidelines for business impact analysis
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NCSC: A basic risk assessment and management method
• NCSC: Risk management guidance

Related NHI Mgmt Group resources: Business Impact Analysis Template · NIST SP 800-30 Risk Assessment Guide · Business Continuity and Disaster Recovery Guide · Cyber Risk Appetite Statement Template · Threat Modelling vs Risk Assessment