Attachment_8_DHS_4300A_Sensitive_Systems_Handbook.pdf

DHS 4300A

Sensitive Systems Handbook

IT Contingency Plan Template

Version 9.1 July 24, 2012

Protecting the Information that Secures the Homeland

Attachment 8

DHS 4300A SENSITIVE SYSTEMS HANDBOOK DHS 4300A Sensitive Systems Handbook – IT CONTINGENCY

PLAN TEMPLATE

v9.1, July 24, 2012 ii

This page intentionally blank v9.1, July 24, 2012 iii

Document Change History

Version Date Description

3.0 April 30, 2005 Initial release

3.1 December 30, 2005 New Contingency Plan template provided.

4.0 June 1, 2006

Contingency Plan requirements refined based on the IT system’s security categorization as to low-, moderate-, or high-impact for the availability security objective.

5.0 March 1, 2007 No change

6.0 May 14, 2008 No change

6.1 September 23, 2008 No change

7.0 August 7, 2009

Incorporated information addressing backup operations plan, written access control policies and procedures, and preservation of audit information. Removed Business Impact Assessment from template.

9.1 July 24, 2012 Minor revisions to Attachment

New template, thoroughly revised v9.1, July 24, 2012 iv

Contents

1.0 Overview

2.0 Relationship to Continuity of Operations Plan

3.0 Guidance for Template Usage

v9.1, July 24, 2012 1

1.0 OVERVIEW

The intent of a contingency plan, as described by Section 3.5.2 of the DHS 4300A Sensitive Systems Handbook, is to ensure the availability of critical information systems under all circumstances. A Contingency Plan provides for capability to respond to emergencies, to recover from them, and to resume normal operations, possibly at an alternate location, in the event of emergency, system failure, or disaster.

Specific control requirements for emergency situations, and level of effort expended, are determined based on the IT system’s security categorization. The level of resources for the Contingency Plan is based on the security categorization for the availability security objective:

• For systems with a low impact for availability, the system owner can determine the Contingency Plan format and content that is appropriate for the system and its environment.

The Contingency Plan generated in the Risk Management System (RMS) automated Certification and Accreditation (C&A) tool can also be used.

• For systems with a moderate impact level for availability, the default Contingency Plan template in RMS should be used.

• Systems with a high impact level for availability should develop a rigorous Contingency Plan. The template to be used for such a plan is provided in this attachment (see below). It can also be found in the Additional Documents section of RMS. The high impact plan can be received in RMS when creating a package, by answering “Yes” to additional documents in the questionnaire.

The DHS Certification and Accreditation Guidance for SBU Systems provides detailed information on developing the Contingency Plan within RMS.

The template included in this attachment is for high impact availability it systems only. The template contains instructions for completing specific sections where practical. Text is added in certain sections; however, this information is intended only to suggest the type of information that may be found in that section. The text is not comprehensive and should be modified to meet specific agency and system considerations. The IT Contingency Plan should be marked with the appropriate security label, such as For Official Use Only.

2.0 RELATIONSHIP TO CONTINUITY OF OPERATIONS PLAN

IT Contingency Plans, for critical systems identified within a Continuity of Operations (COOP) Plan, should be developed and included as appendices to the COOP Plan.

The COOP Plan(s) should cross reference the associated IT Contingency Plan(s) and the IT Contingency Plan(s) should cross-reference the COOP Plan(s).

Allowable outage times identified in IT Contingency Plan(s) should coincide with the business functionality Minimum Allowable Outage/Downtime (MAO) identified in the COOP Plan(s).

3.0 GUIDANCE FOR TEMPLATE USAGE

Throughout the attached template, guidance appears in italics enclosed by angle brackets ( < > ).

When the template is complete, remove all such material.

Generic terms in braces ( { } ) must be replaced with appropriate specific terms. Some, such as {system name} can be globally replaced by word processor software functions. For terms whose v9.1, July 24, 2012 2 replacements do not begin with a capital, errors may occur when those terms are at the beginning of a sentence. Most spell checkers will find these errors if not automatically corrected.

Adjust version number of the plan on the cover and in headers and footers. Versions that are distributed should be whole numbers in the form 1.0, 2.0, 3.0, etc.

The plan, when completed, is “FOR OFFICIAL USE ONLY.” Remove the words “(when completed)” from the headers and footers.

Enter the Component name, system name, and date in the headers.

It is recommended that SharePoint filename be entered as a field code in the footer if possible.

This will help simplify version control.

Insert a table of contents on page v.

Run a spell and grammar check. Note that some correct constructions and spellings will be cited as grammar or spelling “errors.”

Before distributing the completed template, remove this and all preceding pages.

(When completed) FOR OFFICIAL USE ONLY

(when completed) FOR OFFICIAL USE ONLY

{Component name}

{System name}

Information System Contingency Plan

