Applying Root Lead to Evaluation (RCA) to Organization Continuity

December 1, 2012 by Leave a Comment

By Stacy Gardner, Avalution Consulting
Article originally posted on Avalution Consulting’s Blog

Though many business continuity standards emphasize the importance of tracking corrective actions to address identified issues, the recently published ISO 22301 (and previously BS 25999-2) also requires conducting a root cause analysis – looking not just at an issue, but its cause and how it can be prevented in the future.   Root cause analysis (RCA) is an approach that seeks to proactively prevent reoccurrences of the same adverse event or systems failure by tracing causal relationships of a failure to its most likely impactful origin, then putting measures in place to mitigate underlying causes to ultimately help prevent recurrence of the adverse event in the future.  While common in disciplines that deal with extreme precision and protection of life (e.g. quality and environmental health and safety), there’s no reason the business continuity discipline cannot benefit from a similar approach, particularly for practitioners looking to fully implement ISO 22301.  This article explains root cause analysis and identifies how organizations can benefit from implementing the concept in a business continuity context.

The concept of root cause analysis was originally developed by Sakichi Toyoda (the founder of Toyota Motor Corporation), who developed a process called the “Five Whys” to understand potential causes for problems beyond what was immediately obvious.  Root cause analysis became more formalized as it was integrated into several different fields as a performance driver, such as safety, quality, operations and information security.  In each of these areas, reactively responding to an issue was not enough – future issues needed to be prevented, and root cause analysis was the path to enable improved performance and risk mitigation by eliminating true causes, rather than just symptoms.  Incorporating root cause analysis into existing business continuity-related corrective action efforts could very well minimize the likelihood of future disruptive incidents and decrease recovery times.

At times, performing RCA is as easy as implementing the five whys, repeatedly asking “why” something occurred until it seems like you’ve reached the baseline cause of how failure occurred.  The key is a disciplined application of asking probing questions.  For example, analyzing the root cause of why an organization failed to meet a 24-hour recovery time objective for its SAP environment during a recent test could look something like this:

  1. Problem: IT recovery personnel failed to recover the organization’s SAP system within its recovery time objective of 24 hours during last week’s IT DR test   …. Why?
  2. IT recovery personnel said that SAN LUNs were not mapped correctly, which drastically delayed the start of restoration from disk   … Why?
  3. Vendor personnel responsible for prepping the equipment failed to execute the setup specifically to documented expectations   … Why?
  4. Vendor personnel indicated that the instructions seemed contradictory and did not provide the level of detail necessary to execute steps, so they used a basic default setup  …Why?
  5. Upon analysis, documentation did leave out several crucial steps necessary to enable this complex LUN mapping to occur   …Why was this not found earlier?
  6. When performing previous testing, personnel did not fully leverage existing plan documentation  … What changed this time?
  7. The individual responsible for documenting the plan and performing past testing was unavailable, and personnel who performed testing this time indicated they were not properly trained on use of the plans, nor were they instructed on how to escalate issues regarding recovery processes.

Although it might seem the root cause was reached, simply fixing the documentation does not ensure future documentation will be accurate.  Taking it deeper, the previous IT subject matter expert responsible for documenting the procedures often does onsite testing without using documentation, as he has extensive experience in this field and felt he could perform tasks more quickly by recovering based on experience as opposed to documented procedures.  Exploring the issue further revealed that newer personnel assigned to recovery tasks were far less experienced and had not yet received an appropriate level of awareness training.  Related to this point, the IT Director admitted he never required other personnel to validate documentation, as testing takes time away from production support and leveraging the “experts” in each phase lessens testing time.

Part of the solution to this could be to implement an expectation that all documented procedures be validated at least annually by another IT individual within a different area of expertise.  A second part of the solution could be to perform appropriate training up front (that emphasizes familiarity with plans and knowledge of escalation procedures) for both alternate internal individuals and any vendor resources responsible for plan execution.  Together, these efforts could help assure that all IT DR documentation can be effectively used by both internal and external resources during testing.

Although simple in theory, identifying the actual root cause and figuring out when you’ve gone far enough can be complex in practice.  To help understand primary root causes, you must repeatedly ask variants of “why” (and a few other probing questions), then look for the answer that seems most likely to have influenced the issue.  While there may not be a “hard science” to root cause analysis, the deeper you look for causes, the more likely you are to find issues to resolve.  In most cases, the biggest issue most organizations face is not exploring problems in the first place!  Our example demonstrated this problem in the recovery of SAP.  However, it’s likely this problem (the shortcuts) exists in other areas, and addressing the root cause could improve performance and recoverability elsewhere.

