BIA interview guide

What this guide is for

This guide helps you prepare and run a business impact analysis (BIA) interview. It is written for the person leading the interview: business continuity coordinator, risk manager or consultant. It can be used on its own, without prior training, in any organisation.

A BIA measures how the impacts of a disruption build up over time, so that priorities and recovery objectives can be set. The interview is its main source of information: it is where the people who run an activity describe what they deliver, what they depend on and what happens when everything stops.

Four terms to master

• Maximum tolerable period of disruption (MTPD): the length of time after which the impacts of a disruption become unacceptable.
• Recovery time objective (RTO): the target time for resuming an activity or a resource; always shorter than the MTPD, to keep a margin.
• Recovery point objective (RPO): the maximum amount of data you are prepared to lose, expressed as time.
• Minimum business continuity objective (MBCO): the reduced but acceptable level of service to be maintained during the disruption.

What the interview does, and what it does not do

The interview gathers facts and reasoned judgements: what the activity delivers, for whom, at what pace, with which resources, and from what point a stoppage becomes unacceptable. It results in proposed values for the MTPD, RTO, RPO and MBCO.

It does not set these objectives: senior management approves them after comparing activities. Nor is it a risk assessment (you are not estimating the likelihood of an outage or a fire), an IT audit or an appraisal of the team. Saying so at the outset prevents a great many defensive answers.

Who to interview

Interview the person who runs the activity day to day: team leader, department head, process owner. They know what happens on a busy Monday, what customers chase and which workarounds exist. Where useful, add:

• an experienced operator, who knows the tasks, the tools and the unwritten workarounds;
• the person who deals with the activity’s customers, to pin down their expectations and the contractual commitments;
• a finance contact, to quantify financial impacts using the same thresholds for every activity.

Two or three participants is a good format. Beyond that, the interview turns into a meeting and the answers drift towards the most senior person in the room.

Who not to interview alone

• A member of senior management on their own: their view sheds light on what is at stake, rarely on concrete timings and dependencies. Cross-check with the people on the ground.
• The IT manager on their own: they know the systems, not the business consequences of losing them. If they set the objectives, those objectives will reflect what IT can do rather than what the activity needs.
• A newcomer: they know neither the history of incidents nor the peaks.
• The owner of an activity who is also the business continuity coordinator: have their answers reviewed by a peer or by senior management, to avoid self-assessment.

Preparing the interview

Documents to gather

• the organisation chart and the list of in-scope activities, with their owners;
• any description of the activity: procedure, job description, process map;
• commitments to customers: contracts, service levels, promised lead times;
• volumes per day, per week and over the year;
• the calendar of deadlines: closings, returns, payroll, campaigns, seasonal peaks;
• the list of applications and suppliers known to support the activity;
• reports of past incidents.

Duration and format

Allow 60 to 90 minutes. Any shorter and you will not have time to work through the impacts horizon by horizon; any longer and attention drops, so it is better to schedule a second session. Attend as a pair if possible: one leads, the other takes notes.

Sending material in advance

A week beforehand, send the interviewee the purpose of the interview in three lines (making clear that it is neither an audit nor an appraisal), the question blocks below, the impact scoring grid and a request for data: volumes, contracts, incidents.

Do not send a questionnaire to fill in instead of holding the interview: written answers are almost always shorter, more cautious and less usable than a conversation in which you can follow up.

Running the interview, block by block

Start with five minutes of framing: purpose, duration, how the answers will be used, the approval still to come. Then take the blocks in order: they move from the concrete (what the activity delivers) to the abstract (the objectives), which makes answers more reliable. For each block, the list gives the questions to ask and the paragraph that follows explains what you are trying to obtain.

1. The activity and what it delivers

• What does your activity deliver, and to whom: external customers, other departments?
• What would be visible from outside if it stopped tomorrow morning?
• Which downstream activities depend on what you produce?

What you are looking for: a description of the activity in terms of its output, in one or two sentences, and the list of those who receive it. You protect a product or service delivered, not a box on the organisation chart.

2. Volumes and peaks

• How many units do you handle on an average day: orders, cases, calls?
• What is the busiest day or hour, and with what volume?
• What is the minimum headcount needed to handle the normal flow? And a flow reduced to essentials?

