Contingency Plan Policy

Contingency Plan Policy
Policy #:
Version #: 1.0
Approved By:
Effective Date:
Purpose:
The purpose is to establish and implement, as needed, policies and procedures for responding to an
emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that
damages systems that contain sensitive information.
A contingency plan is a routinely updated plan for responding to a system emergency that includes
performing backups, preparing critical facilities, and appropriately detailed migration plans that can be
used to facilitate continuity of operations in the event of an emergency and recovering from a disaster.
Scope:
This policy applies to <<Organization Name>> in its entirety, including all workforce members. Further,
the policy applies to all systems, network, and applications that process, store or transmit sensitive
information.
Policy:
<<Organization Name>> will develop contingency plan documents to identify core activities in the areas
of Data Backup Plan, Disaster Recovery Plan, Emergency Mode Operation Plan, Testing and Revision,
and Applications and Data Criticality Analysis.
<<Organization Name>> will develop and implement a contingency plan to ensure the confidentiality,
integrity, and availability of sensitive information during and after an emergency.
The core objectives of contingency planning include the capability to:
 Restore operations at an alternate site (if necessary)

 Recover operations using alternate equipment (if necessary)
 Perform some or all of the affected business processes using other means
The contingency plan will be developed for the entire enterprise. The contingency plan must address IT
system components such as:
 Local, wide area and wireless networks including Internet access (if critical to the operation of the
business)
 Server systems such as file, application, print and database
 Web sites
 Security systems such as firewalls, authentication servers, and intrusion detection
 Desktop, laptop, PDA systems
<<Organization Name>> will follow the recommendations of The National Institute of Standards and
Technology (NIST) in the area of contingency planning. The NIST recommends following seven key steps
to address the requirements of contingency planning. These seven key steps for contingency planning
are:
1. Develop the contingency policy objective statement
2. Conduct a Business Impact Analysis (BIA)
3. Identify preventive controls
4. Develop recovery strategies
5. Create the contingency plan
6. Conduct testing and training
7. Review and maintenance
Let us review of the steps to better understand how we may be able to meet contingency planning
requirements.
Step 1: Contingency Policy Objective Statement

The first step for the organization to address the requirements associated with contingency planning is to
very clearly define the contingency planning policy. The core objective of the policy statement is to
establish the organizational framework and responsibilities for contingency planning. NIST recommends
that the contingency policy address the following topics:
 Roles and responsibilities

 Scope of policy with respect to systems/platforms and organizations functions
subject to contingency planning
 Resource requirements
 Training requirements
 Exercise and testing schedules
 Plan maintenance schedule
 Frequency of backups and storage of backup media
Step 2: Business Impact Analysis (BIA)

One of the critical steps in contingency planning is Business Impact Analysis (BIA). BIA helps to identify
and prioritize critical Information Technology (IT) systems and components. IT systems may have
numerous components, interfaces and processes. BIA enables a complete characterization of:
 System requirements
 Processes
 Interdependencies
As part of the BIA process, information is collected, analyzed and interpreted. The information provides
the basis for defining contingency requirements and priorities.
The objective is to understand the impact of a threat on the business. The impact of the threat may be
economical, operational or both. Questionnaires or survey tools may be used to collect the information.
BIA is performed at the beginning of disaster recovery and continuity planning to specifically identify the
areas that would suffer the greatest financial or operational loss in the event of a disaster or disruption. A
key objective is to identify all critical systems that are required for the continuity of the business. Further, a
determination of the time it would take to recover such systems in the event of a loss.
The critical steps for BIA include the need to:
1. Identify critical business functions

2. Identify disruption impacts and allowable outage times
3. Develop recovery priorities
Step 3: Preventive Controls
The BIA provides vital information regarding system availability and recovery requirements. It may be
possible to mitigate some outage impacts identified in the BIA through preventive controls. The objective
of preventive controls is to deter, detect, and/or reduce impacts to the system. Wherever possible,
preventive controls are preferable to actions to recover the system after a disruption.
Step 4: Recovery Strategies

