• United States




Business Continuity Event Planning: Understanding the business

Oct 15, 20084 mins
Business Continuity

In my last post, I began a series leading to the development of a Business Continuity Event Management (BCEM) plan, with an overview of BCEM management.  In this installment, we’ll continue our examination of event management and response with a closer look at the first step in the process—Prepare.

The core of preparation for a BCE (business continuity event) is a business impact analysis (BIA). However, if the BCEM team doesn’t have a thorough understanding of the business, the results of the BIA might not have much value when planning process recovery. So before we jump into BIA, let’s spend a little time looking at what it means to understand the business.

The BCEM team must understand three fundamental areas of the business: general business operations, threats, and dependencies.

General business operations

The team must first understand business objectives. Why does the business exist? What are its core values? What is its mission statement, its vision statement?   What is the organization’s risk threshold, its willingness to accept various types of risk? 

Next, the team members should investigate and familiarize themselves with local, state, and federal regulations that might affect their approach to response and recovery. In the U.S., for example, the HIPAA mandates availability of accurate, up-to-date, health information. So if a health care provider suffers a BCE which disrupts electronic records management, the results could be severe.

The team should also know the environment in which the business operates. This doesn’t just involve the geographic location and related natural disaster scenarios. Other environmental factors include legal, public relations, and investment conditions affecting the business as well as political stability in supplier countries and the industry in which the business operates. The goal of understanding operations goes beyond recovery and “staying in business.” It also includes assessing long term affects. Affects which linger long after the failed process is restored.

Finally, the team must work with business management to identify and prioritize business critical processes based on the operational information gathered. This is a first pass to get started. During the BIA, some processes may rise higher on the priorities list while others might fall. 

Threat analysis

When assessing threats to critical processes, the team should look at various scenarios, including, 

  • Malicious targeted or general attacks against IT resources. In many cases, these attacks result in shutting down one or more critical segments of the enterprise network. Additional information on threat modeling for these types of attacks is found in A Practical Approach to Threat Modeling.
  • Natural disasters/Fire. It isn’t enough to look at possible disaster scenarios only for the business’ facilities and processes. The team should also include scenarios in which suppliers of products and services might be affected by their local conditions.
  • Political unrest. Political unrest affects both organizations with a global presence and those which obtain product and services from global sources.
  • Disease. Regional or global pandemics deprive businesses and their suppliers of product and services of their most important asset—people.
  • Utility outage


Critical processes rarely function within an operational vacuum. They depend completely or in part on external and internal factors.


Although assessing the interdependencies between the organization and outside entities is part of the first two parts of the prepare step, it’s important enough to the survival of your business to deserve a detailed examination.

External dependencies take many forms, including,

  • Providers of outsourced IT services. Outsourced services might include application hosting, network monitoring and management, and equipment support and maintenance.
  • Providers of critical manufacturing or service delivery products or services. External dependencies are numerous, including

    • Raw materials
    • Subassemblies
    • Credit card processing
    • Call center/help desk
    • Shipping
    • Web site services provider
    • Power


Although part of the same business, other business units might provide unique contributions to one or more critical processes analyzed. In addition to providing materials or services for producing customer output, they might also be responsible for less visible services, like facilities management. Don’t ignore scenarios in which your internal supply chain or support network might fail.

The final word

This is only the first part of the preparation step, but it’s arguably the most important. Without understanding how and why the business functions, critical processes for reaching business objectives, potential threats to process continuity, and internal and external process dependencies, it’s difficult to build and manage a truly effective BCEM plan.

Another output of these activities is a prioritized list of critical processes. The list might look overwhelming, and it might change during the process-centric BIAs we look at in the next post. But as the wise men say, a journey of a thousand miles begins with the first step… an elephant is eaten one bite at a time… Well, you get the idea. 


Tom Olzak is an information security researcher and an IT professional with more than 34 years of experience in programming, network engineering and security. He has an MBA and a CISSP certification. He is an online instructor for the University of Phoenix, facilitating 400-level security classes.

Tom has held positions as an IS director, director of infrastructure engineering, director of information security and programming manager at a variety of manufacturing, healthcare and distribution companies. Before entering the private sector, he served 10 years in the U.S. Army Military Police, with four years as a military police investigator.

Tom has written three books: Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide. He is also the author of various papers on security management and has been a blogger for, TechRepublic, and Tom Olzak on Security.

The opinions expressed in this blog are those of Tom Olzak and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.