What you are looking for: orders of magnitude rather than accounting precision, and above all the minimum headcount. These figures will be used to size the minimum level of service and the continuity solutions.

3. Seasonality and deadlines

• Are there periods when a disruption would be much more serious: month end, closing, campaign, season?
• Which external deadlines cannot be moved?
• Conversely, are there quiet periods?

What you are looking for: criticality that varies over time. Payroll may tolerate several weeks of disruption mid-month but only a few days around pay day. Keep the least favourable period: it is the one used to assess impacts.

4. Impacts over time, by criterion and by horizon

• If the activity stops completely, what happens after 4 hours? After 24 hours? After 3 days? After a week?
• For each horizon: what are the consequences for customers or service users, financially, contractually or in regulatory terms, for reputation, internally?
• What is your basis: a written commitment, an incident you lived through, an estimate?

What you are looking for: a score from 1 to 4 for each criterion and horizon, using the grid below, backed by a fact. Assume a complete stoppage at the worst plausible moment, whatever the cause: the interview is not about scenarios.

5. Maximum tolerable period of disruption (MTPD)

• Looking at the table we have just filled in, from what point does the stoppage become unacceptable?
• Does part of the activity become unacceptable sooner than the rest?

What you are looking for: an MTPD derived from the impacts rather than announced up front. It lies between the last horizon at which every score is still below 4 and the first at which a score reaches that level; refine it within that interval. If a particular flow has a shorter threshold (urgent requests, priority customers), record two separate MTPDs.

6. Recovery time objective (RTO)

• By when would you need to have resumed, at least at the minimum level, to stay below that threshold with a margin?
• How long does it take to restart the activity once the resources are back?

What you are looking for: an RTO shorter than the MTPD, with an explicit margin covering detection, decision and restart. Do not ask “how quickly can IT bring the system back?”: that is a question about actual recovery capability, which comes later.

7. Recovery point objective (RPO)

• If your data came back as it was an hour ago, last night or last week, what would you lose?
• Could you rebuild what is missing, and from what?

What you are looking for: the acceptable data loss, expressed as time, for each important data set. The RPO is often shorter than IT assumes, because some entries, such as orders taken by telephone, leave no other trace.

8. Minimum business continuity objective (MBCO)

• During the disruption, what absolutely must continue to be delivered, and to whom?
• Which customers, products or flows could wait?
• What share of the normal flow would be acceptable for a few days?

What you are looking for: a concrete definition of the reduced service, with named priorities and a quantified level. An MBCO of 100% of everything is not an MBCO: it shows that the question of priorities has not been settled.

9. Existing degraded modes

• What do you do today when a tool or resource is missing?
• Is this workaround written down? Tested? Known to whom?
• How long could it hold, and with what limitations?

What you are looking for: an inventory of the workarounds actually used, including informal ones, and how long they can last. A degraded mode known to one person only is fragile; it is often a continuity solution in the making that simply needs to be formalised.

10. Dependencies by category

• People: which skills are essential, and how many people have them?
• Premises: can the activity be carried out elsewhere, or remotely?
• IT and data: which applications, networks, workstations?
• Suppliers: which providers are indispensable, and is there an alternative?
• Equipment: which machines, terminals, vehicles?
• Information: which documents, lists or contacts must be to hand?

What you are looking for: a list of dependencies by category, noting for each whether an alternative exists. Spot single points of failure, those resources with no alternative whose loss stops the activity. You do not deal with them during the interview: you pass them on to the analysis of dependencies and solutions.

11. Data and reconstruction

• Where is the data needed to work in degraded mode?
• If the main system is lost, do you have a copy you can consult outside it?
• After recovery, how long would it take to re-enter and check what was done during the outage?

What you are looking for: a way to tie the RPO to reality. Is critical data accessible outside the system? Is re-entry counted in the time needed to return to normal? Reconstruction is often the hidden cost of a disruption.

12. Lessons from past incidents

• What was the last serious disruption you experienced, and how long did it last?
• What did you do, what was missing, whom did you inform?
• What took longest to catch up on?