The objective of recovery strategies is to restore IT operations quickly and effectively following a
disruption. A critical focus is to provide access to all sensitive information. Several factors will influence
recovery strategy including cost, allowable outage time, security and integration with larger
organizational-level contingency plans.
The choice for the recovery approach would depend on the incident, type of system and its operational
requirements. Technologies such as Redundant Arrays of Independent Disks (RAID), automatic fail-over,
Uninterruptible Power Supply (UPS), and mirrored systems should be considered when developing a
system recovery strategy.
Step 5: Development of Contingency Plan

The contingency plan contains detailed roles, responsibilities, teams, and procedures associated with
restoring critical systems following a disruption. The contingency plan should document technical
capabilities designed to support contingency operations. The contingency plan should be tailored to the
organization and its requirements.
Plans need to balance detail with flexibility; usually the more detailed the plan is, the less scalable and
versatile the approach. The NIST identifies five main components of the contingency plan. They are:
1. Supporting Information
2. Notification/Activation Phase
3. Recovery Phase
4. Reconstitution Phase
5. Plan Appendices
Step 6: Testing and Training

Testing of the plan is a critical element of a viable contingency capability. Testing enables plan
deficiencies to be identified and addressed. Testing also helps evaluate the ability of the recovery staff to
implement the plan quickly and effectively. Each IT contingency plan element should be tested to confirm
the accuracy of individual recovery procedures and the overall effectiveness of the plan. The following
areas should be addressed in a contingency test:
 System recovery on an alternate platform from backup media

 Coordination among recovery teams
 Internal and external connectivity
 System performance using alternate equipment
 Restoration of normal operations
 Notification procedures.
Step 7: Review and Maintenance

To be effective, the plan must be maintained in a ready state that accurately reflects system
requirements, procedures, organizational structure, and policies. IT systems undergo frequent changes
because of shifting business needs, technology upgrades, or new internal or external policies. Therefore,
it is essential that the contingency plan be reviewed and updated regularly, as part of the organization’s
change management process, to ensure new information is documented and contingency measures are
revised if required. As a general rule, the plan should be reviewed for accuracy and completeness at least
annually or whenever significant changes occur to any element of the plan.
Responsibilities:
The Security Officer is responsible for leading compliance activities that bring <<Organization Name>>
into compliance with regulatory requirements in areas such as:
 Data backup plan

 Disaster recovery plan
 Emergency mode operation plan
 Testing and revision
 Application and data criticality analysis
Compliance:
Failure to comply with this or any other security policy will result in disciplinary actions as per the HR
XXXXX Policy. Legal actions also may be taken for violations of applicable regulations and standards
such as state and federal rules to include the Family Educational Rights and Privacy Act (FERPA).
Procedure(s):
Procedures related to the Contingency Plan standard include:
 Data backup
 Disaster recovery
 Emergency mode operations
 Testing and revision
 Applications and data criticality analysis
Form(s):
 Business Impact Analysis (BIA) Report
References:
 The Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99)
 International Standards Organization (ISO 27002).
Contact:
John Doe, Security Officer
1234 Anystreet
Anywhere, WY XXXXX
E: [email protected]
P: 307.XXX.XXXX
F: 307.XXX.XXXX
Policy History: Initial effective date: July 1, 2015

Contingency Plan Policy

Uploaded by

Copyright:

Available Formats

Contingency Plan Policy

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Contingency Plan Policy

Uploaded by

Copyright:

Available Formats

Contingency Plan Policy

The core objectives of contingency planning include the capability to:

 Restore operations at an alternate site (if necessary)

Step 1: Contingency Policy Objective Statement

 Roles and responsibilities

Step 2: Business Impact Analysis (BIA)

The critical steps for BIA include the need to:

1. Identify critical business functions

Step 4: Recovery Strategies

Step 5: Development of Contingency Plan

Step 6: Testing and Training

 System recovery on an alternate platform from backup media

Step 7: Review and Maintenance

 Data backup plan

Policy History: Initial effective date: July 1, 2015

You might also like