What is a business impact analysis (BIA)?
A business impact analysis (BIA) is a structured review of what an organization does, what each activity depends on, and how quickly harm builds if it stops. NIST describes it as the process of analyzing operational functions and the effect a disruption might have on them.
What it means in practice
The BIA is where continuity planning starts. It turns “everything is important” into a ranked list. For each business function, it asks what happens if the function is down for an hour, a day, a week. Ready.gov lists the kinds of impact to look for: lost or delayed sales, higher costs, regulatory fines, contractual penalties and unhappy customers. It also notes that timing and duration matter. The same outage can cost far more at month-end than mid-month.
A BIA usually produces four things:
- A list of critical functions, in priority order.
- The people, systems, suppliers, data and facilities each one depends on.
- A recovery time objective and recovery point objective for each function or system.
- The longest outage the business would accept for each function, the maximum tolerable downtime.
Example: a 150-person logistics company finds that dispatch can be down for an hour without much harm, but a day means missed deliveries and penalty clauses. Month-end reporting, which everyone assumed was critical, can wait a week. That finding changes what gets restored first, and what gets paid for.
The right people to interview are the process owners, not just IT. A BIA written only by IT ranks systems by what IT believes matters. It also needs a refresh when the business changes: a new product, an acquisition, a move to a new cloud vendor.
Where it shows up in an incident
The BIA is the document leadership should reach for when several things are broken at once and there isn’t enough capacity to fix them all. It answers “what do we restore first?” before the argument starts. Ready.gov says the highest-impact processes should be restored first.
The business continuity or risk lead usually owns it, with sign-off from business owners. The common failures are familiar. It gets done once for an audit and filed. It ranks systems instead of business functions, so a small supporting service that gates shipping or payment never appears. It skips outside dependencies such as a payment provider or a single supplier. Every owner marks their function critical. And nobody records the manual workarounds that would keep a function limping along.
A BIA also gives you a defensible estimate of what an hour of downtime costs. That helps when deciding how much cyber insurance to buy. See how to test a business continuity plan for where the BIA fits in testing.
In a tabletop exercise
Sample inject: “Day one of a ransomware outage. Leadership has the BIA ranking in front of them. It puts the ERP system first. The operations manager points out that the warehouse can’t ship without a label-printing service that isn’t on the list, and it runs on a server that is also down. What does the group do, and what does this say about the BIA?”
Discussion question: “Who in this room was actually interviewed for our BIA? Which function would be hurt first and fastest, and does the BIA say so?”
Sources
Want to see how your team would handle this for real? Here is how a facilitated tabletop works.