What you are looking for: facts that confirm or correct the scores and the proposed objectives. An incident you lived through is worth more than an estimate: it also reveals actual recovery capability, the capability that has been demonstrated, as distinct from the objective.

Impact scoring grid

Use the same grid for every activity in scope: that is what makes the results comparable. Have the level descriptions, especially the financial thresholds, approved by senior management before the first round of interviews.

Grid to copy for each activity: one score from 1 to 4 per cell, with the supporting fact noted alongside.

Adapt the horizons if your activity runs at a different pace, but keep the same ones across the whole scope.

Avoiding bias

Over-declaration

Every manager has good reasons to consider their activity critical: they know it well, they see its consequences, and they fear that a low score will be read as a lack of importance. A frequent result: every activity shows an MTPD of 4 hours and the BIA can no longer prioritise anything.

To avoid this, explain that criticality measures how quickly a stoppage becomes serious, not the value of the activity or of the team. Ask for a fact behind every score of 3 or 4, ask “what happened last time?”, and compare results across activities when consolidating.

Confusing important with urgent

An activity can be essential over the year and still tolerate several days of disruption: invoicing is the classic example. Conversely, a modest activity becomes intolerable within hours if a short commitment depends on it. Always bring the question back to time: “what happens after 24 hours?” rather than “is this important?”.

An RTO set by IT

When the RTO is derived from what IT can restore (“the backup takes 8 hours to restore, so the RTO is 8 hours”), the objective simply mirrors existing capability and the gap disappears by design. The order must be reversed: the business states its need on the basis of impacts, and that need is then compared with actual recovery capability, demonstrated by a test, an exercise or a real incident. Involve IT in consolidation, not in setting the objectives.

Other common traps

• Reasoning by cause (“what if there were a fire?”): the interview is about the impacts of a stoppage, whatever its origin.
• Taking the average instead of the worst plausible moment: disruptions also happen on peak days.
• Forgetting the catch-up: getting resources back does not mean getting back to normal.

Reporting back and approval

1. Within three working days, write up the interview record and send it to the interviewee for correction. Distinguish what they said from what you propose.
2. Incorporate their corrections, keeping a record of any points of disagreement.
3. Consolidate all records for the scope into a single table, with the same grid and the same horizons. Correct obvious inconsistencies: two linked activities cannot have incompatible MTPDs.
4. Present the summary to senior management, who approve the MTPDs, RTOs, RPOs and MBCOs and settle disagreements. This approval is essential: the objectives commit resources and reflect an accepted level of risk.
5. Tell the interviewees which objectives were adopted and what comes next: dependency analysis, solutions, plan.

Example of a completed record: Norvane

Norvane is a fictitious organisation, created for the academy’s introductory course and its resources; any resemblance to an existing company is coincidental. A regional distributor of medical and hygiene consumables, it employs 140 people, operates a single warehouse and serves some 1,400 business customers, including 5 private clinics.

The interview was led by Thomas Weber, Operations Manager and business continuity coordinator, with the picking team leader and Julie Moreau, Customer Service Manager. Because Thomas Weber also runs this activity, the record was reviewed by Sofia Benali, Finance and Administration Director.

Scores for the overall flow. The clinics’ urgent flow is scored separately: level 4 from 4 hours, because of the contractual commitment to deliver within 4 hours.

Reading the table: level 4 is reached between 24 hours and 3 days. The MTPD for the overall flow was therefore set at 48 hours, and the RTO at 24 hours to keep a margin.

Final checklist

Before the interview

• The grid thresholds, especially the financial ones, have been approved by senior management.
• The question blocks and the grid were sent a week in advance.
• Volumes, contracts and incident reports have been gathered.

During the interview

• The activity is described by what it delivers and to whom.
• Every score of 3 or 4 is backed by a fact.
• The MTPD is derived from the impacts; the RTO is shorter, with an explained margin.
• The RPO is expressed as time for each important data set.
• The MBCO names priorities and a quantified level.
• All six categories of dependency have been reviewed and single points of failure are flagged.
• At least one past incident has been discussed.

After the interview

• The record has been reviewed and corrected by the interviewee.
• The objectives have been consolidated with those of other activities and approved by senior management.
• Single points of failure have been passed on to the dependency analysis.