ISCPs and disaster recovery planning documents are supporting documents in an organization's overall Contingency Plan. In the event of a significant incident, the IRS would use a suite of plans to effectively respond, react, recover, and resume business. The BCP acts as an over-arching plan, that encompasses all activities that ensure business resumes and continues in the event of a significant impact or disaster. (NIST 800-34: Section 2.2)

Note the difference between Contingency Planning and Continuity Planning, both critical components of the overall BCP: (NIST 800-34: Section 2.2)

Numerous plans contribute to the organizations overall BCP. (NIST 800-34: Section 2.2)

The BCP is the business/functional unit plan that includes the advance planning and preparations necessary to minimize loss and ensure continuity of Mission Essential Functions (MEFs), as well as Critical Business Processes (CBPs), during and after a disruption. (NIST 800-34: Section 2.2.1)

The Incident Response Plan should outline procedures 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. (NIST 800-34: Section 2.2.5)

The Critical Infrastructure Protection (CIP) Plan addresses the security, protection, and resiliency of those components of the national infrastructure critical to national and economic security. (TD P 85-01: Appendix J)

The Crisis Communications Plan (CCP), also known as an Emergency Communication Plan (ECP), must document standard procedures for internal and external communications in the event of a disruption. The Crisis Communications Plan specifies the following (NIST 800-34: Section 2.2.3):

The Occupant Emergency Plan (OEP) must outline 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. (NIST 800-34: Section 2.2.8)

The Continuity of Operations Plan (COOP) must outline procedures to restore MEFs at an alternate site for a period of up to 30 days of operation. (NIST 800-34: Section 2.2.2)

The Disaster Recovery (DR) Plan must house a centralized set of information system contingency plans for major disruptions that result in denied access to the primary facility infrastructure for an extended period of time and that further require relocation and transition of information systems. The DRP is site-specific. A DRP must exist for each site, including the primary site, as well as the alternate site(s). (NIST 800-34: Section 2.2.6)

The Information System Contingency Plan (ISCP) must outline procedures for information system recovery following major disruptions. ISCPs must document roles and responsibilities, inventory information, system assessment procedures, detailed recovery procedures, and system testing procedures. The ISCP documents technical capabilities designed to support contingency operations. The ISCP is information system-specific. ISCPs are developed for site-specific applications, business unit level applications, and enterprise-wide applications. An ISCP must exist for each information system. (NIST 800-34: Section 2.2.7)

Consideration of appendices for inclusion in contingency plans must include the following (NIST 800-34: Section 4.5):

IRM 10.8.1 requires the development and maintenance of continuity of support plans/ISCPs. (IRS-defined)

The ISCP must provide the procedures and capabilities for recovering systems and applications when relocation of those assets is not necessary. In addition, the ISCP addresses the resources, roles, responsibilities, and procedures for recovering IT systems after a disruption. (NIST 800-34: Chapter 4)

All FISMA-reportable systems must have an ISCP. (IRS-defined)

All FISMA-reportable systems must exercise their ISCP annually. (IRS-defined)

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

ISCPs must be reviewed no less than annually, and when major changes are made to the system, or contact information necessary in the event of an incident have changed. (IRS-defined)

The DRP defines the resources, roles, responsibilities, actions, tasks, and the steps required, down to a key step level, to restore an IT system to its full operational status at the alternate facility after a disruption. Within the IRS, the DRP is a standalone document contained within the automated tool TSCC. The DRP must include recovery keystroke procedures that provide system or application recovery steps with greater detail than the ISCP. Typically, these disaster recovery planning documents are activated only when there has been a significant incident requiring relocation of the system or application. (IRS-defined)

A DRP or disaster recovery planning document refers to an IT-focused plan designed to restore operability of the target system and/or application in computing space within an alternate site after an emergency. (IRS-defined)

The disaster recovery planning document must define the resources, roles, responsibilities, actions, tasks, and the detailed work steps (keystrokes) required to restore an IT system to its full operational status at the current or alternate facility after a major disruption with long-term effects. (IRS-defined)

