Skip to main content

Business Impact Analysis

Business Impact Analysis (BIA) is where you record how much each business process matters — how quickly it must recover after an outage and how much downtime costs. Offload Security then feeds that context straight into risk scoring, so the same vulnerability counts for more when it sits on the asset behind payroll than when it sits behind a marketing landing page.

In short: BIA is how you tell the platform what's mission-critical, so prioritization reflects your business, not just generic severity.

What it does​

  • Captures process criticality. A guided questionnaire walks you through a structured BIA for each business process — general information, process criticality, technology requirements, and human-resource dependencies.
  • Records recovery targets. For every process you set a Recovery Time Objective (RTO) — how long it can be down — and a Recovery Point Objective (RPO) — how much data loss is tolerable.
  • Quantifies financial impact. You record the cost of downtime (for example, revenue lost per hour of outage), so impact is expressed in money, not just a severity label.
  • Feeds risk scoring. Once a process is linked to an asset, its RTO and financial impact raise the risk score of vulnerabilities on that asset (see How BIA feeds risk scoring).
  • Maps dependencies and single points of failure. Visualize how processes depend on infrastructure, and surface assets that support several critical processes with no redundancy.
  • Tracks exercises and drills. Plan tabletop exercises, functional drills, and full-scale DR tests; log gaps between your target RTO and actual recovery, then track each gap to resolution.
  • Keeps a versioned, reviewable record. Every BIA is version-controlled with an audit trail, moves through states (draft, active, archived, superseded), and can be put on a review cadence so it stays current.

How to use it​

1. Create a Business Impact Analysis​

  1. Open Business Impact Analysis from the left navigation.
  2. Select New BIA (or Add Analysis) and complete the questionnaire section by section.
  3. Fill in the recovery targets and impact figures that drive scoring:
    • RTO — the maximum acceptable downtime (for example, 4 hours, 1 day).
    • RPO — the maximum acceptable data loss.
    • Financial impact — the cost of downtime, such as revenue lost per hour (for example, $50,000/hour).
  4. Save the analysis. It starts as a draft so you can refine it before it counts.

:::tip Be specific with RTO and cost These two fields drive the scoring boost. Concrete values like 4 hours and $50,000/hour are parsed and applied; vague or blank entries are treated as "no boost" rather than guessed. The clearer your inputs, the more accurately the platform prioritizes. :::

2. Activate it and set a review cadence​

  1. When the analysis is ready, move it to active. Active analyses are the ones that feed risk scoring.
  2. Choose a review frequency — monthly, quarterly, semi-annually, annually, or a custom interval. The platform schedules review reminders so the BIA doesn't go stale.
  • Link to an asset so vulnerabilities found on that asset inherit the process's criticality.
  • Link to a risk in the Risk Register to connect a business process with the risks that threaten it. The linked process (name, RTO, and exposure) then appears on the risk so reviewers see the business stakes at a glance.

4. Run exercises and close gaps​

  1. Schedule an exercise — a tabletop, a functional drill, or a full-scale DR test.
  2. Record what actually happened. Where real recovery time misses the BIA's RTO, the platform logs a gap with a severity (low, medium, high, critical).
  3. Work each gap through its remediation status — open → in progress → resolved — so DR findings are tracked to closure rather than forgotten.

5. Review dependencies and single points of failure​

Use the dependency view to see how business processes rely on underlying infrastructure, and to spot single points of failure — assets that support multiple critical processes with no redundancy. These are the places where one outage cascades furthest.

How BIA feeds risk scoring​

This is what makes BIA more than documentation. When the platform scores a vulnerability on an asset, it looks up any active BIA linked to that asset and applies a multiplier built from two signals:

  • Recovery Time Objective (RTO) — the shorter the RTO, the more critical the process, and the larger the boost. A process that must recover within 4 hours raises the score more than one that can be down for a week.
  • Financial impact — the higher the cost of downtime per hour, the larger the boost.

The two factors combine into a single multiplier, which is capped so an over-stated BIA can't balloon a routine finding into a false top priority. You can see exactly how it was applied on the risk card and in the "Why this score?" explanation, which calls out the contributing process — for example, "affects payroll, RTO 4h, $50k/hour exposure."

:::note Graceful by design If an asset isn't linked to any BIA, or the RTO and cost fields are blank, no multiplier is applied — the score is left unchanged rather than guessed. A very old analysis is treated the same way, so a stale BIA never silently distorts your scores. Keep analyses active and reviewed to keep the boost flowing. :::

:::tip Where the boost shows up BIA context surfaces wherever risks are prioritized — on risk cards in the Risk Register and in the score breakdown. If a high-impact process looks under-prioritized, check that its BIA is active, linked to the right asset, and has RTO and cost filled in. :::

Prerequisites​

  • You need permission to manage risk and governance data in your active team. BIA records, like everything else, are scoped to the team you're working in.
  • For scoring to take effect, an analysis must be active and linked to an asset (or process) that vulnerabilities are found on.