Sergey Nivens - Fotolia

Manage Learn to apply best practices and optimize your operations.

Risk analysis boosts disaster recovery planning process

Business continuity and disaster recovery are chronically overlooked. Learn what you can do to avoid losses that could impact your organization.

This article can also be found in the Premium Editorial Download: Storage magazine: On-prem cloud: Storage in a bottle:

Building an effective disaster recovery plan requires considerable work before getting to hardware, software or service considerations. A company needs to have a detailed perspective of the types of risks it will need to be protected from and the impact that those risks represent to the organization. Both a risk analysis (RA) and business impact analysis (BIA) should be performed to determine where to focus resources in the disaster recovery (DR) planning process and how much to invest in building and maintaining those resources. This article will provide a step-by-step roadmap for preparing and completing both of these important analyses.

The importance of standards

Before we examine BIAs and RAs, it's important to review the professional standards and practices that address both activities.

Each of the following standards provides a detailed understanding of the principles of risk management, and also provides guidance on how and where risk management techniques (e.g., conducting a risk assessment) can be effectively used.

The global risk management standard, ISO 31000, Risk Management -- Principles and Guidelines on Implementation, was released by the International Organization for Standardization (ISO). It is recognized as the benchmark standard for risk management worldwide.

Another standard is ISO 31010:2009, Risk Management -- Risk Assessment Techniques, which provides guidance on how to organize and conduct a risk assessment. It complements ISO 31000, in that its specific focus is how to prepare for a risk assessment.

In the U.S., a key RA standard is SP 800-30, Risk Management Guide for IT Systems, by the National Institute of Standards and Technology (NIST). This standard shifts the focus of the risk management process to IT systems and technology, and is a useful companion to ISO 31010.

The new global business impact analysis standard (currently going through the approval process) is ISO 22317, Societal Security -- Business Continuity Management Systems -- Business Impact Analysis. It is the first formal standard addressing the BIA process. Similar to the above risk standards, this new standard sets out the principles of the BIA, and also offers good practice guidance on how to prepare for and conduct a BIA.

Finally, a handy professional practice guide for BIAs and RAs is the Business Continuity Institute's Good Practice Guidelines, 2013 Edition.

The business impact analysis

BIAs identify the impact of disruptive events on key issues like business operations, financial performance, reputation, employees and supply chains, and the systems and networks that support them. The business impact analysis is the starting point for risk identification in a disaster recovery context. BIA results are used in the risk assessment process. Table 1 depicts the relationship among disruptive events and business factors for a BIA -- actual losses and recovery times will, of course, vary from organization to organization.

Business reasons for a business impact analysis

Use BIA results to define the maximum period of time for which the business can survive without its people, process, technology and physical locations. BIAs generate two important metrics. First is the recovery time objective (RTO), which is the maximum amount of time a system can be down before the business suffers. Next is the recovery point objective (RPO), which identifies a point in time needed to recover data to when it was last used.

Questionnaires and interviews can simplify the BIA discovery process. Below you will find examples of potential questions, which can be modified for the specific attributes of your organization.

Preparing BIA questions

Formulate questions to address the following issues, as minimum:

  • Identification of business units and processes that depend on IT
  • Financial value of critical business processes
  • Dependencies on internal departments
  • Dependencies on external organizations
  • Data requirements
  • Minimum time needed to recover data to when it was last used
  • Minimum technology and system requirements needed to conduct business
  • Minimum number of staff needed to conduct business
  • Minimum office space, supplies, vital records and other resources
  • Distribute BIA questions to key members of each department in the company.

Compiling and analyzing the data

Analyze the interview data using a tool such as a formatted spreadsheet. The following list includes suggested headings for individual columns in the BIA spreadsheet and what each column should cover.

  • Business unit name -- The name of the specific department/unit
  • Head count -- The number of full-time (also part-time, contract) staff in the business unit
  • Parent process -- The principal activities the unit performs
  • Priority ranking -- A numerical ranking based on priority/criticality
  • Recovery time objective -- The time frame (e.g., one hour, one week) in which a key process must return to "business as usual" following a disruption
  • Recovery point objective -- The amount of time between data backups that is tolerable to your organization (e.g., 15 minutes, one day)
  • Parent process dependency -- The organizations or services a parent process needs for normal operations
  • Parent process dependents -- The organizations or services that depend on the parent process for normal operations
  • Quantitative impact -- A financial amount associated with the parent process (e.g., revenue)
  • Qualitative impact -- A non-financial impact to the organization (e.g., loss of reputation)
  • Time needed to recover staff -- The minimum number of employees needed to achieve "business almost as usual" within specific time frames
  • Recovery strategy -- The specific actions an IT department should take to recover to a "business almost as usual" state (e.g., restore from backup, run apps from secondary servers/storage, recover to a cloud service)
  • Technology/services recovery time -- The IT systems and services to be recovered within the specific time frame

