The BCI Horizon Scan Report 2025 found that 63.6% of BCM professionals cite cyber security as a top concern over the next five to ten years. Most of the disruptions those professionals are planning for depend on recovery assumptions that trace back to a single source: the BIA interview. Get those conversations right and the whole downstream program has solid foundations. Get them wrong and the RTOs, RPOs, and dependency maps built on them are guesswork.
The problem is that most BIA interviews are not designed as conversations. They are sent as spreadsheets, answered in twenty minutes by a department head with other priorities, and returned with half the fields blank or filled with placeholders. The BCM manager inherits the job of chasing, interpreting, and normalising what comes back. That is not an interview. It is a data collection exercise that does not collect data.
This guide covers what to ask in a BIA interview, how to structure the conversation so process owners give useful answers, and what to do when the answers are vague. For a deeper look at how automation changes the collection side of this problem, the guide to BCM software with automated BIA data collection covers the mechanism in full.
Why most BIA interviews produce bad data
A business impact analysis needs four things from every process owner: what the process does, how long it can be down before serious harm occurs, what it depends on, and who is accountable. Those four things sound simple. Getting them consistently from 50 or 100 process owners is the hard part, and most programs underinvest in the question design that makes consistency possible.
The spreadsheet problem
Sending a spreadsheet template is the default collection method in most programs, and it produces the default output: inconsistent, partial, and optimistic. A process owner filling in a template alone has no prompt to elaborate, no follow-up on a vague answer, and no signal that writing 'IT systems' in the dependencies column is not useful. The BCM manager gets back whatever the respondent thought was sufficient, which varies enormously across departments.
The deeper issue is that a template treats BIA collection as a data entry task. It is not. It is a structured conversation where the value comes from probing, not from the initial answer. A process owner who says their RTO is 24 hours might mean 24 hours before there is any customer impact, or 24 hours before the process is legally required to be running, or 24 hours because that is what they put last time. The difference matters enormously for recovery planning. A spreadsheet cannot ask which one they mean.
The engagement problem
Process owners disengage from BIA collection for a predictable reason: the questions feel abstract and the effort feels one-sided. They are being asked to estimate the consequences of something that has not happened, for a plan they will probably never read, in a format designed for the BCM team rather than for them. The disengagement is rational. The fix is not chasing harder. It is designing the conversation so that answering well feels useful to them.
The BCM managers who get the best BIA data ask concrete, scenario-based questions. Not 'what is your RTO?' but 'if this process went down on a Monday morning and you could not restart it until Thursday, what would break first?' That question lands differently. It is specific, it is imaginable, and it usually surfaces dependencies and escalation paths that the abstract version misses entirely.
Business impact analysis interview questions by category
The questions below are grouped into five categories that mirror the structure of a well-run BIA: process overview, criticality and tolerances, dependencies, people and escalation, and vendor and supplier reliance. Run them in this order. Each category builds on the last, and the dependencies section is much more productive once the process owner has already described what the process does and how critical it is.
Category 1: Process overview
These questions establish shared understanding before anything is measured. Do not skip them even for departments you know well. Process owners often describe their own processes differently to how the BCM team has documented them, and those differences matter.
- Can you describe what this process does and who it serves internal teams, external customers, or regulators?
- What does a normal day look like for this process? What are the inputs, the outputs, and the handoffs?
- How many people are directly involved in running this process?
- Is this process seasonal or event-driven? Are there periods where it is more critical than usual?
- Has this process changed significantly in the last 12 months new systems, new team members, new vendors?
Category 2: Criticality and tolerances
This is where most BIA interviews produce the weakest data, because the questions are usually asked in the abstract. RTO and RPO mean nothing to most process owners until you attach them to a concrete scenario. Frame every tolerance question as a situation, not a measurement.
- If this process went down right now and could not be restarted for 4 hours, what would break first?
- At what point would a customer, regulator, or senior leader notice the process was down?
- Is there a point of no return a time after which a simple restart is not enough and something else has to happen?
- How much data could this process afford to lose? If we restored from a backup that was 24 hours old, what would be missing that cannot be recreated?
- Are there regulatory or contractual deadlines that this process must meet regardless of a disruption?
- If this process were running at 50% capacity, would that be acceptable for a short period? What does 50% look like?
Category 3: Dependencies
Dependencies are the section most likely to be incomplete in a spreadsheet-based BIA. Process owners know their immediate inputs but often underestimate indirect dependencies the system that feeds the system they actually use, or the team that validates a step they assumed was automatic. Ask at multiple levels.
- Which internal systems does this process rely on directly? What would happen to this process if each of those systems was unavailable?
- Which other teams or departments does this process depend on, even indirectly?
- Which external vendors or suppliers are involved? Are any of them single points of failure?
- Are there physical dependencies buildings, equipment, specific locations — that the process cannot run without?
- If you had to run this process from a different location or with a different team, what would stop you?
- Are there any dependencies that are informal things that work because of a specific person's knowledge or relationships, not because of a documented process?
Dependency data collected here feeds directly into AI-assisted dependency mapping. The quality of the map is determined entirely by what comes out of this section of the interview. Named systems and named vendors are usable. 'IT infrastructure' and 'our suppliers' are not.
Category 4: People and escalation
People dependencies are the most underreported category in most BIAs. Process owners tend to describe their processes as more system-dependent than they are, because systems feel like legitimate dependencies and individual knowledge feels like an embarrassing single point of failure. Ask directly.
- Who is the primary owner of this process and who would cover if they were unavailable for two weeks?
- Are there tasks in this process that only one person knows how to do? Is that knowledge documented anywhere?
- Who has the authority to declare that this process needs to invoke a continuity plan?
- Who would you call first if this process went down at 2am on a Sunday?
- Are there key external contacts at vendors, regulators, or partner organisations who would need to be notified if this process was disrupted?
Category 5: Vendor and supplier reliance
Vendor dependencies are a separate category from system dependencies because the failure mode is different. A system going down is an IT recovery problem. A vendor going out of business, being acquired, or refusing to provide service during a sector-wide incident is a supply chain problem with different recovery options and different notification requirements.
- Which vendors or suppliers are involved in this process, and what specifically do they provide?
- Do you have a secondary supplier for any critical inputs, or is each vendor a single source?
- What are the contractual obligations on each vendor for uptime and response time?
- If a key vendor was unavailable for a week, what would you do? Has that option ever been tested?
- Are any of your vendors themselves reliant on a small number of sub-vendors or cloud providers that could create a common-cause failure?
What to do when the answers are vague
Vague answers are the rule, not the exception. Most process owners have never been asked to think about their work through a recovery lens, and they default to safe, approximate answers. The job of the interviewer is to convert those approximations into something usable without making the process owner feel interrogated.
| Vague answer | What it usually means | Follow-up question |
|---|---|---|
| 'A few hours' | No specific measurement has ever been done | 'If it went down now, when would your manager ask you about it?' |
| 'IT systems' | They mean one or two specific systems but haven't named them | 'Which system would you check first if something went wrong?' |
| 'The usual team' | There's a specific person they rely on but don't want to single out | 'If that team was at a conference for a week, who would cover?' |
| 'We'd manage' | They haven't thought through the scenario | 'What's the one thing that would make managing impossible?' |
| 'Our suppliers' | They mean one specific vendor they're dependent on | 'Which supplier would you call first?' |
| 'We follow the standard process' | There is no documented backup process | 'Where is that process documented, and when was it last tested?' |
The common thread is that vague answers are usually accurate at a higher level of abstraction than you need. The follow-up is not a challenge, it is a zoom: you are asking the same question at the level of specificity that makes it useful. Process owners almost always have the information you need. The interview design determines whether you surface it.
Who to interview for a BIA
The standard answer is process owners, but that category is wider and more specific than it sounds. A process owner for BIA purposes is the person who would be accountable if the process failed and the person with the operational knowledge to describe how it actually runs. Those are often different people, and you may need both.
- Department heads: set the criticality context and own the escalation path. Often don't know the operational detail.
- Process leads or team leads: know how the process actually works day to day, including the informal dependencies and single points of knowledge.
- IT leads for systems that support critical processes: the dependency section of any process interview should be validated by someone who understands the underlying systems.
- Vendor relationship owners: for processes with significant third-party dependencies, the person who manages those relationships knows things about vendor capacity and contractual obligations that the process owner may not.
- Finance or legal: for processes with regulatory or contractual deadlines, someone with that context should review the tolerance assumptions before they are finalised.
For DORA-regulated organisations, DORA Article 11 requires that critical or important functions are identified and that ICT dependencies are mapped and maintained. The interview list for those functions needs to include IT asset owners, not just business process owners. The two views of the same function are often significantly different.
Scaling BIA interviews to 50 or more departments
The interview questions above work for any BIA program. The constraint they run into is the one every lean BCM team hits: there is only one of you, and there are 50 departments. Running these interviews sequentially, even at 45 minutes each, is a six-week project that starts going stale before it finishes.
The BCM managers who have solved this problem at scale have done it by separating the question design from the question delivery. The questions above can be asked by an AI agent running parallel conversations across every department simultaneously. The agent follows up on vague answers in real time, in the process owner's language, and returns structured output: named RTOs, RPOs, dependencies, and owners, not free text.
That is what Scott, Fortiv's AI interview agent, does. The BCM manager designs the question set, sends the interview links, and reviews the structured output. The collection itself runs without them. For a full explanation of how this works in practice, the guide to BCM software with automated BIA data collection covers the mechanism, what structured output looks like, and how it compares to the spreadsheet and survey approaches.
The question design still matters just as much with automation. An AI agent asking 'what is your RTO?' gets the same vague answer a spreadsheet does. The concrete, scenario-based questions in this guide are what produce usable data, whether the conversation is run by a BCM manager or an AI agent.
Next step
The questions in this guide are a starting point. Every program adapts them to its own sector, regulatory context, and organisational culture. The ones that stay consistent across every good BIA interview are the scenario-based criticality questions and the dependency follow-ups. Those are the ones that surface what a spreadsheet cannot.
If the constraint you are running into is less about question quality and more about the time it takes to run these conversations across a large organisation, book a demo with Fortiv to see how Scott conducts a structured BIA interview. Or start with the BCM software buyer's guide to understand what to look for in a platform before evaluating options.
Related articles
What is a business impact analysis?
BCM software with automated BIA data collection
AI in dependency mapping: a practitioner's guide
