Emannuel's Thoughts: BCM, Risk- And Crisis management

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 Author: Manu Steens ContentsThe classical BIA is making some great strides:Help, I have a BIA !If you need to create a new (first) BCP:If you already have a BCP that you need to update,Review of the BIA.Description and usefulness of topics in the BIA. 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 listsequenceProcess/activityDescription impactimpact 1-5RTOPriority RTORPODependenciesCP/ NP/ EP/ BP Step 2: resources needed for critical processesTracking ProcessRoles required, numberRequired tools and systemsHardware RequiredWorkspace needed / Number of peopleOther departments/ organizational units/suppliers/servicescontacts and functions and contact information Step 3: assessment of threats/risks.Tracking ProcessThreat/risk statementOpportunity/ reasonProbability High/ ... / LowImpact/ DescriptionImpact high/ ... / LowRisk High/ ... / LowAccept/ 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 BIADescription and utilityName time-critical and/or mission-critical processDescription: 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 processDescription: 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 toolDescription: 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 PeriodDescription: 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 failureDescription: 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 ObjectiveDescription: 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 ObjectiveDescription: 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 OwnerDescription: The person liable for litigation. Utility: When a particular process is involved in an incident, the liable person can easily be notified.Process dependenciesDescription: 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 dependencyDescription: 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 dependencyDescription: 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 dependenceDescription: 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 DependencyDescription: 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 dependenceDescription: 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.