Variants of

Within business continuity, there are several areas that can commonly be identified as root causes for risk mitigation, response and recovery performance issues, although again, it requires tracing issues back further than most professionals choose to explore.  To properly integrate root cause analysis into continuous improvement activities, each issue should be adequately documented, including source of issue, a detailed description, an identification date, and it should also have a field to capture root cause analysis.  Rather than one individual trying to identify the root cause, business continuity personnel should organize and facilitate discussions that involve subject matter experts to whom issues may be assigned or who can provide insight on an issue, and then the group should seek to trace the issue back to its origin together.

Within business continuity, there are numerous root causes that can lead to a variety of issues or complications. The following table notes a few examples, together with likely root causes, though this is far from a complete list.  Also, it’s important to note that just like with tree roots that feed a tree’s growth, there could be more than one root cause that affects a system and results in a problem, so it is important to trace all potential paths of an issue’s origin back, rather than just pursuing one direct cause, to identify all influencing factors.

Problem and Potential Root Cause

Again, root cause analysis is not just solving one instance of a problem, it’s also seeking opportunities to prevent future occurrences of an issue.  Once the origin of an issue is identified, it’s important to evaluate all areas of the business to identify other at-risk areas and ensure proper risk mitigation measures are put in place.  A solution in one area may not necessarily be applicable to all other areas of an organization, but even if it’s not, the act of identifying other similar at-risk areas raises awareness and enables the organization to develop additional solutions that make sense and address these risks before they result in future issues or downtime.

As business continuity management systems continue to mature, root cause analysis will become a powerful tool for business continuity professionals to deeply examine the cause of issues and provide an opportunity to correct them before they occur again.

____________

Stacy Gardner, Managing Consultant
Avalution Consulting: Business Continuity Consulting

Our consulting team regularly publishes perspectives (shorter, independent articles) that touch on the trends currently affecting our profession and the strategic issues facing our clients. This is one of our most recent posts, but the full catalog of our perspectives – over 100 published since 2005 – can be accessed via our blog.

Mgt Summit RCA presentation

Filed Under: General Tagged With: , , , ,

Applying Root Trigger Analysis (RCA) to Organization Continuity

November 21, 2012 by Leave a Comment

By Stacy Gardner, Avalution Consulting
Article originally posted on Avalution Consulting’s Blog

Though many business continuity standards emphasize the importance of tracking corrective actions to address identified issues, the recently published ISO 22301 (and previously BS 25999-2) also requires conducting a root cause analysis – looking not just at an issue, but its cause and how it can be prevented in the future.   Root cause analysis (RCA) is an approach that seeks to proactively prevent reoccurrences of the same adverse event or systems failure by tracing causal relationships of a failure to its most likely impactful origin, then putting measures in place to mitigate underlying causes to ultimately help prevent recurrence of the adverse event in the future.  While common in disciplines that deal with extreme precision and protection of life (e.g. quality and environmental health and safety), there’s no reason the business continuity discipline cannot benefit from a similar approach, particularly for practitioners looking to fully implement ISO 22301.  This article explains root cause analysis and identifies how organizations can benefit from implementing the concept in a business continuity context.

The concept of root cause analysis was originally developed by Sakichi Toyoda (the founder of Toyota Motor Corporation), who developed a process called the “Five Whys” to understand potential causes for problems beyond what was immediately obvious.  Root cause analysis became more formalized as it was integrated into several different fields as a performance driver, such as safety, quality, operations and information security.  In each of these areas, reactively responding to an issue was not enough – future issues needed to be prevented, and root cause analysis was the path to enable improved performance and risk mitigation by eliminating true causes, rather than just symptoms.  Incorporating root cause analysis into existing business continuity-related corrective action efforts could very well minimize the likelihood of future disruptive incidents and decrease recovery times.