The disaster recovery planning document must be developed with the following factors considered: (IRS-defined)

For assistance in developing a DRP/disaster recovery planning document and for copies of the DRP templates, email the SRM at *IT IT DR Mailbox, and put DRP in the subject line to assist in routing the request. (IRS-defined)

NIST 800-34, Contingency Planning Guide for Federal Information Systems, lists seven steps to developing and maintaining an effective ISCP. The initial ISCP is developed during the IRS SA&A process required for every application or system before going into production. The seven steps below provide an overview of the process: (NIST 800-34: Chapter 3)

Critical functions have been defined by the IRS Senior Executive team and business representatives as those most critical to the tax administration mission of the IRS supporting the overall continuity of the Federal Government. (IRS-defined)

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Because the RTO must ensure that the MTD is not exceeded, the RTO must be shorter than the MTD. (NIST 800-34: Section 3.2.1)

COOP functions must be sustained within 12 hours and for up to 30 days form an alternate site; ISCP recovery time objectives are determined by the system-based BIA. (NIST 800-34: Section 3.2.1)

The ISCP Coordinator, working with management, must determine the optimum point (also known as the Cost Balance Point) to recover the information system by 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. 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. (NIST 800-34: Section 3.2.1)

Refer to IRM 10.8.13 for additional guidance regarding BIA.

Employees with DR responsibilities must be required to complete DR-focused training each year. (IRS-defined)

Training hours must be based on employees roles with respect to DR as indicated in the ITSCM Training Curriculum. (IRS-defined)

Employees/managers must work with their training coordinator to ensure credit is given for classes relating to ITSCM/ISCP. (IRS-defined)

Employees with primary or full time DR duties are encouraged to complete formal, vendor-sponsored DR training and tests for DR certification. (IRS-defined)

Employees with DR certifications must be required to complete the appropriate number of hours (Continuing Professional Education (CPE)) yearly to maintain their certification. (IRS-defined)

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Training for personnel with contingency plan responsibilities must focus on familiarizing them with ISCP roles and teaching skills necessary to accomplish those roles. Training must be provided at least annually. Personnel newly appointed to ISCP roles must receive training shortly thereafter. (NIST 800-34: Section 3.5.2)

Recovery personnel must be trained on the following plan elements (NIST 800-34: Section 3.5.2):

ISCPs must be maintained in a state of readiness, which includes having the following: (NIST 800-34: Section 3.5):

Testing results must be used to assess and report on the overall sustainability of IT Service Continuity within the IRS. Through the evaluation, assessment, or exercise of the ITSCM Program, identified gaps may be mitigated by program changes, proposed investment strategies, process adjustments, or risk acceptance/avoidance/transference options. ISCP TT&E improves the IRS’s ability to prepare for, respond to, manage, and recover from adverse events. (NIST 800:34: Section 3.5)

ISCP exercises must consist of Tabletop, Functional Exercises, or DR Test as required based on security availability and additional guidance issued by Director, Security Risk Management. (IRS-defined)

Department of the Treasury and OMB ISCP exercise requirements must be based on the FIPS 199 security availability category below: (NIST 800-34: Section 3.5.3)

For FIPS 199 LOW systems, the tabletop must simulate a disruption, include all main ISCP points of contact, and be conducted by the system owner. (NIST 800-34: Section 3.5.4)

For FIPS 199 MODERATE systems, the functional exercise must include all ISCP points of contact and be facilitated by the system owner. Exercise procedures must be developed to include an element of system recovery from backup media. (NIST 800-34: Section 3.5.4)

For FIPS 199 HIGH systems, the full-scale functional exercise must include a system failover to the alternate location. This could include additional activities such as full notification and response of key personnel to the recovery location, recovery of a server or database from backup media or setup, and processing from a server at an alternate location. The test must also include a full recovery and reconstitution of the information system to a known state. (NIST 800-34: Section 3.5.4)

In addition to the exercise requirements above, an annual tabletop and a functional exercise must be conducted for all systems and applications that support one for more of the IRS critical functions. (IRS-defined)

