Business Continuity Event Planning: Analysis and Remediation

In this post of the Business Continuity Event Management (BCEM) series, we continue event response and recovery planning with a transition from incident response to recovery operations. 

The first step in handling a business continuity event (BCE) is an effective response.  Once the situation is stabilized, analysis and remediation (recovery) can begin.

The core of the analysis and remediation phase is the Business Continuity Plan.  According to BS 25999-1:2006 (p. 33),

The purpose of a business continuity plan (BCP) is to enable an organization to recover or maintain its activities in the event of a disruption to normal business operations. 

BCPs are activated (invoked) to support the critical activities required to deliver the organization’s objectives.  They may be invoked in whole or in part and at any stage of the response to an incident.

The BCP must contain information sufficient to allow recovery of critical systems and implementation of failed process workarounds.  It should also include contact information for all stakeholders, recovery team members, and technology vendors.  All of this information should have been collected during understanding the business and BIA activities.

In many organizations, the BCP is seen as a disaster recovery plan, a plan to recover from catastrophic events.  Although it must contain DR documentation, it should also support less pervasive recovery operations.  The following is a descriptive list of required components for a basic BCP:

• Event Management.   This section includes:

  • Team lead names and contact information
  • The conditions under which the plan may be invoked
  • Communication of recovery invocation and progress
  • Definition of roles and responsibilities 
  • Reporting and communication centers for recovery personnel
  • Information about when and how to move operations to one or more alternate sites

• System Recovery.  A section should exist for each critical process, and should include:

  • Instructions for rebuilding technology
  • Technology vendor contacts for each externally supported component
  • List of dependent processes
  • List of affected internal and external stakeholders
  • Workarounds, both manual and technical
• Templates.  Templates for documenting all BCP recovery activities.

The final component of an effective BCP is testing.  The first time a team member sees the BCP should not be at 2 P.M. the day of an event.  Not all testing requires a trip to an alternate site.  The type of test performed is dictated by the test objectives.

For example, if you want to simply ensure completeness of documentation or to strengthen team familiarity with a system’s recovery process, getting everyone into a conference room for a documentation-based walkthrough is an inexpensive what to check your work.  If, however, you want to know if following the documentation actually results in system recovery, you will want to send a team to the alternate site for the test.

All results should be documented during the test and used to modify the BCP, if necessary.