• United States




Business Continuity Event Planning: Documentation Overview

Nov 04, 20083 mins
Business Continuity

In previous posts, we stepped through the process of understanding the business, the threats it faces related to business continuity, and how prepared it is to prevent, detect, or respond to events.  We continue with our look at Business Continuity Event Management (BCEM) planning by looking at developing and managing the two key BCEM documents: the incident response plan (IRP) and the business continuity plan (BCP).

In this article, I provide an overview of these plans and their relationship to each other.  In the subsequent two articles, we examine in detail the content of each document.  We’ll also discuss implementation and management of the processes the documents describe.

Documenting the BCEM Plan

Handling business continuity events (BCE) requires two perspectives.  First, recovery teams must understand the framework used to detect, contain, recover, and manage events.  Second, recovery teams and business users must have solid, tested processes for mitigating BCE impact and restoring services to levels existing before the event.  The BCEM planning team should document these processes, tools, and techniques in an IRP and a BCP. 

The combined goals of the IRP and the BCP are depicted in Figure 1.  IRP activities begin immediately upon detection of an event.  Impact mitigation is implementation of BCP processes intended to provide workarounds for failed processes.  Recovery and management tasks, also initiated by the BCP, return the company to normalcy.  Note that the Recovery & Management arrow extends beyond the event timeline.  This represents the long term impact of management efforts to improve prevention, response, mitigation, and recovery outcomes via an event after action review.

 Figure 1

Incident Response Plan

Processes defined in the IRP initiate when an event is identified.  According to BS 25999-1:2006, the IRP is “concerned with the development and implementation of appropriate plans and arrangements to ensure continuity of critical activities and the management of an incident.”  It is the incident response team which assesses the type and scope of the incident, who to notify, and to what extent the BCP is to be implemented.  I also works with recovery teams to complete the after action review.

At a high level, the IRP includes containment, mitigation, communication, eradication (malware events), and after action improvement activities. 

Business Continuity Plan

A BCP includes all documentation necessary to mitigate business impact and to recover broken processes:

  • Manual processes to continue product or service delivery, even if at a lower level of output, until full recovery is possible
  • Individual device or system recovery instructions
  • Disaster recovery processes for catastrophic events
  • Contracts/agreements for alternate data center or business office sites as well as alternate staffing

The final word

The combination of the IRP—the overall plan for handling an incident—and the BCP should result in minimal business impact, process recovery within MTDs, and a final review of root causes as well as how the teams might do better next time… and there will be a next time.

 In the next article, I step through building an IRP, assembling a response team, team training, and plan testing and improvement.


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.