Business Impact Analysis (BIA), how do you do that?

Creating a Business Impact Analysis (BIA), how do you do that? I assume that the organization is mature enough to know why BCM is needed and therefore why a BIA is needed in the process of doing BCM. This is about a possible implementation way of the BIA. The premise is that the organization already does risk management and has a risk analysis in place that is also useful for the organization’s processes. Although this is not always necessary. Many find it expedient to do the BIA first because one can subject the most important processes to a comprehensive risk analysis first. So we start with a business impact analysis, how do you do that?

In this contribution, I write my own opinion, not that of any organization. This contribution is inspired by the following works:   No Nonsense Business Continuity Planning for Busy Continuity Planners; Charley Newnham   The Definitive Handbook of Business Continuity Management 3° Edition; Andrew Hiles

The classical BIA is making some great strides:

Form an understanding of the organization and its processes

Identify the necessary resources

Estimate threats and risks.

Understand the organization and its processes

Identify all of the organization’s processes

Identify Time-Critical Processes (CP), Essential Processes (EP), Necessary Processes (NP) and Usable Processes (BP).

Identify stakeholders and interested parties.

Estimate the impact over time for each process if it drops out or if something interrupted it.

Determine the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each process.

Identify internal and external dependencies.

• Among other things, also of timings of other plans
• Among others, also of the existing and not yet existing measures
• Among other things, from manuals and documents
• …

Sort the list according to the RTO

Now choose the processes top-x for which you want to work out the BCP later(these are the time-critical processes.)

Identify the necessary resources

Human: define the roles to execute the processes,

• How many FTEs do you require?
• Which customers are necessary?
• What tech support do you need?
• Which suppliers are necessary?
• Do we need staff from other entities?

Machines: data accesses; telework capabilities;…

Required data

Required workstations

• Desks
• Chairs
• Computers
• Heating
• Coffee
• Meeting space
• Technical room
• Geographic preference

Estimate threats and risks.

• Use the results of the risk analysis if they already exist for the processes.
• Initially, limit yourself to the time-critical processes.

Help, I have a BIA !

Then you know that the life of the BIA is a process with a purpose. The purpose is to support a realistic BCP. And because of that, it is an exercise that pays off when disaster strikes.

If you need to create a new (first) BCP:

• Then you share the BIA with those who need to understand it. You also ask them for their opinions and feedback.
• Then you make sure the planning includes only the CPs (time-critical processes) that matter in the time window your plan covers.
• Then get the supervisor to sign off on the BIA and make sure he agrees with its contents.

If you already have a BCP that you need to update,

• Then make sure the critical processes in the BIA and the priorities in the plan match.
• Then align the BCP with the RTOs in the BIA.
• Then you align the SLAs with the RTOs in the BIA.
• Then you share the BIA with those who need to understand it. You also ask them their opinions and feedback.
• Then you make sure the planning includes only the CPs (time-critical processes) that matter in the time window your plan covers.
• Then get the supervisor to sign off on the BIA and make sure he agrees with its contents.

Thus, a possible BIA has the following tables and layout:

Step 1: process list
sequence	Process/activity	Description impact	impact 1-5	RTO	Priority RTO	RPO	Dependencies	CP/ NP/ EP/ BP

Step 2: resources needed for critical processes
Tracking Process	Roles required, number	Required tools and systems	Hardware Required	Workspace needed / Number of people	Other departments/ organizational units/suppliers/services	contacts and functions and contact information

Step 3: assessment of threats/risks.
Tracking Process	Threat/risk statement	Opportunity/ reason	Probability High/ … / Low	Impact/ Description	Impact high/ … / Low	Risk High/ … / Low	Accept/ Move/ Reduce/ Remove / What is already in place preemptively?

Owner of the BIA: xxx xxxxx

Senior Customer BIA: xxx xxxxx

Version date: yyyymmdd

Version: NN.nn

Review of the BIA.

The BIA is the foundation of the BCP. It provides insight into why to include what in the BCP and what not. This makes updating a BCP faster, but then you also need to keep the BIA accurate. Do this

