• United States




Business Continuity Event Management – An overview

Oct 08, 20083 mins
Business Continuity

The purpose of Business Continuity Event Management (BCEM) is reduction of harm to employees, customers, investors, and the business when an unexpected business interruption—a business continuity event (BCE)–occurs.  In this post, I provide an overview of how to manage a BCE.  In future posts, we’ll incrementally expand this high-level view into a BCEM plan.

When responding to a catastrophic BCE, the first consideration is protection of human life.  Although we’ll address this in our plan, most of our focus will be on managing the smaller events which happen much more frequently. 

The second consideration is the restoration of information processing services. Finally, we need to mitigate people, process, or technology weaknesses which enabled the event—the root causes. BCEM which effectively addresses these areas produces the following benefits for the organization:

  1. The business impact of each incident is minimized
  2. Human safety is addressed
  3. Corporate liability due to lack of due diligence is mitigated
  4. Regulatory requirements are met
  5. The organization’s public image is protected by a fast, professional response

Meeting these objectives requires a process-based approach.  The steps in the process we’ll follow as we move toward a complete BCEM plan are depicted in Figure 1.

Figure 1:  BCEM Process

  • Prepare — Optimal business mitigation is rarely possible unless the organization plans for probable events.  Preparation includes development of manual processes, implementation of redundant systems, documentation of mitigation and recovery plans, and training key personnel.
  • Detect – Early detection of a service interruption helps minimize harm.  Detection tools and techniques are a critical element of a BCEM strategy.
  • Contain and Mitigate – Upon detection, the response team should use act as planned during the Prepare step to either quickly recover the failed process or system, or to implement interim, mitigating processes.  For example, the loss of an order entry system might result in telephone sales staff moving to paper-based order taking to continue accepting customer purchases.
  • Analyze – Once service is restored or mitigated, an analysis of the event provides understanding of root cause as well as possible issues with containment and mitigation processes.  Even if the service is still down, the recovery team should take the time to identify root causes before attempting remediation.  Addressing symptoms instead of the disease results in inevitable recurrences of the event.
  • Remediate and Measure – Using information collected in the analysis step, the recovery team uses an action plan to remove root causes and, if necessary, restore full system operation.  They should then monitor and measure the effectiveness of their remediation steps. 

Results of this process provide feedback to employees responsible for preparation activities.  Lessons learned, especially during incident and response root cause analysis in the Analyze step, are integrated into detection, containment, and mitigation documentation.  It’s also necessary to change recovery team training to account for differences.


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.