A business impact analysis (BIA) works out what a disruption would cost you, process by process, and how fast each process has to come back. The steps below take you from a blank page to a signed-off report: set the scope, build a team, rank your processes, collect data, map dependencies, quantify impact, set recovery targets and write it up. Ready.gov describes a BIA as a way to predict the consequences of a disruption and gather the information needed to build recovery strategies. That is the whole job. Everything else is method.
TL;DR
- A BIA ranks your business processes by how badly and how quickly an outage hurts, then sets recovery targets for each.
- Eight steps: scope, team, process list, data gathering, dependencies, impact scoring, recovery objectives, report and review.
- A risk assessment asks how likely a threat is. A BIA asks what happens if the process stops, whatever the cause.
- The hard part is rarely the math. It is getting executive time and honest answers from the people who run the processes.
- Treat the BIA as a living document and redo it after major changes in systems, vendors, locations or regulation.
Table of Contents
- What a BIA is, and what it produces
- The eight business impact analysis steps
- BIA vs risk assessment
- Our perspective: where BIAs go wrong
- When you want help running one
- Keeping the BIA current
- FAQ
- Sources
What a BIA is, and what it produces
A BIA is a structured study of your operations that answers three questions. Which processes can your business not afford to lose? How much does each hour or day of downtime cost? What has to be restored first, and by when?
The output is not a pile of paperwork. It is a ranked list of processes with, for each one, an estimated operational and financial impact, the people and systems it depends on, and a recovery time target. That list drives every later decision: which systems get backup and failover, how much you spend on disaster recovery, and what goes into your continuity plan.
If you want the five elements in one line, a usable BIA produces these five things:
- A list of critical business functions.
- The impact of losing each one, in money, operations, customers and compliance.
- The dependencies behind each function: people, applications, data, facilities and third parties.
- Recovery objectives for each function, such as recovery time and recovery point.
- A priority order and a report that leadership can sign.
Different guides slice these differently, so treat the five as a working summary rather than an official standard. The eight steps below produce all of them.
The eight business impact analysis steps
The sequence follows the common pattern: G2's eight-step walkthrough runs from defining objectives and scope, through assembling a team and prioritizing processes, to data gathering, review, reporting and plan development. We have kept that backbone and added the detail we see matter in practice.
Step 1: Define the objective and the scope
Write one sentence on why you are doing this. "Support our disaster recovery design" and "meet a customer's continuity questionnaire" lead to different depth. Then set the boundary: the whole company, one business unit, or one site.
For a first BIA at a small or mid-sized company, cover the entire business at a coarse level rather than one department in great detail. You will find the biggest surprises in the processes nobody thought to include.
Decide at this point what you will measure. Most teams use a mix of:
- Revenue lost or delayed per hour and per day
- Extra costs such as overtime, temporary staff and expedited shipping
- Contractual penalties and regulatory exposure
- Customer impact, including churn and complaints
Step 2: Get executive sponsorship and assemble the team
This is where BIAs stall. Gartner observes that many organizations underestimate the executive support and time a comprehensive BIA takes. Plan for that. Name a sponsor who can compel answers from department heads, and tell them up front how many hours their managers will spend.
A workable team has:
- A project lead, often from IT, risk or operations
- One representative per business unit who understands how work really gets done
- Finance, to validate cost figures
- IT, to map systems to processes
- Compliance or legal, if you operate under HIPAA, PCI DSS or similar rules
Involve the people who run processes day to day. Asana notes they understand on-the-ground realities that a high-level view misses, and that is consistently true in our experience.
Step 3: List and prioritize business processes
Build a complete inventory of processes before you judge any of them. Think in terms of what the business does, not which department does it: take orders, ship product, bill customers, run payroll, answer support calls, process claims, release code.
Then sort them roughly into three groups: clearly critical, clearly deferrable, and unsure. The unsure group gets the most attention in the interviews. A first pass like this keeps you from spending hours analyzing the office supply reorder process.
Step 4: Gather data with questionnaires and interviews
Ready.gov recommends a BIA questionnaire sent to managers and staff with detailed knowledge of the processes, to identify impacts and critical resources. Follow up with short interviews, because written answers are often vague and a ten-minute conversation fixes that.
Good questionnaire questions are specific:
- What does this process produce, and for whom?
- What happens after 1 hour, 4 hours, 1 day, 3 days and 1 week without it?
- Are there peak periods, such as month-end close, open enrollment or holiday season, when an outage is worse? Ready.gov specifically says to account for seasonal and time-sensitive variation.
- Is there a manual workaround, and how long can staff sustain it?
- Which applications, data sets, vendors and people does it need?
Also pull historical data. Past outages, their recovery timelines and their financial losses give you real numbers to check against what managers estimate, as Asana points out.
Step 5: Map dependencies
A process is only as resilient as the weakest thing it relies on. The FFIEC IT Examination Handbook tells management to inventory critical assets, including people, hardware, software and data, along with infrastructure such as network connectivity and facilities. Add third-party services to that list.
For each critical process, record:
| Dependency type | Examples to capture |
|---|---|
| People | Key roles, single points of knowledge, required skills |
| Applications | ERP, EHR, CRM, payment systems, internal tools |
| Data | Databases, file shares, backups and how fresh they are |
| Infrastructure | Network links, cloud regions, power, office or clinic sites |
| Third parties | SaaS vendors, payment processors, carriers, managed providers |
Workflow diagrams, org charts and data flow diagrams all help here. The most valuable finding is usually a hidden dependency: a "low priority" server that feeds a critical process, or a vendor with no contractual recovery commitment. Vendor exposure is its own discipline, and our overview of third-party cybersecurity risks covers the types worth checking.
Step 6: Assess operational and financial impact
Now score the damage. Ready.gov says the BIA should identify operational and financial impacts such as lost sales and income, regulatory fines and customer defection, and that processes with the greatest impacts should be restored first.
A simple approach that works for most mid-sized firms:
- Estimate the cost per hour of downtime for each critical process, split into hard costs (revenue, penalties, overtime) and soft costs (reputation, customer churn).
- Rate impact over time windows: 1 hour, 4 hours, 24 hours, 72 hours, 1 week.
- Find the point where the impact becomes unacceptable. That is your maximum tolerable downtime for the process.
Here is a worked illustration with made-up numbers, for the mechanics only. An online store that books $4,000 in sales per hour on a normal day loses roughly that much for each hour its checkout is down, plus any chargebacks and ad spend wasted on a dead site. A day before a peak sale, the same hour is far costlier. So checkout gets a short tolerance. The internal wiki, by contrast, can be down for days with minor irritation. That contrast is exactly what the BIA is for.
Where you cannot produce a dollar figure, use a three- or five-point scale with defined meanings (for example, "high: regulatory reporting breach or loss of a top-ten customer"). Consistent definitions matter more than precision.
Step 7: Set recovery objectives
Turn tolerances into targets. The CISA CRR Resource Guide says a BIA should establish recovery time objectives (RTOs), the desired speed of recovery, and recovery point objectives (RPOs), the desired currency of recovered information. In plain terms:
- Maximum tolerable downtime: how long the process can be down before the damage becomes unacceptable.
- RTO: how fast you aim to restore it. It must be shorter than the maximum tolerable downtime, with margin.
- RPO: how much recent data you can afford to lose, which dictates backup or replication frequency.
Example: payment processing has a tolerable downtime of 4 hours, so you set an RTO of 2 hours and an RPO of 5 minutes. That points toward replication, not nightly backups. Payroll might tolerate 3 days and a 24-hour RPO, which a daily backup covers cheaply.
This is also where cost enters. CISA notes that BIA information can justify mitigation spending by clarifying risk tolerance, for example accepting longer recovery times to reduce costs. Not everything deserves a hot standby. Our guide on RTO vs RPO targets goes deeper on choosing and validating the numbers.
Step 8: Write the report, then review it on a schedule
The report should be short enough that an executive reads it. Include:
- Scope and method
- The ranked list of critical processes with impact ratings
- Dependencies and single points of failure
- Recovery objectives per process
- Gaps between today's capability and the targets
- Recommended actions, with rough cost and owner
The gap list is the part that earns the budget. If payments need a 2-hour RTO and your current restore takes 14 hours, say so plainly. Our article on turning BIA findings into funded fixes shows how to package those gaps for approval.
Then close the loop. The BIA feeds your disaster recovery planning and business continuity plan, and those plans need testing against the targets you set.
BIA vs risk assessment
People confuse the two because they feed each other. The difference is the question each one asks.
| Business impact analysis | Risk assessment | |
|---|---|---|
| Core question | What happens if this process stops, and how fast must it return? | How likely is a given threat, and how bad would it be? |
| Starting point | Business processes | Threats and vulnerabilities |
| Cause of disruption | Irrelevant; focuses on the effect | Central; each threat is analyzed |
| Main output | Priorities and recovery objectives | Ranked risks and controls |
Read the Ready.gov explanation for the official framing: a risk assessment looks at the likelihood and impact of specific threats, while the BIA predicts the consequences of disruption to business functions to set recovery requirements. The CISA guide adds that risk assessments should be used to identify likelihood and potential impact of disruption threats, which then inform the BIA.
In practice, do both. The BIA tells you what matters most. The risk assessment tells you what is most likely to hit it. If you want the security side in detail, see our explainer on security risk assessments for your business.
Our perspective: where BIAs go wrong
We run IT, security and compliance work for small businesses, healthcare providers and startups, and the same failure patterns keep showing up.
The BIA is done by IT alone. IT can list systems, but only the business can say which hour of an outage hurts. When IT guesses, the targets get set to what the infrastructure can already do, which defeats the purpose.
Everything is critical. If every process has a 1-hour RTO, nothing has been prioritized and the budget request is unaffordable. Force ranking. A BIA that leaves a third of processes in the "can wait" group is usually an honest one.
Targets nobody has tested. An RTO on paper is a hope. We would rather see a modest target that the team has restored against than an ambitious one that has never been tried.
No link to the provider stack. Many companies buy backup from one vendor, monitoring from another, cloud from a third and compliance help from a fourth. Nobody owns the recovery end to end. That is the fragmentation we built Nexus to remove: one accountable provider for security, cloud, infrastructure and compliance means the BIA's targets map to one SLA instead of four. Our write-up on integrated IT service providers explains that trade-off.
Our advice: keep the first BIA lean, finish it in weeks rather than quarters, and fix the top three gaps before polishing anything.
— Nick - Sr. Executive
When you want help running one
If your team lacks the time or the specialists, we run BIAs as part of our compliance and risk work and carry the results into cloud, backup and disaster recovery design, with 24/7 monitoring behind the targets. You can see the full range on our services page, or start from the Nexus home page and tell us what you need to recover and how fast.
Keeping the BIA current
A BIA goes stale quietly. G2 advises reviewing and updating it periodically as new processes and risks emerge. The FFIEC wants the methodology to be repeatable, so management can reevaluate information after significant changes. Microsoft likewise suggests ranking functions by criticality and re-evaluating those rankings on a regular basis.
No source we reviewed sets a single mandatory interval, so pick a rhythm and write it down. A sensible default is a light annual review plus a fresh pass after any of these triggers:
- A merger, acquisition or new location
- A migration to a new cloud platform or core application
- A new critical vendor, or a vendor change
- A new regulation or customer contract with continuity terms
- A real incident that exposed a gap
Use each review to test the targets too. Our guide to disaster recovery testing explains how often each system tier should be exercised.
FAQ
What are the five elements of a business impact analysis?
There is no single official list, but a complete BIA covers five things: critical functions, the impact of losing them, their dependencies, recovery objectives such as RTO and RPO, and a priority order captured in a report. The eight steps above produce all five.
How long does a BIA take?
It depends on scope and how quickly managers return questionnaires. A focused BIA for a small company can be finished in a few weeks, while a multi-site enterprise needs longer. Executive sponsorship and scheduled interviews are what keep it from dragging.
Do small businesses need a BIA?
Yes, in a lighter form. A small company usually has fewer processes but also fewer spare resources, so knowing which systems must return first matters more. A short questionnaire, a one-page process ranking and a list of recovery targets is a sound start.
Who should own the BIA?
A business-side sponsor should own it, with IT, finance and compliance contributing. Putting it under IT alone tends to produce targets based on current technology rather than business need.
Sources
- Business Impact Analysis, Ready.gov
- How To Conduct Business Impact Analysis in 8 Easy Steps, G2
- How to Perform a Business Impact Analysis, Gartner
- FFIEC IT Examination Handbook, identification of critical business functions
- CRR Resource Guide: Service Continuity Management, CISA
- Business Impact Analysis (BIA): How to Do It + Template, Asana
- Considerations for your Enterprise Business Continuity plan, Microsoft