InfoSec-Specific Executive Development for
CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive
labs to build you and your team's InfoSec skills
What does a business continuity plan typically include? This piece explains the key components of a typical business continuity plan and recommends ways to ensure the plan is flexible enough to meet all the needs of the organization.
Before specific business continuity plans components can be discussed, it is important to understand the many uses to which a business continuity plan document may be put. Internal teams require more practical detail, whereas such detail – and the
caveats associated – can actively work against the use of a business continuity plan for assurance.
Figure 1 lists the different audiences for a typical business continuity plan, along with how each uses the plan.
Figure 1: BCPs Must Serve Many Audiences and Uses
Internal recovery team
Management, board, etc.
Oversight, assurance, defining metrics
Prospects, customers, partners and auditors
Due diligence, assurance, defining metrics
Source: IANS, 2021
Examining a business continuity plan from a component perspective requires a firm understanding of the plan’s audience and the use to which it will be put. Figure 2 describes key components of an effective business continuity plan and details when
to include each.
Looking at BCP from a component perspective is an interesting exercise, because it requires a firm understanding of the plan’s audience and the use to which it will be put. Figure 2 describes each component of a BCP and details when to include each.
Figure 2: Typical BCP Components
When to Include
Half-page identifying the specific people to contact (phone or instant message) for emergency-related questions
Only when sharing internally
Half-page identifying other contacts, such as fire, ambulance, rescue, police, police non-emergency, Department of Homeland Security (in the U.S.), poison control, the FBI, and related critical contacts
System/ Business Description
Summary section covering the overall plan, surfacing critical metrics, e.g., recovery time objective (RTO), recovery point objective (RPO), service-level agreements (SLAs) etc., and describing what is being recovered
Detailed list of system components with discussions of how they connect and who is responsible for what
Descriptions of offices, data centers, call centers and other facilities, with short summaries of security controls in place and a discussion of how each combination of location/control are to operate during recovery/continuity operations
Only if the business has a high reliance on physical presence; not needed in “work from anywhere” setups
Descriptions of how remote connectivity works during normal operations and how it is expected to work during recovery/continuity operations
Care should be taken as to whether remote connectivity connects users to a “place” (high reliance on physical location) or to a “system” (work from anywhere)
Discussion of whether the recovery uses a hot/hot, hot/warm or hot/cold design (cloud-based businesses may not fit this model, but it will still need to be discussed)
Description of how data moves through the system and how that data flow is expected to change/continue during recovery/continuity
Only for internal use and/or assurance; never share externally without a non-disclosure agreement (NDA)
Detailed list of assumptions made during the creation of the plan so rapid assessment of the plan’s applicability under specific circumstances can be assessed
Only when sharing internally
Listing of outage types, ranked from least to most severe. Include critical metrics, such as:
Even if the “classic” outage types are unlikely to cause damage – such as short-term power outages when on-site UPS provides for 12 hours of power – they should be discussed here because this is where people will
look for assurance.
Always, but only include ART for internal audiences (never external audiences)
Multiple sections detailing which systems are to be recovered in which order. Consider technical dependencies as well as recovery of systems/ processes that will “buy time” during the recovery, allowing other business groups
to be effective.
Only when driving internal work; exclude when sharing externally or for assurance purposes
Discussion of which teams are expected to take on specific roles during the recovery/continuity operations
Discussion of which roles otherwise non-essential teams are to take on during recovery. For example, it is wise to repurpose a sales team into a customer assurance team because they have no direct recovery/continuity role and customer
inquiries are likely to increase during such operations.
Only when sharing internally to guide internal practices
Discussion around all the types of connectivity the organization requires and any methods of redundancy, as well as how workers are to access systems and communicate with one another while connectivity is problematic
Only if system/environment is complex and guidance is needed (e.g., exclude if cloud provider handles connectivity redundancy)
Detailed list of which internal roles are expected to contact which external parties, such as designating a specific executive for public relations and another for operational oversight, or delegating communications with insurance to the
finance or risk departments.
List of business-critical partners, description of what each does, their contact information and a discussion of how the partner fits into the recovery/continuity operations as well as what recovery/continuity operations exist for the
Description of who is empowered to declare a disaster, who is to declare a disaster in their absence, and what processes are to be followed when deciding a disaster must be declared.
Detailed procedure of activating the plan, identifying which roles perform which actions when, where the checkpoints may be, and what steps are to be taken should a primary path fail.
This process requires considerable thought because some triggering events (aka disasters) can result in personnel unavailability. Process and personnel redundancy is essential.
Plan Activation Checklist
Pairs with the Activation Process, ensuring that all dependencies are met during the activation process.
Discussion of how business is expected to operate during a pandemic. Traditionally not emphasized, pandemic planning has grown in prominence in the last year.
While most disaster declaration processes tend to skip human resources (HR), it is wise to give the director of HR the power to declare pandemic continuity operations, with board-level overrides.
Discussion of “classic” disaster types and the type of preparedness in place to reduce the overall risk of such events.
Even if the “classic” disaster types are unlikely to cause damage – such as tornadoes for an underground bunker – they should be discussed here because this is where people will look for assurance.
Discussion of how the business expects to continue to provide paychecks to personnel as well as pay for non-standard expenses while in recovery/continuity operations.
Recovery Administrative Support
Discussion of how record-keeping, status meetings, communications and other critical “invisible labor” elements of the business will continue to function during recovery/continuity operations.
These are potentially political issues. It is important to plan for this work, but in practice, if this section is omitted, specific individuals will likely step forward to ensure these actions are taken. Recognizing this fact can cause
political blow-back, but not recognizing it can cause put-upon workers to leave the organization after recovery is complete.
Recovery HR Support
Discussion of how employee issues are to be addressed during recovery/continuity operations. Including, but not limited to:
* Disasters can involve circumstances that make illnesses and injuries more likely than normal.
Detailed section discussing how often disaster recovery/business continuity tests are to be run, how they are to be run, and who is responsible for ensuring they are run properly.
In complex environments, this section can define how often “full” tests are run vs “bubble” tests.
Always, but reduce to a summary for external use
List of previous tests, results compared to RTO/RPO, and explanations for deviations.
Pre-defined scripts to use when communicating recovery/continuity transitions to customers, clients, partners, workers, the press, government officials, etc.
Impact Analysis/ Lessons Learned
Discussion of what was learned from the previous execution of this plan – either live or through a tabletop exercise
A business continuity plan can be a robust document or a simple list of expectations. There are no firm requirements – other than the document must meet the needs of its audience. Additionally, the increasing adoption of cloud-based technologies
shifts the need for such plans from point-wise procedural documents to more comprehensive business-level essays of consideration.
Whatever you do to create your business continuity plan, it is extremely likely your first draft will be lacking – sometimes significantly so. Do not let this fact keep you from continually revising the plan so it best fits all the needs of the
organization. A solid business continuity plan can take years to iterate into, but it is possible, and the process can be valuable in unexpected ways.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
December 8, 2022
By IANS Faculty
Find best practices for ensuring the security of your organization’s OT environment using this checklist based on the Purdue Reference Model for industrial control network segmentation.
December 6, 2022
By IANS Research
Improve your attack surface management plan using 9 steps to mitigate risk and strengthen enterprise security posture.
December 1, 2022
Improve your vendor management program using six focus areas to benchmark program maturity and identify key pitfalls to avoid.