A useful BIA pre-work questionnaire collects facts stakeholders can verify before the meeting. It may capture preliminary impacts, workarounds, and recovery needs, but those responses require live validation.
The goal is to keep the interview from becoming a data-entry session. With basic information in hand, the continuity team can challenge assumptions, resolve contradictions, and determine recovery needs.
In short
BCMMetrics practitioner guidance uses a simple distinction:
If a stakeholder can research, verify, or copy the answer from a current record, collect it in pre-work. If the answer requires interpretation, challenge, tradeoffs, cross-functional agreement, or approval, validate it live.
The questionnaire can still ask when impacts begin, how long a workaround might last, or what recovery target the stakeholder believes is needed. Label those responses preliminary so the interview can test the evidence and assumptions.
Michael Herrera has described how interviews without pre-work spent hours gathering basic information. After MHA Consulting and BCMMetrics introduced pre-work forms, the team reported shorter interviews and better information. This is practitioner experience, not a universal benchmark.
ISO/TS 22317:2021 supports a formal, documented BIA process but does not prescribe one uniform method. Adapt this boundary to the organization.
Focus each questionnaire on one defined process or service. Broad department-level requests are harder to compare or connect to recovery priorities.
| Input | Ask during pre-work | Response format | Validate during the interview |
|---|---|---|---|
| Process scope and ownership | What process or service is being assessed? What output does it produce? Who owns and performs it? | Short description, owner, participating teams | Confirm that everyone is discussing the same unit of analysis and that no material activity is hidden inside a broad label. |
| Operating profile | What are the normal operating hours, peak periods, deadlines, volumes, and minimum service commitments? | Defined fields, ranges, dates, supporting record | Test which conditions materially change the impact or recovery need. |
| People, locations, and equipment | Which roles, locations, facilities, specialized equipment, or approvals are normally required? | Categorized list with quantities where known | Distinguish required resources from preferred resources and identify concentration risks. |
| Systems and data | Which applications, data, integrations, records, and communication tools support the process? | Structured system list and data requirements | Confirm whether the named systems restore the complete process and reconcile business and IT terminology. |
| Internal and external dependencies | Which teams, suppliers, utilities, service providers, or upstream and downstream processes are required? | Dependency category, name, service provided, owner | Test whether each dependency is essential, replaceable, shared, or subject to a conflicting recovery capability. |
| Workarounds | What alternate procedure exists? Who performs it? What tools, data, approvals, capacity, and duration does it require? | Description plus known limits and last validation date | Determine whether the workaround is usable, sustainable, controlled, and sufficient to support the proposed recovery need. |
| Impact over time | What happens if the process stops across the program’s defined time bands? Who is affected, and what commitments are missed? | Preliminary impact ratings with explanation and evidence source | Challenge severity, timing, best-case assumptions, double counting, and differences between normal and peak periods. |
| Recovery inputs | What RTO, RPO, minimum service level, or recovery sequence does the stakeholder believe is needed? | Preliminary target, rationale, dependencies, assumptions | Compare the target with impact timing, workaround limits, IT capability, supplier commitments, cost, and other process priorities. |
| Evidence and unknowns | Which records support the answers? What remains unknown, and who can resolve it? | Links or document names, open item, owner, due date | Decide whether missing information affects the result and how it will be closed. |
Use the same definitions, time bands, impact categories, and response formats across comparable business areas. Software will preserve inconsistent definitions rather than correct them.
For more on suppliers, systems, and workarounds, see The BIA Inputs Most Teams Miss.
Use the live interview for questions that cannot be resolved reliably through a form:
A stakeholder may enter a four-hour RTO during pre-work. Treat it as a position to examine, not an approved result. Ask what happens before and after four hours, which dependencies must recover first, and whether the workaround changes the urgency.
For the live-session structure, use BIA Interviews: How to Get Consistent Inputs from Busy Stakeholders. For recovery-target strategy, see MHA Consulting’s RTO and RPO in Practice.
Review the submission early enough to request missing records or invite another subject-matter expert.
Flag responses when:
Consider a claims-payment process with a four-hour RTO, a provider with a 24-hour recovery commitment, and an unspecified workaround. The interview should test the dependency and workaround, identify when material impact begins, and determine whether four hours is defensible.
BIA On-Demand supports the execution side of this workflow. Current approved materials show that teams can share pre-work links, receive completion notifications, configure impact categories and scoring, capture processes and dependencies, and generate reports.
The questionnaire moves basic data gathering outside the meeting so the interview can focus on validation and recovery targets.
The software does not decide whether an answer is credible or an RTO is justified. The organization still owns the method, facilitation, challenge, approval, and follow-through.
A BIA pre-work questionnaire should focus the interview, not replace it. Collect the facts and preliminary views first. Use the meeting to challenge answers, resolve conflicts, document exceptions, and agree on next steps.