A business impact analysis (BIA) follows eight steps: define scope and objectives, assemble a cross-functional team, prioritize processes, collect data, analyze the findings, document the results, develop recovery plans, and review the analysis on a set cycle. The output is a ranked list of your business functions, the cost of losing each one, and how long you can afford to be without it. This guide walks through each step in the order we use with regulated organizations such as law firms and energy operators, with worked examples and the mistakes that make a BIA useless.
TL;DR
- A BIA predicts the consequences of a disruption and gathers the information needed to build recovery strategies, according to Ready.gov.
- The eight steps: scope, team, prioritize, collect data, analyze, document, plan recovery, and maintain.
- Set the Maximum Acceptable Outage (MAO) first. Recovery time and recovery point objectives follow from it, not from what IT hopes to deliver.
- A BIA measures the severity of consequences. A risk assessment measures the likelihood of threats. You need both.
- A BIA is a business leadership exercise, not an IT task, and it goes stale whenever your systems change.
Table of Contents
- What a business impact analysis actually produces
- The 8 business impact analysis steps
- A worked example: a 30-attorney Houston firm
- BIA vs. risk assessment
- Common BIA mistakes
- Our perspective: where BIAs succeed or fail
- Getting help with your BIA
- FAQ
- Sources
What a business impact analysis actually produces
Before the steps, be clear about the deliverable. A BIA is not a report for its own sake. Ready.gov describes the outcome as a prioritized sequence for restoring business functions, built on the operational and financial impact of a disruption: lost income, regulatory fines, contractual penalties and similar costs.
In practice you finish with four things:
- A list of critical processes ranked by how quickly their loss hurts.
- For each, a Maximum Acceptable Outage, the point where damage becomes unrecoverable.
- Recovery time objectives (RTOs) and recovery point objectives (RPOs) that fit those limits.
- A map of the people, systems, vendors and facilities each process depends on.
The BIA is also a stage of a larger program. NIST's contingency planning guide, SP 800-34, treats it as one step in a seven-step process that starts with policy and moves through the BIA, preventive controls, recovery strategies, plan development, testing and training, and maintenance. The BIA sits in the middle because every later decision depends on it.
The 8 business impact analysis steps
The sequence below follows the eight-step framework common in industry guidance, with detail added from Ready.gov and NIST. Process names and depth vary by company, so treat it as a working template, not a legal standard.
Step 1: Define scope and objectives
Decide what the BIA covers and why you are doing it. A 40-attorney firm might scope the whole practice. A midstream operator might start with the control systems and billing for one pipeline asset. Be specific about the driver:
- A client or regulator requires documented continuity planning.
- A cyber insurer is asking for evidence of recovery capability.
- You have moved to a new cloud platform or merged with another firm.
- Leadership wants to know what an outage would really cost.
Write the objective in one sentence. Example: "Identify which functions must resume within 24 hours of a ransomware event, and what recovery they require." Everything later is judged against that sentence.
Step 2: Assemble the cross-functional team
A BIA done inside IT alone produces technically neat and commercially wrong answers. NIST and industry experts stress that the BIA is a business leadership exercise: IT cannot set a recovery time for a service until leadership has defined how long the business can survive without it.
A workable team includes:
- An executive sponsor with budget authority (a managing partner, COO or CFO).
- A process owner from each in-scope function, such as docketing, billing, field operations or trading support.
- IT and security representatives.
- Finance, to put numbers on losses.
- Legal or compliance, to flag contractual and regulatory obligations.
Get the sponsor's backing in writing. Without it, busy managers will not return your questionnaires.
Step 3: Prioritize the processes to analyze
You cannot analyze every task in the company in depth. List your functions at a high level, then pick the ones whose failure would be felt first. For a law firm, that usually means:
- Court filing and deadline calendaring
- Email and document management
- Client trust accounting and billing
- Conflict checking and intake
For an oil and gas operator it may include SCADA or operational technology monitoring, scheduling and nominations, and joint-interest billing. Do a quick first-pass ranking, then spend your effort on the top tier.
Step 4: Collect data through workshops, not just questionnaires
Questionnaires are the default tool, and they are the weakest part of many BIAs. Busy managers fill them in quickly and inconsistently. Practitioners who do this well use questionnaires to gather the basics and then run interactive workshops that map interdependencies, the hidden links between departments and third-party vendors that written answers tend to miss.
For each process, capture:
| Data point | Example question |
|---|---|
| Purpose and owner | What does this process deliver, and who is accountable? |
| Systems and data | Which applications, databases and files does it use? |
| People and facilities | How many staff, and can they work remotely? |
| Vendors and third parties | Which outside providers must be up for this to run? |
| Timing | Are there peak periods, such as filing deadlines or month-end close? |
| Workarounds | Can it run manually, and for how long? |
| Obligations | What contracts, court rules or regulations set time limits? |
Flow-charting a process on a whiteboard often exposes a dependency nobody listed, such as a single hosted tool that three "independent" functions all rely on.
Step 5: Assess the impact of a disruption
This is the analytical core. For each critical process, estimate the operational and financial effects as the outage lengthens. Ready.gov suggests tracking disruption duration in intervals: under 1 hour, 1 to 8 hours, 8 to 24 hours, 24 to 72 hours, over 72 hours, over a week, and over a month. The same worksheet asks you to note timing, since an outage at month-end or before a filing deadline costs more than one on a quiet Tuesday.
Score impact across categories that matter to you:
- Financial: lost revenue, unbilled time, overtime, recovery costs.
- Legal and regulatory: missed deadlines, fines, breach notification duties.
- Contractual: service-level penalties, client termination rights.
- Reputational: client confidence, referral loss.
- Safety and environmental: especially in energy operations.
Use a consistent scale, for example low, moderate, high, severe, with dollar thresholds defined in advance by finance. Where you can, use real figures, and flag where they are estimates.
Step 6: Set the MAO, RTO and RPO
Order matters here. Define the Maximum Acceptable Outage first: the longest the business can be without a process before the damage is irreversible or the loss unaffordable. Then set the recovery time objective (how fast the process must be back, always shorter than the MAO) and the recovery point objective (how much data loss is tolerable, measured in time).
The common failure is setting RTOs based on what IT believes it can deliver. That is backwards. If the business needs docketing back in four hours and current backups take two days to restore, you have found a gap that justifies investment. Our companion piece on RTO and RPO for disaster recovery and business continuity covers how executives should approach those numbers.
Step 7: Document the results in a BIA report
Keep the report short enough that leaders read it. It should include:
- Scope, method and participants.
- The ranked list of critical processes.
- Impact by time interval for each.
- MAO, RTO and RPO per process.
- Dependencies, including vendors and single points of failure.
- Gaps between required and current recovery capability.
- Recommendations, with estimated cost and owner.
The BCI's Good Practice Guidelines 7.0 reduced the number of BIA types, and the emphasis is now on simpler, more practical approaches integrated into operational management rather than bulky documents. A 15-page report with a one-page executive summary beats a 120-page binder.
Step 8: Turn findings into recovery plans and keep them current
A BIA with no continuity plan is, in the words of one industry analysis, a record of potential failure. Its real value is using the numbers to justify and prioritize budget for recovery resources, whether that is redundant infrastructure or specialized incident response support. If you need a model for the plan itself, see our continuity plan example for business leaders.
Then set a review cycle. In regulation-heavy sectors such as financial services, guidance calls for formal review and endorsement of the BIA at least annually or after major operational changes, as summarized by G2. Most regulated firms should adopt the same rhythm even where no rule requires it.
A worked example: a 30-attorney Houston firm
The figures below are illustrative, not client data.
The firm scopes its BIA to five functions. In workshops, the team discovers that docketing, email and document management all depend on one cloud platform and one identity provider. Finance estimates that a full day without document access means missed filings, unbilled time and potential malpractice exposure. The managing partner sets a MAO of 24 hours for docketing and 48 hours for billing.
The resulting objectives:
| Function | MAO | RTO | RPO |
|---|---|---|---|
| Deadline calendaring | 24 hours | 4 hours | 1 hour |
| Email and documents | 24 hours | 8 hours | 4 hours |
| Client trust accounting | 72 hours | 24 hours | 24 hours |
| Billing | 48 hours | 24 hours | 24 hours |
The gap analysis shows nightly backups cannot meet the one-hour RPO for docketing. That finding, not the spreadsheet, is what gets the improvement funded.
BIA vs. risk assessment
Readers often ask whether a BIA and a risk assessment are the same thing. They are related but distinct. Per NIST IR 8286D, a risk assessment looks at the likelihood of threats such as natural disasters or cyberattacks, while the BIA focuses on the severity of consequences and the criticality of the resources needed to execute the mission. TechTarget calls the BIA essentially an extension of a risk assessment, and Ready.gov says potential loss scenarios should be identified during a risk assessment.
| Risk assessment | Business impact analysis | |
|---|---|---|
| Core question | What could go wrong, and how likely is it? | What happens to the business if it does, and how fast? |
| Focus | Threats, vulnerabilities, likelihood | Consequences, criticality, time |
| Main output | Risk register and controls | Priorities, MAO, RTO, RPO |
| Drives | Preventive controls | Recovery strategy and budget |
Run the risk assessment to find likely scenarios, then use the BIA to learn which ones you cannot survive. For more on the first half, see our guides to quantitative risk assessment and security assessments for mid-market companies. If your organization is also working toward a formal security certification, a checklist for ISO 27001 in regulated firms shows where impact and risk analysis fit into an audit-ready management system.
Common BIA mistakes
- Treating it as an IT project. Technology staff cannot decide how much downtime the firm can tolerate.
- Guessing RTOs. Start from the MAO, then test whether recovery capability meets it.
- Relying on questionnaires alone. Add workshops to find hidden dependencies.
- Ignoring vendors. Your recovery time can never be shorter than your slowest critical provider's.
- Letting it go stale. Practitioners note that a static, check-the-box report becomes obsolete within months once you adopt new SaaS tools or cloud infrastructure. Tie the BIA into change management: when the critical software stack changes, revisit the BIA.
- Stopping at the report. No plan, no testing, no budget decision means no value.
Our perspective: where BIAs succeed or fail
We see the same pattern in regulated organizations. Leaders assume the BIA belongs to IT, IT sets recovery targets it can comfortably meet, and the document sits in a folder until an auditor or insurer asks for it. The exercise only works when a managing partner or operations executive states, in plain business terms, how long each function can be down.
For law firms, the exposure is client confidentiality and court deadlines. For energy operators, it is operational continuity and safety alongside the data. In both, the BIA is what turns a cybersecurity budget request from "we should have better backups" into "docketing has a 24-hour limit and our current recovery takes two days." That is also the logic behind stress-testing cybersecurity ROI with real assumptions, and it shapes how we think about cyber risk and firm reputation.
Our advice: keep the scope tight, make the sponsor visible, run at least one workshop per critical function, and put a review date on the calendar before you finish.
— vCISO
Getting help with your BIA
If you want an outside lead for the process, CISOSafe provides virtual CISO services, security risk assessments and audit and certification readiness support for regulated organizations, including law firms and energy companies. We can facilitate the workshops, connect BIA findings to your compliance obligations, and turn the results into a recovery roadmap leadership can fund. See our services or start at cisosafe.com.
FAQ
What are the five elements of a business impact analysis?
There is no single official list, but most guidance converges on five: critical business functions, the impact of disruption over time, dependencies (systems, people, vendors), recovery objectives such as MAO, RTO and RPO, and the resources needed to recover. The eight steps above are how you gather and document them.
How long does a business impact analysis take?
It depends on scope and how quickly managers participate. A focused BIA on five to ten critical functions can often be completed in a matter of weeks, while an enterprise-wide effort takes longer. Executive sponsorship is the biggest factor in speed.
How often should a BIA be updated?
Review it at least annually and whenever something major changes, such as a new cloud platform, a merger, a new office or a change in a critical vendor. Guidance for regulated sectors like financial services calls for annual review or review after significant operational change.
Who should own the BIA?
A business executive should sponsor it, with process owners supplying the data and IT and security supporting. NIST and industry experts stress that it is a business leadership exercise because only leadership can define how much outage the business can survive.
Sources
- Business Impact Analysis, Ready.gov
- SP 800-34, Contingency Planning Guide for Information Technology Systems, NIST CSRC
- Using Business Impact Analysis to Inform Risk Prioritization and Response, NIST
- NIST IR 8286D (updated), Using Business Impact Analysis to Inform Risk Prioritization and Response
- How To Conduct Business Impact Analysis in 8 Easy Steps, G2
- Business impact analysis vs. risk assessment explained, TechTarget
- Good Practice Guidelines 7.0: Analysing business continuity requirements, BCI