At times, performing RCA is as easy as implementing the five whys, repeatedly asking “why” something occurred until it seems like you’ve reached the baseline cause of how failure occurred.  The key is a disciplined application of asking probing questions.  For example, analyzing the root cause of why an organization failed to meet a 24-hour recovery time objective for its SAP environment during a recent test could look something like this:

  1. Problem: IT recovery personnel failed to recover the organization’s SAP system within its recovery time objective of 24 hours during last week’s IT DR test   …. Why?
  2. IT recovery personnel said that SAN LUNs were not mapped correctly, which drastically delayed the start of restoration from disk   … Why?
  3. Vendor personnel responsible for prepping the equipment failed to execute the setup specifically to documented expectations   … Why?
  4. Vendor personnel indicated that the instructions seemed contradictory and did not provide the level of detail necessary to execute steps, so they used a basic default setup  …Why?
  5. Upon analysis, documentation did leave out several crucial steps necessary to enable this complex LUN mapping to occur   …Why was this not found earlier?
  6. When performing previous testing, personnel did not fully leverage existing plan documentation  … What changed this time?
  7. The individual responsible for documenting the plan and performing past testing was unavailable, and personnel who performed testing this time indicated they were not properly trained on use of the plans, nor were they instructed on how to escalate issues regarding recovery processes.

Although it might seem the root cause was reached, simply fixing the documentation does not ensure future documentation will be accurate.  Taking it deeper, the previous IT subject matter expert responsible for documenting the procedures often does onsite testing without using documentation, as he has extensive experience in this field and felt he could perform tasks more quickly by recovering based on experience as opposed to documented procedures.  Exploring the issue further revealed that newer personnel assigned to recovery tasks were far less experienced and had not yet received an appropriate level of awareness training.  Related to this point, the IT Director admitted he never required other personnel to validate documentation, as testing takes time away from production support and leveraging the “experts” in each phase lessens testing time.

Part of the solution to this could be to implement an expectation that all documented procedures be validated at least annually by another IT individual within a different area of expertise.  A second part of the solution could be to perform appropriate training up front (that emphasizes familiarity with plans and knowledge of escalation procedures) for both alternate internal individuals and any vendor resources responsible for plan execution.  Together, these efforts could help assure that all IT DR documentation can be effectively used by both internal and external resources during testing.

Although simple in theory, identifying the actual root cause and figuring out when you’ve gone far enough can be complex in practice.  To help understand primary root causes, you must repeatedly ask variants of “why” (and a few other probing questions), then look for the answer that seems most likely to have influenced the issue.  While there may not be a “hard science” to root cause analysis, the deeper you look for causes, the more likely you are to find issues to resolve.  In most cases, the biggest issue most organizations face is not exploring problems in the first place!  Our example demonstrated this problem in the recovery of SAP.  However, it’s likely this problem (the shortcuts) exists in other areas, and addressing the root cause could improve performance and recoverability elsewhere.

Variants of

Within business continuity, there are several areas that can commonly be identified as root causes for risk mitigation, response and recovery performance issues, although again, it requires tracing issues back further than most professionals choose to explore.  To properly integrate root cause analysis into continuous improvement activities, each issue should be adequately documented, including source of issue, a detailed description, an identification date, and it should also have a field to capture root cause analysis.  Rather than one individual trying to identify the root cause, business continuity personnel should organize and facilitate discussions that involve subject matter experts to whom issues may be assigned or who can provide insight on an issue, and then the group should seek to trace the issue back to its origin together.

Within business continuity, there are numerous root causes that can lead to a variety of issues or complications. The following table notes a few examples, together with likely root causes, though this is far from a complete list.  Also, it’s important to note that just like with tree roots that feed a tree’s growth, there could be more than one root cause that affects a system and results in a problem, so it is important to trace all potential paths of an issue’s origin back, rather than just pursuing one direct cause, to identify all influencing factors.

Problem and Potential Root Cause

Again, root cause analysis is not just solving one instance of a problem, it’s also seeking opportunities to prevent future occurrences of an issue.  Once the origin of an issue is identified, it’s important to evaluate all areas of the business to identify other at-risk areas and ensure proper risk mitigation measures are put in place.  A solution in one area may not necessarily be applicable to all other areas of an organization, but even if it’s not, the act of identifying other similar at-risk areas raises awareness and enables the organization to develop additional solutions that make sense and address these risks before they result in future issues or downtime.

As business continuity management systems continue to mature, root cause analysis will become a powerful tool for business continuity professionals to deeply examine the cause of issues and provide an opportunity to correct them before they occur again.

____________

Stacy Gardner, Managing Consultant
Avalution Consulting: Business Continuity Consulting 

Our consulting team regularly publishes perspectives (shorter, independent articles) that touch on the trends currently affecting our profession and the strategic issues facing our clients. This is one of our most recent posts, but the full catalog of our perspectives – over 100 published since 2005 – can be accessed via our blog.

Filed Under: General Tagged With: , , , ,

Using Toolkits to Make Company Continuity Less complicated

October 26, 2012 by Leave a Comment

By Greg Marbais, Avalution Consulting
Article originally posted on Avalution Consulting’s Blog