Results from the BIA will identify, prioritize and document the critical business processes conducted by various business units and the IT resources needed to keep them operational.

Software for conducting a BIA

Specialized BIA software tools may be part of business continuity software (eBRP Suite and Resilience ONE from Strategic BCP) or separate tools (BIA Professional from SunGard). Ensure that BIA results can be integrated into an overall disaster recovery project that identifies mission-critical systems and their dependencies, potential threats (from a risk analysis) and recovery strategies, and designs a DR plan.

The risk analysis

Once the BIA has been completed, identify the most critical business processes and the supporting IT assets needed by each. The risk analysis helps you identify threats and vulnerabilities that could potentially disrupt the continued operation of the BIA-identified processes and systems.

The RA involves risk identification, assessing the likelihood of the event occurring, and defining the severity of the event's consequences.

Once you've identified the most critical business processes from the BIA, identify threats from various sources, such as company records of disruptive events, National Weather Service historical data, U.S. Geological Survey maps and government agencies such as the Federal Emergency Management Agency, the Department of Homeland Security and the Department of Energy

Grouping risks

After identifying risks and threats, group them into different categories, starting with natural and human-made. Within the human-made category, add deliberate and accidental causes. Natural hazards are typically considered "acts of God" in which there is no one to blame. Table 2 provides an example of risk grouping.

Risks categorized as natural, deliberate, accidental or indirect

Performing a risk analysis

When performing an RA, begin by identifying potential threats and vulnerabilities from the resources previously noted. Analyze the likelihood of an event occurring, the potential severity of the event and the vulnerabilities impacting the situation. Next, calculate an overall risk rating as a product of the likelihood of the event occurring (range – 0.0 = unlikely, to 1.0 = will occur) times the potential severity (range – 0.0 = no damage, to 1.0 = totally destroyed) times the vulnerability (range – 0.0 = highly vulnerable, to 1.0 = totally protected). Table 3 provides an example of this formula (sample data used).

Overall risk rating formula for potential threats

The calculated risk figure in the "hurricane" example means that there is a one in four chance of a hurricane occurring that causes significant damage, based on existing vulnerabilities to severe storms. From the completed table you can identify and prioritize risks for further action.

Once all relevant risks have been analyzed, identify strategies to deal with only the highest risks or you can address all risk categories. The strategies you define for mitigating risks are used to help design disaster recovery strategies, which are used to create disaster recovery plans.

Five most important activities in a risk analysis

The five most important things to do in a risk analysis are:

  1. Define the purpose and scope of the risk analysis, as it helps determine the goals of the RA.
  2. Identify the business functions that may be at risk to further pinpoint the technological and infrastructure reasons for conducting an RA.
  3. Establish the most likely risks that could affect the business functions.
  4. Specify the risk metrics to analyze, such as the statistical probability of a risk occurring.
  5. Determine how the results will be used (mapped with BIA results), e.g., identify business functions and IT assets with the highest risk of disruption.

BIO: Paul Kirvan, CISA, FBCI, is an independent BC/DR consultant and IT auditor. He contributes regularly to SearchDisasterRecovery, and is a member of the Board of the Business Continuity Institute's USA Chapter.

Next Steps

10 DR planning mistakes to avoid

Disaster recovery planning remains hit or miss

Practice makes perfect with DR planning process

This was last published in August 2015

Dig Deeper on Disaster recovery planning - management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Have business impact and risk analyses helped your disaster recovery planning process?
Cancel

-ADS BY GOOGLE

SearchSolidStateStorage

SearchCloudStorage

SearchDataBackup

SearchStorage

Close