Refer to Exhibit 10.8.60-1 for a definition of a tabletop and functional exercise. (IRS-defined)

Procedures for conducting ISCP Exercises are in IRM 10.8.62. (IRS-defined)

Additional guidance based on Department of the Treasury, OMB, or IRS requirements are issued by the SRM Director each FISMA period. (IRS-defined)

Owners of FISMA-reportable systems that support a critical function must be required to test the recovery of their system annually. (IRS-defined)

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

All FISMA Non-Reportable (FNR) applications are required to have a DRP or disaster recovery planning document(s). As a general rule, applications not covered by any FISMA system or application DRP may develop a DRP-FNR as a general rule. (IRS-defined)

A tested DRP is a disaster recovery planning document that has been subjected to an evaluation using a DR Test Plan to identify the scope, objectives, and expected results, recovering the system/application using backup data on different equipment or another location. The actual summary results are used to measure the ability of the recovery personnel using the disaster recovery planning document(s) to recover an IT system and its data to full operational status following a disruption. (IRS-defined)

Procedures for requesting and conducting DR Tests are in IRM 10.8.62. (IRS-defined)

The test results must be documented in the Summary Report within 30 calendar days after the conclusion of the annual Disaster Recovery Test. (IRS-defined)

All disaster recovery planning documents must be updated as appropriate based on lessons learned following any conducted tests/exercises. (IRS-defined)

Refer to IRM 10.8.1, CP-04 or IRM 10.8.24, CP-4 for additional guidance on contingency testing.

Recovery Phase activities must focus on implementing recovery strategies to restore system capabilities, repair damage, and resume operational capabilities at the original or new alternate location. (NIST 800-34: Section 4.3)

When recovering a complex system, recovery procedures must reflect system priorities identified in the BIA. The sequence of activities must reflect the system’s MTD to avoid significant impacts to related systems. Procedures must be written in a stepwise, sequential format so system components may be restored in a logical manner. The procedures must also include escalation instructions to coordinate with other teams where relevant when certain situations occur, such as (NIST 800-34: Section 4.3.1):

The ISCP must provide detailed procedures to restore the information system or components to a known state. Recovery procedures may address the following actions (NIST 800-34: Section 4.3.2):

Effective escalation and notification procedures must define and describe the events, thresholds, or other types of triggers that are necessary for additional action. Actions would include additional notifications for more recovery staff, messages and status updates to leadership, and notices for additional resources. (NIST 800-34: Section 4.3.3)

Refer to IRM 10.8.1 or IRM 10.8.24, CP-10 System Recovery and Reconstitution for additional guidance on information system recovery and reconstitution.

The Reconstitution Phase must define the actions taken to test and validate system capability and functionality. Recovery activities are completed and normal system operations are resumed. (NIST 800-34: Section 4.4)

Refer to IRM 10.8.1 or IRM 10.8.24, CP-10 System Recovery and Reconstitution for additional guidance on information system recovery and reconstitution.

Contingency strategies, covering backup and recovery, must be created in accordance with FIPS 199 and NIST SP 800-53 to mitigate risks arising from the use of information and information systems in the execution of mission/business processes. (NIST 800-34: Section 3.4)

Consideration of recovery methods must include the following (NIST 800-34: Section 3.4.1):

To effectively plan for realistic recovery, an evaluation of the resources required to resume mission/business processes as quickly as possible must be conducted. Necessary resources must be identified and listed in the appropriate sections of the ISCP/disaster recovery planning documents (e.g., facilities personnel, equipment, software, data files, system components, and vital records etc.). (NIST 800-34: Section 3.2.2)

Developing recovery priorities is the last step and an important output of the BIA process. Utilizing the data gathered during the BIA (such as outage impact, tolerable downtime, resources required, and impact to the critical functions), recovery priorities can be effectively established. The ISCP Coordinator must consider system recovery measures and technologies to meet the resulting information system recovery priority hierarchy. (NIST 800-34: Section 3.2.3)

