A business impact analysis (BIA) is the structured assessment of what happens to an organization when each of its activities is disrupted, how the harm grows over time, and therefore how quickly and how completely each activity must be recovered. Its outputs are the recovery objectives that every continuity strategy, recovery plan, technology design and exercise is built to meet: the maximum tolerable period of disruption, the recovery time objective, the recovery point objective and the minimum service level during recovery. A BIA done well tells the organization where to spend its resilience money; a BIA done as a questionnaire, in which process owners write down the recovery times they would like, produces objectives nobody tested and investments nobody needed, and it is the single most common root cause behind the findings in a business continuity audit.
This guide gives the method. It covers the process inventory and the criticality criteria that decide which activities get a full analysis, impact-over-time analysis across five dimensions, how each recovery objective is derived from the impact curve rather than declared, dependency mapping across systems, data, people, sites and suppliers, the consistency checks between dependent processes, how to run the workshops and design the questionnaire, three worked BIAs (a cash collection process at a distributor, a production line at a food manufacturer and a payroll function at a bank), the data quality problems auditors find in BIAs, how the BIA connects upward to impact tolerances and sideways to the audit plan, and a questionnaire template. It follows ISO/TS 22317, the technical specification for business impact analysis that accompanies ISO 22301, and the Business Continuity Institute’s practice, and it is written for the people who run BIAs and the auditors who test them.
In this guide
- The terms, precisely
- Step 1: the process inventory and criticality criteria
- Step 2: impact over time
- Step 3: deriving the recovery objectives
- Step 4: dependency mapping
- Step 5: consistency checks across processes
- Running the workshops and the questionnaire
- Tooling, effort and cadence
- Worked BIA 1: route cash collection at MidState Beverage
- Worked BIA 2: a production line at Brightwater Foods
- Worked BIA 3: payroll at Lakeshore Bancorp
- The data quality problems auditors find
- Connecting the BIA to tolerances, strategies and the audit plan
- Template: the BIA questionnaire
- Questions about business impact analysis
- Related guides
The terms, precisely
| Term | Definition | Derived from | Common confusion |
|---|---|---|---|
| Maximum tolerable period of disruption (MTPD), also maximum acceptable outage | The time after which the harm from a disrupted activity becomes unacceptable to the organization | The impact-over-time curve: where the curve crosses the organization’s threshold of unacceptable harm | Treated as the same as the RTO; it is the ceiling the RTO must sit under |
| Recovery time objective (RTO) | The target time for resuming the activity at its minimum service level after disruption | Set below the MTPD with a margin for detection, decision and the recovery itself | Declared by the owner as a wish; set equal to the MTPD with no margin |
| Recovery point objective (RPO) | The maximum acceptable age of the data the activity restarts with (the acceptable data loss window) | The impact of lost or re-keyed transactions over the window | Confused with backup frequency; backup frequency is how the RPO is met |
| Minimum business continuity objective (MBCO), or minimum service level | The reduced level of output acceptable during recovery | What customers and regulators need, not what the process normally produces | Assumed to be 100 percent, which makes recovery strategies unaffordable |
| Work recovery time | The time after systems return to catch up on the backlog and verify data before normal operation | Transaction volume during the outage and the re-keying capacity | Omitted, so that “system back” is reported as “process recovered” |
| Impact tolerance | The maximum tolerable disruption to an important business service as experienced by its users, set by the board | Harm to customers and the market (resilience guide) | Treated as another name for the RTO; it sits above the RTOs of the processes that deliver the service |
Step 1: the process inventory and criticality criteria
The BIA starts from a complete inventory of the organization’s activities at a consistent level (a process, not a department and not a task), reconciled to the organization chart, the product and service list and the application inventory so that nothing is missed; the taxonomy and audit universe guides use the same reconciliation. Every process gets a short screening assessment against the criticality criteria; the processes that pass get the full analysis in steps 2 to 4; the rest are recorded as non-critical with the reason, and that record is what an auditor tests from below. Criteria should be written and few: does the process deliver or directly support an important business service or a product customers depend on; does it carry a legal, regulatory or contractual deadline; does it protect life, safety or the environment; does it move money or hold customer assets; does its failure stop other critical processes. A mid-size organization typically ends with 20 to 60 critical processes from an inventory of 100 to 300.
Step 2: impact over time
The analysis that distinguishes a BIA from a questionnaire is impact over time: for each critical process, what harm has accumulated if it has been disrupted for one hour, four hours, one day, three days, one week, two weeks and a month, across the dimensions the organization cares about. Five dimensions cover most organizations: financial (lost revenue, penalties, recovery cost), customer and service (customers unable to transact, orders unfilled, claims unpaid), regulatory and legal (deadlines missed, reportable events, license conditions), operational knock-on (other processes stopped, backlog that cannot be cleared) and health, safety and environment. Each cell is rated on the organization’s impact scale (the risk matrix guide’s five-point impact anchors serve), and the process’s impact profile is the highest dimension at each time point. The curve has two features that matter: the point at which any dimension reaches the organization’s unacceptable level, which fixes the MTPD, and the shape before it, which decides whether a cheap slow recovery or an expensive fast one is justified. Processes whose harm is severe immediately (payments, patient care, safety systems) need recovery in hours; processes whose harm is modest for days and then jumps at a regulatory or payroll deadline can wait, and the curve shows exactly how long.
| Time disrupted | Financial | Customer | Regulatory and legal | Operational knock-on | Health, safety, environment | Profile (highest) |
|---|---|---|---|---|---|---|
| 1 hour | 1 | 2 | 1 | 1 | 1 | 2 Minor |
| 4 hours | 2 | 3 | 1 | 2 | 1 | 3 Moderate |
| 1 day | 3 | 4 | 2 | 3 | 1 | 4 Major |
| 3 days | 4 | 5 | 3 | 4 | 1 | 5 Severe: MTPD reached |
| 1 week | 5 | 5 | 4 | 5 | 2 | 5 |
| 2 weeks | 5 | 5 | 5 | 5 | 2 | 5 |
The table shows a profile whose customer dimension drives it: minor for an hour, major within a day, severe by day three, which fixes the MTPD at three days and points to an RTO of a day or less. The organization’s threshold for “severe” is a policy decision made once, in the BIA methodology, and applied to every process; the risk appetite statement is where it should be anchored.
Step 3: deriving the recovery objectives
| Objective | Derivation rule | From the table above |
|---|---|---|
| MTPD | The earliest time point at which any dimension reaches the unacceptable level | 3 days |
| RTO | MTPD less a margin for detection and decision (the time before recovery starts, often 2 to 8 hours) and for work recovery after systems return; typically one third to one half of the MTPD for processes with backlog | 24 hours: leaves a day for detection, invocation and work recovery inside the 3-day ceiling |
| RPO | The data loss window beyond which re-creation is infeasible or the error rate from re-keying is unacceptable; derived from transaction volume per hour and the ability to reconstruct from source documents | 4 hours: about 1,800 transactions, reconstructible from depot records within the work recovery time |
| Minimum service level | The output needed to keep customer and regulatory impact below the severe level during recovery | Priority customers and regulatory deadlines first: 60 percent of normal volume |
| Work recovery time | Backlog at the RTO divided by catch-up capacity (overtime, temporary staff) | About 12 hours for a one-day outage |
The derivation is the control against wishful objectives. An owner who wants a 2-hour RTO for a process whose impact curve is flat for two days is asked to show the harm that justifies the cost; an owner who declares a 5-day RTO for a process whose customer impact is severe at day one is shown the curve. Objectives are then approved by the process owner and the steering body together, and the approval record is what an auditor reads first.
Step 4: dependency mapping
For each critical process the BIA records what it cannot run without, in six categories: applications and infrastructure (with the data each holds); data and records (including paper and spreadsheets); people (roles, minimum numbers, key individuals, skills that cannot be substituted); sites and equipment; suppliers and outsourced services (with the supplier’s own continuity arrangements and the fourth parties behind them); and other internal processes upstream and downstream. Each dependency is reconciled to the relevant inventory (the application inventory, the vendor master, the HR system) so that the BIA’s view and the organization’s match, and each is tagged with whether it is a single point of failure. The dependency map is what turns the BIA into something a strategy can be built from and a scenario can be tested against, and it is the step most often skipped when the BIA is a questionnaire; a BIA that lists “ERP” as the only system dependency for a process that also runs on three spreadsheets and a courier contract has not mapped anything. The resilience guide describes the same mapping at the level of the service.
Step 5: consistency checks across processes
| Check | Rule | Typical failure |
|---|---|---|
| Upstream dependency | A process’s RTO cannot be shorter than the RTO of a process or system it depends on | Order management with a 4-hour RTO depends on a pricing engine with a 48-hour RTO |
| Downstream pressure | A process feeding a critical downstream process inherits an RTO short enough to protect it | Master data maintenance rated non-critical while every critical process depends on it |
| Shared resource | Processes sharing a system, site or team have objectives the shared resource can meet together | Twelve processes each assuming the same twenty people will perform their workaround |
| RPO versus RTO | Data older than the RPO cannot be the restart point if the RTO assumes it | RPO 24 hours with an RTO of 4 hours for a transaction process |
| Tolerance ceiling | The RTOs of processes delivering an important business service must together fit inside its impact tolerance | Three sequential 8-hour RTOs under a 12-hour tolerance |
| Supplier promise | A supplier’s contracted recovery commitment is no longer than the RTO of the process depending on it | Cloud provider committing to 24-hour recovery behind a 4-hour process |
Running the workshops and the questionnaire
Questionnaires collect facts; workshops produce judgments. The practical design uses both: a short questionnaire sent in advance to collect the inventory facts (volumes, systems, staff, suppliers, deadlines, peak periods), then a 90-minute workshop per process or process group with the owner, a deputy, a technology representative and the continuity lead, in which the impact-over-time table is built live and the objectives derived in front of the people who will own them. Three rules improve the output. Use scenarios to make the time points real (“it is Tuesday at 10 a.m. and the ERP has been down since Monday morning; what has happened by now?”). Challenge every rating with the dimension’s anchor text, so that “severe” means what the methodology says and not what the owner feels. And record the reasoning, not only the scores, because the next BIA cycle will start from it and the auditor will test it. Peak periods (month end, harvest, holiday trading, payroll day) are analyzed separately where impact differs materially; a disruption at month end is a different event from the same disruption mid-month. Workshops are recorded with the owner’s reasoning for each rating, and the facilitator closes each session by reading back the derived objectives and the single points of failure so that nobody leaves surprised by what the BIA says.
Tooling, effort and cadence
A BIA for 30 to 60 critical processes is a spreadsheet-scale exercise and most organizations run it in one, with a template per process and a summary sheet of objectives and dependencies; business continuity and GRC platforms carry the same structure with workflow, reminders and the dependency links to application and vendor inventories, which is worth having once the inventory passes about fifty processes or the organization has adopted the resilience framing and needs service maps. Effort for a first full BIA in a mid-size organization is typically two to four person-months for the facilitating team plus two to three hours of each process owner’s time, concentrated in the workshops; annual reviews take a quarter of that where the triggers have been maintained and the dependency links are live. The cadence that works is an annual review of every critical BIA, a re-performance when a trigger fires, and a full inventory reconciliation each year, with the steering body approving the aggregate before the exercise program for the following year is designed from it. The order matters: objectives first, then strategies, then exercises that measure against the objectives, which is the traceability chain the BCM audit tests and the reason a BIA done in the wrong order (strategies first, objectives fitted to them) fails that audit.
Worked BIA 1: route cash collection at MidState Beverage
MidState Beverage, the three-state drinks distributor used in examples across this site, collects about $31 million a year in cash and checks through 300 route drivers from roughly 4,200 customers across twelve depots, reconciled daily at depot level on the route-accounting module of a 2013 ERP and depot spreadsheets. The process is a transaction process with a daily cycle and a cash-handling exposure.
| Element | Analysis |
|---|---|
| Impact over time | 4 hours: minor (drivers continue collecting on paper); 1 day: moderate (depot reconciliations incomplete, cash in safes above insured limits at four depots); 3 days: major (customer statements wrong, deposit delays, cash accumulation $350,000 above policy, fraud exposure); 1 week: severe (collections unreconciled across all depots, customer disputes, liquidity timing) |
| MTPD | 5 days (the point at which unreconciled cash and customer disputes become unacceptable, and insurance cover on held cash is exceeded at most depots) |
| RTO | 48 hours for the route-accounting module, leaving three days for reconciliation catch-up |
| RPO | End of previous business day: driver handhelds hold the day’s transactions and can be re-synced; paper route sheets allow reconstruction of one day |
| Minimum service level | Collections continue on paper at all depots; deposits made daily from manual listings; reconciliation deferred but documented |
| Dependencies | Route-accounting module; 380 handheld devices and their sync service; depot spreadsheets (12, one per depot, the undocumented single point of failure); armored courier contract; depot cashiers (two per depot, one at three depots); bank deposit processing |
| Consistency checks | Handheld sync service RTO 24 hours (compatible); courier contract has no continuity commitment (gap); three single-cashier depots cannot sustain manual reconciliation (gap) |
| Outcome | Objectives approved; two strategy actions: courier continuity clause and cross-training at three depots; the spreadsheets added to the application inventory and backup scope |
Worked BIA 2: a production line at Brightwater Foods
Brightwater Foods, the $180 million food manufacturer with three plants used in examples across this site, runs its highest-volume product on a single line at plant 2 that supplies two retail customers accounting together for 48 percent of sales under contracts with service-level penalties. The process is a physical production process with a weekly delivery cycle and a food safety overlay.
| Element | Analysis |
|---|---|
| Impact over time | 1 day: minor (finished goods stock covers 2.5 days of orders); 3 days: major (stock exhausted, first missed deliveries, penalty clauses triggered at day 4); 1 week: severe (both retailers’ shelves empty, delisting risk under the contracts’ continuity provisions, revenue loss about $1.2 million a week); HSE: 1 at all points (line stopped is safe) |
| MTPD | 4 days (penalty clauses and the delisting provision) |
| RTO | 72 hours to resume production at minimum level, on the line or an alternative |
| RPO | Not data-driven for the line itself; the production scheduling and traceability records carry an RPO of 4 hours because food safety traceability must be reconstructible for every batch |
| Minimum service level | 60 percent of weekly volume prioritized to the two contract customers |
| Dependencies | The line (no duplicate in the group); the plant’s utilities and refrigeration; the sole-source closure-component supplier (three weeks of stock, eight-week qualification lead time, from the third-party review); the ERP for scheduling and traceability; the maintenance management system (outside DR scope, found by the BCM audit); eleven skilled operators; cold-chain logistics provider |
| Consistency checks | Plant 1 cannot run the product (different line configuration), so the “transfer to plant 1” strategy fails the check; a co-packer qualified in advance is the feasible strategy; closure supplier stock covers the MTPD only if the supplier’s disruption is short, so a second-source qualification is a strategy action |
| Outcome | Objectives approved; strategy redesigned around a pre-qualified co-packer and a second closure source; the line’s spare-parts list reviewed against the RTO |
Worked BIA 3: payroll at Lakeshore Bancorp
Lakeshore Bancorp, the $9 billion regional bank used in examples across this site, pays about 1,900 employees semi-monthly through a cloud payroll provider, with HR data from its own system and approvals by managers. The process is a support function with a deadline-driven impact profile.
| Element | Analysis |
|---|---|
| Impact over time | Flat and minor for most of the cycle; jumps to major in the three days before pay day (employee hardship, regulatory wage-payment deadlines in several states) and severe if pay day is missed by more than a day |
| MTPD | Pay day plus one day; effectively up to 12 days mid-cycle and 2 days at the deadline, so the BIA records the deadline-relative figure |
| RTO | 24 hours when within five days of pay day; 5 days otherwise |
| RPO | Last completed pay run: the provider’s platform holds the data; the bank’s HR changes for the period can be re-entered from approved records |
| Minimum service level | Pay everyone the prior period’s net pay on time; correct differences in the next run |
| Dependencies | The cloud payroll provider (SOC 1 Type 2 reviewed per the SOC 1 guide); the HR system; the bank’s own ACH origination to fund the payroll account; two payroll specialists; manager approvals workflow |
| Consistency checks | Provider’s contracted recovery commitment (24 hours) meets the deadline-period RTO; the prior-period rerun procedure is documented and was exercised; the two specialists are the single point of failure (cross-training action) |
| Outcome | Objectives approved with the deadline-relative RTO explicitly recorded; one action (cross-training a third specialist) |
The three examples show why a single RTO column cannot carry a BIA: one process’s harm grows steadily with cash accumulation, one’s jumps at a contractual cliff, and one’s depends on the calendar. The impact-over-time table captures all three; a questionnaire asking “what is your RTO?” captures none.
The data quality problems auditors find
| Problem | How it shows | Test that finds it | Fix |
|---|---|---|---|
| Declared, not derived, objectives | RTOs in round numbers with no impact table behind them; every process “4 hours” | Ask for the impact-over-time analysis for three processes | Re-perform the analysis in workshops |
| Stale BIAs | Review dates older than the ERP migration, the acquisition or the reorganization | Compare BIA dates with the change log | Trigger-based review plus the annual cycle |
| Incomplete inventory | Processes in the organization chart or product list absent from the BIA | Reconcile the inventory | Reconciliation as a step in the methodology |
| Dependencies at the wrong level | “ERP” as the only system; no spreadsheets, no people, no suppliers | Compare dependencies with the application inventory and ask the owner what they would do without each | Six-category dependency template |
| Inconsistent objectives across dependent processes | Short RTO depending on a long one | Dependency chain analysis | Consistency checks as a methodology step |
| RPO confused with backup schedule | RPO equals the nightly backup for a process keying 2,000 transactions an hour | Ask how the day’s transactions would be reconstructed | Derive RPO from reconstruction capacity |
| Peak periods ignored | One profile for a process whose impact triples at month end | Ask about the worst day of the month | Peak-period profiles |
| No minimum service level | Recovery assumed at full capacity, making strategies unaffordable or unrealistic | Check the strategy cost against the objective | Define the minimum output and prioritize customers |
| Unapproved | No owner signature; never seen by the steering body | Approval records | Sign-off step |
Connecting the BIA to tolerances, strategies and the audit plan
The BIA connects upward, sideways and outward. Upward, where the organization has adopted the operational resilience framing, each process’s objectives sit under the impact tolerance of the important business service it delivers, and the consistency check in step 5 confirms that the chain of RTOs fits inside the tolerance; the BIA is the source of the service map’s process layer. Sideways, the BIA’s objectives are the requirements the continuity strategy must meet and the exercise program must prove, which is the traceability chain the BCM audit tests, and its dependency map is the input to technology recovery design and to the third-party program‘s criticality tiers. Outward, internal audit uses the BIA in its own risk assessment: processes with short MTPDs and single points of failure score higher on the operational factor, and a function that reads the BIA before rating its universe rates better than one that does not. The Topical Requirement workbook places the BIA within the IIA’s resilience requirements.
Template: the BIA questionnaire
Business impact analysis: [process name]. Owner and deputy: [names, roles]. Sites and teams performing it: [list]. Purpose and outputs: [what the process delivers, to whom]. Volumes and cycle: [transactions per day; daily, weekly or monthly cycle; peak periods and why]. Deadlines: [legal, regulatory, contractual, with dates]. Impact over time (rate each dimension at 1 hour, 4 hours, 1 day, 3 days, 1 week, 2 weeks, 1 month on the organization’s five-point impact scale, with the reason): financial; customer and service; regulatory and legal; operational knock-on; health, safety and environment. Peak-period profile if different: [table]. Derived objectives: MTPD [time and the dimension that fixed it]; RTO [time and the margin reasoning]; RPO [window and the reconstruction reasoning]; minimum service level [output and priority order]; work recovery time [estimate]. Dependencies (mark single points of failure): applications and infrastructure; data and records including spreadsheets and paper; people (roles, minimum numbers, key individuals, skills); sites and equipment; suppliers and outsourced services (with their recovery commitments); upstream and downstream processes. Existing workarounds: [manual procedures, their capacity and the staff trained]. Consistency checks: [upstream RTOs; shared resources; tolerance ceiling; supplier commitments]. Approval: owner [signature, date]; steering body [date]. Next review: [date or trigger].
Questions about business impact analysis
What is the difference between MTPD and RTO?
The MTPD is the time after which disruption becomes unacceptable; the RTO is the target for resuming the activity, set below the MTPD with a margin for detection, decision and work recovery. Setting them equal leaves no room for anything to go wrong.
How is an RPO decided?
From the data loss the activity can absorb: how many transactions would be lost over the window and whether they can be reconstructed from source documents within the work recovery time. Backup frequency is then set to meet the RPO, not the other way round.
How often should a BIA be updated?
Reviewed annually and re-performed whenever a trigger fires: a new system, an acquisition, a reorganization, a new supplier, a relocation or a lesson from an incident or exercise. A BIA older than the last major change is stale whatever its review date says.
Who should run the BIA?
The continuity or resilience function facilitates; process owners provide the judgments and sign them; technology and suppliers confirm dependencies and capabilities; the steering body approves the aggregate. Internal audit challenges and tests but does not own it.
What is the difference between a BIA and a risk assessment?
The BIA asks what happens if an activity is disrupted, whatever the cause; the risk assessment asks what could cause the disruption and how likely it is. Continuity planning needs both: the BIA sets the objectives, the risk assessment picks the scenarios.
How does the BIA relate to impact tolerances?
Impact tolerances are set by the board for important business services as experienced by customers; the processes delivering a service carry RTOs that must together fit inside its tolerance. The BIA supplies the process layer of the service map and the consistency check confirms the fit.
How does internal audit test a BIA?
By reconciling the inventory, re-performing the impact-over-time analysis for a sample of processes with their owners, checking derivation of the objectives, comparing dependencies with the inventories, running the consistency checks across dependent processes, and tracing objectives to demonstrated recovery in the exercise file.
Related guides
- How to audit the business continuity program — where the BIA is tested.
- Operational resilience explained — impact tolerances above the BIA.
- The Organizational Resilience Topical Requirement — the IIA’s requirements and a workbook.
- Five business continuity concepts — the vocabulary.
- Business continuity risk: complete overview — the risk the BIA scopes.
- Auditing cyber resilience — recovery capability measured.
- Backup and recovery audit — meeting the RPO.
- Third-party resilience — supplier dependencies and stock buffers.
- Fourth-party risk and vendor concentration — the dependencies behind suppliers.
- Third-party risk management program — criticality tiers from the BIA.
- SOC 1 report review — supplier recovery assurance.
- Risk assessment matrix — the impact scale the BIA uses.
- Risk appetite statements — where the unacceptable threshold is anchored.
- Risk taxonomy — the reconciliation discipline.
- Building the audit universe — the same inventory, used by internal audit.
- The annual internal audit risk assessment — using BIA outputs in audit planning.
- Internal audit and disaster recovery — the technology side.
Leave a Reply