Business Impact Analysis Questionnaire: A Deep BIA Interview Guide

A strong business impact analysis (BIA) is a structured business conversation about how disruption changes over time, what level of service must be preserved, and which resources and dependencies are necessary to recover. The questions below are designed as a reusable interview/questionnaire bank. Not every question belongs in every BIA; choose the questions that help decision-makers approve realistic continuity requirements.

79-question BIA interview bank

A. Scope, service and ownership

1. What service, process or product is being analysed?
2. Who is accountable for the business outcome and who can approve recovery requirements?
3. Who receives the service: customers, citizens, employees, market participants, patients, suppliers or other services?
4. What are the normal operating hours, peak periods, cut-off times and seasonal events?
5. What outputs or transactions prove the service has been delivered?
6. Which locations, channels, legal entities and teams are in scope?
7. Which activities are explicitly out of scope or covered by another BIA?
8. What volumes define a normal day and a peak day?
9. Which service-level or contractual commitments matter during disruption?
10. What planned changes over the next 12 months could invalidate the analysis?

B. Impact over time

11. What happens after 1 hour, 4 hours, 8 hours, 24 hours, 2–3 days, one week and longer?
12. When does customer harm become material?
13. When is there a safety, health or environmental consequence?
14. When would a legal or regulatory obligation be missed?
15. When do financial losses or liquidity/cash-flow effects become material?
16. When does backlog become unrecoverable with normal staffing?
17. When does reputation or stakeholder confidence become materially affected?
18. Could disruption cascade into another critical service?
19. Are impacts different during peak day, month-end, payroll, settlement, exam, seasonal or emergency periods?
20. At what point are impacts unacceptable even if the organisation is still technically operating?

C. Recovery objectives and minimum service

21. What is the maximum tolerable period of disruption / maximum acceptable outage and what evidence supports it?
22. What service must be restored before that limit?
23. What RTO is required for minimum viable service?
24. Is the RTO shorter during peak/cut-off periods?
25. What data RPO applies to each critical data set?
26. Does transaction integrity require less data loss than a generic application RPO?
27. What is the MBCO: minimum throughput, users, locations, hours, channel or service quality?
28. Which customer groups or transactions receive scarce capacity first?
29. How long can the minimum service be sustained before another strategy is required?
30. Who approves exceptions when demonstrated capability cannot meet the requested target?

D. People and skills

31. What is minimum staffing by role and shift?
32. Which roles have unique knowledge, certification, language, approval or privileged access?
33. Who are trained alternates?
34. Can work be redistributed to another team or location?
35. What remote-work capability is required?
36. What is the maximum realistic absenteeism assumption?
37. Which roles are shared with other critical services and could become a conflict during enterprise-wide disruption?
38. What training or exercise evidence shows alternates can perform the work?

E. Facilities and physical resources

39. Which sites are required and what makes them usable?
40. How many alternate seats are genuinely available during a regional disruption?
41. Which equipment, secure rooms, production lines, lab equipment or paper records are location-specific?
42. What power, cooling, transport, access control or safety dependencies exist?
43. Can the activity operate remotely, relocate, split, or be performed by another site?
44. What physical stock, consumables, spare parts or specialist tools are needed and for how long?

F. Technology, data and information

45. Which applications are essential to minimum service and in what sequence?
46. Which shared services are hidden dependencies: identity, DNS, network, telephony, email, integration platform, data warehouse, printing?
47. Which databases, files, records or reference data are authoritative?
48. How much data loss can be tolerated for each data type?
49. Which interfaces or APIs are required before the business service is usable?
50. Which manual records must be captured during technology loss and later reconciled?
51. Are emergency credentials, MFA devices, certificates, keys or privileged accounts required?
52. What has the latest DR test actually demonstrated?

G. Suppliers and external parties

53. Which third parties are essential within the RTO?
54. What service do they provide and which of our products/services depend on it?
55. What contractual recovery commitments exist?
56. Have those commitments been tested or evidenced?
57. Which subcontractors, cloud providers, telecom providers or utilities create concentration risk?
58. Is there an alternate supplier and how long would activation/onboarding take?
59. What customer data or access does the supplier hold?
60. What happens if the supplier fails at the same time as our primary site/system?
61. Are exit, data return and emergency-support arrangements practical?

