This is the second of two posts examining the prepare step in building and managing a BCEM (Business Continuity Event Management) plan. In the previous post, we saw how understanding the business is critical to a business impact mitigation and process recovery. The activities discussed produce input for the business impact analysis, including: Business objectives Regulatory environment Critical processes Threats Process interdependencies Process vulnerabilities Using this information, we can plan for inevitable process failures. The BIA uses business impact information and the probability of specific business continuity events to calculate levels of business risk. The end result of a BIA is a picture of the BCEM threat, vulnerability, mitigation, and response framework and how that framework reduces risk to levels acceptable to management.Instead of segregating the BIA from risk assessment and mitigation activities, I integrated them into an overall business continuity risk management process. The result is a continuous, risk-centric approach to BCEM preparation.What is Business Impact?Business impact is a measure of how an organization might be affected by a process failure, caused by technology, premise, or human resource issues. Impact is classified as either revenue or non-revenue.Revenue impact includes the full or partial failure of any process which produces, collects, or processes business income. Examples include: Accounts receivable systems Availability of revenue generating facilities Availability of sales, service or product delivery, or revenue collection employees Any other process whose failure diminishes the organization’s ability to fund operations, pay its bills, or make payroll Non-revenue impact is caused by challenges that do not directly affect short term realization of revenue, including: Payroll systems Availability of employees not directly related to revenue generation, such as human resources Public perception Regulatory compliance Environmental damage Although causes of non-revenue impact might not result in immediate financial losses, some could result in long term financial damage through loss of investor or customer good will. Business impact can be calculated using either a qualitative or a quantitative approach. Qualitative analysis depends on the experience of employees and consultants to arrive at risk scores. The results of the quantitative approach are estimates of potential dollar losses based on known costs or revenue streams. Most organizations don’t understand process interruption costs well enough to use quantitative BIA methods. So we’ll focus on a qualitative approach in this article. The BIAThe BIA, as presented in this series, is a risk management tool. A very simple formula depicts the relationship between business impact and risk.Risk = Probability of Occurrence * Business ImpactProbability of occurrence is calculated using the threat and vulnerability analysis performed in the previous step, understanding the business. It’s represented as the number of occurrences expected in a single year. This is known as the Annual Rate of Occurrence.For example, if information about known threats, vulnerabilities, and actual events lead an analyst to believe a threat will cause a weakness to interrupt business operations once every four years, the probability of occurrence is .25. During a qualitative BIA, the analyst uses probability of occurrence (PO) and business impact (BI) to arrive at a risk score. The risk score is a measure of the amount of damage resulting from one or more failed critical processes. The BIA Process Figure 1 depicts BIA phases—the Prepare step in the BCEM Planning cycle—at a high level.Figure 1 The first phase, Understand the Business, was covered in the last post. In the remaining sections of this article, we’ll step through the next three.Calculate MTDs MTD (Maximum Tolerable Downtime) is the maximum time a critical process can be down, or hindered in some way, without irreparable harm to the business. It’s typically calculated as part of a BIA and is used during risk calculations.At a high level, a BIA begins with identifying critical processes, describes resources necessary to maintain them, calculates the financial or PR impact on the business if the process fails, and determines process MTD. Other processes which depend on the failed process’ output also suffer. So a BIA must also describe the interrelationship between all critical processes and factor this into their MTDs.A process MTD is an adjustable value, affected by several variables. For more information on MTDs and how to calculate them, or extend recovery periods, see Calculating MTD based on impact mitigation and recovery capabilities. Perform FMEAThe FMEA (Failure Modes and Effects Analysis) was developed to predict and mitigate possible failures in manufacturing processes. Unlike root cause analysis, which takes place following an event, FMEA activities precede system or process implementation. They help prepare teams for inevitable failures, mitigating business impact. This makes FMEA a good fit for BCEM planning.The best way to describe FMEA is stepping through a commonly used tool. See Figure 2. (Download the FMEA template.) Process Description. This column contains the name of a critical process identified during the earlier preparation activities. Potential Failure Mode. Each process usually consists of two or more components subject to failure. For example, a cash collection process might require an Accounts Receivable application and supporting infrastructure as well as AR clerks to operate it. All components making up a critical process should be listed in this column. Potential Effects of Failure. This is a description of the business impact of a failed component. • SEV. This column is a numeric severity rating of the failure described in the previous column. The downloadable template includes a worksheet with a sample severity table listing rankings from 1 through 10. Potential Causes. Each failure might have several causes. Each cause should be listed in this column. PROB. This column represents a PO value for each potential cause. Instead of using a fractional value, FMEA uses a score from 1 to 10, as shown in the Probability of Occurrence worksheet included in the template. Current Controls. For each cause, there should be one or more controls to prevent or detect potential failure. These controls are listed in this column and should include response plans designed to recover within related MTDs. DET. This column contains a detectability score. As depicted in the Detectability worksheet included in the template, the score is also selected from values from 1 through 10, based on the organization’s ability to detect potential problems. RPN. RPN (Risk Priority Number) is a value resulting from the formula SEV * PROB * DET. The higher the number, the greater the risk. Management should establish a threshold representing acceptable risk. Any RPN over that threshold requires mitigation. Mitigate Risk Once failure modes with RPNs exceeding the acceptable risk threshold are identified and prioritized, mitigation steps are scheduled. The FMEA template provides columns for action plan tasks, including Recommended Actions and Responsibility, Target Completion Date, and Action Taken. An additional set of RPN values are provided to recalculate risk, following action plan task completion. If the RPN is still too high, additional mitigation steps are identified, executed, and the resulting RPN calculated. This process continues until the RPN drops below the acceptable risk threshold or management accepts the increased risk.The final wordBIA is a continuous process, with repeated analysis when new systems are implemented, major upgrades occur, or processes change. The output of the BCEM BIA includes not only useful insight into business continuity event risk and ways to mitigate it. It also includes documented controls and event response processes ensuring rapid detection and effective recovery of failed process components.For more information on FMEA, see Failure Mode and Effects Analysis. Related content opinion MQTT is not evil, just not always secure The MQTT messaging protocol standard used by IoT vendors is not inherenly secure enough. Solutions exist to secure it, but organizations and vendors must assess risk and properly configure IoT and network security. By Tom Olzak Jul 17, 2017 3 mins Internet of Things opinion IoT messaging protocol is big security risk Popular IoT messaging protocol lacks encryption and sufficient device authentication security. By Tom Olzak Jul 14, 2017 3 mins Cloud Security Data and Information Security Internet of Things opinion Anatomy of an insider attack Manage insider attack risks with scenarios and application of common sense. By Tom Olzak Sep 30, 2016 4 mins Business Continuity Security opinion Identity governance and admin: beyond basic access management User behavior analytics give additional power to identity management and compliance. By Tom Olzak Aug 30, 2016 5 mins Investigation and Forensics Compliance Security Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe