NIST Special Publication 800-34 Rev. 1
Contingency Planning Guide for
Federal Information Systems
Marianne Swanson
Pauline Bowen
Amy Wohl Phillips
Dean Gallup
David Lynes
NIST Special Publication 800-34 Rev. 1
Contingency Planning Guide for
Federal Information Systems
Marianne Swanson
Pauline Bowen
Amy Wohl Phillips
Dean Gallup
David Lynes
May 2010
U.S. Department of Commerce
Gary Locke, Secretary
National Institute of Standards and Technology
Patrick D. Gallagher, Director
Certain commercial entities, equipment, or materials may be identified in this document in
order to describe an experimental procedure or concept adequately. Such identification is not
intended to imply recommendation or endorsement by the National Institute of Standards and
Technology, nor is it intended to imply that the entities, materials, or equipment are
necessarily the best available for the purpose.
There are references in this publication to documents currently under development by NIST in
accordance with responsibilities assigned to NIST under the Federal Information Security
Management Act of 2002. The methodologies in this document may be used even before the
completion of such companion documents. Thus, until such time as each document is
completed, current requirements, guidelines, and procedures (where they exist) remain
operative. For planning and transition purposes, federal agencies may wish to closely follow
the development of these new documents by NIST. Individuals are also encouraged to review
the public draft documents and offer their comments to NIST.
All NIST documents mentioned in this publication, other than the ones noted above, are
available at http://csrc.nist.gov/publications.
National Institute of Standards and Technology Special Publication 800-34
Natl. Inst. Stand. Technol. Spec. Publ. 800-34, 150 pages (May 2010)
CODEN: NSPUE2
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of
concept implementations, and technical analysis to advance the development and productive use of
information technology. ITL’s responsibilities include the development of technical, physical,
administrative, and management standards and guidelines for the cost-effective security and privacy of
sensitive unclassified information in federal computer systems. This Special Publication 800-series
reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative
activities with industry, government, and academic organizations.
ii
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Authority
This document has been developed by the National Institute of Standards and Technology (NIST) in
furtherance of its statutory responsibilities under the Federal Information Security Management Act
(FISMA) of 2002, Public Law 107-347.
NIST is responsible for developing standards and guidelines, including minimum requirements, for
providing adequate information security for all agency operations and assets, but such standards and
guidelines shall not apply to national security systems. This guideline is consistent with the requirements
of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency
Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental
information is provided in A-130, Appendix III.
This guideline has been prepared for use by federal agencies. It may be used by nongovernmental
organizations on a voluntary basis and is not subject to copyright. Attribution would be appreciated by
NIST.
Nothing in this document should be taken to contradict standards and guidelines made mandatory and
binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these
guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official.
NIST Special Publication 800-34, Revision 1, 150 pages
(May 2010)
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
iii
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Compliance with NIST Standards and Guidelines
NIST develops and issues standards, guidelines, and other publications to assist federal agencies in
implementing the Federal Information Security Management Act (FISMA) of 2002 and in managing costeffective programs to protect their information and information systems.
1
•
Federal Information Processing Standards (FIPS) are developed by NIST in accordance with
FISMA. FIPS are approved by the Secretary of Commerce and are compulsory and binding for
federal agencies. Since FISMA requires that federal agencies comply with these standards,
agencies may not waive their use.
•
Guidance documents and recommendations are issued in the NIST Special Publication (SP) 800series. Office of Management and Budget (OMB) policies (including OMB FISMA Reporting
Instructions for the Federal Information Security Management Act and Agency Privacy
Management) state that, for other than national security programs and systems, agencies must
follow NIST guidance. 1
•
Other security-related publications, including NIST interagency and internal reports (NISTIRs)
and ITL Bulletins, provide technical and other information about NIST’s activities. These
publications are mandatory only when so specified by OMB.
While agencies are required to follow NIST guidance in accordance with OMB policy, there is flexibility within NIST’s
guidance in how agencies apply the guidance. Unless otherwise specified by OMB, the 800-series guidance documents
published by NIST generally allow agencies some latitude in the application. Consequently, the application of NIST guidance
by agencies can result in different security solutions that are equally acceptable, compliant with the guidance, and meet the
OMB definition of adequate security for federal information systems. When assessing federal agency compliance with NIST
guidance, auditors, evaluators, and assessors should consider the intent of the security concepts and principles articulated
within the particular guidance document and how the agency applied the guidance in the context of its specific mission
responsibilities, operational environments, and unique organizational conditions.
iv
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Acknowledgements
The authors, Marianne Swanson and Pauline Bowen of the National Institute of Standards and
Technology (NIST), Amy Wohl Phillips, Dean Gallup, and David Lynes of Booz Allen Hamilton, wish to
thank their colleagues who reviewed drafts of this document and contributed to its technical content. The
authors would like to acknowledge Kelley Dempsey, Esther Katzman, Peter Mell, Murugiah Souppaya,
Lee Badger, and Elizabeth Lennon of NIST, and David Linthicum of Booz Allen Hamilton for their keen
and insightful assistance with technical issues throughout the development of the document.
v
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Table of Contents
Executive Summary....................................................................................................................1
Chapter 1.
1.1
1.2
1.3
1.4
Chapter 2.
2.1
2.2
Chapter 3.
3.1
3.2
3.3
3.4
3.5
3.6
Chapter 4.
4.1
4.2
4.3
Introduction ....................................................................................................1
Purpose....................................................................................................................... 1
Scope.......................................................................................................................... 2
Audience ..................................................................................................................... 3
Document Structure .................................................................................................... 4
Background ....................................................................................................5
Contingency Planning and Resilience ........................................................................ 5
Types of Plans ............................................................................................................ 7
2.2.1 Business Continuity Plan (BCP) ......................................................................8
2.2.2 Continuity of Operations (COOP) Plan............................................................8
2.2.3 Crisis Communications Plan............................................................................9
2.2.4 Critical Infrastructure Protection (CIP) Plan.....................................................9
2.2.5 Cyber Incident Response Plan ......................................................................10
2.2.6 Disaster Recovery Plan (DRP) ......................................................................10
2.2.7 Information System Contingency Plan (ISCP)...............................................10
2.2.8 Occupant Emergency Plan (OEP).................................................................10
Information System Contingency Planning Process................................13
Develop the Contingency Planning Policy Statement ............................................... 14
Conduct the Business Impact Analysis (BIA)............................................................ 15
3.2.1 Determine Business Processes and Recovery Criticality..............................16
3.2.2 Identify Resource Requirements ...................................................................19
3.2.3 Identify System Resource Recovery Priorities ..............................................19
Identify Preventive Controls ...................................................................................... 19
Create Contingency Strategies ................................................................................. 20
3.4.1 Backup and Recovery ...................................................................................20
3.4.2 Backup Methods and Offsite Storage............................................................21
3.4.3 Alternate Sites ...............................................................................................21
3.4.4 Equipment Replacement ...............................................................................24
3.4.5 Cost Considerations ......................................................................................25
3.4.6 Roles and Responsibilities ............................................................................26
Plan Testing, Training, and Exercises (TT&E) .......................................................... 27
3.5.1 Testing...........................................................................................................27
3.5.2 Training..........................................................................................................28
3.5.3 Exercises .......................................................................................................29
3.5.4 TT&E Program Summary ..............................................................................29
Plan Maintenance ..................................................................................................... 31
Information System Contingency Plan Development...............................34
Supporting Information.............................................................................................. 35
Activation and Notification Phase ............................................................................. 36
4.2.1 Activation Criteria and Procedure..................................................................36
4.2.2 Notification Procedures .................................................................................36
4.2.3 Outage Assessment ......................................................................................38
Recovery Phase........................................................................................................ 39
4.3.1 Sequence of Recovery Activities ...................................................................39
vi
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
4.4
4.5
Chapter 5.
5.1
5.2
5.3
5.4
5.5
4.3.2 Recovery Procedures ....................................................................................39
4.3.3 Recovery Escalation and Notification ............................................................40
Reconstitution Phase ................................................................................................ 41
Plan Appendices ....................................................................................................... 42
Technical Contingency Planning Considerations.....................................43
Common Considerations .......................................................................................... 43
5.1.1 Use of the BIA ...............................................................................................44
5.1.2 Maintenance of Data Security, Integrity, and Backup....................................44
5.1.3 Protection of Resources ................................................................................46
5.1.4 Adherence to Security Controls.....................................................................46
5.1.5 Identification of Alternate Storage and Processing Facilities.........................46
5.1.6 Use of High Availability (HA) Processes........................................................48
Client/Server Systems .............................................................................................. 48
5.2.1 Client/Server Systems Contingency Considerations .....................................49
5.2.2 Client/Server Systems Contingency Solutions ..............................................51
Telecommunications Systems .................................................................................. 52
5.3.1 Telecommunications Contingency Considerations........................................53
5.3.2 Telecommunications Contingency Solutions.................................................54
Mainframe Systems .................................................................................................. 56
5.4.1 Mainframe Contingency Considerations........................................................56
5.4.2 Mainframe Contingency Solutions.................................................................56
System Contingency Planning Considerations Summary......................................... 57
Appendix A— Sample Information System Contingency Plan Templates ..................... A.1-1
A.1
A.2
A.3
Sample Template for Low-Impact Systems....................................................... A.1-1
Sample Template for Moderate-Impact Systems .............................................. A.2-1
Sample Template for High-Impact Systems ...................................................... A.3-1
Appendix B— Sample Business Impact Analysis (BIA) and BIA Template ...................... B-1
Appendix C— Frequently Asked Questions......................................................................... C-1
Appendix D— Personnel Considerations in Continuity and Contingency Planning........ D-1
Appendix E— Contingency Planning Controls .................................................................... E-1
Appendix F— Contingency Planning and the System Development Life Cycle (SDLC).. F-1
Appendix G— Glossary..........................................................................................................G-1
Appendix H— Acronyms........................................................................................................ H-1
Appendix I— Resources...........................................................................................................I-1
List of Figures
Figure 2-1: Contingency-Related Plan Relationships ................................................................12
Figure 3-1: Contingency Planning Process................................................................................13
Figure 3-2: Business Impact Analysis Process for the Information System...............................16
Figure 3-3: Cost Balancing ........................................................................................................18
Figure 4-1: Contingency Plan Structure.....................................................................................34
vii
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Figure 4-2: Sample Call Tree.....................................................................................................37
Figure 4-3: Sample Recovery Process ......................................................................................40
Figure F-1: System Development Life Cycle ........................................................................... F-1
List of Tables
Table 2-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderate-,
and High-Impact Systems of Contingency-Related Plans.....................................................7
Table 2-2: Type of Plans.............................................................................................................11
Table 3-1: Information System Resource/Component Table .....................................................19
Table 3-2: FIPS 199 Category Backup & Strategy Examples....................................................20
Table 3-3: Sample Alternate Site Criteria ..................................................................................23
Table 3-4: Contingency Strategy Budget Planning Template ....................................................25
Table 3-5: ISCP TT&E Activities ................................................................................................30
Table 3-6: Sample Record of Changes......................................................................................32
Table 5-1: Summary ..................................................................................................................58
Table E-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderateand High- Impact Systems of Contingency-Related Plans................................................ E-1
Table F-1: CP Control Implementation in the SDLC ................................................................ F-4
viii
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Errata
The following changes have been incorporated into Special Publication 800-34, Revision 1, as of the date
indicated in the table.
DATE
5/21/2010
5/21/2010
TYPE
Editorial
Editorial
CHANGE
Remove hyphenation from “Wohl Phillips”
Change “mission/business functions” to
“mission/business processes”
5/21/2010
Editorial
Remove hyphenation from “mission essential”
5/21/2010
Editorial
5/21/2010
Editorial
5/21/2010
5/21/2010
5/21/2010
Editorial
Editorial
Substantive
5/21/2010
Editorial
5/21/2010
5/21/2010
Editorial
Substantive
5/21/2010
Editorial
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
5/21/2010
Editorial
Substantive
5/21/2010
Substantive
5/21/2010
Editorial
5/21/2010
Editorial
5/21/2010
Editorial
Correct number of Contingency Planning security
controls to 9
Change “information system contingency plan” to
“ISCP”
Change caption from “Plan Types” to “Types of Plans”
Change “mission essential functions” to “MEFs”
Clarify the relationship between Mean Tolerable
Downtime and Recovery Point Objective
Change “continuity planners” to “contingency
planners”
Change “missions” to “mission”
Add “and scope” to the description of system backup
policies specifications
Change “Information Systems Planning” to “ISCP” in
footnote
Change “applications” to “systems”
Change “information technology systems” to
“information systems”
Change “Special Publication” to “SP”
Clarify the Contingency Plan Test/Exercise
requirement for Contingency Plan Control-4 (CP-4).
Change “All” to “Low Impact = Yes
Mod. Impact = Yes
High Impact = Yes”
Add Contingency Plan Control-4 (CP-4) to the
Alternate Processing Site Recovery event; Change
Moderate Impact requirement from “Yes” to “N/A”
Add commas around “as part of the organization’s
change management process” in the plan maintenance
description of reviewing and updating the ISCP
Figure 4-2, Sample Call Tree, align and remove
shadow
Remove “and applications” from the Sequence of
Recovery Activities
ix
PAGE NUMBER
v
ES-1, 1, 2, 3, 7, 8,
10, 11, 13, 15, 16,
18, 19, 20, 21, 40,
44, 47, 48, 56 A.14, A.2-4, A.3-4, B1, B-2, B-3, B-4, C1, C-2, C-3, C-4, E2, F-2, G-1, G-2
2, 5, 8, C-1, G-1,
H-2
6
10
11
11, C-1, C-2
17
17
20
21
21
23, B-4
24, C-1
30
30
30
31
37
39
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
DATE
5/21/2010
TYPE
Editorial
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
Editorial
5/21/2010
Substantive
5/21/2010
Editorial
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
Substantive
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
Substantial
5/21/2010
Editorial
5/21/2010
5/21/2010
Editorial
Substantive
5/21/2010
Substantive
5/21/2010
Substantive
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
5/21/2010
Editorial
Editorial
5/21/2010
5/21/2010
5/21/2010
11/11/2010
Editorial
Editorial
Editorial
Substantive
CHANGE
Change “backup application” to “backup solution” in
the description of Backup Software
Change “discloser” to “disclosure”
Remove “major applications and general support” from
system description
Change “Mission, National, or Primary Essential
Functions” to “Mission, Primary, or National Essential
Functions”
Spell out “ISDN” as “Integrated Services Digital
Network (ISDN)”; add “with a bandwith of 128Kbps”
for clarification
Change “Information System Contingency Plan
(ISCP)” to “ISCP”
Change “Contingency Plan” to “ISCP”
Change “contingency plan coordinator” to “ISCP
Coordinator”
Change “be needed” to “need”
Change “Section 4.1 of the plan” to “Section 4.2.1 of
this plan”, in reference to location of system functions
Add to directions for Recovery Procedures “If an
alternate location is part of the recovery strategy,
include procedures for recovery to that site.”
Correct section numbering starting at 5.6
Change “System Validation Test Plan” to “system
validation test plan” in Appendix E
Clarify “at least yearly” to “at the organization defined
frequency (e.g., yearly)”
Change “and exercise and questions” to “and an
exercise and questions”
Correct reference number to Offsite Data Storage
Remove “For moderate impact systems, a yearly
functional test is required.” This is not a requirement.
Remove “For high impact systems, a yearly functional
test is required.” This is not a requirement.
Change “Incident Response Plan (IRP)” to “Cyber
Incident Response Plan”
Add “Information System Contingency Plan”
Change “operation/maintenance” to
“Operation/Maintenance”
Change “Business Impact Analysis (BIA)” to “BIA”
Change “Primary Mission Essential Functions” to
“primary mission essential functions”
Add “(MTD)” after “mean tolerable downtime”
Add “and Contingency” to the Appendix title
Add “(BCP) after “business continuity plan”
Replaced Section 5.2 with Data Functionality Testing
template text and direction. Previous text was a repeat
of Section 5.3.
x
PAGE NUMBER
45
46
54
54
55
A.1-4, A.2-4, A.34, B-1, D-1
A.1-5, A.3-5
A.1-7, A.2-7, A.3-7
A.1-7, A.2-7, A.3-7
A.1-7, A.2-7, A.3-7
A.1-8
A.1-9
A.1-12, A.2-12,
A.3-12
A.1-13, A.2-14,
A.3-15
A.1-13, A.2-14,
A.3-15
A.2-9, A.3-10
A.2-14
A.3-15
B-1
B-1
C-2
C-2
C-3
C-3
D-1
D-1
A.3-8
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Executive Summary
NIST Special Publication 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems,
provides instructions, recommendations, and considerations for federal information system contingency
planning. Contingency planning refers to interim measures to recover information system services after a
disruption. Interim measures may include relocation of information systems and operations to an
alternate site, recovery of information system functions using alternate equipment, or performance of
information system functions using manual methods. This guide addresses specific contingency planning
recommendations for three platform types and provides strategies and techniques common to all systems.
Client/server systems;
Telecommunications systems; and
Mainframe systems.
This guide defines the following seven-step contingency planning process that an organization may apply
to develop and maintain a viable contingency planning program for their information systems. These
seven progressive steps are designed to be integrated into each stage of the system development life cycle.
1. Develop the contingency planning policy statement. A formal policy provides the authority
and guidance necessary to develop an effective contingency plan.
2. Conduct the business impact analysis (BIA). The BIA helps identify and prioritize information
systems and components critical to supporting the organization’s mission/business processes. A
template for developing the BIA is provided to assist the user.
3. Identify preventive controls. Measures taken to reduce the effects of system disruptions can
increase system availability and reduce contingency life cycle costs.
4. Create contingency strategies. Thorough recovery strategies ensure that the system may be
recovered quickly and effectively following a disruption.
5. Develop an information system contingency plan. The contingency plan should contain
detailed guidance and procedures for restoring a damaged system unique to the system’s security
impact level and recovery requirements.
6. Ensure plan testing, training, and exercises. Testing validates recovery capabilities, whereas
training prepares recovery personnel for plan activation and exercising the plan identifies
planning gaps; combined, the activities improve plan effectiveness and overall organization
preparedness.
7. Ensure plan maintenance. The plan should be a living document that is updated regularly to
remain current with system enhancements and organizational changes.
This guide presents three sample formats for developing an information system contingency plan based
on low-, moderate-, or high-impact level, as defined by Federal Information Processing Standard (FIPS)
199, Standards for Security Categorization of Federal Information and Information Systems. Each
format defines three phases that govern actions to be taken following a system disruption. The
Activation/Notification Phase describes the process of activating the plan based on outage impacts and
notifying recovery personnel. The Recovery Phase details a suggested course of action for recovery
teams to restore system operations at an alternate site or using contingency capabilities. The final phase,
ES-1
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Reconstitution, includes activities to test and validate system capability and functionality and outlines
actions that can be taken to return the system to normal operating condition and prepare the system
against future outages.
ES-2
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Chapter 1.
Introduction
Information systems are vital elements in most mission/business processes. Because information system
resources are so essential to an organization’s success, it is critical that identified services provided by
these systems are able to operate effectively without excessive interruption. Contingency planning
supports this requirement by establishing thorough plans, procedures, and technical measures that can
enable a system to be recovered as quickly and effectively as possible following a service disruption.
Contingency planning is unique to each system, providing preventive measures, recovery strategies, and
technical considerations appropriate to the system’s information confidentiality, integrity, and availability
requirements and the system impact level.
Information system contingency planning refers to a coordinated strategy involving plans, procedures,
and technical measures that enable the recovery of information systems, operations, and data after a
disruption. Contingency planning generally includes one or more of the following approaches to
restore disrupted services:
Restoring information systems using alternate equipment;
Performing some or all of the affected business processes using alternate processing (manual)
means (typically acceptable for only short-term disruptions);
Recovering information systems operations at an alternate location (typically acceptable for
only long–term disruptions or those physically impacting the facility); and
Implementing of appropriate contingency planning controls based on the information system’s
security impact level.
This document provides guidelines to individuals responsible for preparing and maintaining information
system contingency plans (ISCPs). The document discusses essential contingency plan elements and
processes, highlights specific considerations and concerns associated with contingency planning for
various types of information system platforms, and provides examples to assist readers in developing their
own ISCPs.
1.1
Purpose
This publication assists organizations in understanding the purpose, process, and format of ISCP
development through practical, real-world guidelines. While the principles establish a baseline to meet
most organizational needs, it is recognized that each organization may have additional requirements
specific to its own operating environment. This guidance document provides background information on
interrelationships between information system contingency planning and other types of security and
emergency management-related contingency plans, organizational resiliency, and the system development
life cycle (SDLC). The document provides guidance to help personnel evaluate information systems and
operations to determine contingency planning requirements and priorities. Requirements from FIPS 199,
Standards for Security Categorization of Federal Information and Information Systems, security impact
levels, and NIST Special Publication 800-53, Recommended Security Controls for Federal Information
Systems and Organizations contingency planning controls are integrated throughout the guideline.
Considerations for impact levels and associated security controls for contingency planning are presented
to assist planners in developing the appropriate contingency planning strategy. Although the information
presented in this document is largely independent of particular hardware platforms, operating systems,
and applications, technical considerations specific to common information system platforms are
addressed.
CHAPTER 1
1
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
1.2
Scope
This document is published by NIST as recommended guidelines for federal organizations. To assist
personnel responsible for developing contingency plans, this document discusses common technologies
that may be used to support contingency capabilities. Given the broad range of information system
designs and configurations, as well as the rapid development and obsolescence of products and
capabilities, the scope of the discussion is not intended to be comprehensive. Rather, the document
describes technology practices to enhance an organization’s information system contingency planning
capabilities. These guidelines present contingency planning principles for the following common
platform types:
Client/server systems;
Telecommunications systems; and
Mainframe systems.
The document outlines planning principles for a wide variety of incidents that can affect information
system operations. These range from minor incidents causing short-term disruptions to disasters that
affect normal operations for an extended period. Because information systems vary in design and
purpose, specific incident types and associated contingency measures are not addressed in this guide.
Instead, a defined process is provided for identifying planning requirements needed to develop an
effective contingency plan for any information system.
This document does not address facility-level information system planning (commonly referred to as a
disaster recovery plan) or organizational mission continuity (commonly referred to as a continuity of
operations [COOP] plan) except where it is required to restore information systems and their processing
capabilities. Nor does this document address continuity of mission/business processes. Although
information systems typically support mission/business processes, the processes also depend on a variety
of other resources and capabilities not associated with information systems. Recovery of mission
essential functions is addressed by COOP plans or business continuity plans. These plans are part of a
suite of security and emergency management-related plans further described in Section 2.2. The ISCP
may be prepared in coordination with disaster recovery planning, COOP planning, or business continuity
planning to the degree that a particular system is necessary to provide a capability that is required during
any of these events/efforts.
Information in this guide is consistent with guidelines provided in other NIST documents, including NIST
SP 800-53 and FIPS 199. The guidelines proposed are also consistent with federal mandates affecting
contingency, continuity of operations, and disaster recovery planning, including:
Federal Information Security Management Act (FISMA) of 2002;
OMB Circular A-130, Management of Federal Information Resources, Appendix III, November
2000;
Federal Continuity Directive (FCD)-1, Federal Executive Branch National Continuity Program
and Requirements, February 2008;
National Security Presidential Directive (NSPD)-51/Homeland Security Presidential Directive
(HSPD)-20, National Continuity Policy, May 2007;
National Continuity Policy Implementation Plan, August 2007; and
National Response Framework, March 22, 2008.
CHAPTER 1
2
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Federal organizations are required to comply with the above federal policies in addition to internal
departmental or agency policies.
Information System:
An information system is a discrete set of information resources organized for the collection,
processing, maintenance, use, sharing, dissemination, or disposition of information.*
Information system components include, but are not limited to, mainframes, servers, workstations,
network components, operating systems, middleware, and applications. Network components can
include, for example, such devices as firewalls, sensors (local or remote), switches, guards,
routers, gateways, wireless access points, and network appliances. Servers can include, for
example, database servers, authentication servers, electronic mail and Web servers, proxy
servers, domain name servers, and network time servers. Information system components are
either purchased commercially off-the-shelf or are custom-developed and can be deployed in landbased, sea-based, airborne, and/or space-based information systems.**
* As defined by 44 U.S.C., Sec 3502.
** As defined in NIST Special Publication 800-53, Recommended Security Controls for Federal
Information Systems and Organizations.
1.3
Audience
This document has been created for managers within federal organizations and those individuals
responsible for information systems or security at system and operational levels. It is also written to
assist emergency management personnel who coordinate facility-level contingencies with supporting
information system contingency planning activities. The concepts presented in this document are specific
to government systems, but may be used by private and commercial organizations, including contractor
systems. The audience includes the following types of personnel:
2
3
4
Managers responsible for overseeing information system operations or mission/business
processes that rely on information systems; 2
Chief Information Officers (CIOs) with overall responsibility for the organization’s information
systems; 3
Senior Agency Information Security Officers (SAISOs) responsible for developing and
maintaining the security of information systems at the organizational level; 4
Information System Security Officers (ISSOs)/Information System Security Managers
(ISSMs) and other staff responsible for developing, implementing, and maintaining an
information system’s security activities;
System engineers and architects responsible for designing, implementing, or modifying
information systems;
System administrators responsible for maintaining daily information system operations;
Managers include Authorizing Officials, information system owners, and information owners.
For organizations without a CIO position, FISMA requires a comparable executive to have authority over the information
systems.
SAISOs are also called Chief Information Security Officers (CISOs).
CHAPTER 1
3
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Users who employ desktop and portable systems to perform their assigned job functions; and
Other personnel responsible for designing, managing, operating, maintaining, or using
information systems.
1.4
Document Structure
This document is designed to logically lead the reader through the contingency plan development process.
The process includes designing a contingency planning program, evaluating the organization’s needs
against contingency strategy options based on the system impact levels, security controls, and technical
considerations, and documenting the contingency strategy into a contingency plan, testing the plan, and
maintaining it. The resulting contingency plan serves as a “user’s manual” for executing the strategy in
the event of a disruption. Where possible, examples or hypothetical situations are included to provide
greater understanding.
The remaining chapters of this document address the following areas of contingency planning:
Chapter 2, Background, provides background information about contingency planning, including
the purpose of various security and emergency management-related plans, their relationships to
ISCPs, and how the plans are integrated into an organization’s overall resilience strategy by
implementing the six steps of the Risk Management Framework (RMF). 5 In addition, the way in
which the FIPS 199 impact levels and NIST SP 800-53 contingency planning controls must be
considered during the contingency planning process is also explained.
Chapter 3, Information System Contingency Planning Process, details the fundamental planning
principles necessary for developing an effective contingency capability. The principles outlined
in this section are applicable to all information systems. The section presents contingency
planning guidelines for all elements of the planning cycle, including business impact analysis,
alternate site selection, and recovery strategies. The section also discusses the development of
contingency plan teams and the roles and responsibilities commonly assigned to personnel during
plan activation.
Chapter 4, Information System Contingency Plan Development, breaks down the activities
necessary to document the contingency strategy and develop the ISCP. Maintaining, testing,
training, and exercising the contingency plan are also discussed in this section.
Chapter 5, Technical Contingency Planning Considerations, describes contingency planning
concerns specific to the three common platform types listed in Section 1.3, Scope. This section
helps contingency planners identify, select, and implement the appropriate technical contingency
measures for their given systems.
This document includes nine appendices. Appendix A provides three sample ISCP templates, based on
the FIPS 199 impact levels. Appendix B presents a sample BIA template. Appendix C contains a list of
Frequently Asked Questions about information system contingency planning. Problems relevant to
planning for personnel considerations are discussed in Appendix D. Appendix E provides a summary of
NIST SP 800-53 contingency planning controls and control enhancements. Appendix F explains the
integration of contingency planning into an organization’s SDLC. Appendices G and H contain a
glossary of terms and acronyms, respectively. Appendix I provides suggested resources and references.
5
The Risk Management Framework is described in draft NIST SP 800-39, Managing Risk from Information Systems: An
Organizational Perspective.
CHAPTER 1
4
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Chapter 2.
Background
Information systems are vulnerable to a variety of disruptions, ranging from mild (e.g., short-term power
outage, disk drive failure) to severe (e.g., equipment destruction, fire). Much vulnerability may be
minimized or eliminated through management, operational, or technical controls as part of the
organization’s resiliency effort; however, it is virtually impossible to completely eliminate all risks. 6
Contingency planning is designed to mitigate the risk of system and service unavailability by providing
effective and efficient solutions to enhance system availability.
This chapter discusses the ways in which federal information system contingency planning fits into an
organization’s larger risk management, security, and emergency preparedness programs (each of which is
a key component in developing a resiliency program). Other types of emergency preparedness-related
plans and their relationships to information system contingency planning are also described. Finally, the
section discusses how integrating contingency planning principles throughout the SDLC promotes system
compatibility and a cost-effective means to increase an organization’s ability to respond quickly and
effectively to a disruptive event.
2.1
Contingency Planning and Resilience
An organization must have the ability to withstand all hazards and sustain its mission through
environmental changes. These changes can be gradual, such as economic or mission changes, or sudden,
as in a disaster event. Rather than just working to identify and mitigate threats, vulnerabilities, and risks,
organizations can work toward building a resilient infrastructure, minimizing the impact of any disruption
on mission essential functions.
Resilience 7 is the ability to quickly adapt and recover from any known or unknown changes to the
environment. Resiliency is not a process, but rather an end-state for organizations. The goal of a resilient
organization is to continue mission essential functions at all times during any type of disruption. Resilient
organizations continually work to adapt to changes and risks that can affect their ability to continue
critical functions. Risk management, contingency, and continuity planning are individual security and
emergency management activities that can also be implemented in a holistic manner across an
organization as components of a resiliency program.
Effective contingency planning begins with the development of an organization contingency planning
policy and subjection of each information system to a business impact analysis (BIA). This facilitates
prioritizing the systems and processes based on the FIPS 199 impact level and develops priority recovery
strategies for minimizing loss. FIPS 199 provides guidelines on determining information and information
system impact to organizational operations and assets, individuals, other organizations and the nation
through a formula that examines three security objectives: confidentiality, integrity, and availability. 8
Confidentiality preserves authorized restrictions on information access and disclosure, including
means for protecting personal privacy and proprietary information.
Integrity guards against improper information modification or destruction, and includes ensuring
information non-repudiation and authenticity.
6
For example, in many cases, critical resources (such as electric power or telecommunications) may reside outside the
organization’s control, and the organization may be unable to ensure their availability.
7
The Department of Homeland Security (DHS) Risk Lexicon (September 2008) defines resilience as the “ability to resist,
absorb, recover from or successfully adapt to adversity or a change in conditions.” The DHS Risk Lexicon can be found at
www.dhs.gov/xlibrary/assets/dhs_risk_lexicon.pdf.
8
As defined in 44 U.S. Code 35 Section 3542 (January 8, 2008).
CHAPTER 2
5
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Availability ensures timely and reliable access to and use of information.
The impact for each security objective is determined to be high, moderate, or low, based on definitions
provided in FIPS 199. The highest of the individual security objective impact levels are used to
determine the overall information system security impact level.
Contingency planning considerations and strategies address the impact level of the availability security
objective of information systems. Strategies for high-impact information systems should consider highavailability and redundancy options in their design. Options may include fully redundant load balanced
systems at alternate sites, data mirroring, and offsite database replication. High-availability options are
normally expensive to set up, operate, and maintain and should be considered only for those high-impact
information systems categorized with a high-availability security objective. Lower-impact information
systems may be able to use less expensive contingency options and tolerate longer downtimes for
recovery or restoration of data.
Effective contingency planning includes incorporating security controls early in the development of an
information system, and maintaining these controls on an ongoing basis. NIST SP 800-53, Rev. 3,
identifies nine Contingency Planning (CP) security controls for information systems. Not all controls are
applicable to all systems. The FIPS 199 security categorization determines which controls apply to a
particular system. For example, information systems that have availability as a security objective
categorized as low-impact do not require alternate processing or storage sites, and information systems
that have an availability security objective categorized as moderate-impact require compliance with only
the first system backup control enhancements. Using the FIPS 199 security categorization allows for
tailoring of the CP security controls in NIST SP 800-53 to those applicable to the appropriate security
control baselines. Table 2-1 provides a summary of the CP controls from NIST SP 800-53 and their
applicability to the security control baselines. Further details and descriptions of the contingency
planning controls are provided in Appendix E.
Several CP controls reference environmental controls, which are part of the NIST SP 800-53 Physical and
Environmental Protection (PE) control family. Environmental controls considerations are only for the
location or building that houses the information system. The environment includes the hardware and
technology assets that support the information system. Section 3.3 of NIST SP 800-53 provides more
information on environmental controls and their relationship to information systems.
There are options available to organizations to facilitate compliance with the CP controls. NIST SP 80053 allows for compensating security controls to provide comparable protection for an information system
to comply with the intent of a CP control. An organization may use a compensating security control in
lieu of a CP control as long as there is justification for the use of the compensating control and
willingness to accept the risk of the compensating control implementation. Further explanation of
compensating security controls is available in Section 3.3 of NIST SP 800-53.
CHAPTER 2
6
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Table 2-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderate-, and High-Impact
Systems of Contingency-Related Plans 9
Control
No.
Control Name
Security Control Baselines
Low
Moderate
High
CP-6
Contingency Planning Policy
and Procedures
Contingency Plan
Contingency Training
Contingency Plan Testing and
Exercise
Contingency Plan Update
(Withdrawn)
Alternate Storage Site
CP-7
Alternate Processing Site
Not Selected
CP-8
Telecommunications Services
Not Selected
CP-8 (1) (2)
CP-9
Information System Backup
Information System Recovery
and Reconstitution
CP-9
CP-9 (1)
CP-6 (1) (2) (3)
CP-7 (1) (2) (3)
(4) (5)
CP-8 (1) (2) (3)
(4)
CP-9 (1) (2) (3)
CP-10
CP-10 (2) (3)
CP-10 (2) (3) (4)
CP-1
CP-2
CP-3
CP-4
CP-5
CP-10
2.2
CP-1
CP-1
CP-1
CP-2
CP-3
CP-2 (1)
CP-3
CP-2 (1) (2) (3)
CP-3 (1)
CP-4
CP-4 (1)
CP-4 (1) (2) (4)
-----Not Selected
----CP-6 (1) (3)
CP-7 (1) (2) (3)
(5)
------
Types of Plans
Information system contingency planning represents a broad scope of activities designed to sustain and
recover critical system services following an emergency event. Information system contingency planning
fits into a much broader security and emergency management effort that includes organizational and
business process continuity, disaster recovery planning, and incident management. Ultimately, an
organization would use a suite of plans to properly prepare response, recovery, and continuity activities
for disruptions affecting the organization’s information systems, mission/business processes, personnel,
and the facility. Because there is an inherent relationship between an information system and the
mission/business process it supports, there must be coordination between each plan during development
and updates to ensure that recovery strategies and supporting resources neither negate each other nor
duplicate efforts.
Continuity and contingency planning are critical components of emergency management and
organizational resilience but are often confused in their use. Continuity planning normally applies to the
mission/business itself; it concerns the ability to continue critical functions and processes during and after
an emergency event. Contingency planning normally applies to information systems, and provides the
steps needed to recover the operation of all or part of designated information systems at an existing or
new location in an emergency. Cyber Incident Response Planning is a type of plan that normally focuses
on detection, response, and recovery to a computer security incident or event.
In general, universally accepted definitions for information system contingency planning and the related
planning areas have not been available. Occasionally, this leads to confusion regarding the actual scope
and purpose of various types of plans. To provide a common basis of understanding regarding
information system contingency planning, this section identifies several other types of plans and describes
their purpose and scope relative to information system contingency planning. Because of the lack of
standard definitions for these types of plans, the scope of actual plans developed by organizations may
9
Numbers in parentheses in this table refer to control enhancements defined for that control in NIST SP 800-53. A control
enhancement either adds related functionality or strengthens a basic control.
CHAPTER 2
7
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
vary from the descriptions below. This guide applies the descriptions and references in sections below to
security and emergency management-related plans. The plans listed are in alphabetical order, and do not
imply any order of importance.
2.2.1
Business Continuity Plan (BCP)
The BCP focuses on sustaining an organization’s mission/business processes during and after a
disruption. An example of a mission/business process may be an organization’s payroll process or
customer service process. A BCP may be written for mission/business processes within a single business
unit or may address the entire organization’s processes. The BCP may also be scoped to address only the
functions deemed to be priorities. A BCP may be used for long-term recovery in conjunction with the
COOP plan, allowing for additional functions to come online as resources or time allow. Because
mission/business processes use information systems (ISs), the business continuity planner must
coordinate with information system owners to ensure that the BCP expectations and IS capabilities are
matched.
2.2.2
Continuity of Operations (COOP) Plan
COOP focuses on restoring an organization’s mission essential functions (MEF) at an alternate site and
performing those functions for up to 30 days before returning to normal operations. Additional functions,
or those at a field office level, may be addressed by a BCP. Minor threats or disruptions that do not
require relocation to an alternate site are typically not addressed in a COOP plan.
Standard elements of a COOP plan include:
Program plans and procedures
Continuity communications
Risk management
Vital records management
Budgeting and acquisition of resources
Human capital
Essential functions
Test, training, and exercise
Order of succession
Devolution
Delegation of authority
Reconstitution
Continuity facilities
COOP plans are mandated for organizations by HSPD-20/NSPD-51, National Continuity Policy and FCD
1, Federal Executive Branch National Continuity Program and Requirements. Federal directives
distinguish COOP plans as a specific type of plan that should not be confused with Information System
Contingency Plans, Disaster Recovery Plans or BCPs. Nongovernment organizations typically use BCPs
rather than COOP plans to address mission/business processes.
CHAPTER 2
8
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
COOP vs. ISCP – The Basic Facts
FUNCTIONS
COOP plans address national, primary, or mission essential functions; ISCPs address federal
information systems.
o
COOP functions have specific criteria; not all government mission/business processes meet
COOP criteria.
o
COOP functions may be supported by information systems.
o
Information systems support government mission/business processes, but not all government
mission/business processes fall within the scope of COOP.
SCOPE
COOP planning applies to mission essential functions of federal government departments and
agencies.
ISCPs apply to all information systems in federal organizations.
AUTHORITIES
2.2.3
COOP is mandated for federal organizations by HSPD-20/NSPD-51, FCDs 1 and 2, and the
National Continuity Policy Implementation Plan (NCPIP); ISCPs are mandated for federal
organizations by FISMA.
Crisis Communications Plan
Organizations should document standard procedures for internal and external communications in the
event of a disruption using a crisis communications plan. A crisis communications plan is often
developed by the organization responsible for public outreach. The plan provides various formats for
communications appropriate to the incident. The crisis communications plan typically designates specific
individuals as the only authority for answering questions from or providing information to the public
regarding emergency response. It may also include procedures for disseminating reports to personnel on
the status of the incident and templates for public press releases. The crisis communication plan
procedures should be communicated to the organization’s COOP and BCP planners to ensure that the
plans include clear direction that only approved statements are released to the public by authorized
officials. Appendix D provides further discussion of topics addressed by the crisis communications plan
and informational resources.
2.2.4
Critical Infrastructure Protection (CIP) Plan
Critical infrastructure and key resources (CIKR) are those components of the national infrastructure that
are deemed so vital that their loss would have a debilitating effect of the safety, security, economy, and/or
health of the United States. 10 A CIP plan is a set of policies and procedures that serve to protect and
recover these national assets and mitigate risks and vulnerabilities. CIP plans define the roles and
responsibilities for protection, develop partnerships and information sharing relationships, implement the
risk management framework defined in the National Infrastructure Protection Plan (NIPP) and Homeland
Security Presidential Directive (HSPD) - 7 for CIKR assets, and integrate federal, state and local
emergency preparedness, protection, and resiliency of critical infrastructure.
10
For more information on Critical Infrastructure and Key Resources (CIKR), refer to the Department of Homeland Security’s
National Infrastructure Protection Plan 2009, available at www.dhs.gov/xlibrary/assets/NIPP_Plan.pdf.
CHAPTER 2
9
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
2.2.5
Cyber Incident Response Plan
The cyber incident response plan 11 establishes procedures to address cyber attacks against an
organization’s information system(s). 12 These procedures are designed to enable security personnel to
identify, mitigate, and recover from malicious computer incidents, such as unauthorized access to a
system or data, denial of service, or unauthorized changes to system hardware, software, or data (e.g.,
malicious logic, such as a virus, worm, or Trojan horse). This plan may be included as an appendix of the
BCP.
2.2.6
Disaster Recovery Plan (DRP)
The DRP applies to major, usually physical disruptions to service that deny access to the primary facility
infrastructure for an extended period. A DRP is an information system-focused plan designed to restore
operability of the target system, application, or computer facility infrastructure at an alternate site after an
emergency. The DRP may be supported by multiple information system contingency plans to address
recovery of impacted individual systems once the alternate facility has been established. A DRP may
support a BCP or COOP plan by recovering supporting systems for mission/business processes or mission
essential functions at an alternate location. The DRP only addresses information system disruptions that
require relocation.
2.2.7
Information System Contingency Plan (ISCP)
An ISCP provides established procedures for the assessment and recovery of a system following a system
disruption. The ISCP provides key information needed for system recovery, including roles and
responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing
of a system.
The ISCP differs from a DRP primarily in that the information system contingency plan procedures are
developed for recovery of the system regardless of site or location. An ISCP can be activated at the
system’s current location or at an alternate site. In contrast, a DRP is primarily a site-specific plan
developed with procedures to move operations of one or more information systems from a damaged or
uninhabitable location to a temporary alternate location. Once the DRP has successfully transferred an
information system site to an alternate site, each affected system would then use its respective ISCP to
restore, recover, and test systems, and put them into operation.
2.2.8
Occupant Emergency Plan (OEP)
The OEP outlines first-response procedures for occupants of a facility in the event of a threat or incident
to the health and safety of personnel, the environment, or property. Such events include a fire, bomb
threat, chemical release, domestic violence in the workplace, or a medical emergency. Shelter-in-place
procedures for events requiring personnel to stay inside the building rather than evacuate are also
addressed in an OEP. OEPs are developed at the facility level, specific to the geographic location and
structural design of the building. General Services Administration (GSA)-owned facilities maintain plans
based on the GSA OEP template. The facility OEP may be appended to the COOP or BCP, but is
executed separately and as a first response to the incident. Aspects of planning for personnel safety and
evacuation are discussed in Appendix D.
11
A cyber incident response plan is different from the Cyber Incident Annex of the National Response Framework (NRF). The
Cyber Incident Annex is for incidents “capable of causing extensive damage to critical infrastructure or key assets” and is
more applicable to CIP plans.
12
NIST SP 800-61 Rev. 1, Computer Security Incident Handling Guide, provides guidance on establishing a cyber incident
response capability and plan.
CHAPTER 2
10
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Error! Reference source not found. summarizes the types of plans. The plan types identified are
implemented individually or in coordination with one another as appropriate to respond to a disruptive
event.
Table 2-2: Type of Plans
Plan
Purpose
Scope
Business
Continuity
Plan (BCP)
Provides procedures for
sustaining mission/business
operations while recovering
from a significant disruption.
Addresses mission/business
processes at a lower or
expanded level from COOP
MEFs.
Continuity of
Operations
(COOP) Plan
Provides procedures and
guidance to sustain an
organization’s MEFs at an
alternate site for up to 30
days; mandated by federal
directives.
Provides procedures for
disseminating internal and
external communications;
means to provide critical
status information and control
rumors.
Provides policies and
procedures for protection of
national critical infrastructure
components, as defined in
the National Infrastructure
Protection Plan.
Provides procedures for
mitigating and correcting a
cyber attack, such as a virus,
worm, or Trojan horse.
Addresses MEFs at a facility;
information systems are
addressed based only on
their support of the mission
essential functions.
Disaster
Recovery
Plan (DRP)
Provides procedures for
relocating information
systems operations to an
alternate location.
Activated after major system
disruptions with long-term
effects.
Information
System
Contingency
Plan (ISCP)
Provides procedures and
capabilities for recovering an
information system.
Addresses single information
system recovery at the
current or, if appropriate
alternate location.
Occupant
Emergency
Plan (OEP)
Provides coordinated
procedures for minimizing
loss of life or injury and
protecting property damage
in response to a physical
threat.
Focuses on personnel and
property particular to the
specific facility; not
mission/business process or
information system-based.
Crisis
Communications Plan
Critical
Infrastructure
Protection
(CIP) Plan
Cyber
Incident
Response
Plan
CHAPTER 2
Plan Relationship
Mission/business process
focused plan that may be
activated in coordination
with a COOP plan to
sustain non-MEFs.
MEF focused plan that
may also activate several
business unit-level BCPs,
ISCPs, or DRPs, as
appropriate.
Addresses communications
with personnel and the public;
not information systemfocused.
Incident-based plan often
activated with a COOP or
BCP, but may be used
alone during a public
exposure event.
Addresses critical
infrastructure components
that are supported or
operated by an agency or
organization.
Risk management plan
that supports COOP
plans for organizations
with critical infrastructure
and key resource assets.
Addresses mitigation and
isolation of affected systems,
cleanup, and minimizing loss
of information.
Information systemfocused plan that may
activate an ISCP or DRP,
depending on the extent
of the attack.
Information systemfocused plan that
activates one or more
ISCPs for recovery of
individual systems.
Information systemfocused plan that may be
activated independent
from other plans or as
part of a larger recovery
effort coordinated with a
DRP, COOP, and/or
BCP.
Incident-based plan that
is initiated immediately
after an event, preceding
a COOP or DRP
activation.
11
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Figure 2-1 shows the interrelationship of each plan as they are implemented to respond to the event as
applicable to their respective scopes.
Figure 2-1: Contingency-Related Plan Relationships
CHAPTER 2
12
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Chapter 3.
Information System Contingency Planning Process
This section describes the process to develop and maintain an effective information system contingency
plan. The process presented is common to all information systems. The seven steps in the process are:
1. Develop the contingency planning policy;
2. Conduct the business impact analysis (BIA);
3. Identify preventive controls;
4. Create contingency strategies;
5. Develop an information system contingency plan;
6. Ensure plan testing, training, and exercises; and
7. Ensure plan maintenance.
These steps represent key elements in a comprehensive information system contingency planning
capability. Developing contingency planning policy and performing system BIA(s) are accomplished
early in the SDLC (see Appendix F) and before the systems are categorized in accordance with the RMF.
Six of the seven planning process steps are discussed in this section. Because plan development
represents the core of information system contingency planning, including the individual sections that
compose the plan, plan development is addressed in Chapter 4. Responsibility for the planning process
generally falls under the auspice of the Information System Contingency Plan Coordinator, or ISCP
Coordinator, who is typically a functional or resource manager within the organization. The ISCP
Coordinator develops the strategy in cooperation with other functional and resource managers associated
with the system or the mission/business processes supported by the system. The ISCP Coordinator also
typically manages development and execution of the contingency plan. All federal information systems
must have a contingency plan. Figure 3-1 illustrates the contingency planning process.
Develop
Contingency
Planning Policy
Conduct
Business
Impact
Analysis
• Identify
statutory or
regulatory
requirements
• Develop IT
contingency
planning
policy
statement
• Reflect FIPS
199
• Publish policy
• Determine
business
processes
and recovery
criticality
• Identify outage
impacts and
estimated
downtime
• Identify
resource
requirements
• Identify
recovery
priorities for
system
Identify
Preventive
Controls
• Identify
controls
• Implement
controls
• Maintain
controls
Create
Contingency
Strategies
• Backup &
recovery
• Consider
FIPS 199
• Identify roles &
responsibilities
• Address
alternate site
• Identify
equipment
and cost
considerations
• Integrate into
system
architecture
Develop
Contingency
Plan*
• Document
recovery
strategy
Plan Testing,
Training, and
Exercises
• Plan testing
• Train
personnel
• Plan
exercises
• TT&E
activities
Plan
Maintenance
• Review and
update plan
• Coordinate
with internal/
external
organizations
• Control
distribution
• Document
changes
*Discussed in Section 4
Figure 3-1: Contingency Planning Process
CHAPTER 3
13
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
3.1
Develop the Contingency Planning Policy Statement
To be effective and to ensure that personnel fully understand the organization’s contingency planning
requirements, the contingency plan must be based on a clearly defined policy. The contingency planning
policy statement should define the organization’s overall contingency objectives and establish the
organizational framework and responsibilities for system contingency planning. To be successful, senior
management, most likely the CIO, must support a contingency program and be included in the process to
develop the program policy. The policy must reflect the FIPS 199 impact levels and the contingency
controls that each impact level establishes. Key policy elements are as follows:
Roles and responsibilities;
Scope as applies to common platform types and organization functions (i.e., telecommunications,
legal, media relations) subject to contingency planning;
Resource requirements;
Training requirements;
Exercise and testing schedules;
Plan maintenance schedule; and
Minimum frequency of backups and storage of backup media.
Sample information system contingency policy statement
All organizations must develop contingency plans for each information system to meet
the needs of critical system operations in the event of a disruption. The procedures for
execution of such a capability shall be documented in a formal contingency plan by the
Information Systems Contingency Plan (ISCP) Coordinator and must be reviewed
annually and updated as necessary by the ISCP Coordinator. The plan must account
for the FIPS 199 security categorization (low, moderate, high) and comply with the
appropriate security controls. The plan must assign specific responsibilities to
designated staff or positions to facilitate the recovery and/or continuity of essential
system functions. Resources necessary to ensure viability of the procedures must be
acquired and maintained. Personnel responsible for target systems must be trained to
execute contingency procedures. The plan recovery capabilities and personnel shall be
tested annually to identify weaknesses of the capability.
As information system contingency plans are developed during the Initiation phase of the SDLC, 13 they
should be coordinated with related organization-wide policies and programs, including information
system security, physical security, human resources, system operations, and emergency preparedness
functions. Information system contingency activities should be compatible with program requirements
for these areas, and recovery personnel should coordinate with representatives from each area to remain
aware of new or evolving policies, programs, or capabilities. The ISCPs must be written in coordination
with other plans associated with each target system as part of organization-wide resilience strategy. Such
plans include the following:
13
The SDLC refers to the scope of activities associated with a system, encompassing the system’s initiation, development and
acquisition, implementation, operation, and maintenance, and ultimately its disposal that instigates another system initiation.
The SDLC approach is discussed in depth in NIST SP 800-64, Security Considerations in the Information System Development
Life Cycle. An overview of contingency planning and the SDLC is provided in Appendix F.
CHAPTER 3
14
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Information system security plans;
Facility-level plans, such as the OEP and DRP;
MEF support such as the COOP plan; and
Organization-level plans, such as CIP plans.
Similarly, the six-step RMF 14 brings together the supporting security standards and guidelines necessary
for managing risk related to information systems. Implementing the RMF on an information system
encompasses a broad range of activities to identify, control, and mitigate risks. From the information
system contingency planning perspective, the six steps in the RMF actively support the development,
implementation, testing, and maintenance of an information system’s contingency plan as it supports the
mission of the organization.
3.2
Conduct the Business Impact Analysis (BIA)
The BIA is a key step in implementing the CP controls in
NIST SP 800-53 and in the contingency planning process
overall. The BIA enables the ISCP Coordinator to
characterize the system components, supported
mission/business processes, and interdependencies. The
BIA purpose is to correlate the system with the critical
mission/business processes and services provided, and
based on that information, characterize the consequences of
a disruption. The ISCP Coordinator can use the BIA
results to determine contingency planning requirements and
priorities. Results from the BIA should be appropriately
incorporated into the analysis and strategy development
efforts for the organization’s COOP, BCPs, and DRP. The
BIA should be performed during the Initiation phase of the
SDLC. As the system design evolves and components
change, the BIA may need to be conducted again during the
Development/Acquisition phase of the SDLC.
Incorporating the RMF Step 1 (FIPS 199 categorization)
and Step 2 (select security controls) helps to ensure that the
BIA accounts appropriately for the level of risk to the
organization.
COOP vs. ISCP – The Basic Facts
BUSINESS IMPACT ANALYSIS
(BIA)
COOP functions are subject to a
process-focused BIA; federal
information systems are subject to
a system-focused BIA.
o
Information systems that
support COOP functions will be
identified in the process-based
BIA.
o
FCD-2 provides a required
template for a process-based
BIA; NIST 800-34 provides a
recommended template for a
system-based BIA.
Three steps are typically involved in accomplishing the BIA:
1. Determine mission/business processes and recovery criticality. Mission/Business processes
supported by the system are identified and the impact of a system disruption to those processes is
determined along with outage impacts and estimated downtime. The downtime should reflect
the maximum time that an organization can tolerate while still maintaining the mission.
2. Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the
resources required to resume mission/business processes and related interdependencies as
14
NIST SP 800-37 further describes the RMF and provides guidance on organization-wide risk management including the
development of risk management strategies, risk-related governance issues, defining protection requirements and associated
risks for organizational mission/business processes, integration of security and privacy requirements into enterprise
architectures, and managing risk within the system development life cycle.
CHAPTER 3
15
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
quickly as possible. Examples of resources that should be identified include facilities, personnel,
equipment, software, data files, system components, and vital records.
3. Identify recovery priorities for system resources. Based upon the results from the previous
activities, system resources can be linked more clearly to critical mission/business processes and
functions. Priority levels can be established for sequencing recovery activities and resources.
The sample BIA process and data collection activities, outlined in this section and illustrated in Figure
3-2, consisting of a representative information system with multiple components (servers), are designed to
help the ISCP Coordinator streamline and focus contingency plan development activities to achieve a
more effective plan. 15 An example of the BIA process and a BIA template are provided in Appendix B.
Stakeholder
input
Potential
Impacts
Max Tolerable
Downtime*
Recovery Time
System
Components
Objective*
FIPS 199
Confidentiality Integrity Availability
Process
Invoice
Operations – more than
1,000 staff affected
72 hours
Application
Server
36 hours
L
L
L
Prepare
Report
Reputation – media outlets
announce concerns
30 hours
Web
Server
24 hours
M
M
M
Create
Budget
Reputation –
congressional insight
36 hours
Database
Sever
12 hours
L
M
M
Customer Service – over 500
customer complaints
36 hours
Desktop
Computers
30 hours
L
L
L
Respond to
Inquiries
Interdependencies
Moderate
Business
Process
*Notional Times
Figure 3-2: Business Impact Analysis Process for the Information System
3.2.1
Determine Business Processes and Recovery Criticality
An information system can be very complex and often supports multiple mission/business processes,
resulting in different perspectives on the importance of system services or capabilities. To accomplish the
BIA and better understand the impacts a system outage or disruption can have on the organization, the
ISCP Coordinator should work with management and internal and external points of contact (POC) 16 to
identify and validate mission/business processes and processes that depend on or support the information
system. The identified processes’ impacts are then further analyzed in terms of availability, integrity,
confidentiality, and the established FIPS 199 impact level for the information system.
FIPS 199 requires organizations to categorize their information systems as low impact, moderate impact,
or high impact for the security objectives of confidentiality, integrity, and availability (RMF Step 1). The
FIPS 199 category for the availability security objective serves as a basis of the BIA. Further
identification of additional mission/business processes and impacts captures the unique purpose of the
15
For completeness and to assist ISCP Coordinators who may be new to or unfamiliar with the information system, the sample
BIA process presented includes basic steps. In many cases, the ISCP Coordinator will be very familiar with specific system
components and the ways in which they support business processes and may modify the approach to fit the respective system
and contingency needs.
16
When identifying POCs, it is important to include organizations that provide or receive data from the system as well as POCs
of any interconnected systems. Coordination should enable the system manager to characterize the full range of support
provided by the system, including security, managerial, technical, and operational requirements.
CHAPTER 3
16
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
system. Organizational and system uniqueness are important considerations for contingency planning and
business impact. Adding information types to address this uniqueness will enhance the prioritization of
system component impacts.
Unique processes and impacts can be expressed in values or units of measurement that are meaningful to
the organization. Values can be identified using a scale and should be characterized as an indication of
impact severity to the organization if the process could not be performed. 17 For example, an impact
category such as “Costs” can be created with impact values expressed in terms of staffing, overtime, or
fee-related costs.
The ISCP Coordinator should next analyze the supported mission/business processes and with the process
owners, leadership and business managers determine the acceptable downtime if a given process or
specific system data were disrupted or otherwise unavailable. Downtime can be identified in several
ways. 18
Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time the system
owner/authorizing official is willing to accept for a mission/business process outage or disruption and
includes all impact considerations. Determining MTD is important because it could leave
contingency planners with imprecise direction on (1) selection of an appropriate recovery method,
and (2) the depth of detail which will be required when developing recovery procedures, including
their scope and content. 19
Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system
resource can remain unavailable before there is an unacceptable impact on other system resources,
supported mission/business processes, and the MTD. Determining the information system resource
RTO is important for selecting appropriate technologies that are best suited for meeting the MTD. 20
When it is not feasible to immediately meet the RTO and the MTD is inflexible, a Plan of Action and
Milestone should be initiated to document the situation and plan for its mitigation.
Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or
system outage, to which mission/business process data can be recovered (given the most recent
backup copy of the data) after an outage. Unlike RTO, RPO is not considered as part of MTD.
Rather, it is a factor of how much data loss the mission/business process can tolerate during the
recovery process.
Because the RTO must ensure that the MTD is not exceeded, the RTO must normally be shorter
than the MTD. For example, a system outage may prevent a particular process from being
completed, and because it takes time to reprocess the data, that additional processing time must
be added to the RTO to stay within the time limit established by the MTD.
17
NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories,
provides additional guidance on security categories and information types that could influence criticality.
18
The first version of NIST SP 800-34 used the term Maximum Allowable Outage (MAO) to describe the downtime threshold.
To further delineate business process and information system downtime, Maximum Tolerable Downtime (MTD) and Recovery
Time Objective (RTO) terms are used.
19
Any information system that supports continuity of operations Mission Essential Functions (MEF), Primary Mission Essential
Functions (PMEF), or National Essential Functions (NEF) must be able to meet the function’s MTD of 12 hours or less per
FCD-1.
20
RTOs for telecommunications systems that support continuity of operation MEFs, PMEFs, or NEFs must support the
function’s COOP requirements including those put forth by National Communications Systems (NCS) Directive 3-10.
CHAPTER 3
17
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
COOP vs. ISCP – The Basic Facts
RECOVERY TIMES
COOP functions must be sustained within 12 hours and for up to 30 days from an alternate site;
ISCP recovery time objectives are determined by the system-based BIA.
o
Information systems that support COOP functions must have an RTO that meets COOP
requirements.
o
Information systems that do not support COOP functions do not require alternate sites as
part of the ISCP recovery strategy, but may have an alternate site security control
requirement.
The ISCP Coordinator, working with management, should determine the optimum point to recover the
information system by addressing the factors mentioned above while balancing the cost of system
inoperability against the cost of resources required for restoring the system and its overall support for
critical mission/business processes. This can be depicted using a simple chart, such as the example in
Figure 3-3.
Cost of Disruption
(Business Downtime)
Cost to Recover
(System Mirror)
Cost
Cost
Balance
Point
Cost to Recover
(Tape Backup)
Length of Disruption Time
Figure 3-3: Cost Balancing
The longer a disruption is allowed to continue, the more costly it can become to the organization and its
operations. Conversely, the shorter the RTO, the more expensive the recovery solutions cost to
implement. For example, if the system must be recovered immediately, zero downtime solutions and
alternate processing site costs will be much higher, whereas a low-impact system with a longer RTO
would be able to implement a less costly simple tape backup system. Plotting the cost balance points will
show an optimal point between disruption and recovery costs. The intersecting point (Cost Balance Point
in Figure 3-3: Cost Balancing) will be different for every organization and system based on the financial
constraints and operating requirements.
CHAPTER 3
18
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
3.2.2
Identify Resource Requirements
Realistic recovery efforts require a thorough evaluation of the resources required to resume
mission/business processes as quickly as possible. Working with management and internal and external
POCs associated with the system, the ISCP Coordinator should ensure that the complete information
system resources are identified. 21 A simple table such as the one shown in Table 3-1 can be used to
capture relevant information system resources.
Table 3-1: Information System Resource/Component Table
System
Resource/Component
Application Server
3.2.3
Platform/OS/Version (as
applicable)
Sun V245/ Solaris / v10.0
Description
Serves as the main
application server
Identify System Resource Recovery Priorities
Developing recovery priorities is the last step of the BIA process. Recovery priorities can be effectively
established taking into consideration mission/business process criticality, outage impacts, tolerable
downtime, and system resources. The result is an information system recovery priority hierarchy. The
ISCP Coordinator should consider system recovery measures and technologies to meet the recovery
priorities.
3.3
Identify Preventive Controls
In some cases, the outage impacts identified in the BIA may be mitigated or eliminated through
preventive measures that deter, detect, and/or reduce impacts to the system. Where feasible and costeffective, preventive methods are preferable to actions that may be necessary to recover the system after a
disruption. Step 2 of the RMF includes the identification of effective contingency planning preventive
controls and maintaining these controls on an ongoing basis. A variety of preventive controls are
identified in NIST SP 800-53, depending on system type and configuration; some common measures are
listed below:
21
Appropriately sized uninterruptible power supplies (UPS) to provide short-term backup power to
all system components (including environmental and safety controls);
Gasoline- or diesel-powered generators to provide long-term backup power;
Air-conditioning systems with adequate excess capacity to prevent failure of certain components,
such as a compressor;
Fire suppression systems;
Fire and smoke detectors;
Water sensors in the computer room ceiling and floor;
To avoid duplication of effort, this information may be obtained from the system component inventory and the system software
inventory.
CHAPTER 3
19
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Heat-resistant and waterproof containers for backup media and vital non electronic records;
Emergency master system shutdown switch;
Offsite storage of backup media, non electronic records, and system documentation;
Technical security controls, such as cryptographic key management; and
Frequent scheduled backups including where the backups are stored (onsite or offsite) and how
often they are recirculated and moved to storage.
3.4
Create Contingency Strategies
Organizations are required to adequately mitigate the risk arising from use of information and information
systems in the execution of mission/business processes. The challenge for organizations is in
implementing the right set of security controls. Guided by the RMF and in accordance with FIPS 199 and
NIST SP 800-53, security controls are selected and implemented. Contingency strategies are created to
mitigate the risks for the contingency planning family of controls and cover the full range of backup,
recovery, contingency planning, testing, and ongoing maintenance.
3.4.1
Backup and Recovery
Backup and recovery methods and strategies are a means to restore system operations quickly and
effectively following a service disruption. The methods and strategies should address disruption impacts
and allowable downtimes identified in the BIA and should be integrated into the system architecture
during the Development/Acquisition phase of the SDLC. A wide variety of recovery approaches may be
considered, with the appropriate choice being highly dependent upon the incident, type of system,
BIA/FIPS 199 impact level, and the system’s operational requirements. 22 Specific recovery methods
further described in Section 3.4.2 should be considered and may include commercial contracts with
alternate site vendors, reciprocal agreements with internal or external organizations, and service-level
agreements (SLAs) with equipment vendors. In addition, technologies such as redundant arrays of
independent disks (RAID), automatic failover, UPS, server clustering, and mirrored systems should be
considered when developing a system recovery strategy.
Several alternative approaches should be considered when developing and comparing strategies, including
cost, maximum downtimes, security, recovery priorities, and integration with larger, organization-level
contingency plans. Table is an example that can assist in identifying the linkage of FIPS 199 impact
level for the availability security objective, recovery priority, backup, and recovery strategy.
Table 3-2: FIPS 199 Category Backup & Strategy Examples
FIPS 199
Availability
Impact Level
Information System Target Priority and
Recovery
Backup / Recovery Strategy 23
Low
Low priority - any outage with little impact,
damage, or disruption to the organization.
Backup: Tape backup
Strategy: Relocate or Cold site
Moderate
Important or moderate priority - any
system that, if disrupted, would cause a
moderate problem to the organization and
possibly other networks or systems.
Backup: Optical backup,
WAN/VLAN replication
Strategy: Cold or Warm site
22
Chapter 5, Technical Contingency Planning Considerations, provides detailed discussion of recovery methods applicable to
specific types of information systems.
23
Additional recovery strategy technical details and descriptions can be found in Sections 3.4.2 through 3.4.6.
CHAPTER 3
20
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
FIPS 199
Availability
Impact Level
Mission-critical or high priority - the
damage or disruption to these systems
would cause the most impact on the
organization, mission, and other networks
and systems.
High
3.4.2
Information System Target Priority and
Recovery
Backup / Recovery Strategy 23
Backup: Mirrored systems and
disc replication
Strategy: Hot site
Backup Methods and Offsite Storage
System data should be backed up regularly. Policies should specify the minimum frequency and scope of
backups (e.g., daily or weekly, incremental or full) based on data criticality and the frequency that new
information is introduced. Data backup policies should designate the location of stored data, file-naming
conventions, media rotation frequency, and method for transporting data offsite. Data may be backed up
on magnetic disk, tape, or optical disks, such as compact disks (CDs). The specific method chosen for
conducting backups should be based on system and data availability and integrity requirements. These
methods may include electronic vaulting, network storage, and tape library systems. 24
It is good business practice to store backed-up data offsite. Commercial data storage facilities are
specially designed to archive media and protect data from threatening elements. If using offsite storage,
data is backed up at the organization’s facility and then labeled, packed, and transported to the storage
facility. If the data is required for recovery or testing purposes, the organization contacts the storage
25
facility requesting specific data to be transported to the organization or to an alternate facility.
Commercial storage facilities often offer media transportation and response and recovery services. When
selecting an offsite storage facility and vendor, the following criteria should be considered:
Geographic area: distance from the organization and the probability of the storage site being
affected by the same disaster as the organization’s primary site;
Accessibility: length of time necessary to retrieve the data from storage and the storage facility’s
operating hours;
Security: security capabilities of the shipping method, storage facility, and personnel; all must
meet the data’s security requirements;
Environment: structural and environmental conditions of the storage facility (i.e., temperature,
humidity, fire prevention, and power management controls); and
Cost: cost of shipping, operational fees, and disaster response/recovery services.
3.4.3
Alternate Sites
As stated in Section 2.1, NIST SP 800-53 identifies the CP controls for information systems. The FIPS
199 security categorization for the availability security objective determines which controls apply to a
particular system. For example, an information system categorized with a low-availability security
objective does not require alternate storage or a processing site (CP-6 and CP-7, respectively), and an
information system with a moderate-availability security objective requires the system backup and testing
24
25
Additional technical considerations are discussed in Chapter 5.
Backup tapes should be tested regularly to ensure that data are being stored correctly and that the files may be retrieved without
errors or lost data. Also, the ISCP Coordinator should test the backup tapes at the alternate site, if applicable, to ensure that the
site supports the same backup configuration that the organization has implemented.
CHAPTER 3
21
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
the backup (CP-9 [1]). Further details and descriptions of the contingency planning controls are provided
in Appendix E.
Although major disruptions with long-term effects may be rare, they should be accounted for in the
contingency plan. Thus, for all FIPS 199 moderate- or high-impact systems, the plan should include a
strategy to recover and perform system operations at an alternate facility for an extended period.
Organizations may consider FIPS 199 low-impact systems for alternate site processing, but that is an
organizational decision and not required. In general, three types of alternate sites are available:
Dedicated site owned or operated by the organization;
Reciprocal agreement or memorandum of agreement with an internal or external entity; and
Commercially leased facility.
Regardless of the type of alternate site chosen, the facility must be able to support system operations as
defined in the contingency plan. The three alternate site types commonly categorized in terms of their
operational readiness are cold sites, warm sites, or hot sites. 26 Other variations or combinations of these
can be found, but generally all variations retain similar core features found in one of these three site types.
Progressing from basic to advanced, the sites are described below.
Cold Sites are typically facilities with adequate space and infrastructure (electric power,
telecommunications connections, and environmental controls) to support information system
recovery activities.
Warm Sites are partially equipped office spaces that contain some or all of the system hardware,
software, telecommunications, and power sources.
Hot Sites are facilities appropriately sized to support system requirements and configured with
the necessary system hardware, supporting infrastructure, and support personnel.
As discussed above, these three alternate site types are the most common. There are also variations, and
hybrid mixtures of features from any one of the three. Each organization should evaluate its core
requirements in order to establish the most effective solution. Two examples of variations to the site
types are:
Mobile Sites are self-contained, transportable shells custom-fitted with specific
telecommunications and system equipment necessary to meet system requirements.
Mirrored Sites are fully redundant facilities with automated real-time information mirroring.
Mirrored sites are identical to the primary site in all technical respects.
There are obvious cost and ready-time differences among the options. In these examples, the mirrored
site is the most expensive choice, but it ensures virtually 100 percent availability. Cold sites are the least
expensive to maintain, although they may require substantial time to acquire and install necessary
equipment. Partially equipped sites, such as warm sites, fall in the middle of the spectrum. In many
cases, mobile sites may be delivered to the desired location within 24 hours, but the time necessary for
equipment installation and setup can increase this response time. The selection of fixed-site locations
should account for the time and mode of transportation necessary to move personnel and/or equipment
there. In addition, the fixed site should be in a geographic area that is unlikely to be negatively affected
by the same hazard as the organization’s primary site.
26
For more complete technical details and descriptions, refer to Chapter 5.
CHAPTER 3
22
CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS
Table summarizes the criteria that can be employed to determine which type of alternate site meets the
organization’s requirements. Sites should be analyzed further by the organization, including
considerations given to business impacts and downtime defined in the BIA. As sites are evaluated, the
ISCP Coordinator should ensure that the system’s security, management, operational, and technical
controls are compatible with the prospective site. Such controls may include firewalls, physical access
controls, and personnel security requirements of the staff supporting the site.
Table 3-34: Sample Alternate Site Criteria
Site
Cost
Cold Site
Warm Site
Hot Site
Low
Medium
Medium/High
Hardware
Equipment
None
Partial
Full
Telecommunications
Setup Time
None
Partial/Full
Full
Long
Medium
Short
Location
Fixed
Fixed
Fixed
Alternate sites may be owned and operated by the organization (internal recovery), or commercial sites
may be available under contract. If contracting for the site with a commercial vendor, adequate testing
time, work space, security requirements, hardware requirements, telecommunications requirements,
support services, and recovery days (how long the organization can occupy the space during the recovery
period) must be negotiated and clearly stated in the contract. Customers should be aware that multiple
organizations may contract with a vendor for the same alternate site; as a result, the site may be unable to
accommodate all of the customers if a disaster affects enough of those customers simultaneously. The
vendor’s policy on how this situation should be addressed and how priority status is determined should be
negotiated.
Two or more organizations with similar or identical system configurations and backup technologies may
enter into a formal agreement to serve as alternate sites for each other or enter into a joint contract for an
alternate site. This type of site is set up via a reciprocal agreement or memorandum of understanding
...
Purchase answer to see full
attachment