Charlie Maclean-Bristol, Deputy Resilience Director at Databarracks, shares lessons from more than 25 years of conducting BIAs and RAs. He outlines the 7 steps he uses to plan, conduct and report on a BIA and RA.
A business impact analysis (BIA) and risk assessment (RA) are the foundations of business continuity, yet in my experience, many organisations do not do them well.
Identifying your activities and deciding which to recover first and which can wait is a key part of the BIA and of the business continuity process. Get the BIA wrong and you could recover parts of the organisation too slowly after an incident, increasing the impact, or set unnecessarily short recovery targets, leading to unnecessary expenditure. The RA identifies threats to the organisation and vulnerabilities, including single points of failure, which could have a significant impact. By identifying single points of failure, you can take appropriate steps to mitigate them.
Too often, I have seen BIAs and RAs conducted badly, without capturing the key information that good practice says they should cover. I have also seen a BIA conducted in isolation as a one-off exercise, never updated, with the information left to moulder in a spreadsheet rather than inform business continuity planning. For me, this is a waste of time unless all you want to do is tick the box to say the BIA and RA have been completed.
In this blog, I aim to outline the key steps involved in planning, conducting and reporting on a BIA and RA. Whether you are new to the profession or have been doing this for some time, you can use these steps as a framework for developing your own process. I have focussed on what should be done, rather than how to do it. The approach may differ in parts from the BCI’s Good Practice Guidelines 7.0.
Step 1: Define the scope of the BIA and RA
The first step is to establish which parts of the organisation the BIA and RA will cover and do the groundwork before the interviews begin. This is your opportunity to understand the organisation you are working for. Doing your background research means you arrive at the interviews with a basic understanding of the organisation and how it works. You should not be using valuable interview time to discover information you could have found beforehand.
Outcomes from step 1:
- Organisational scope agreed: Define the organisation, business units, departments, locations and other areas included in the assessment. If the whole organisation is not in scope, decide how to consider dependencies on internal departments, such as IT, which sit outside your scope. Do you treat them as third-party suppliers?
- Organisation sufficiently understood: Understand what the organisation does, how it is structured, its ownership, locations and how it operates. The better you understand the organisation, the better your BIA will be.
- Products and services identified: Establish the main products and services delivered to customers and other interested parties.
- Organisational structure understood: Obtain and review the organisation chart, departments, functions and significant reporting relationships. This will help you identify who to invite to the BIA and RA interviews. This could also include parent organisations, owners, boards or government departments the organisation is managed by.
- Operating context understood: Understand the principal stakeholders, outsourced activities, important partnerships and the environment in which the organisation operates. Research the key risks in its industry, as well as incidents affecting the local areas in which it operates.
- Existing documentation identified: Establish what BIAs, plans, risk information and continuity arrangements already exist. Some organisations say they have nothing, and then you discover work that has been forgotten about or carried out in pockets across the organisation.
- Future changes identified: Consider significant reorganisations, acquisitions, new systems, locations or other known changes that could affect the assessment. If changes are imminent, you may decide to hold off. Alternatively, you may proceed to meet other deadlines, knowing you will need to revisit the findings soon after.
Step 2: Set priorities and values with top management
Conduct a workshop with top management to understand the organisation’s strategic context and the outcomes it cannot afford to lose. This is also where you agree the impact criteria, or values, you will use throughout the BIA.
Outcomes from step 2:
- Strategic context established: Understand the organisation’s strategy, objectives and any significant changes that may influence its resilience requirements in the near future.
- Critical outcomes identified: Determine which products, services, outcomes or capabilities top management considers essential. Do they have a view on how long the organisation can tolerate their loss, or when they need to be recovered?
- Impact values agreed: Agree the impact categories you will use to assess disruption. These could include life safety, reputation, regulatory breaches, customer service and financial impacts, amongst others. For each of these, there should be a definition of what an “unacceptable impact” looks like.
- Strategic risks identified: Capture top management’s principal resilience concerns, the vulnerabilities and risks facing the organisation.
- Validation arrangements agreed: Establish whether top management will review, validate and ultimately approve the BIA findings.
Step 3: Gather supporting information
Gather information about the organisation’s resources and dependencies before the detailed BIA interviews begin. This allows you to pre-populate information and avoids asking every department for details that should already be available centrally. It also gives you a common list of names. You may otherwise find that different departments use different names for the same application.
Not all this information will be available, but use what you can find to improve your understanding of the organisation and inform the BIA and RA discussions.
Outcomes from step 3:
- IT information gathered: Obtain the agreed application list, details of system ownership and relevant technology information. This could include agreed recovery time objectives (RTOs) and recovery point objectives (RPOs), as well as whether systems are hosted internally or provided by third parties as Software as a Service (SaaS).
- Supplier information gathered: Obtain information on key suppliers, outsourced services and other important third parties.
- Building information gathered: Obtain a list of sites, facilities, specialist facilities within buildings and which departments or parts of the organisation operate within them.
- People information gathered: Obtain staffing numbers, locations, organisational structures and details of relevant specialist roles.
- Resource information gathered: Obtain lists of equipment, utilities, materials, vehicles, consumables and specialist resources.
- Risk information gathered: Obtain relevant corporate risk registers, information on risk appetite, details of the matrices used in risk, known vulnerabilities and previous RAs.
- Obligations information gathered: Obtain relevant legal, regulatory, statutory and contractual information. Procurement and compliance departments may be able to provide this.
- Incident information gathered: Review relevant previous incidents, near misses and known resilience concerns.
- Existing resilience information gathered: Obtain existing BIAs, continuity plans, recovery arrangements and details of improvement work.
Top tip: Make sure every piece of information you collect during the BIA has a purpose and informs the organisation’s planning and recovery. Don’t collect information for the sake of it.
Step 4: Plan for the BIA and RA
Plan the BIA and RA so that you capture the right information, speak to the right people and cover all parts of the organisation within scope. Participants need to be prepared, and you need to allow enough time for the discussions, write-up and review.
Outcomes from step 4:
- Assessment population confirmed: Identify every department, function or operational area requiring assessment and decide at what level within the organisation you will conduct the BIA and RA.
- Type of BIA: Decide whether you will conduct an activity-based or process-based BIA.
- Participants correctly identified: Select people who understand the activities, deadlines, impacts, resources and dependencies being assessed.
- Assessment approach agreed: Confirm whether you will gather information through interviews, workshops or a combination of the two.
- Pre-meeting information gathering: Decide whether to use a workbook, questionnaire or AI tool to gather information before conducting the BIA.
- Devise the interview or workshop sheet: Define the information you need to capture in the interviews.
- Interview programme established: Invite the participants to the interviews and workshops.
- Participants appropriately briefed: Ensure those taking part understand the purpose of the assessment and the key terminology. This could be done by email, training with slides and voiceover, or a short workshop (online or face-to-face) to explain what preparation is required, the purpose of the BIA and RA, and the questions they will be asked.
- Information pre-populated: Add information already obtained from IT, HR, Facilities, Procurement and other central sources, as well as any workbooks completed before the interview or workshop.
- Agree the data formats and locations: Agree on the format in which the data will be held (e.g. in Excel or a database) and where the data will be stored. Agree whether individual departmental BIAs and RAs will be stored or whether the data will be collated.
- Feedback from interviews: Agree whether you will send each interview’s findings back to the interviewee for review and sign-off.
Step 5: Conduct the BIA and RA
Conduct interviews or workshops to understand what each area does, the consequences if its activities stop, how quickly it needs to recover, and the resources it requires. The RA should identify threats and vulnerabilities that could prevent those activities from being carried out or make the resources they depend on unavailable.
Outcomes from step 5:
- Activities or processes identified: Establish the main activities or processes undertaken by each business area without breaking them down into unnecessary detail.
- Disruption impacts assessed: Assess how the consequences of an activity being unavailable develop over time, using the agreed values.
- MTPDs determined: Establish when disruption becomes unacceptable and record the reasoning behind each maximum tolerable period of disruption (MTPD).
- RTOs determined: Establish the target recovery time required to prevent unacceptable impact.
- MBCOs determined: Define the minimum acceptable operating level required during recovery, expressed as the minimum business continuity objective (MBCO).
- Application RTOs and RPOs determined: Document the requested RTOs and RPOs for each application used.
- Variation considered: Identify seasonal, cyclical, deadline-driven or other periods when recovery requirements change.
- Resources identified: Capture the premises, suppliers, people and other resources required to perform each activity.
- Department dependencies: Identify department dependencies on each other.
- Recovery resources identified: Establish the staffing and other resources needed to recover each activity.
- Risks and vulnerabilities assessed: Identify credible threats, vulnerabilities, single points of failure, existing controls and areas of exposure.
- Uncertainty clearly recorded: Record assumptions, missing information and disagreements that need to be checked or resolved later.
Step 6: Document and analyse
Write up the findings from the interviews or workshops and share them for sign-off. Bring the information together so you can compare recovery requirements, identify shared dependencies and establish where current arrangements fall short.
Outcomes from step 6:
- Individual findings documented: Complete the BIA and RA record for each business area and go back to the interviewee for any missing information. Send the findings back to the relevant person for confirmation and sign-off, where agreed.
- Information consolidated centrally: Bring the assessments together into one agreed set of data for the organisation.
- Recovery priorities challenged: Review unusually short, long or conflicting recovery requirements.
- Dependencies formally validated: Check significant shared dependencies, concentrations and single points of failure.
- IT gaps reviewed: Check business application RTO and RPO requirements against IT’s technical recovery capability.
- Risk findings reviewed: Review significant vulnerabilities, risk exposures and proposed mitigation measures.
- Capability gaps agreed: Establish where existing arrangements cannot meet the business’s recovery requirements.
- Concentrations and SPOFs identified: Highlight common dependencies, single points of failure (SPOFs) and areas where several activities could fail together.
- Requirements and capability compared: Compare the RTOs and RPOs requested by the business with actual or currently understood recovery capability.
Step 7: Share feedback and agree actions
Senior management needs to agree on recovery priorities across the organisation and understand significant risks and gaps in recovery capability.
Outcomes from step 7:
- Management presentation developed and presented: Present the key BIA and RA findings to top management for sign-off. Particularly important are the RTOs for activities across the organisation, the risks identified and the suggested mitigation measures. Don’t present every piece of information you have collected. Select the findings you need signed off and the risks and issues management needs to understand.
- Next actions identified: Use the agreed findings to inform continuity strategies, plans, IT recovery, supplier resilience, exercises and improvement work.
Ongoing management
The work doesn’t stop when the BIA and RA are completed.
The BIA and RA need to be maintained and updated at planned intervals and when significant changes occur, in line with the organisation’s business continuity policy and procedures. Don’t let them sit in a spreadsheet until the next review. The aim is to keep them live and current, and not let them become a snapshot of how the organisation used to operate.