H. Workarounds and capacity

62. Is there a manual or alternate process?
63. What volume can it handle per hour/day?
64. What controls are lost or changed when using the workaround?
65. What new fraud, privacy, safety, error or reconciliation risks appear?
66. How long can the workaround operate?
67. What data must be captured for later re-entry?
68. What triggers stopping the workaround?
69. Has the workaround been exercised with realistic volume?

I. Interdependencies and recovery sequence

70. Which upstream service must recover first?
71. Which downstream service is blocked by this activity?
72. Are recovery objectives mutually consistent across dependencies?
73. Does another critical service compete for the same people, seats, network, supplier or DR capacity?
74. Which dependency has the slowest demonstrated recovery time?
75. What is the minimum set of dependencies needed for MBCO versus full service?
76. Where is there a single point of failure or concentration?
77. Who owns each cross-functional dependency?

J. Evidence, validation and approval

78. What data supports financial/customer/volume statements?
79. Which obligation or policy supports regulatory/legal impact?
80. What exercise or incident evidence validates the assumptions?
81. What recovery test proves technology can meet the requirement?
82. What supplier evidence is current?
83. Which gaps exist between target and demonstrated capability?
84. Who owns each gap and by when?
85. Who reviewed and approved the BIA?
86. What event triggers an early review?
87. When is the next scheduled review?

Impact-over-time worksheet

The cells should contain evidence-based statements, not generic scores alone. A 1–5 matrix can help prioritise, but retain the narrative describing what actually happens and when. That narrative supports recovery-objective approval and makes future reviews easier.

Capability gap: target versus demonstrated reality

BIA quality rules

• Use a consistent impact taxonomy but allow service-specific evidence.
• Separate maximum tolerable disruption from the recovery target; leave room for detection, decision, recovery and stabilisation.
• Record different RPOs for different data when necessary.
• Connect every critical dependency to an owner and evidence source.
• Treat the BIA as a decision record: include approver, assumptions, gaps and change triggers.
• Review after material change, significant incident/exercise or at the organisation’s scheduled interval.
• Do not use BIA scores as a substitute for management judgement where safety, law or vulnerable customers are involved.

Official references and further reading

• ISO/TS 22317:2021 — International guidance for implementing and maintaining a formal documented BIA process; it does not prescribe one uniform process.
• ISO 22301:2019 — BCMS requirements.
• ISO 22313:2020 — Guidance on applying ISO 22301.
• NIST SP 800-34 Rev. 1 — US federal IT contingency-planning guidance that includes BIA as part of the contingency planning process.

BIA interview worksheet: impact by dimension and time

BIA calculation example: do not let a score hide the reasoning

Suppose an order-fulfilment service normally processes 12,000 orders per day. A four-hour outage can be absorbed with backlog overtime; after 12 hours, same-day shipping commitments fail; after 24 hours, priority customers and revenue recognition are materially affected; after 48 hours, warehouse space and carrier schedules constrain recovery. The BIA might therefore set an MTPD/MAO of 24 hours, an RTO of 8 hours and an MBCO of 40% of normal priority-order capacity. Those values should be approved together because an eight-hour RTO is meaningless if the workaround can process only 5% of the urgent queue.

Dependency interview: ask “what is required to deliver the service?”

BIA challenge questions for reviewers

• What fact makes this service more time-critical than the next service?
• If every process asks for a two-hour RTO, which ones actually receive scarce recovery capacity first?
• Does the application RTO support the business RTO after infrastructure, interfaces and validation are included?
• Does the RPO reflect business data-loss tolerance or only the backup schedule?
• Can MBCO be delivered with the minimum people and technology listed?
• Which recovery requirement is not currently achievable?
• Which third party is a single point of failure?
• Which manual workaround introduces fraud, privacy, safety or reconciliation risk?
• What seasonal/peak day changes the answers?
• What evidence would cause the owner to change the approved RTO or MBCO?