Many business continuity professionals face shrinking budgets and, because of an expanding business continuity program scope and aggressive recovery objectives, lack the time necessary to “touch” all areas of the organization and optimally prepare for disruptive events. As a result, practitioners need a way to create repeatable processes to execute recurring planning activities in a decentralized manner while making efficient use of the organization’s personnel to comply with management’s expectations. One approach we often find useful in rolling out a standardized, thorough, efficient and repeatable process for business continuity activities is the creation of a business continuity program toolkit. A business continuity toolkit typically contains a set of instructional narratives, as well as templates, tools and examples to help dispersed personnel appropriately execute business continuity planning activities consistent with organizational standards.

The development of business continuity toolkit is an approach growing in popularity, with the end goal of implementing and executing repeatable, effective business continuity activities across larger, dispersed organizations in order to meet management’s performance objectives. Business continuity toolkits often include instructions that are easy for those charged with planning – especially those planning on a part-time basis – to follow and understand. This approach makes the most out of centralized business continuity professionals and provides part-time planners with the proper information to be effective in their planning role.

Preparing to develop and implement a business continuity toolkit should begin with a clear set of objectives, outcomes and how success will be measured, obtaining approval from management (as required by the organization) and establishing a timeline with key milestones.

What’s in a Business Continuity Toolkit?
The contents of a toolkit are necessarily unique to each organization; however, most contain the following:

  • Governance materials that establish the expectations of the organization for business continuity planning. 
  • Written instructions and guidance to prepare for, execute and conclude each core business continuity activity, together with recommendations regarding how to select and engage the most appropriate resources. 
  • Templates that address common program elements. 

Documents commonly included in a toolkit are shown in the following diagram:

Example Toolkit

The materials and application of the toolkit will vary from organization to organization; however, it’s important to ensure that the toolkit is written and designed at a high enough level so that every organizational element can utilize the content and apply it effectively. Instructions should include task detail, links to templates and examples, and the method to maintain and continually improve the outcome. Further, the instructions included in the toolkit should provide users with a structured process to execute a business continuity activity in alignment with organizational policy and program requirements.

As noted above, an effective toolkit will include templates and examples that help those charged with planning to perform the required activities and tasks listed in the instructions, all leading to an appropriate level of preparedness for disruptive events. Templates and examples included in most toolkits include interested party communications, meeting and planning session agendas, report structures and presentation files. Each template should be referenced in the instructions as to when it should be used. Templates often included in a toolkit are:

  • Communications templates provide a structured method to convey expectations for all planning participants. An example email template used for a business impact analysis (BIA) kickoff meeting would explain that the department is implementing or reviewing a BIA, that the recipient has been identified as a person that should be involved in the process and what the recipient will be expected to do during the data gathering effort and throughout the BIA process. 
  • Agenda templates provide a basic structure to help planners carry out meetings designed to plan for or perform business continuity planning activities. An example agenda template used for a BIA kickoff meeting often includes an introduction to the BIA, a discussion of the scope of the BIA, a review of roles and responsibilities for all participants, an overview of the BIA process, and next steps in order to prepare for the BIA. 
  • Report templates provide a structure that enables planners to document the information necessary to enable preparedness for disruptive events. For example, a template used for summarizing BIA information would include a high-level summary of the information necessary to justify recovery objectives, a structure for reporting the detailed findings, and next steps. 
  • Presentation templates provide the basic structure and content used to convey findings, recommendations and enable management decision-making. For example, a BIA summary presentation would convey recommended recovery objectives, justification and perhaps even gaps between recommendations and current-state capabilities. 

Before Building a Toolkit
A business continuity toolkit is only valuable when the basic process for conducting a business continuity activity is defined and expectations agreed upon. When developing a toolkit, it is important to first create the structure for the business continuity program and reflect this structure in a policy statement and standard operating procedures (SOP). The toolkit essentially translates the program into actionable activities and tasks for those required to perform business continuity activities. Since the toolkit is meant to make performing business continuity activities easier and the outcomes better, it may not be valuable early in a program’s maturity when frequent changes to the toolkit are likely needed. In addition, it may be helpful to “beta test” the toolkit prior to rolling it out throughout the organization.