• Once a year
• With any significant change in the organization (new processes, old processes ending, a new building, people changing such as staff, the staff,…, suppliers, citizens, the environment changing, SLAs changing, …

So you check with a revision to see if anything has changed since the previous version.

Description and usefulness of topics in the BIA.

Process information for BIA	Description and utility
Name time-critical and/or mission-critical process	Description: Identification of the process that is: time-critical: a process that must be restarted within 48 after an incident; and/or mission-critical: a process that helps achieve an entity’s mission. Utility: A list of sensitive processes on which the survival of the organization in particular depends.
Description process	Description: Brief explanation of what the time critical/mission critical process entails, when it begins and when it ends. Utility: As long as no generic names for processes exist, the description is needed to provide clarity on what the content of the intended process is.
Process tool	Description: The people and resources needed to run a time-critical and/or mission-critical process. Each work resource determines the period(s) in which it is urgent, how many units are needed and what alternative can be proposed. Process work resources may include: – Staff (number and function) – Workstations – Phones / Fax / cell phones – Workstations – Laptops – Printing & copying facilities – Access to e-mail – Internet access – …   Utility: In a crisis period, a process can be restarted more quickly if it is known what work resources are needed to do so.
Process Period	Description: Time(s) when the time-critical/mission-critical process is performed. Utility: This time indicator indicates the period of the year when a process has the selected process urgency. This may differ for seasonal processes, for example. This allows flexible reporting to set up a repair that is most relevant to when the crisis occurs.
Impact in case of process failure	Description: Describes the extent of damages suffered. These impacts may include reputational damage, financial damage, human damage, work delays, material damage, … Utility: Impact is often seen as the degree of urgency to determine a “process urgency. It is therefore an indicator of how great losses of all kinds could be if a process fails.
RTO: Recovery Time Objective	Description: The passage of time allowed by management from a disruptive incident to the provisional restart of operations, often at a predetermined level of capability. Utility: This quantity is a more refined indicator of the urgency of restarting the processes and gives technicians an indication of the priority order in which they should be able to restart the processes for the benefit of the organization(s). Among other things, this indicator is essential for planning the restart of IT systems.
RPO: Recovery Point Objective	Description: The period of time allowed between two moments of secure data storage. I.e., the maximum amount of data/transactions that may be lost between the last secure data store and the disruptive incident. Utility: This indicator is for ICT-related processes an indicator related to the backup system. It provides an idea of how much backlog will have to be cleared, and of how much work from the last few days may have been lost.
Process Owner	Description: The person liable for litigation. Utility: When a particular process is involved in an incident, the liable person can easily be notified.
Process dependencies	Description: These dependencies say which processes depend on each other (in both directions: “depends on” and “is necessary for”) Utility: With this information, one has a better view of the problem and can prevent the evolution of a cascade of crises.
Hardware dependency	Description: The dependence on hardware, such as laptops, notebooks, iPads, iPhones, servers, …This information should be clear (in part: servers,…) in the operating file. Utility: This allows IT to provide an estimate to management for hardware expenses, as well as knowing what hardware is needed to set up a new system on which to run the processes.
Software dependency	Description: The dependence on software, such as browsers, document system, centerstage, office,…This information should be clear (in part: servers,…) in the exploitation file. Utility: This allows IT to provide an estimate to management for software expenses, as well as knowing what software is needed to set up a new system on which to run the processes.
Financial dependence	Description: process-related, building-related expenses et al. Utility: This dependency provides an understanding of some of the costs when processes are restarted. This helps in preparing/requesting budgets and cost items.
Facility Dependency	Description: The dependencies of items such as sandwiches, coffee, tables, bureautica, chairs, electricity, toilets, water, light, air conditioning,… Utility: This allows the CFO to estimate facility expenses, as well as know what facilities are needed to put people to work.
Stakeholder dependence	Description: This is data in contact lists, such as suppliers, customers, employees… Utility: Gives management an overview of all parties involved, with whom it needs to liaise in order to get processes operational again through them / for them.