Version <0.0> <Date>

Prepared by Organization Name City, State, ZIP

{COMPONENT NAME}

{SYSTEM NAME} CONTINGENCY PLAN <DATE>

Filename (SharePoint location, if desired (field code) ii

Filename (SharePoint location, if desired (field code) iii

PLAN APPROVAL

As the designated authority for {system name}, I hereby certify that this information system contingency plan is complete and in accordance with Department of Homeland Security Sensitive Systems Policy Directive 4300A, and that the information contained in this CP is provides an accurate representation of hardware, software, and telecommunications components of the application.

I further certify that this document identifies the criticality of the system as it relates to the mission of the {Component name}, and that the recovery strategies identified will provide the ability to recover the system’s functionality in the most expedient and cost-efficient methods in keeping with the system’s level of criticality.

Further, I attest that this CP for {system name} will be tested at least annually. This CP was last tested on {exercise date}; the test, training, and exercise (TT&E) material associated with this test can be found {location of TT&E results}. This document will be modified as changes occur and will remain under version control in accordance with DHS Sensitive Systems Policy Directive 4300A.

________________________________ Date _____________

{system owner name}

{system owner title}

<add other applicable approving authorities if appropriate>

Filename (SharePoint location, if desired (field code) iv

Filename (SharePoint location, if desired (field code) v

<insert table of contents>

Filename (SharePoint location, if desired (field code) vi

Filename (SharePoint location, if desired (field code) 1

1.0 INTRODUCTION

Information systems are vital to the mission business processes of {Component name};

therefore, it is critical that services provided by {system name} are able to operate effectively without excessive interruption. This Contingency Plan (CP) establishes comprehensive procedures to recover {system name} quickly and effectively following disruption of service.

1.1 Authorities

Federal Law

Federal Information Security Management Act of 2002 (FISMA), 44 USC 3541 et seq., enacted as Title III of the E-Government Act of 2002, Pub L 107-347, 116 Stat 2899

National Defense Authorization Act for Fiscal Year 2001, Title X, Subtitle G, Pub L 106-398, 114 Stat 1564 “Government Information Security Reform,”

Presidential Decision Directive

Presidential Decision Directive (PDD) 67, “Enduring Constitutional Government and Continuity of Government Operations,” October 1998

National Institute of Standards and Technology Federal Information Processing

NIST FIPS 199, “Standards for Security Categorization of Federal Information and Information Systems,” February 2004

Federal Preparedness Circular

Federal Preparedness Circular (FPC) 65, “Federal Executive Branch Continuity of Operations (COOP),” June 15, 2004

1.2 Background

This {system name} CP establishes procedures to recover {system name} following a disruption.

The following objectives have been established for this plan:

• Maximize the effectiveness of contingency operations in three phases:

◦ Activation and Notification phase— The plan is activated and the extent of damage is determined.

◦ Recovery phase— operations are restored.

◦ Reconstitution phase—Validation of {system name} is ensured through testing, and normal operations are resumed.

• Identify the activities, resources, and procedures needed for {system name} processing during prolonged interruptions of normal operations.

• Assign responsibilities to designated {Component name} personnel and provide guidance for recovering {system name} during prolonged interruptions of normal operations.

• Ensure coordination among all personnel responsible for {Component name} contingency planning strategies.

Filename (SharePoint location, if desired (field code) 2

• Ensure coordination with external points of contact and vendors whose involvement is necessary to the execution of this CP.

1.3 Scope

This CP has been developed for {system name}, which is classified as a {level of impact}impact system as defined by Federal Information Processing Standard (FIPS) 199, “Standards for Security Categorization of Federal Information and Information Systems.” Procedures detailed in this CP are for {level of impact}impact systems and designed to recover {system name} within {RTO hours}. This plan does not address replacement or purchase of new equipment;

short-term disruptions lasting less than {RTO hours}; or loss of data at the onsite facility or at the user-desktop levels. Only the availability security objective shall be applied to the NIST SP 800-53 Contingency Plan controls defined for low, moderate, and high potential impact levels.

This CP does not apply in the following situations:

• Overall recovery and continuity of mission business operations. The Business Continuity Plan (BCP) and Continuity of Operations Plan (COOP) address continuity of business operations.

• Emergency evacuation of personnel. The Occupant Emergency Plan (OEP) addresses employee evacuation.

1.4 Assumptions

This plan is based on the following assumptions:

• {system name} has is a {level of impact} impact system according to FIPS 199 criteria.

• <for high impact systems> Alternate processing sites and offsite storage are required and have been established for this system.

• <for high impact systems> Current backups of system software and data are intact and available at the offsite storage facility in {City, State} and are available if needed for relocation of {system name}

• <For high impact systems> Alternate facilities have been established at {City, State} and are available if needed for relocation of {system name}.

• {system name} is inoperable at {Component name} and cannot be recovered within 48 hours.

• Key {system name} personnel have been identified and trained in their emergency response and recovery roles and are available to activate the {system name} CP.

• <additional assumptions as appropriate>

CONCEPT OF OPERATIONS

<The concept of operations section provides details about {system name}; an overview of the three phases of the CP (Activation and Notification, Notification, and Recovery); and a description of roles and responsibilities of {Component name}’s personnel during contingency plan execution.>

Filename (SharePoint location, if desired (field code) 3

1.5 System Description

<Information for this section should be available from the system’s Security Plan (SP). Attach the latest version of the SP to this CP, referencing this section’s content to specific sections of the SP.

• Provide a general description of system architecture and functionality.

• Describe the operating environment, physical location, general location of users, and partnerships with external organizations and systems.

• Include information about any technical considerations, such as backup procedures, that are important to recovery. >

1.6 Overview of the Three Phases

This CP has been developed to recover the {system name} in three phases. This approach ensures that system recovery is performed in a methodical sequence that maximizes effectiveness of recovery effort and minimizes system outage time due to errors and omissions. The three system recovery phases are:

• Activation and Notification Phase

◦ This CP is activated following an outage or disruption that may be reasonably expected to extend beyond 48 hours. The outage event may result in severe damage to the facility housing the system; severe damage or loss of equipment; or other damage that typically results in long-term loss.

◦ After activation of the CP, system owners and users are notified of a possible long-term outage, and a thorough outage assessment if performed for the system. Results of the outage assessment are presented to system owners, and may be used to modify recovery procedures to specifically address the cause of the outage.

• Recovery Phase

◦ During the recovery phase, activities and procedures for recovery are written for use by appropriately skilled technicians in recovering the system without intimate system knowledge. This phase includes notification and awareness escalation procedures for communication of recovery status to system owners and users.

• Reconstitution Phase

◦ Define the actions taken to test and validate system capability and functionality at the original or new permanent location. Validation procedures may include functionality or regression testing, concurrent processing, and/or data validation. Upon completion of validation, the system is declared recovered and operational by system owners.

◦ Plan deactivation is the final step, during which users are notified of the system’s operational status; recovery effort documentation is finalized; activity logs are finalized; and lessons learned are documented for incorporation into plan updates.

Resources are readied for any future events.

Filename (SharePoint location, if desired (field code) 4

1.7 Roles and Responsibilities

In addition to the Senior Management Official identified in this section, this Contingency Plan establishes several teams trained to participate in recovering {system name} operations, environment, and all applications. Team members include personnel who are responsible for daily operations of the system.

<Describe the responsibilities of each individual and team, with narrative and bulleted lists similar to those in the typical text that follows. Include responsibilities, leadership, and coordination with other individuals and teams during the recovery process. Highlight overall recovery objectives and specific responsibilities. Do not detail procedures that will be used to execute the responsibilities; those procedures will be included in the appropriate phase sections.

Rewrite and modify the typical text where needed.> The relationships of the team leaders involved in system recovery and their member teams are illustrated in Figure {xx}.

<Insert hierarchical diagram of recovery teams. Show team names and leaders; do not include actual names of personnel.>

1.7.1 Senior Management Official

This individual is a Senior Manager is responsible to Executive Management for all facets of contingency planning and exercises, as well as for recovery operations.

• Pre-event

◦ Approve the plan

◦ Ensure the plan is maintained

◦ Ensure training is conducted

◦ Authorize periodic plan testing exercises

◦ Support the Contingency Management Team Leader and all other participants prior to and during scheduled and unscheduled exercises and plan tests

• Post-event

◦ Declaration of a disaster

◦ Authorize travel and housing arrangements for team members

◦ Authorize expenditures through the Administration Team

◦ Manage and monitor the overall recovery process

◦ Periodically advise senior staff, customers, and media relations personnel of the status

◦ Support the Contingency Management Team Leader and all other participants during debilitating conditions/situations

Filename (SharePoint location, if desired (field code) 5

1.7.2 Contingency Management Team

<The responsibilities described may also be those of a team called the Alternate Site Recovery Coordination Team> The Contingency Management Team is responsible for managing the total recovery effort; for ensuring that other teams and personnel perform all checklist items; for providing a “Command Center” for coordination and overall communications; for ensuring that activities are accomplished among all teams within planned time frames and for providing assistance in resolving problems that may arise. This team is activated by the Senior Management Official or System Owner. All other teams report directly to the Contingency/ Management Team, whose specific duties are:

1.7.2.1 Contingency Management Team Leader

• Pre-event

◦ Maintain and update the plan as needed or scheduled but not less than annually

◦ Distribute copies of plan to team members

◦ Coordinate testing as needed or scheduled but not less than annually

◦ Train team members

• Post-event

◦ Accomplish initial notification of Team members

◦ Establish a command center for recovery operations

◦ Assist in damage assessment

◦ Coordinate activities of recovery teams

◦ Notify alternate site of activation

◦ Notify Team Leaders of other Teams of CP activation

◦ Authorize the Administration Team to make the necessary travel and hotel accommodations for recovery team members

◦ Periodically report to the Senior Management Official status of recovery efforts and details as required

1.7.2.2 Contingency Management Team Members:

• Pre-event

◦ Assist the Team Leader as directed

◦ Participate in contingency exercises

◦ Understand all CP roles and responsibilities

• Post-event

◦ Perform command center functions

Filename (SharePoint location, if desired (field code) 6

◦ Maintain a record of all communications using the provided log forms

1.7.3 Damage Assessment Team

The Damage Assessment Team is responsible for damage assessment of the computer facilities as quickly as possible following CP activation, and for reporting the level of damage to the Contingency/Emergency Management Team. The Team also, provides assistance when possible in the cleanup and repair of the facility. Specifically, the team responsibilities are:

• Pre-event

◦ Understand role and responsibilities under the CP

◦ Work to reduce the likelihood of events that could require CP activation

◦ Train employees in emergency preparedness

◦ Participate in CP exercises and tests

◦ Have a thorough understanding of damage assessment procedures

• Post-disaster

◦ Determine accessibility to facility, building, offices, and work areas/stations

◦ Assess extent of damage to the system and computer center

◦ Assess need and/or adequacy of physical security/guards

◦ Estimate time to recover primary facility and system

◦ Identify salvageable hardware

◦ Inform Contingency Management Team about the extent of damages, estimated recovery time, the need for physical security, and salvageable equipment details

◦ Maintain a salvageable equipment log

◦ Coordinate with suppliers restoring, repairing, or replacing equipment not under the purview of another CP

◦ Support data center cleanup following an incident

1.7.4 Hardware Team

<With appropriate modifications, the typical content below may be relevant to:

Hardware Salvage Team Original Site Restoration/Salvage Coordination Team>

The Hardware team is responsible for site preparation, physical planning, and installation of data processing equipment to provide required processing capability when the CP is activated. The Team’s responsibilities include ordering and installing hardware and software necessary at the alternate and permanent sites.

• Pre-event

Filename (SharePoint location, if desired (field code) 7

◦ Understand roles and responsibilities under the CP

◦ Work closely with the Contingency Management Team to reduce the likelihood of events that could require CP activation

◦ Work closely with the Contingency Management Team to reduce the likelihood of events that could require CP activation

◦ Train employees in emergency preparedness

◦ Participate in contingency plan exercises and tests

◦ Thoroughly understand CP procedures

◦ Maintain current system configuration information in an off-site storage facility and in this plan

• Post-event

◦ Verify pending occupancy requirements with alternative site

◦ Inspect physical space at the alternative site

◦ Interface with Software, Communications and Operations Team members on space configuration for the alternative site

◦ Coordinate transportation of salvageable equipment to the alternative site

◦ Notify the Administration Team of equipment requirements

◦ Ensure installation of required temporary terminals and workstations connected to the alternative site hardware

◦ Plan the hardware installation at the alternative site

◦ Plan and coordinate transportation of and installation of hardware at the permanent site, when available

1.7.5 Software Team

<With appropriate modifications, the typical responsibilities enumerated below may also be applicable to the following teams:

Systems Software Team Server Recovery Team (e.g., client server, Web Server) LAN/WAN Recovery Team Database Recovery Team Application Recovery Team(s) Telecommunications Team Test Team Network Operations Recovery Team Operating Systems Administration Team>

The Software Team is responsible for installation and configuration of all system and application software not installed by other administrators.

Filename (SharePoint location, if desired (field code) 8

• Pre-event

◦ Understand roles and responsibilities under the CP

◦ Work closely with the Contingency Management Team to reduce the likelihood of events that could require CP activation

◦ Train employees in emergency preparedness

◦ Participate in CP exercises and tests

◦ Thoroughly understand CP procedures

◦ Maintain current system software configuration information in an off-site storage facility and in an appendix to this plan

• Post-event

◦ Arrange for delivery of off-site storage containers containing backup media

◦ Receive, inventory and control access to the off-site storage containers and media

◦ Restore system/application software data files not installed in conjunction with another plan’s personnel

◦ Test and verify operating system and application software functions as required

◦ Return backup media storage containers to the off-site storage facility

1.7.6 Communications Team

The Communications Team is responsible for establishing voice and data links to/from the alternative site. This includes connecting local and remote users/customers to the alternate site.

• Pre-event

◦ Understand roles and responsibilities under the CP

◦ Work closely with the Contingency Management Team to reduce the likelihood of events that could require CP activation

◦ Train employees in emergency preparedness

◦ Participate in contingency plan exercises and tests

◦ Thoroughly understand CP procedures

◦ Maintain current communications configuration information in an off-site storage facility and in this CP

• Post-event

◦ Assist the Damage Assessment Team in evaluating communications equipment

◦ Plan, coordinate, and install the communications equipment required at the alternative site

◦ Plan, coordinate, and install the necessary cabling at the alternative sire not accomplished by another plan’s recovery personnel

Filename (SharePoint location, if desired (field code) 9

1.7.7 Physical and Personnel Security Team

The Physical and Personnel Security Team is responsible for providing personnel identification and access limitations to the building and floors and acts as liaison with emergency personnel.

This is crucial during the time of an incident because of the uncommonly large number of vendors, contractors and other visitors requiring access to the facility.

• Pre-event

◦ Understand roles and responsibilities under the CP

◦ Work closely with the Contingency Management Team to ensure physical security of existing system and facilities

◦ Train employees in emergency preparedness

◦ Participate in CP exercises and tests

◦ Thoroughly understand CP procedures

• Post-event

◦ Cordon off the facility including offices to restrict unauthorized access

◦ Coordinate with Building Management for authorized personnel access

◦ Provide additional physical security/guards

◦ Act as liaison with emergency personnel, such as fire and police departments

◦ Schedule and provide transportation security for files, reports, and equipment

◦ Provide assistance to officials investigating the damaged facility and site

1.7.8 Administration and Procurement Support Team

<Depending on potential workload, other teams might be formed as appropriate to assume some of the responsibilities listed below. Such teams could be these:

• Transportation and Relocation Team

• Media Relations Team

• Legal Affairs Team> The Administration and Procurement Support Team is responsible for providing secretarial, procurement, travel, housing, off-site storage, and other administrative matters not performed by other teams. The Team has limited authority to fund emergency expenditures other than capital equipment and salaries. This Team is also responsible for conveying pertinent information to the Department’s Media Relations Officer, will work with the Department’s Legal Representation staff on related matters.

• Pre-event

◦ Understand roles and responsibilities under the CP

◦ Work closely with the Contingency Management Team to ensure that all administrative functions are accomplishable

Filename (SharePoint location, if desired (field code) 10

◦ Work closely with the Contingency Management Team to reduce the likelihood of events that could require CP activation

◦ Work closely with the Contingency Management Team to ensure all potential means of transportation are understood and provided for

◦ Train employees in emergency preparedness

◦ Participate in contingency exercises

◦ Know the procedures to be followed

◦ Ensure details of administering emergency funds expenditures are known

◦ Assess need for alternative means of communication (other than normal telephone service) is available to all employees involved

◦ Ensure that current listings of viable means of transportation to the alternate site are maintained both at the off-site storage facility and included in an appendix to this plan

◦ Ensure that current contact information for the Department’s Media Relations Officer and for the Department’s Legal Representation is maintained both at the off-site storage facility and included in an appendix to this plan.

• Post-event

◦ Prepare, coordinate, and obtain approval for all procurement requests

◦ Coordinate deliveries

◦ Process requests for payment for all invoices related to the incident

◦ Arrange for travel and lodging of Team members

◦ Provide for acquisition of telephone equipment and services including voice, dial-up, and leased lines

◦ Provide for alternative means of communication among the teams in the event that normal telephone services are unavailable

◦ Arrange for temporary secretarial support for filing, and other administrative services required by the teams

◦ Coordinate with other teams to provide transportation as required

◦ Plan, coordinate and provide transportation to the alternate site and for teams as required in the accomplishment of their missions

◦ Support activities of the Department’s Media Relations Officer and Legal Representation staff as directed by the Contingency Management Team

1.8 Activation and Notification Phase

The Activation and Notification Phase defines initial actions taken once a {system name} disruption has been detected or appears to be imminent. This phase includes activities to notify recovery personnel, conduct an outage assessment, and activate the CP. At the completion of the

Filename (SharePoint location, if desired (field code) 11

Activation and Notification Phase, {system name} CP staff will be prepared to perform recovery measures.

1.8.1 Activation Criteria and Procedure

The {system name} CP may be activated if one or more of the following criteria are met:

• The type of outage indicates {system name} will be down for more than {RTO hours}

• The facility housing {system name} is damaged and may not be available within {RTO hours}

• <Other criteria, as appropriate>

The following persons or roles may activate the CP if one or more of these criteria are met:

<Establish one or more roles that may activate the plan based on activation criteria. Authorized persons may include the system or business owner, or the operations point of contact (POC) for system support.>

1.8.2 Notification

The first step upon activation of the {system name} CP is notification of appropriate mission/business and system support personnel. Contact information for appropriate POCs is included in Appendix <specify> Contact List Appendix>.

<Describe CP notification procedures, to include who makes the initial notifications, the sequence in which personnel are notified (e.g., system owner, technical POC, CP Coordinator, business unit or user unit POC, and recovery team POC). Describe notification methodology (email blast, call tree, automated notification system, etc.).>

• The first responder will notify the System Owner conveying all known information regarding the event

• The System Owner will inform the Damage Assessment Team (DAT) Leader of the event and direct initiation of assessment procedures

• The DAT Leader will notify Team members and direct them to complete the assessment procedures prescribed by this CP.

1.8.3 Damage Assessment

Following notification, the DAT will determine the extent of damage and estimate recovery time.

Assessment results are provided to the Contingency Management Team Leader. If damage assessment cannot be performed due to dangerous conditions, alternative steps will be taken as prescribed by this CP. For {system name}, the following method and procedure for notifications are used:

<Outline detailed procedures to include how to determine the cause of the damage; identification of potential for additional disruption or damage; affected physical area(s); and determination of the physical infrastructure status, IT equipment functionality, and inventory. Procedures should include recording items that will need to be replaced and the estimated time to restore normal operations. >

Filename (SharePoint location, if desired (field code) 12

1.9 Recovery Phase

During the Recovery Phase formal recovery operations are undertaken, beginning after the CP has been activated and notification accomplished; outage assessments have been completed (if possible); and appropriate teams have been mobilized. Recovery Phase activities focus on implementation of recovery strategies to restore system capabilities, repair damage, and resume operational capabilities at the original or alternative location. Upon completion of the Recovery Phase, {system name} will be functional and capable of performing the functions identified in Section 2.1 of this plan.

1.9.1 Sequence of Recovery Activities

The following activities occur during recovery of {system name}:

<Modify the following list as appropriate for the recovery strategy

• Identify recovery location (if not at original location)

• Identify required resources to perform recovery procedures

• Retrieve backup and system installation media

• Recover hardware and operating system (if required)

• Recover system from backup and system installation media>

1.9.2 Recovery Procedures

The following procedures are provided for recovery of {system name} at the original location.

Recovery procedures are outlined per team and will be executed in the prescribed sequence to maintain an efficient recovery effort.

<Provide general procedures for system recovery from backup media. If there is an alternative site, include procedures for recovery to that site. Specific keystroke level procedures may be provided in an appendix referenced in this section. Teams or persons responsible for each procedure should be identified.>

1.10 Reconstitution Phase

Reconstitution is the process during which normal system operations are resumed. If the original facility is not recoverable, activities in this phase can be applied to preparation of a new permanent location to support system requirements. A determination must be made as to whether the system has undergone significant change and will require reassessment and reauthorization. The phase consists of two major activities: validating successful reconstitution and deactivation of the CP.

1.10.1 Validation of Reconstitution

1.10.1.1 Validation Data Testing

The process of testing and validating data ensures that data files or databases have been completely recovered at the permanent location. The procedures in this process are found in this CP section.

Filename (SharePoint location, if desired (field code) 13

<Outline procedures for testing and validation to ensure that data is correct and up to date. This section may be combined with the Functionality Testing section if one set of procedures tests both functionality and data validity. Identify the teams or persons responsible for each procedure. An example of a validation data test for a low-impact system would be to test whether the last known complete transaction was updated in the database. Detailed data test procedures may be provided in Appendix E, System Validation Test Plan. >

1.10.1.2 Validation Functionality Testing

The process of testing and validating functionality ensures that the system is ready to return to normal operations.

<Outline procedures for system functionality testing and validation to ensure that the system is operating correctly. This section may be combined with the Data Testing section if one set of procedures tests both functionality and data validity. Identify the teams or persons responsible for each procedure. An example of a functional test for a low-impact system is logging onto the system and running a report or performing a transaction. Detailed functionality test procedures may be provided in Appendix E, System Validation Test Plan.>

1.10.2 Contingency Plan Deactivation

Once all of the activities outlined in this section have been completed, the {system owner} will formally deactivate the CP recovery and reconstitution effort. Notification of this declaration will be provided to all business and technical POCs.

1.10.2.1 Recovery Declaration

Upon successfully completing both functionality and data testing and validation, the {system owner} will formally declare that recovery efforts are complete, and that {system name} is in normal operations. {System name} business and technical POCs will be notified of the declaration by the CP Coordinator.

1.10.2.2 Notification of Users

When normal operations are restored, users will be notified by {role} using predetermined notification procedures (email, broadcast message, phone calls, etc.).

1.10.2.3 Cleanup

Cleaning up temporary recovery locations, dismantling temporary equipment, restocking supplies used, returning manuals or other documentation to their original locations, and readying the system for future contingency events will be accomplished by the Cleanup Team.

<Provide any specific cleanup procedures for the system including preferred locations for manuals and documents and returning backup or installation media to its original location.>

1.10.2.4 Data Backup

As soon as reasonably practical after recovery, the system will be fully backed up and a new copy of the current operational system stored for future recovery efforts. This full backup is then kept with other system backups. The procedures for conducting a full system backup are:

Filename (SharePoint location, if desired (field code) 14

<Provide appropriate procedures for ensuring that a full system backup is conducted within a reasonable time, ideally at the next scheduled backup time. >

1.10.2.5 Event Documentation

It is important to thoroughly document all recovery steps and changes in status, including actions taken and problems encountered during the recovery and reconstitution effort. Record lessons learned for inclusion when this CP is updated. It is the responsibility of each CP team and responsible individual to provide their documentation to the Contingency Management Team Leader.

<Provide details about the types of information each CP team leader is required to provide or collect for updating the CP with lessons learned. Types of documentation that should be collected after CP execution include but might not be limited to:

• Activity logs (including recovery steps performed and by whom, the time the steps were initiated and completed, and any problems or concerns encountered while executing activities)

• Functionality and data testing results

• Lessons learned documentation

• After Action Report> Event documentation procedures should detail responsibilities for development, collection, approval, and maintenance.>

Filename (SharePoint location, if desired (field code) 15

SUGGESTED APPENDIXES

<The attached CP appendixes are recommended. Other appendixes may be included based on system and plan requirements.>

Appendix A: Personnel Contact List <Include contact information for the CP’s Senior Management Official, and the leader and members of each team. For each contact, list name, title, address, and telephone numbers for work, home, and mobile.>

Appendix B: Vendor and Supplier Contact List <Include contact information for all key maintenance or support vendors. For each list name, title, address, and telephone numbers for work, home, and mobile. Include contract numbers and contractual response and onsite times.>

Appendix C: Detailed Recovery Procedures <This appendix includes detailed recovery procedures for the system, perhaps including:

• Keystroke-level recovery steps

• System installation instructions from tape, CD, or other media; Required configuration settings

• or changes

• Recovery of data from tape and audit logs

• Other system recovery procedures, as appropriate

<If the system’s recovery and reconstitution is solely reliant on another group or supporting system (such as a mainframe system), provide contact information and locations of detailed written recovery procedures for that supporting system.>

Appendix D: Alternate Processing Procedures <This section should identify any alternate manual or technical processing procedures that can be used to allow the business unit to continue some processing of information that would normally be done by the affected system. Examples of alternate processes include manual forms processing, input into workstations to store data until it can be uploaded and processed, and queuing of data input.

Appendix E: System Validation Test Plan <Include system acceptance procedures to be performed after the system has been recovered and prior to putting the system into full operation for users. The system validation test plan may include data testing and regression or functionality testing conducted prior to implementation of a system upgrade or change.

An example of a system validation test plan:>

Once the system has been recovered, the following steps will be performed to validate system data and functionality:

Procedure Expected Results Actual Results OK? Tester At the command prompt, type in System Log-in Screen

Filename (SharePoint location, if desired (field code) 16 sysname appears Log in as user testuser, using password testpass

Initial Screen with Main Menu shows

From Menu - select 5- Generate Report

Report Generation Screen shows

- Select Current Date Report

- Select Weekly

- Select To Screen

Report is generated on screen with last successful transaction included

- Select Close Report Generation Screen Shows

- Select Return to Main Menu

Initial Screen with Main Menu shows

- Select Log-Off Log-in Screen appears

Appendix F: Alternate Storage, Site, and Telecommunications <Alternative storage, site, and telecommunications information is required for high-impact systems.

Refer to NIST SP 800-53 Rev. 3 for required control specifics. Information that should be provided for each area includes:

Alternate Storage

• City and state of alternative storage facility, and distance from primary facility

• Whether the alternative storage facility is owned by the organization or is a third-party storage provider

• Name and points of contact for the alternate storage facility

• Delivery schedule and procedures for packaging media to go to alternate storage facility

• Procedures for retrieving media from the alternative storage facility

• Names and contact information for those persons authorized to retrieve media

• Alternative storage configuration features that facilitate recovery operations (such as keyed or card reader access for authorized retrieval personnel)

• Any potential problems with access to the alternative storage site in the event of a widespread disruption or disaster

• Mitigation for potential access problems at alternative storage site in the event of a widespread disruption or disaster

• Types of data located at the alternative storage site, including databases, application software, operating systems, and other critical information system software

• Other information as appropriate

Alternate Processing Site

• Location (city and state) of alternative processing site, and distance from primary facility

Filename (SharePoint location, if desired (field code) 17

• Whether the alternative processing site is owned by the organization or is provided by another organization

• Name and contact information for the alternative processing site

• Procedures for accessing and using the alternative processing site

• Access security features of alternate processing site

• Names and contact information for those persons authorized to go to alternate processing site

• Type of alternate processing site, and equipment available there

• Alternate processing site configuration information such as available power, floor space, office space, telecommunications availability, etc.

• Potential accessibility problems at the alternate processing site in the event of a widespread disruption or disaster

• Mitigation for access problems at the alternative processing site in the event of a widespread disruption or disaster

• SLAs or other agreements for use of the alternative processing site, available office space, setup times, etc.

• Other information as appropriate

Alternative Telecommunications:

• Name and contact information of alternate telecommunications vendors;

• Geographic locations of alternate telecommunications vendors facilities (such as central offices, switch centers, etc.);

• Contracted capacity of alternate telecommunications;

• SLAs or other agreements for implementation of alternate telecommunications capacity;

• Information on alternate telecommunications vendor contingency plans;

• Names and contact information for those persons authorized to implement or use alternate telecommunications capacity

• Other information as appropriate. >

Appendix G: System and Input-Output Diagrams <Information for this appendix should be available from the system’s system Security Plan (SP).

The appropriate information can be copied from the SP, or the appendix can be attached as part of this appendix and reference made here to the appropriate SP section. Language or references should include any system architecture, input/output, or other technical or logical diagrams that may be useful in recovering the system.>

Filename (SharePoint location, if desired (field code) 18

Appendix H: Hardware and Software Inventory < Inventory information should include type of system server or hardware, including processors and memory requirements, storage requirements, and any other pertinent information. The software inventory should identify the operating system (including version and service pack levels, and any applications (such as database software), needed to operate the system.>

Appendix I: Interconnections Table <Information for this appendix should be available from the system’s system Security Plan (SP).

The appropriate information can be copied from the SP, or the appendix can be attached as part of this appendix and reference made here to the appropriate SP section. Include information on all other systems that directly interconnect or exchange information with the system. Include the type of connection, information transferred, and contact person for that system.

If the system does not have any direct interconnections, so state.>

Appendix J: Test and Maintenance Schedule <All CPs should be reviewed and tested at the frequency specified by the organization (at least annually) or whenever there is a significant system change. In this appendix, provide a schedule for the testing of the system. For low-impact systems, a yearly tabletop exercise is sufficient.

The tabletop exercise should include all CP Points of Contact, and should be conducted by an outside or impartial observer. A formal test plan should be developed prior to the tabletop exercise, and the exercise and questions developed to include key sections of the CP including a walk-through of the following:

• Notification procedures

• System recovery on an alternate platform from backup media

• Internal and external connectivity

• Reconstitution procedures Results of the test are documented in an After Action Report, and Lessons Learned are developed for updating the CP.

The following is a sample annual test and maintenance schedule for a low-impact system:>

Step Due Date Responsible Party Date

Scheduled Date

Completed Identify tabletop facilitator. April 1 Contingency Management

Team Leader

Develop tabletop test plan. May 1 Tabletop Facilitator Invite participants. May 10 Tabletop Facilitator Conduct tabletop test. May 31 Tabletop Facilitator, Contingency Management Team Leader, POCs

Finalize after action report and lessons learned.

June 10 Contingency Management Team Leader

Update CP based on lessons learned.

June 30 CP Coordinator

Approve and distribute updated version of CP.

July 15 CP Director, CP Coordinator

Filename (SharePoint location, if desired (field code) 19

Appendix J: Associated Plans, Processes, and Procedures <Information for this appendix should be available from the system’s system Security Plan (SP).

The appropriate information can be copied from the SP, or the appendix can be attached as part of this appendix and reference made here to the appropriate SP section. Identify CPs for any other systems that either interconnect or provide support. Identify the current version of the CP, its location, and the primary POC.

Appendix K: Business Impact Analysis <Include Business Impact Analysis results in this appendix.>

Appendix L: Document Revision History

Record of Changes

Date Section Description Changed by

{Component name}

{System name}

Information System Contingency Plan

Prepared by Organization Name C ity, State, ZIP

Version <0.0>

<Date>

Plan Approval

As the designated authority for {system name}, I hereby certify that this information system contingency plan is complete and in accordance with Department of Homeland Security Sensitive Systems Policy Directive 4300A, and that the information contained in this CP is provides an accurate representation of hardware, software, and telecommunications components of the application.

I further certify that this document identifies the criticality of the system as it relates to the mission of the {Component name}, and that the recovery strategies identified will provide the ability to recover the system’s functionality in the most expedient and cost-efficient methods in keeping with the system’s level of criticality.

Further, I attest that this CP for {system name} will be tested at least annually. This CP was last tested on {exercise date}; the test, training, and exercise (TT&E) material associated with this test can be found {location of TT&E results}. This document will be modified as changes occur and will remain under version control in accordance with DHS Sensitive Systems Policy Directive 4300A.

________________________________ Date _____________

{system owner name}

{syst…