Another important consideration is the effect of culture on the use toolkits. Large organizations with independent business units spread across multiple geographies could have significantly different corporate cultures. Different cultures could lead to differing approaches to executing business continuity activities, such as a BIA. The toolkit needs to be adapted to the local culture – and diverse regulatory requirements and customer expectations – which is more than translating it into the local language. In addition, the process described in the toolkit may need to be adapted. For example, an organization that uses workshops to elicit business continuity strategy options in the United States may run into difficulty using the same process in China. In China, a similar process would often generate few strategy ideas, especially if the workgroup includes personnel at multiple levels of the organization. There is a cultural factor in China that prevents employees from providing feedback which may harm the reputation of another member of the group. This cultural factor means that conducting a BIA or trying to obtain strategy options requires changing the approach to get valid information. Ultimately, culture plays a substantial role in the effectiveness of a business continuity program, so it’s important that the program is adapted to the culture.

Conclusions
A business continuity toolkit enables the execution of a decentralized program and the implementation of standardized, consistent and compliant business continuity activities in an efficient manner. Bottom-line, the benefits a toolkit provides to the business continuity professional and the organization as a whole are that it:

  1. Clarifies expectations for those performing planning activities and provides examples to illustrate expectations; 
  2. Reduces the risk of non-compliance with regulatory requirements or other obligations; and 
  3. Enables the business continuity professional’s transition from an advisor on all preparedness tasks to a consultant to the most important and complex tasks. 

In the end, a business continuity toolkit helps optimize limited resources and appropriately engage personnel throughout the organization, thus mitigating risk and enabling effective recovery from disruptive events.

If you’re considering using a toolkit to roll out business continuity across your organization, please contact us to discuss how we can quickly establish a toolkit for your organization and aid you in deploying it.

—————————

Greg Marbais, Consultant
Avalution Consulting: Business Continuity Consulting

Our consulting team regularly publishes perspectives (shorter, independent articles) that touch on the trends currently affecting our profession and the strategic issues facing our clients. This is one of our most recent posts, but the full catalog of our perspectives – over 100 published since 2005 – can be accessed via our blog.

Filed Under: General Tagged With:

How to Establish Danger Appetite in the Context of Organization Continuity

October 3, 2012 by Leave a Comment

By Brian Zawada &amp Jacque Rupert, Avalution Consulting
Write-up originally posted on Avalution Consulting&rsquos Blog

The introduction of ISO 22301 (Societal security &ndash Requirements &ndash Enterprise continuity management system) far more closely aligns company continuity to the broader danger management discipline. A main contributor to this alignment is the common&rsquos requirement to realize the organization&rsquos &ldquorisk appetite&rdquo (a term not used in BS 25999).&nbsp

ISO 22301&rsquos definition of threat appetite (Section 3.49) is the &ldquoamount and variety of risk that an organization is willing to pursue or retain&rdquo. The regular makes reference to risk appetite in two sections:

ISO 22301 and Danger Appetite

In addition, the authors of the guidance document supporting ISO 22301, titled ISO DIS 22313, make one particular further reference to threat appetite in the section focused on establishing the context for the business continuity management technique:

ISO 22301 and Danger Appetite

For these searching for alignment with or certification to ISO 22301, organization continuity professionals (or those charged with enterprise continuity planning) should realize the idea of risk appetite and address the needs outlined above.&nbsp

Please note: the goal of this post is not to provide a comprehensive, theoretical understanding of risk appetite, as other whitepapers and info sources already do this, but rather to introduce the idea to company continuity professionals and offer you insight on leveraging and &ldquoimplementing&rdquo this idea in our profession.

The Relationship Amongst Danger Appetite and Business Continuity
We think the contributors to ISO 22301 integrated the notion of threat appetite (&ldquoamount and type of risk that an organization is willing to pursue or retain&rdquo) into a enterprise continuity management program standard for two important factors:

  1. Organizations ought to view danger appetite as all-encompassing, incorporating all places of threat, including the company continuity-associated risks linked with disruptive incidents and&nbsp
  2. Utilizing danger appetite to adequately scope and support a business continuity management system aids align business continuity to organizational strategy and other risk management efforts, enabling organization continuity to better integrate into broader threat management.&nbsp

Further, when carried out effectively, risk appetite becomes a key input to (and it could overlap considerably with) a company continuity management system&rsquos scope and objectives.&nbsp