The data gathered during the BIA must be used to establish recovery priorities within systems, applications, and the enterprise. (NIST 800-34: Section 3.2.3)

Refer to IRM 10.8.13 for additional guidance regarding BIA.

Outage impacts identified in the BIA must be looked at to determine if the impacts may be mitigated or eliminated through preventive measures. Preventive controls or actions, where feasible and cost effective, reduce overall cost and actions that may be required to recover the system after a disruption. Some preventive controls are listed in NIST SP 800-53. Some common measures include: (NIST 800-34: Section 3.3)

Refer to IRM 10.8.13 for additional guidance regarding BIA.

Detailed lists of equipment needs and specifications must be maintained within contingency plans. (NIST 800-34: Section 3.4.4)

If an IRS information system is damaged or destroyed or if the primary site is unavailable, necessary hardware and software will need to be activated or procured quickly and delivered to the alternate location. To prepare for equipment replacement, the following strategies exist: (NIST 800-34: Section 3.4.4)

The ISCP coordinator must consider the following factors impacting equipment replacement: (NIST 800-34: Section 3.4.4)

The ISCP Coordinator must ensure that the strategy chosen can be implemented effectively with available personnel and financial resources. (NIST 800-34: Section 3.4.5)

The ISCP Coordinator must perform cost-benefit analysis of vendor, hardware, software, travel/shipping, labor/contractor, testing and supply costs for each of the following: (NIST 800-34: Section 3.4.5)

Only system administrators, managers, or other individuals with responsibility for IT Contingency or ITSCM must have access to or copies of applicable ISCPs and/or disaster recovery planning documents. (IRS-defined)

System administrators, managers, or other individuals with responsibility for IT Contingency or ITSCM must be provided copies of or access to system and application ISCPs and/or disaster recovery planning documents by their management or the system or application owner. (IRS-defined)

Requests for copies of or access to system and application ISCPs and/or disaster recovery planning documents must be made through the employees' manager to the system and/or application owner. (IRS-defined)

All other requests for copies of, or access to, system and application ISCPs and/or disaster recovery planning documents must be requested from the system or application owner. The request must specify what is being requested, purpose, contact person, and where the copy is to be sent. (IRS-defined)

Encryption is most effective when applied to both the primary data storage device and on backup media going to an offsite location. Media readers (e.g., tape drives, CD or DVD readers) should be available at the alternate site location to correctly read the encrypted data during recovery efforts. The cryptographic key and the encryption software should both be available to the new system at the alternate processing site, along with the keying material. (NIST 800-34: Section 5.1.2)

The following common backup methods must be considered (NIST 800-34: Section 5.1.2):

In developing a system backup policy, the following questions must be considered (NIST 800-34: Section 5.1.2):

Certain factors should be considered when choosing the appropriate backup solution (NIST 800-34: Section 5.1.2):

Use of high availability (HA) processes to provide for online real-time resilient access to alternate system resources should be considered. HA denotes systems that can achieve an uptime of 99.999 percent or better. (NIST 800-34: Section 5.1.6)

A system should be resilient to environmental and component-level failures. The following strategies for protection of resources should be considered (NIST 800-34: Section 5.1.3):

Client/server systems can have processing and data at both the server and client workstation levels. (NIST 800-34: Section 5.2)

Telecommunications networks should be documented. (NIST 800-34: Section 5.3.1)

Vendors and communication providers must be documented. (NIST 800-34: Section 5.3.1)

Telecommunications contingency solutions must have system security, management, operational, and technical controls set that are equal to that of counterpart telecommunications networks in production. (NIST 800-34: Section 5.3.1)

The BIA must be reviewed to determine telecommunications recovery priorities. The BIA must identify the high-availability FIPS 199 impact levels for any data networks and email that support COOP Mission, Primary, or National Essential Functions. (NIST 800-34: Section 5.3.1)

Refer to IRM 10.8.33, Information Technology (IT) Security, Mainframe System Security Policy, for addition guidance on mainframes.