This is a method guide, not a software generator. Nothing on this page builds a business impact analysis for you, scores your processes, or exports a recovery plan. A business impact analysis (BIA) is the disciplined way you decide which activities matter, how fast harm grows when they stop, and which recovery priorities those facts justify. The “generator” in the title is the sequence below: the questions, the order, and the decisions a named owner has to sign.
Recovery priorities are the order in which you restore work so the harm of a disruption stays inside what the organization can accept. Skip the analysis and you will fund whichever recovery is easiest to buy. This sequence is that order.
Decide what the BIA is allowed to decide
What it means: A BIA produces a small set of decisions: which activities are in scope, how impact accumulates over time if each one stops, what recovery time and recovery point the activity requires, and which dependencies make those numbers real or fictional. It does not produce a continuity plan, a budget, or a tool configuration. Those come after, and only if someone with authority accepts the analysis.
What good looks like: A one-page scope before any workshop. In scope: the activities that deliver products, services, and the internal work those services cannot run without. Out of scope: improvements people wish they had, and systems that are painful but not on the path of a prioritized activity. A named sponsor who will read the result and is allowed to say no to a requested recovery time.
Common failure mode: The BIA is opened as a software project. Someone asks for a portal, a workflow, and a dashboard before a single activity has an owner. The tool then becomes the analysis. When the tool is empty — as a generator with no product behind it always is — the firm has neither a method nor a priority list.
Name activities the way the work actually happens
What it means: The unit of analysis is an activity you could stop and describe: “settle yesterday’s card transactions,” “release a finished lot,” “open the chart and place the order.” It is not a department name and not an application name. Departments do many things. Applications support many activities. If you analyze at the wrong level, every recovery time collapses into one number that fits nothing.
What good looks like: A list short enough to interview. Each activity has a verb, an output, the team that performs it, and the hours it runs. Peak periods are noted — month-end, open enrollment, a storm weekend — because impact is not flat across the calendar. The list is reviewed by the people who do the work, not only by the people who drew the process map last year.
Common failure mode: One row per department, recovery time “4 hours,” dependency “IT.” The row cannot be tested, cannot be staffed, and cannot be disagreed with, which is why it survives every review.
Measure impact over time, not as a label
How harm grows
What it means: Ask what is true if the activity is down for an hour, for a shift, for a day, for a week. Separate customer harm, financial harm, regulatory or contractual exposure, and harm to other activities that depend on this one. You are looking for the point where the impact becomes unacceptable. That point is the maximum tolerable period of disruption. It is a business judgment. It is not the time your current backup happens to need.
What good looks like: A time ladder filled in with the activity owner in the room, challenged by someone who does not report to them. Impacts are described in operational facts: orders that cannot ship, patients who cannot be treated, payments that miss a cutoff. Where a number is estimated, the basis of the estimate is written next to it. Where you do not know, the cell says unknown — and unknown is a finding, not a zero.
Common failure mode: Every activity scored “high” on a five-point scale with no time axis. High compared with what, and after how long, is never answered. The priority list that falls out is the list of whoever attended the workshop.
Recovery time and recovery point
What it means: The recovery time objective is how quickly the activity must be restored so that you remain inside the tolerable period, with margin for the fact that restoration is messy. The recovery point objective is how much data or work-in-progress you can afford to lose or recreate. Set them from the impact ladder. Then check them against the resources. If the resource cannot meet the objective, you have a gap. The gap is the point of the analysis. Do not edit the objective until the gap disappears on paper.
What good looks like: Each in-scope activity has an RTO and an RPO stated in hours or in a business cutoff, an owner, and a note that says whether today’s capability meets them. Gaps are listed separately from the objectives. Strategies — alternate site, manual workaround, faster restore, accepted risk — are chosen against the gaps, after the numbers exist.
Common failure mode: The technology team proposes the RTO that the existing backup window already achieves, and the business signs it because the meeting is over. The impact ladder is filled in afterward to match. Nothing was analyzed.
Map dependencies before you rank anything
What it means: An activity’s priority is wrong if you have not named what it needs: people and skills, a place, applications and the data they read, suppliers, and the upstream activities that feed it. A shared platform that ten activities need is more important than any one of those activities’ individual scores. The dependency, not the loudest owner, often sets the recovery order.
What good looks like: For each prioritized activity, a short dependency line: upstream activity, system, data, vendor, and the workaround if that dependency is gone. Shared dependencies are called out once and inherited, so you do not discover in the incident that six “independent” workarounds all need the same identity service. Internal and external dependencies are both on the line.
Common failure mode: Dependencies captured as a logo wall of vendors. No upstream activity, no data, no person. The recovery priority list then orders applications by replacement cost instead of by the work that stops.
Turn the analysis into recovery priorities
What it means: A recovery priority is the order and the timing in which you restore activities and the resources under them, given that you will not get everything back at once. Build it from the tolerable periods, the dependencies, and the gaps. The first tier is what must return before harm becomes unacceptable, including the shared resources those activities silently require. Later tiers are what can wait, with the wait stated in time, not in a color.
What good looks like: A single ordered list the crisis lead can hold: activity, owner, RTO, RPO, the resources that must already be up, the workaround if they are not, and the person authorized to accept a miss. The list is short on the first page. Supporting detail sits behind it. When two activities conflict for the same people or the same system, the conflict is resolved in the list, not left for the incident.
Common failure mode: Three priority lists — one from the business, one from IT, one from the crisis plan — that do not match. In the event, the team follows whichever list is open. The BIA is cited in the after-action as “available” and was not used.
Sign it, then keep it from rotting
What it means: A BIA that nobody signs is a draft. The signature is the business owner accepting the impact judgments and the recovery priority, not the resilience analyst accepting that the spreadsheet is finished. After signature, the analysis rots when activities, suppliers, or systems change and the document does not. Tie review to those changes. A calendar reminder alone will not catch a new product that went live without an activity row.
What good looks like: Each activity row names the owner who confirmed it and the date. A change trigger — new service, new supplier on a prioritized activity, failed test, reorganization of the team that performs the work — reopens the rows it touches. The recovery priority list in the crisis plan is the same list, not a summary someone retyped.
Common failure mode: An annual refresh that copies last year’s times forward, changes the cover date, and calls itself current. The owner who signed has left. The new owner has never seen the ladder.
FAQ
Will this page generate a BIA for me?
No. There is no questionnaire engine, scoring model, or downloadable plan behind this title. Use the sequence — scope, activities, impact over time, dependencies, recovery priorities, signature — and have a named owner complete it for your organization. A form that fills itself in is not a business impact analysis.
What is the difference between a BIA and a risk assessment?
A risk assessment asks what could disrupt you and how likely it is. A BIA asks what happens to the work as time passes after the disruption, regardless of which threat caused it. You need both. The BIA is what sets recovery priorities. Likelihood does not.
Who should sign the BIA?
The owner of the activity, for the impact and the tolerable period, and a sponsor who can fund or formally accept the gaps. The person who facilitated the workshops does not sign on their behalf. A model does not sign.
How does this relate to important business services?
Important business services are the customer or market outcomes you must keep delivering. The BIA analyzes the activities and resources under those outcomes and sets recovery priorities so the service can stay inside its impact tolerance. If you only do the BIA at department level, you will not see the service. If you only name the service, you will not know what to restore first.
How often should recovery priorities change?
When the work changes, when a test shows the priority cannot be met, or when the owner changes. An annual review is a backstop, not the method. Copying last year’s list forward is how priorities rot.
How this connects
Program-level depth — data collection, financial modeling, and how findings become strategy — is in the advanced BIA program guide. How those priorities serve an impact tolerance on a customer outcome is in the operational resilience guide and the important business services guide. If you are tempted to let a model refresh the rows for you, read the note on automated BIA: automation can keep a map from rotting, and it still does not sign the analysis or prove a restore.