Keys to Determining Threat Appetite
As noted above, many sources of information are obtainable that describe the concept of danger appetite and the greatest method for determining an organization&rsquos danger appetite. Avalution analyzed these sources to aid further understand how to most properly help our clientele in determining and documenting their danger appetites as it pertains to organization continuity preparing, as properly as integrate the notion into our own company continuity system (since we are actively transitioning from BS 25999-two to ISO 22301 within our organization). One particular of the most valuable sources we identified is a white paper published by the Institute for Danger Management (IRM), which introduced a quantity of &ldquodesign&rdquo aspects the authors considered as important to figuring out danger appetite. 3 of these design aspects, or considerations, are paraphrased below, which we located aids to better realize and decide danger appetite:&nbsp

  1. An organization&rsquos danger appetite is &ndash or should be &ndash measurable&nbsp
  2. The acceptability of threat must have a time (temporal) consideration, to ensure periodic assessment (given organizational and environmental alter)&nbsp
  3. Threat acceptance ought to not have anything to do with relaxing controls (risk treatment options)&nbsp

With this stated, and in our opinion, some of the sources of data &ndash other than executive management &ndash that organizations really should evaluate when figuring out danger appetite incorporate:

  • Annual reports and monetary statements&nbsp
  • Consumer contracts&nbsp
  • Regulatory requirements&nbsp
  • Business strategic plans&nbsp
  • Marketing and advertising materials&nbsp
  • Board meeting minutes&nbsp

Although we will not go into additional detail on determining threat appetite, these looking for extra data should contemplate reviewing the following:

  • COSO &ndash Understanding and Communicating Danger Appetite&nbsp
  • ERM Symposium &ndash Cremonino&nbsp
  • Towers Perrin &ndash ERM Threat Appetite&nbsp
  • COSO &ndash ERM Executive Summary&nbsp

Instance &ndash Risk Appetite at Avalution
In transitioning from BS 25999-2 to ISO 22301, we had to understand how risk appetite pertains to our business continuity management method, provided that this is a new formalized requirement essential for certification. Using the guidance and method described in the previous section of this article, we documented our risk appetite summary as follows:

In 2012, we are willing to tolerate a finite amount of downtime as long as it does not outcome in the following:

  1. Damaged reputation among our clients that leads to broader, unfavorable market place perception
  2. Missed service level agreements particular to The Preparing Portal and BC Catalyst&nbsp
  3. Financial loss in excess of $ 50,000
  4. Project delays of much more than three days due to resource disruption and lost information

In order to align our existing organization continuity system with this statement relating to danger appetite, Avalution management intends to staff and appropriately resource our enterprise continuity management program to minimize downtime in the most effective, pragmatic manner feasible.&nbsp

As noted earlier in this short article, this statement aligns with the IRM style considerations, specifically:

  • It aligns to our merchandise and services, as well as our organization&rsquos strategic priorities, and hence the scope of our company continuity management program&nbsp
  • It delivers quantifiable techniques to measure risk&nbsp
  • It notes a time element (2012)&nbsp
  • It notes where our management team accepts a level of risk, which frees resources to boost our company, services and technology, as effectively as invest in our men and women&nbsp

Conclusions
Danger appetite is an critical idea that involves strategic, operational and tactical elements &ndash all of which influence the productive implementation and continual improvement of a business continuity management program. Taking into consideration threat appetite as element of organization continuity organizing allows business continuity to far more closely align with threat management efforts, enabling enterprise continuity efforts to focus mostly on the risks management is unwilling to accept regarding critical items, services, business processes and resources (all of which an organization should obviously document within its danger appetite). Understanding the boundaries &ndash based on an acceptable level of threat &ndash introduces focus and clarity in arranging, which outcomes in greater levels of effectiveness and efficiency in safeguarding an organization&rsquos most time-sensitive or vital activities.&nbsp

Further, considering danger appetite in the context of organization continuity planning really should support management frame organization continuity in relation to how they currently think about the broader subject of dangers to the organization, with the danger of disruptive incidents becoming only one particular factor to consider. Aligning the organization continuity work to how management already thinks (on a strategic level) really should contribute to a stronger, clearer value proposition for the preparedness effort, which ought to allow long-term support and management involvement.&nbsp

Due to the benefits outlined throughout this short article, Avalution believes that the idea of threat appetite is a welcome addition to ISO 22301, and one particular that organization continuity specialists must find out far more about in order to be an active participant in a broader threat management effort.

________________________

Brian Zawada, Director of Consulting &amp Jacque Rupert, Managing Consultant
Avalution Consulting: Company Continuity Consulting

Our consulting group frequently publishes perspectives (shorter, independent articles) that touch on the trends currently affecting our profession and the strategic troubles facing our clientele. This is one particular of our most current posts, but the complete catalog of our perspectives &ndash over 100 published because 2005 &ndash can be accessed by means of our weblog.

Filed Under: General Tagged With: , ,