10.8.60 IT Service Continuity Management (ITSCM) Policy and Guidance

Manual Transmittal

December 02, 2019

Purpose

(1) This transmits the revised Internal Revenue Manual (IRM) 10.8.60, Information Technology (IT) Security, IT Service Continuity Management (ITSCM) Policy and Guidance.

Material Changes

(1) The following sections have been updated/clarified with this version of policy:

  1. IRM 10.8.60 has been completely restructured and aligned to TD P 85-01, Treasury Information Technology (IT) Security Program and NIST SP 800-34 Contingency Planning Guide for Federal Information Systems. Many sections have been added, revised, deleted or relocated within this IRM. For a detailed listing of the changes please see Exhibit 10.8.60-3.

(2) Editorial changes (including grammar, spelling, and minor clarification) were made throughout the IRM.

Effect on Other Documents

This supersedes IRM 10.8.60, dated September 4, 2015, and all prior versions of IRM 10.8.60. This IRM supplements IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, IRM 10.8.2, Information Technology Security Roles and Responsibilities, and IRM 10.8.62, Information Technology (IT) Security, Information Systems Contingency Plan (ISCP) and Disaster Recovery (DR) Test, Training, and Exercise (TT&E) Program, defines test, training, and exercise processes to ensure Internal Revenue Service (IRS) information technology (IT) resources and business processes can be recovered.

Audience

IRM 10.8.60 shall be distributed to all personnel responsible for ensuring that adequate security and/or availability is provided for IRS information and information systems. This policy applies to all employees, contractors, and vendors of the IRS.

Effective Date

(12-02-2019)

Nancy Sieger
Acting Chief Information Officer

Program Scope and Objectives

  1. This IRM lays the foundation to implement and manage IT Service Continuity Management (ITSCM) for information systems security and availability regarding Information System Contingency Plans (ISCP) and Disaster Recovery (DR) within the IRS.

  2. Audience: The provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS.

    2. Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.

    3. All IRS information and information systems. For information systems that store, process, or transmit classified information, please refer to IRM 10.9.1, National Security Information , for additional procedures for protecting classified information.

  3. Policy Owner: Chief Information Officer.

  4. Program Owner: Architecture and Implementation (an organization within Cybersecurity)

Scope

  1. This IRM covers policy for the IRS's overall ITSCM Program and Business Continuity Plan (BCP). The pieces of the BCP shall work together to create and support the overall Business Continuity of the IRS.

  2. The IRS shall ensure that the product and version (e.g., software, hardware etc.,) selected is in accordance with IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) that dictates the official products and versions within the IRS.

  3. The IRS shall ensure the application or system version (e.g., software, hardware) is a version for which the vendor still offers standardized technical support.

  4. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence, unless the security controls/requirements in this policy are more restrictive or otherwise noted.

Objectives

  1. This IRM establishes the minimum baseline security policy and requirements for all IRS IT assets in order to:

    1. Protect the critical infrastructure and assets of the IRS against attacks that exploit IRS assets.

    2. Prevent unauthorized access to IRS assets.

    3. Enable IRS IT computing environments that meet the security requirements of this policy and support the business needs of the organization.

  2. It is acceptable to configure settings to be more restrictive than those defined in this IRM.

  3. To configure less restrictive controls requires a risk-based decision. See the Risk Acceptance and Risk-Based Decisions section within this IRM for additional guidance.

Background

  1. This IRM provides policies and guidance to be used by the Internal Revenue Service (IRS) organizations to carry out their respective responsibilities under ITSCM for information systems security and availability regarding Information System Contingency Plans (ISCP) and Disaster Recovery (DR).

    1. The Associate Chief Information Officer (ACIO) Information Technology (IT) Cybersecurity, is responsible for defining relevant policy requirements, for the IRS enterprise-wide ITSCM program and for ensuring Information System (IS) Contingency Plans are developed, executable, and successfully implemented.

    2. This IRM defines the overall requirements to ensure compliance with policy and regulations and the ability to recover the IRS's Critical Business Processes (CBPs), hereinafter referred to as Critical Functions, through the systems and applications that support them.

  2. FIPS 200 mandates the use of Special Publication 800-53 as baseline for the creation of agency IT security policy.

  3. IRM 10.8.60 is part of the Security, Privacy and Assurance policy family, IRM Part 10 series for IRS Information Technology Cybersecurity.

Authority

  1. IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, establishes the security program and the policy framework for the IRS.

  2. This ITSCM policy provides requirements and guidance to ensure that:

    1. All IRS systems and applications owned or managed by IRS employees, vendors, or contractors are compliant with Office of Management and Budget (OMB), Federal Information Security Modernization Act of 2014 (FISMA), National Institute of Standards and Technology (NIST), Department of Homeland Security (DHS), Treasury, and IRS guidelines as they relate to disaster recovery.

    2. All IRS IT systems and applications shall have sufficient Disaster Recovery (DR) capability to recover IRS data with system/application functionality (data is available and usable to customer) according to agreed upon, pre-defined Recovery Time Objective(s)/Recovery Point Objective(s)/Maximum Tolerable Downtime (RTO/RPO/MTD) documented in the ISCP.

  3. In accordance with Federal laws and regulations, the IRS shall:

    1. Establish and manage an Information Security Program within all its offices.

    2. Assign security responsibility to appropriate officials.

    3. Ensure continuity of operations for information systems that support the operations and assets of the agency.

    4. Authorize Security Assessment & Authorization (SA&A) for systems and applications prior to operations, and periodically after deployment.

    5. Conduct tabletops, functional exercises, or disaster recovery tests (e.g., Alternate Processing Sites (APS)) as required for their systems’ disaster recovery planning documents capabilities at least annually within a FISMA period. FISMA periods run from July 1 thru June 30 each year. Exercises and tests will be conducted with all impacted parties.

    6. Train appropriate personnel in their continuity roles in accordance with succession plan.

    7. Track and document findings and lessons learned to ensure that corrective action plans and executive briefings can be developed.

    8. Ensure that findings are reported to executive management for the direction and leadership to assure timely implementation of corrective action plans to resolve findings or accept risks.

  4. The Capability Maturity Model Integration (CMMI) shall be used to judge the maturity of all IRS organizational processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.

  5. The Information Technology Infrastructure Library (ITIL), a collection of best practices, shall be used by the IRS to build an efficient framework for delivering IT Service Management (ITSM), ITSCM , and ensuring that the IRS is meeting business goals and delivering benefits that facilitate business change, transformation, and growth.

  6. The Project Management Institute (PMI) organization advances the project management profession through globally recognized standards and certifications. PMI standards, such as the Project Management Body of Knowledge (PMBOK), are the preferred IRS method of Project Management.

  7. All artifacts developed or acquired by the IRS, shall incorporate CMMI, ITIL, and/or PMI requirements, in order to meet the business objectives of the IRS because they represent investments by the organization that are expected to provide current and future business value to the IRS.

Risk Acceptance and Risk-Based Decisions

  1. Any exception to this IRM requires that the Authorizing Official (AO) make a Risk-Based Decision.

  2. Risk-Based Decision requests shall be submitted in accordance with IRM 10.8.1 and use of Form 14201, as described in the Risk Acceptance Request and Risk-Based Decision Standard Operating Procedures (SOP), available on the Enterprise Federal Information Security Management Act (FISMA) Compliance SharePoint site via the Risk Acceptance Requests link:≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. Refer to IRM 10.8.1 for additional guidance about risk acceptance.

Roles and Responsibilities

  1. IRM 10.8.2, Information Technology Security Roles and Responsibilities, defines IRS-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. The supplemental roles and responsibilities provided below are specific to the implementation of the IRS ITSCM Program.

IRS Executive Sponsors, Program Managers, and Technical Leads

  1. IRS Executive Sponsors, Program Managers, and Technical Leads shall be identified for all major infrastructure initiatives. These initiatives shall:

    1. Comply with Enterprise Life Cycle (ELC) requirements.

    2. Address infrastructure changes.

    3. Support day-to-day operations (e.g., desktop support, Unified Work Request (UWR) process, change requests, Service Desk support, server support, security, email support, and asset inventory).

    4. Comply with or establish Service Level Agreements (SLAs).

    5. Complete infrastructure integration tests.

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

  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    4. ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    5. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    6. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    7. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    8. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    4. ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Information Technology (IT)

  1. IT is responsible for:

    • Ensuring NIST SP 800–53 contingency plan controls are implemented and documented.

    • Completing a BIA on all systems.

    • Providing updates to the ISCP with changes to the owner as they are identified, but not less than annually.

    • Providing subject matter expertise for DR capabilities.

    • Providing subject matter expertise to write the detailed content (keystrokes/step-by-step) of each plan.

    • Assigning a DR Test Director.

    • Performing annual execution and exercise of each ISCP.

    • Performing annual execution and tests of each disaster recovery planning document.

    • Updating the disaster recovery planning documents with changes after each DR Test.

    • Partnering with SRM and BODs to coordinate requirements, priorities, recovery times, cost evaluations, and support to procurement activities to enhance DR capabilities to meet stated business objectives.

    • Maintaining/owning the content of the disaster recovery planning documents.

    • Providing resources for DR planning, including staffing, location, and procuring funded equipment.

    • Establishing a succession planning document to ensure the service is protected from experiencing a personnel single point of failure within their organization in the event of a disaster, which would negatively impact the recovery of systems and/or applications.

    • Securing concurrence, in writing, from the Director, SRM prior to closing all ISCP/disaster recovery planning documents related POA&M items.

    • Ensuring that staff, who have roles in developing and/or exercising information system contingency plans and/or disaster recovery plans, attend contingency planning and disaster recovery awareness and training.

    • Coordinating with Business Owners to identify or develop potential recovery or alternate processing sites for FISMA-reportable and non-reportable applications with requirements defined in the IT BIA.

    • Identifying backup storage sites and coordinating with Business Owners to document site location in the ISCP and disaster recovery planning documents.

    • Ensuring that all data/applications code has been backed up and sequence is identified in the ISCP.

    • Ensuring backup media has been encrypted with encryption procedures listed in the ISCP.

    • Ensuring backup media is sent to an offsite location and coordinating with Business Owners to document site location in the ISCP.

Business Operating Division (BOD) Information System Owners

  1. The BOD/Information System Owner is the agency official responsible for the overall procurement, development, integration, modification, operation and maintenance of the information system. For applications housed on systems owned by or operated by IT, IRS IT will work with BODs to determine appropriate enterprise priorities and identify funding sources for the procurement of equipment. The Information System Owner is also known as the Business and Functional Unit Owner.

  2. Each BOD that owns or operates IT resources shall comply with the IT requirements. See the Information Technology (IT) section in this IRM.

  3. Each contractor or vendor that owns or operates IT resources on behalf of the IRS shall comply with the IT requirements.

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  5. In addition to the Information System Owner/Business and Functional Unit Owner responsibilities defined in IRM 10.8.2, Business and Functional Unit Owners shall:

    • Include security requirements in their capital planning and investment business cases.

    • Ensure security requirements are adequately funded and documented in accordance with OMB Circular A-11 (Preparation, Submission, and Execution of the Budget).

    • Fully describe and document the information system in the ISCP.

    • Clearly define system and application priorities, subsequent needs, and related risk acceptance or avoidance for recovery.

    • Determine recovery needs and timeframes needed for business restoration through comprehensive BIA evaluations.

    • Determine what data needs to be recovered and the priority order for recovery.

    • Develop DR requirements during the development phase of all new systems and throughout any production system upgrades.

    • Provide the funding for the DR equipment/space/storage needed to meet the recovery goals (set by the business).

    • Fully describe and document the details of the information system in the ISCP that is required by FISMA for each system.

    • Ensure ISCPs and DR plans for all applications and systems are reviewed annually, have a tabletop exercise performed annually and tested annually if applicable per current requirements.

    • Work jointly with IT Operations, SRM, and A&I in development and tests of DR plans to ensure business continuity.

    • Support the development of processing priorities for completion of work following emergencies that degrade computer processing capabilities.

    • Work jointly with IT in the tests of the disaster recovery planning documents to ensure availability of data from the recovered system.

    • Work with SRM regarding enterprise priorities.

  6. When integrated Business Continuity (BC) ITCSM exercises are planned, it is recommended that BODs work jointly with AWSS, IRS IT operations, and SRM to conduct these exercises and to validate the recovery times of critical functions and supporting applications.

Contracting Officer (CO)

  1. Each contractor or vendor that owns or operates IT resources on behalf of the IRS shall also comply with IRS IT requirements in that particular contract and the Information Technology (IT) section of this IRM.

  2. Contracting Officers (COs) acting on IRS behalf are required to ensure the inclusion of IRS DR expectations within contracts for the purpose of DR support. The contract shall include the following:

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. SRM or A&I (as applicable) are responsible for preparing justification and requirement documents to support the letting of any contracts needed to support ITSCM; to provide necessary recovery capability; or to support continuity plans in conjunction with the ITIL Supplier Management process.

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    Note:

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

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

IT Security Controls

  1. The security controls in this IRM supplement the requirements defined in IRM 10.8.1.

  2. In addition to the Contingency Planning guidance defined within this IRM, requirements for the following Contingency Planning control areas shall be implemented in accordance with IRM 10.8.1 .

    • CP-11 Alternate Communications Protocols

    • CP-12 Safe Mode

    • CP-13 Alternate Security Mechanisms

  3. NIST controls have been identified in their applicable sections within this IRM.

AT - Security Awareness Training

  1. FISMA requires that all agencies establish security awareness training to inform personnel, including contractors and vendors, of information security risks associated with their activities, and their responsibilities in complying with agency policies and procedures to protect the confidentiality, integrity, and availability of information and information systems.

  2. See IRM 10.8.1 and IRM 10.8.2 for additional guidance on Security Awareness.

CP-3 Contingency Training

  1. See IRM 10.8.1, CP-3 Contingency Training for additional guidance on contingency training.

Disaster Recovery Training
  1. SRM shall be responsible for developing and disseminating training information through IRS IT/FISMA Program Management Office BOD representatives to identified employees. (IRS-defined)

  2. SRM shall establish training in support of the DR program. (IRS-defined)

  3. The training established by SRM shall support annual FISMA security training requirements. (IRS-defined)

  4. The training established by SRM shall be available through the Enterprise Learning Management System (ELMS). (IRS-defined)

    Note:

    ELMS is the official IRS system of record for training for all IRS employees.

  5. For more information on training see NIST training publications, NIST SP 800-50, Building an Information Technology Security Awareness and Training Program, and NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model. (IRS-defined)

Disaster Recovery Training Guidelines
  1. Employees with DR responsibilities shall be required to complete DR-focused training each year. (IRS-defined)

    1. Minimum training requirements for Employees with DR responsibilities are documented in IRS IT Disaster Recovery Training Curriculum located at:
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. Additional training shall be available through elective courses from the online services provided by IRS, on-the-job training, or through offerings of a private vendor.

    3. DR training classes or seminars shall count toward the employees' annual security training requirement.

  2. Training hours shall be based on the employees' role with respect to DR as indicated in the ITSCM Training Curriculum. (IRS-defined)

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

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

    1. DR training shall count towards the employee's annual security training requirement.

      Note:

      Vendor-sponsored refers to vendors that provide training on ITSCM, Business Continuity, and/or ISCP.

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

    1. The CPE hours earned shall count towards the employees' annual security training requirement.

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

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

    • Purpose of the plan

    • Cross-team coordination and communication

    • Reporting procedures

    • Security requirements

    • Team-specific processes (Activation and Notification, Recovery, and Reconstitution Phases)

  3. See IRM 10.8.1, CP-3 Contingency Training for additional guidance on contingency training.

CP-2 Contingency Planning and Resilience

  1. The IRS shall 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. (NIST 800-34: Section 2.1)

  2. Resilience is the ability to quickly adapt and recover from any known or unknown changes to the environment. 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 goal of the disaster recovery program is to continually improve IRS's ability to adapt to changes, risks, and unexpected events that can affect our ability to continue our critical functions and mission. (NIST 800-34: Section 2.1)

  3. Contingency planning focuses on the Federal Information Processing Standards (FIPS) 199 Standards for Security Categorization of Federal Information and Information Systems security categorization of availability when looking at the contingency needs of information systems. Strategies for high-impact systems should consider high availability options in their design, where a low availability system may not need to be available for several weeks in the event of a significant disruption. High availability options are usually expensive and include things such as redundant systems, data mirroring, and database replication; these options should only be considered for critical, high availability systems. (NIST 800-34: Section 2.1)

  4. 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 identifies Contingency Planning (CP) security controls for information systems. Not all controls are applicable to all systems. The IRS uses the FIPS 199 security categorization as a baseline to determine which controls apply to a particular system. For example, information systems that have availability as a security objective categorized as moderate-impact may only require compliance with only the first system backup control enhancements. Once a baseline has been identified, the IRS can then tailor the baseline to meet IRS business needs and then apply the appropriate controls and control enhancements to IRS information systems. See IRM 10.8.1 to see the tailored baseline of contingency planning security controls that are applicable. (NIST 800-34: Section 2.1)

    Note:

    The CP security controls defined in IRM 10.8.1 are the minimum controls. The IRS requires all systems to have a DR site and those systems or applications supporting an IRS Critical Business Process may also have an increased requirement.

  5. See IRM 10.8.1 for the minimum contingency planning security controls that are applicable, based on the IRS’s tailored contingency planning baseline.

Contingency Planning/Disaster Recovery and Business Continuity
  1. 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, like an umbrella, 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)

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

    Contingency Planning applies to information systems and addresses the steps necessary to recover operations at an existing or new location in an emergency.

    Continuity Planning applies to the business/mission of the service and the ability to continue critical functions and functions during and after an emergency event.

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

    1. Nine core documents from a DR perspective are:

      - Business Continuity Plan (BCP)

      - Continuity of Operations Plan (COOP)

      - Crisis Communications Plan (CCP)

      Critical Infrastructure Protection (CIP) Plan

      - Incident Response Plan

      - Disaster Recovery (DR)

      - Information System Contingency Plan (ISCP)

      - Occupant Emergency Plan (OEP)

      - Incident Management Plan (IRS-defined)

    2. These documents relate as indicated in the table:

      Business Continuity Plan
      Business Continuity Plan (BCP) Continuity of Operations Plan (COOP) Crisis Communications Plan (CCP) Critical Infrastructure Protection (CIP) Plan Incident Response Plan Disaster Recovery (DR) Plan Information System Contingency Plan (ISCP) Occupant Emergency Plan (OEP) Incident Management Plan
Contingency Planning/Disaster Recovery Plans
  1. 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)

    1. The ISCP Coordinator shall coordinate with information system owners to ensure that the BCP expectations and IS capabilities are matched. (NIST 800-34: Section 2.2.1)

    2. See Business Continuity Plan section in IRM 10.8.1 for additional guidance on BCP. (IRS-defined)

  2. 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)

    1. See IRM 10.8.1, for additional guidance on Incident Response.

    2. See IRM 10.8.2, for Incident Response roles and responsibilities.

  3. 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)

    1. CIP’s Plan defines the roles and responsibilities for protection, develops partnerships and information sharing relationships, implements the risk management framework defined in the National Infrastructure Protection Plan (NIPP) and Homeland Security Presidential Directive (HSPD) - 7 for critical infrastructure and key resources, and integrates federal, state and local emergency preparedness, protection, and resiliency of critical infrastructure. (NIST 800-34: Section 2.2.4)

    2. CIP’s Plan applies to all components that own, administer, or operate Treasury Designated Cyber Critical Infrastructure, including those housed in contractor and non-Treasury government facilities. (TD P 85-01: Appendix J)

    3. See IRM 10.8.1 for additional guidance on CIP.

  4. The Crisis Communications Plan (CCP), also known as a Emergency Communication Plan (ECP), shall 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):

    1. Individual(s) as the only authority for answering questions from or providing information to the public regarding emergency response. Designated person(s) shall have access to IRS’ senior leadership.

    2. Procedures for disseminating reports to personnel on incident status.

    3. Templates for public press releases.

  5. The Occupant Emergency Plan (OEP) shall 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)

    1. Shelter-in-place procedures shall be included in the OEP.

      Note:

      OEPs and shelter-in-place procedures for IRS employees can be found on the Employee Resource Center (ERC) website on the Emergency Information tab at: ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. See IRM 10.8.1 for additional guidance on Emergency Response Capability.

  6. The Continuity of Operations Plan (COOP) shall 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)

    1. The COOP shall include, at a minimum:
      i. Program plans and procedures
      ii. Risk Management
      iii. Budgeting and acquisition of resources
      iv. Essential functions
      v. Order of succession
      vi. Delegation of authority
      vii. Continuity Facilities
      viii. Continuity communications
      ix. Vital records management
      x. Human capital
      xi. Test, training, and exercise
      xii. Devolution
      xiii. Reconstitution

    Note:

    COOP plans are mandated for organizations by HSPD-20/NSPD-51, National Continuity Policy and DHS Federal Continuity Directive (FCD), Federal Executive Branch Continuity Program and Requirements.

  7. The Disaster Recovery (DR) Plan shall 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 shall exist for each site, including the primary site, as well as the alternate site(s). (NIST 800-34: Section 2.2.6)

  8. The Information System Contingency Plan (ISCP) shall outline procedures for information system recovery following major disruptions. ISCPs shall 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 shall exist for each information system. (NIST 800-34: Section 2.2.7)

Plan Appendices
  1. Consideration of appendices for inclusion in contingency plans shall include the following (NIST 800-34: Section 4.5):

    • Contact information for contingency planning team personnel

    • Vendor contact information, including offsite storage and alternate site POCs

    • BIA

    • Detailed recovery procedures and checklists

    • Detailed validation testing procedures and checklists

    • Equipment and system requirements lists of the hardware, software, firmware, and other resources required to support system operations. Details shall be provided for each entry, including model or version number, specifications, and quantity

    • Alternate mission/business processing procedures that may occur while recovery efforts are being done to the system

    • ISCP testing and maintenance procedures

    • System interconnections (systems that directly interconnect or exchange information)

    • Vendor SLAs, reciprocal agreements with other organizations, and other vital records

Information System Contingency Planning Process

  1. 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)

    1. Develop the contingency planning policy statement.

    2. Conduct the BIA.
      - The initial BIA is conducted during the SA&A process and is included in the ISCP.
      - See the Business Impact Analysis (BIA) Requirements section within this IRM for additional guidance.

    3. Identify preventive controls.

    4. Develop recovery strategies.

    5. Develop an ISCP.

    6. Plan, test, train participants, and exercise the ISCP.

    7. Conduct ISCP maintenance.

      Note:

      For each ISCP, an ISCP Coordinator shall be designated by Business Operating Divisions (BODs), IT Operations, Security Risk Management (SRM) and Architecture and Implementation (A&I).

      Note:

      Per Treasury: For some smaller (particularly FIPS 199 Low availability) systems, a full contingency plan may not exist when a bureau decides that the system's contingency plan is to not bring the system back up after an incident. This will still have to be documented. To satisfy this requirement, include a summary of the Business Impact Analysis that supports the decision to not recover or reconstitute the system. The testing requirement for these systems can be satisfied by annually validating and appropriately updating documentation of the decision.

  2. The previous steps are key elements in a comprehensive contingency planning strategy.

IT Business Impact Analysis (IT BIA)

  1. The IT BIA is a critical step in IT contingency planning and the ISCP. The BIA is used to determine business processes and recovery criticality, identify outage impacts, identify resource requirements and identify recovery priorities for systems. (NIST 800-34: Section 3.2)

  2. The IT BIA is an integral part of the System Development Life Cycle (SDLC) (e.g., ELC) process of an IRS information system. It should be conducted during the Initiation Phase of the SDLC and further updated during the Domain Architecture, Detailed Design, and System Development Phases of the SDLC, as the system design evolves and components change. (NIST 800-34: Section 3.2)

  3. The IT BIA takes into account business needs and requirements as well as information technology. See the Conducting the IT BIA section in this IRM for more detail. (NIST 800-34: Section 3.2)

  4. The IT BIA evaluates the business and system requirements, processes, and interdependencies to determine contingency requirement and priorities. The IT BIA correlates system components with the critical services they provide to quantify the consequences to the business of a disruption to the system components or application. (NIST 800-34: Section 3.2)

  5. The IT BIA is evaluated and written in relation to an application and/or system. IT BIAs are considered stand-alone for that particular application or system, but are managed at an enterprise level and by site. (NIST 800-34: Section 3.2)

  6. The site-based IT BIA serves to: (IRS-defined)

    • Identify the impact that disruptions to computer applications could have on the ability of a particular site, to perform its critical functions.

    • Determine recovery priorities for site-specific applications that support the critical functions, regardless of security categorization.

    • Identify the risks faced by the site. This helps to evaluate or determine the effectiveness of the site's risk mitigation priorities and associated expenditures.

  7. The Business Unit IT BIA serves as a core initiative to: (IRS-defined)

    • Identify the impact that disruptions to a business process would have on the ability of the IRS to perform its critical functions within a given BOD.

    • Determine recovery priorities for all Business Unit level applications supporting these processes, regardless of location.

    • Identify the risks faced by the Business Units and measure the appropriateness of its risk mitigation priorities and expenditures.

  8. The enterprise-wide IT BIA serves as a core initiative to: (IRS-defined)

    • Identify the impact that disruptions to computer applications would have on the ability of the IRS to perform its critical functions.

    • Determine recovery priorities for all IRS applications supporting these processes, regardless of location.

    • Identify the risks faced by the enterprise, and measure the appropriateness of its risk mitigation priorities and expenditures.

  9. COOP functions are subject to a process-focused BIA. Federal information systems are subject to a system-focused BIA. (NIST 800-34: Section 3.2)

    1. Information systems that support COOP functions will be identified in the process-based BIA.

    2. FCD-2 provides a required template for a process-based BIA; NIST 800-34 provides a recommended template for a system-based BIA.

  10. Results from the IT BIA shall be appropriately incorporated into the analysis and strategy development efforts for the IRS’ COOP, BCPs, and DRP. (NIST 800-34: Section 3.2)

  11. Important Terms: (NIST 800-34: Section 3.2)

    IT Business Impact Analysis (BIA) - A structured process to identify the critical functions that are supported by the documented IT resource.

    Maximum Tolerable Downtime (MTD) - The maximum amount of time a business can tolerate the outage of a critical business function. Sometimes referred to as Maximum Tolerable Outage (MTO), the MTD consists of two elements, the systems recovery time (RTO) and the work recovery time (WRT). Therefore, MTD = RTO + WRT (see below).

    Recovery Point Objective (RPO) - The point in time, prior to a disruption or system outage (e.g., end of previous day’s processing). RPOs are often used as the basis for the development of backup strategies, and as a determinant of the amount of data that might need to be recreated after the systems or functions have been recovered.

    Recovery Time Objective (RTO) - The period of time within which a system (as defined in the Authorization Boundary Memo (ABM)) shall be recovered after an outage (e.g., one business day). RTOs are often used as the basis for the development of recovery strategies, and as a determinant as to whether or not to implement the recovery strategies during a disaster situation.

    Service Continuity (SC) - Supports Business Continuity Management by reducing the risk from events to an acceptable level and planning for the recovery of IT services. SC summarizes information about measures that serve the purpose of disaster preparation. SC planning addresses business IT risks, processes, data, services, and components.

    Service Levels (SLs) - The details of IT Service usage: volume, capacity, resource, performance, availability windows, etc.

    Service Level Requirements (SLRs) - Business requirements supporting service continuity for an IT service. The SLRs belong to the AO who owns the service. The SLR information needs to contain both comprehensible and comprehensive details. The SLRs provide a basis for negotiations linked to the formulation of Service Level Objectives (SLOs) or Service Level Agreements (SLAs).

    Work Recovery Time (WRT) - The period of time within which critical business functions are recovered and running once the systems are restored.

    For a pictorial view of the these terms, use the link to Definitions & Diagrams on the Business Impact Analysis (BIA) Project site:≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

BIA Requirement
  1. All FISMA-reportable systems and applications shall have an initial BIA conducted as part of the SA&A process. See also the Information System Contingency Planning Process section within this IRM for additional guidance. (IRS-defined)

  2. Conducting and funding of BIA activities shall be the responsibility of the Business Owner. (IRS-defined)

  3. The BIA is an ongoing, living document that shall be evaluated on an annual basis or whenever there is a change to business requirements, systems, or applications. (IRS-defined)

Conducting the IT BIA
  1. These four primary steps shall be completed as part of an IT BIA. (IRS-defined)

    1. Identify the business requirements and purpose of the application undergoing the BIA.

    2. Identify outage tolerances:

      •Disruption impacts to specific business functions
      •Maximum Tolerable Downtime (MTD) times
      •Recovery Time Objectives (RTO)
      •Recovery Point Objective (RPO)
      •Interdependencies supporting other IT resources (systems, internal/external applications, etc.)
    3. Identify outage impacts. Items to consider:

      •Loss of data/data loss impact
      •Operational impact
      •Customer service impact
      •Damage to reputation
    4. Identify recovery priorities. Such as:

      •Critical Functions
      •Business process RTOs
      •Outage impact (see above)

Critical Business Processes (CBPs)/Critical Functions

  1. 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)

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

      • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

    Note:

    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 shall be added to the RTO to stay within the time limit established by the MTD.

  6. COOP functions shall 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)

    1. Information systems that support COOP functions shall have an RTO that meets COOP requirements.

    2. 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.

  7. The ISCP Coordinator, working with management, shall 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)

    Note:

    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.

CP-6 - Alternate Storage Site

  1. The alternate storage site storage location shall be located in sufficient distance as to not be affected by a physical incident affecting the area of the production location, but within adequate distance to retrieve stored data/documents per the documented business needs. (IRS-defined)

  2. Contracted services for retrieval from off premise storage facilities shall be based on the system/applications RTO objectives. (IRS-defined)

  3. Yearly verification shall be performed and documented to ensure that: (IRS-defined)

    1. Backup media are stored at designated alternate storage site locations and readily retrievable. (IRS-defined)

    2. The backup/alternate storage site organization/vendor’s delivery time, is based on the business needs during normal and non-normal prime and non-prime business hours. (IRS-defined)

    3. The backup alternate storage site information is documented in the ISCP with the site name and location of the alternate storage site. (IRS-defined)

  4. The annual verification shall extend to include a review and update of the access control list for the alternate storage site, making note that, in an incident, it may be non-local staff who are called upon to retrieve/receive backup media. (IRS-defined)

  5. The annual review shall also ensure that the offsite copy of the DR plan is current. (IRS-defined)

  6. See IRM 10.8.1, for additional guidance on CP-6 Alternate Storage Sites.

CP-7 - Alternate Processing Site

  1. Alternate Processing sites shall be IRS facilities or an approved contractor site. (IRS-defined)

    1. Contractors may manage/operate some systems. These shall be managed in accordance with IRS Security Policy guidance and contractual agreements.

  2. IRS Enterprise Computing Centers shall be the first choice for managing FISMA-reportable systems unless justification warrants a different site. (IRS-defined)

  3. When selecting fixed-site locations for recovery of IRS FISMA-reportable systems and applications, the time and mode of transportation necessary to move personnel there shall be taken into consideration. This is particularly critical if personnel at the potential location do not have the skills necessary to recover/operate the equipment, systems, and applications. (Example: During a widespread disaster, such as that of September 11, 2001, roads and bridges might be closed to vehicles and air transportation might be restricted.) In addition, the fixed site shall be in a geographic area that is unlikely to be negatively affected by the same disaster event (e.g., weather-related impacts or power grid failure) as the organization’s primary site. (IRS-defined)

  4. Use or development of designated and potential alternate processing sites shall be submitted to and analyzed by the IT, Enterprise Operations, Operational Security Program Management Office. Requests shall be based on the specific requirements defined in the BIA. (IRS-defined)

  5. The alternate processing site shall have system security, management, operational, and technical controls that are equal to the production site. Such controls may include firewalls, physical access controls, data controls, and security clearance level of the site and staff supporting the site. (NIST 800-34: Section 3.4.3)

  6. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  7. Important Terms: (NIST 800-34: Section 3.4.3)

    1. Sites categorized by operational readiness are as follows:
      Cold Sites - are typically facilities with basic space and infrastructure (electric power, telecommunications connections, and environmental controls) to support information system recovery activities. No equipment or telecommunications are established or in place. There is sufficient room to house needed equipment to sustain a system’s critical functions.

      Note:

      Cold sites are least expensive options as an alternate site option though characterized by the longest amount of time for recovery, several days to weeks.


      Warm Sites - are partially equipped office spaces that contain some or all of the system hardware, software, telecommunications, and power sources. However, the equipment is not loaded with the software or data required to operate the system. Warm sites should have backup media readers that are compatible with the system’s backup strategy. Warm sites may not have equipment to run all systems or all components of a system, but rather only enough to operate critical mission/business processes.

      Note:

      Warm sites fall in the middle of expense and in the middle of recovery time, as an alternate site.


      Hot Sites - are locations with fully operational equipment and capacity to quickly take over system operations after loss of the primary system facility. A hot site has sufficient equipment and the most current version of production software installed, and adequate storage for the production system data. Hot sites should have the most recent version of backed-up data loaded, requiring only updating with data since the last backup. In many cases, hot site data and databases are updated concurrently with or soon after the primary data and databases are updated. Hot sites also need a way to quickly move system users’ connectivity from the primary site. Hot sites also require having operational support nearly equal to the production.

      Note:

      Hot sites are more expensive options as an alternate site option though characterized by short amount of time for recovery.

    2. Hybrid variations are as follows:
      Mobile Sites - are self-contained, transportable shells custom-fitted with specific telecommunications and system equipment necessary to meet system requirements.

      Note:

      Mobile sites may be delivered to desired location within 24 hours, though time for equipment installation and setup lengthens recovery time.


      Mirrored Sites - are fully redundant facilities with automated real-time information mirroring. Mirrored sites are identical to the primary site in all technical respects.

      Note:

      Mirrored sites are the most expensive option as an alternate site option though characterized by the shortest amount of time for recovery.

  8. When the alternate processing site is an approved contractor site, the following elements shall be clearly negotiated and stated in an Memorandum of Understanding (MOU) or an SLA (NIST 800-34: Section 3.4.3):

    • Contract/agreement duration

    • Cost/fee structure for disaster declaration and occupancy (daily usage), administration, maintenance, testing, annual cost/fee increases, transportation support cost (receipt and return of offsite data/supplies, as applicable), cost/expense allocation (as applicable), and billing and payment schedules

    • Disaster declaration (i.e., circumstances constituting a disaster, notification procedures)

    • Site/facility priority access and/or use

    • Site availability

    • Site guarantee

    • Other clients subscribing to same resources and site, and the total number of site subscribers, as applicable

    • Contract/agreement change or modification process

    • Contract/agreement termination conditions

    • Process to negotiate extension of service

    • Guarantee of compatibility

    • Information system requirements (including data and telecommunication requirements) for hardware, software, and any special system needs (hardware and software)

    • Change management and notification requirements, including hardware, software, and infrastructure

    • Security requirements, including special security needs

    • Staff support provided/not provided

    • Facility services provided/not provided (use of onsite office equipment, cafeteria, etc.)

    • Testing, including scheduling, availability, test time duration, and additional testing, if required

    • Records management (onsite and offsite), including electronic media and hardcopy

    • Service-level management (performance measures and management of quality of information system services provided)

    • Work space requirements (e.g., chairs, desks, telephones, personal computers)

    • Supplies provided/not provided (e.g., office supplies)

    • Additional costs not covered elsewhere

    • Other contractual issues, as applicable

    • Other technical requirements, as applicable

  9. See IRM 10.8.1, for additional guidance on CP-7 Alternate Processing Sites. (IRS-defined)

CP-9 Information System/Application Backups

  1. All FISMA-reportable systems and applications and non-applications (as defined by FISMA) shall be backed up in a restorable format on a regular basis, encrypted, and stored offsite. (IRS-defined)

  2. Systems and applications shall be frequently backed up in accordance with IRM 10.8.1 frequency requirements. (IRS-defined)

    1. See IRM 10.8.1 CP-9 Information System Backup for additional guidance on backup frequencies. (IRS-defined)

  3. Backup frequencies and type of backups shall be defined in the Operations/Customer SLA and documented in applicable SA&A documents. (IRS-defined)

    1. Frequency and type of backups are based on data criticality and data fluidity. (NIST 800-34: Section 3.4.2)

    2. Data backup policies may include the following (NIST 800-34: Section 3.4.2):
      i. Location of stored data
      ii. File-naming conventions
      iii. Media rotation frequency
      iv. Method for transporting data offsite

    3. Storage media may include the following (NIST 800-34: Section 3.4.2):
      i. Magnetic disk
      ii. Tape
      iii. Optical disks

    4. Backup methods may include the following (NIST 800-34: Section 3.4.2):
      i. Electronic vaulting
      ii. Network storage
      iii. Tape library systems

  4. All backup media shall be stored offsite. (IRS-defined)

    1. Data shall be backed up at an IRS approved facility and then labeled, packed and transported to the storage facility in accordance with IRM 10.8.1. (NIST 800-34: Section 3.4.2)

    2. If the data is required for recovery or testing purposes, the IRS contacts the storage facility requesting specific data to be transported to the IRS facility or to an alternate facility designated by the IRS. (NIST 800-34: Section 3.4.2)

    3. Selection of an offsite storage facility and vendor shall include the following considerations (NIST 800-34: Section 3.4.2):
      i. Geographic area – Distance from the IRS facility and the probability of the storage site being affected by same disaster as the IRS’ site shall be considered.
      ii. Accessibility – Length of time of data retrieval upon request shall be considered. Consider storage facility’s operating hours.
      iii. Security – Security capabilities of shipping method, storage facility and personnel shall meet the data’s security requirements.
      iv. Environment – Physical environmental controls of storage facility shall meet the IRS facility’s security requirements.
      v. Cost – Cost of shipping, operational fees, and disaster response/recovery services shall be considered.

    4. Depending on the FIPS 199 impact level, data encryption may be required for protecting system backup information while in transit and at rest to minimize the risk if backup media is lost or stolen. (NIST 800-34: Section 5.4.1)

  5. All Mobile Media shall be encrypted. (IRS-defined)

    1. See IRM 10.8.1, MP-5 Media Transport Control Enhancement for additional guidance on encryption of mobile media. (IRS-defined)

  6. Offsite backup storage shall be identified and documented in the ISCP with the name of the location and location site. Offsite backup storage shall be identified and documented in the ISCP with the name of the location and location site. (IRS-defined)

  7. See IRM 10.8.1, CP-9 Information System Backup for additional guidance on information backup. (IRS-defined)

CP-10 Recovery and Reconstitution

  1. In addition to the Recovery and Reconstitution guidance defined within this IRM, requirements for Recovery and Reconstitution shall be implemented in accordance with IRM 10.8.1.

Recovery Phase
  1. Recovery Phase activities shall 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)

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

    • An action is not completed within the expected time frame

    • A key step has been completed

    • Item(s) must be procured

    • Other system-specific concerns exist

  3. The ISCP shall 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):

    • Obtaining authorization to access damaged facilities and/or geographic area

    • Notifying internal and external business partners associated with the system

    • Obtaining necessary office supplies and work space

    • Obtaining and installing necessary hardware components

    • Obtaining and loading backup media

    • Restoring critical operating system and application software

    • Restoring system data to a known state

    • Testing system functionality including security controls

    • Connecting system to network or other external systems

    • Operating alternate equipment successfully

  4. Effective escalation and notification procedures shall 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)

  5. See IRM 10.8.1, CP-10 Information System Recovery and Reconstitution for additional guidance on information system recovery and reconstitution.

Reconstitution Phase
  1. The Reconstitution Phase shall 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)

    1. Validation of Recovery:
      i. Concurrent Processing - Concurrent processing is the process of running a system at two separate locations concurrently until there is a level of assurance that the recovered system is operating correctly and securely.
      ii. Validation Data Testing - Data testing is the process of testing and validating recovered data to ensure that data files or databases have been recovered completely and are current to the last available backup.
      iii. Validation Functionality Testing - Functionality testing is a process for verifying that all system functionality has been tested, and the system is ready to return to normal operations.

    2. ISCP Deactivation:
      i. Notifications - Upon return to normal operations, users shall be notified by the ISCP Coordinator (or designee) using predefined notification procedures.
      ii. Cleanup - Cleanup is the process of cleaning up work space or dismantling any temporary recovery locations, restocking supplies, returning manuals or other documentation to their original locations, and readying the system for another contingency event.
      iii. Offsite data storage - If offsite data storage is used, procedures shall be documented for returning retrieved backup or installation media to its offsite data storage location.
      iv. Data Backup - As soon as reasonable following reconstitution, the system shall be fully backed up and a new copy of the current operational system stored for future recovery efforts. This full backup shall be stored with other system backups and comply with applicable security controls.
      v. Event Documentation - All recovery and reconstitution events shall be well documented, including actions taken and problems encountered during the recovery and reconstitution efforts. An after-action report with lessons learned shall be documented and included for updating the ISCP.
      vi. An announcement with the declaration shall be sent to all business and technical contacts.

    Note:

    The ISCP Coordinator, in coordination with BODs, IT Operations, SRM and A&I, shall determine if the system has undergone significant change and will require reassessment and reauthorization.

  2. See IRM 10.8.1, CP-10 Information System Recovery and Reconstitution for additional guidance on information system recovery and reconstitution.

Recovery Strategies
  1. Contingency strategies, covering backup and recovery, shall 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)

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

    • Commercial contracts with alternate site vendors

    • Reciprocal agreements with internal or external organizations

    • Service-level agreements (SLAs) with equipment vendors

    • Redundant arrays of independent disks (RAID)

    • Automatic failover

    • UPS

    • Server clustering

    • Mirrored systems

Identify Resource Requirements
  1. To effectively plan for realistic recovery, an evaluation of the resources required to resume mission/business processes as quickly as possible shall be conducted. Necessary resources shall 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)

    Note:

    Examples of resources that shall be identified include facilities, personnel, equipment, software, data files, system components, and vital records.

Identify System Resource Recovery Priorities
  1. 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 shall consider system recovery measures and technologies to meet the resulting information system recovery priority hierarchy. (NIST 800-34: Section 3.2.3)

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

Identify Preventive Controls
  1. Outage impacts identified in the BIA shall be looked at to determine if they 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)

    • Generators (e.g., gasoline or diesel-powered) to provide long-term backup power.

    • Fire suppression systems, fire and smoke detectors.

    • Water sensors in computer rooms’ ceilings and floors.

    • Uninterruptible power supplies (UPS) to provide short-term backup power for system components including (environmental and safety controls).

    • Air-conditioning systems with adequate excess capacity to prevent failure of certain components, such as a compressor.

    • 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.

    • Frequent scheduled backups including where the backups are stored (onsite or offsite) and how often they are recirculated and moved to storage.

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

  2. 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)

    1. Vendor Agreements - SLAs with hardware, software, and support vendors shall be made for emergency maintenance service and maintained with contingency plans. SLAs shall specify the following:
      i. How quickly the vendor will respond after being notified.
      ii. Priority of shipment of replacement equipment.
      iii. Priority status that the IRS will receive from vendor in the event of a catastrophic disaster involving multiple vendor clients.

    2. Equipment Inventory - IRS equipment may be purchased in advance and stored in inventory or at a warm site. This equipment will need to be reviewed periodically. Such equipment may become obsolete or unsuitable as system technologies and requirements change.

    3. Existing Compatible Equipment - Agreements made with approved contractor sites, to be used as an Alternate Processing site, shall stipulate that similar and compatible equipment will be available for contingency use by the IRS.

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

    1. Purchasing equipment can extend recovery time due to wait time for shipment and setup.

    2. Storing equipment is expensive but reduces recovery time.

    3. Availability of transportation may be limited or temporarily halted in the event of a catastrophic disaster.

    4. Scope of disaster may entail mass equipment replacement and transportation delays that would extend the recovery period.

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

  2. The ISCP Coordinator shall 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)

    1. Alternate Site
      i. Cold Site
      ii. Warm Site
      iii. Hot Site

    2. Offsite Storage
      i. Commercial
      ii. Internal

    3. Equipment Replacement
      i. SLA
      ii. Storage
      iii. Existing Use

Information System Contingency Plan (ISCP) Requirements

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

  2. The ISCP shall 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)

    Note:

    See the Disaster Recovery Plan (DRP) section in this IRM for additional guidance.

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

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

    Note:

    The ISCP tabletop/test processes and documentation are the same during an Accreditation and Authorization and during the SRM ISCP FISMA Process.

  5. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  6. ISCPs shall 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)

Supporting Information
  1. Supporting information included in the ISCP shall include an introduction section and a concept of operations section, as well as BIA, POC lists and procedures. (NIST 800-34: Section 4.1)

  2. The introduction section shall include the background, scope and assumptions (NIST 800-34: Section 4.1):

    • Background - This subsection establishes the reason for developing the ISCP and defines the plan objectives.

    • Scope - The scope identifies the FIPS 199 impact level and associated RTOs as well as the alternate site and data storage capabilities (as applicable).

    • Assumptions - This section includes the list of assumptions that were used in developing the ISCP as well as a list of situations that are not applicable.

  3. The concept of operations section shall provide additional details about the information system, the phases of the contingency plan, and a description of the information system contingency plan roles and responsibilities (NIST 800-34: Section 4.1):

    • System description - The description of the information system addressed by the contingency plan shall include the information system architecture, location(s), and any other important technical considerations. System description content may include an input/output (I/O) diagram and a system architecture diagram.

    • Overview of three phases - The ISCP recovery is implemented in three phases: (1) Activation and Notification, (2) Recovery, and (3) Reconstitution.

    • Roles and responsibilities - The roles and responsibilities section presents the overall structure of contingency teams, including the hierarchy and coordination mechanisms and requirements among the teams. The section also provides an overview of team member roles and responsibilities in a contingency situation. Teams and team members shall be designated for specific response and recovery roles during contingency plan activation.

      Note:

      Refer to NIST SP 800-18, Rev. 1, Guide for Developing Security Plans for Federal Information Systems, for further details concerning information system documentation.

Activation and Notification Phase
  1. The ISCP shall be activated if one or more of the activation criteria for that system are met. Activation criteria may include (NIST 800-34: Section 4.2.1):

    • Extent of any damage to the system (e.g., physical, operational, or cost).

    • Criticality of the system to the organization’s mission (e.g., critical infrastructure protection asset).

    • Expected duration of the outage lasting longer than the RTO.

  2. The appropriate recovery teams may be notified once the system outage or disruption has been identified and the ISCP Coordinator has determined that activation criteria have been met. (NIST 800-34: Section 4.2.1)

  3. Notification procedures shall describe methods that will be effective for 24 hours a day / 7 days a week / 365 days a year timeframe. Prompt notification is important for reducing the effects of a disruption on the system. Notifications may be accomplished, either automated or manual, via telephone, pager, electronic mail (email), cell phone, and messaging methods. (NIST 800-34: Section 4.2.2)

    1. Automated notification systems follow established protocols and criteria and can include rapid authentication and acceptance and secure messaging. Automated notification systems may require up-front investment and learning curve.

    2. A common manual notification method is a call tree. This technique involves assigning notification duties to specific individuals, who are team leaders of a functional or geographic area and who in turn are responsible for notifying other recovery personnel. The call tree shall account for primary and alternate contact methods. The call tree shall identify personnel by their team position, name, and contact information (e.g., home, work, cell phone, email addresses, and home addresses).

    3. Information to be included in notification may include the following (NIST 800-34: Section 4.2.2):
      i. Nature of the outage or disruption that has occurred or is impending
      ii. Any known outage estimates
      iii. Response and recovery details
      iv. Where and when to convene for briefing or further response instructions
      v. Instructions to prepare for relocation for estimated time period (if applicable)
      vi. Instructions to complete notifications using the call tree (if applicable)

      Note:

      Notifications sent via email shall be done with caution because there is no way to ensure receipt and acknowledgement. Notifications shall be sent to work or personal accounts to ensure greater visibility by recovery personnel.

      Note:

      Notification procedures shall define procedures when designated personnel cannot be contacted.

      Note:

      Point of contacts shall be identified for each external organization or interconnected system partner that may be adversely affected if they are unaware of the situation. These POCs may be included in notification procedures.

  4. To determine how the ISCP will be implemented following a system disruption or outage, it is essential to assess the nature and extent of the disruption. The outage assessment shall be completed as quickly as the given conditions permit, with personnel safety remaining the highest priority. The following areas shall be addressed: (NIST 800-34: Section 4.2.3)

    • Cause of the outage or disruption

    • Potential for additional disruptions or damage

    • Status of physical infrastructure (e.g., structural integrity of computer room, condition of electric power, telecommunications, and heating, ventilation and air-conditioning [HVAC])

    • Inventory and functional status of system equipment (e.g., fully functional, partially functional, nonfunctional)

    • Type of damage to system equipment or data (e.g., water, fire and heat, physical impact, electrical surge)

    • Items to be replaced (e.g., hardware, software, firmware, supporting materials)

    • Estimated time to restore normal services

CP-4 IT Contingency Tests and Exercises

  1. IRM 10.8.1 requires exercises or tests of a system's contingency plan capabilities to be conducted at least annually. (IRS-defined)

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. The following areas shall be addressed in a contingency plan test, as applicable (NIST 800-34: Section 3.5.1):

    • Notification procedures

    • System recovery on an alternate platform from backup media

    • Internal and external connectivity

    • System performance using alternate equipment

    • Restoration of normal operations

    • Other plan testing (where coordination is identified, i.e., COOP, BCP)

  4. Guidance and procedures for IT Contingency Tests and Exercises are located in IRM 10.8.62, Information Technology (IT) Security, Disaster Recovery Test, Training, and Exercise Program. (IRS-defined)

  5. See IRM 10.8.1, CP-4 Contingency Testing for additional guidance on contingency testing.

ISCP Testing, Training, and Excercise (TT&E)
  1. ISCPs shall be maintained in a state of readiness, which includes having the following: (NIST 800-34: Section 3.5):

    1. Personnel shall be trained to fulfill their roles and responsibilities within the plan.

    2. Plans shall be exercised to validate their content.

    3. Systems and system components shall be tested to ensure their operability in the environment specified in the ISCP.

  2. Testing results shall 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)

Information System Contingency Plan (ISCP) Exercises
  1. ISCP exercises shall 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)

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

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

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

  5. For FIPS 199 HIGH systems, the full-scale functional exercise shall 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 shall also include a full recovery and reconstitution of the information system to a known state. (NIST 800-34: Section 3.5.4)

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

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

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

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

Information System Contingency Plan (ISCP) Maintenance
  1. To be effective, the plan shall be maintained in a ready state that accurately reflects current system requirements, procedures, organizational structure, and policies. (NIST 800-34: Section 3.6)

    1. ISCPs shall 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.

  2. At a minimum, plan reviews shall focus on the following elements (NIST 800-34: Section 3.6):

    • Operational requirements

    • Security requirements

    • Technical procedures

    • Hardware, software, and other equipment (types, specifications, and amount)

    • Names and contact information of team members

    • Names and contact information of vendors, including alternate and offsite vendor POCs

    • Alternate and offsite facility requirements

    • Vital records (electronic and hardcopy)

  3. The ISCP Coordinator shall maintain a record of copies of the plan and to whom they were distributed. (NIST 800-34: Section 3.6)

    1. To ensure its availability and good condition in the event local plan copies cannot be accessed because of disaster, a copy shall also be stored at the alternate site and with the backup media.

    2. Strict version control shall be maintained by requesting old plans or plan pages to be returned to the ISCP Coordinator in exchange for the new plan or plan pages.

    3. Other information that shall be stored with the plan includes the following:
      i. Contracts with vendors (SLAs and other contracts)
      ii. Software licenses
      iii. System user manuals
      iv. Security manuals
      v. Operating procedures

  4. Changes made to the plan, strategies, and policies shall be coordinated through the ISCP Coordinator, who shall communicate changes to the system owner. (NIST 800-34: Section 3.6)

    1. The ISCP Coordinator shall record plan modifications using a record of changes, which lists the page number, change comment, and date of change.

    2. The ISCP Coordinator shall coordinate frequently with system POCs, internal to the IRS, as well as external, to ensure that impacts caused by changes will be reflected in the contingency plan.

    3. The ISCP Coordinator shall evaluate the following supporting information to ensure that the information is current and continues to meet system requirements adequately:
      i. Alternate site contract, including testing times
      ii. Offsite storage contract
      iii. Software licenses
      iv. MOUs or vendor SLAs
      v. Hardware and software requirements
      vi. System interconnection agreements
      vii. Security requirements
      viii. Recovery strategy
      viiii. Contingency policies
      x. Training and awareness materials
      xi. Testing scope
      xii. Other plans, e.g., COOP, BCP.

    4. When a significant change occurs, the BIA shall be updated with the new information to identify new contingency requirements or priorities.

    5. As new technologies become available, preventive controls may be enhanced and recovery strategies may be modified.

  5. Plan maintenance shall be continued as the information system passes through the Disposal phase of its life cycle to ensure that the plan accurately reflects recovery priorities and concurrent processing changes. (NIST 800-34: Section 3.6)

  6. Availability of electronic vital records supporting contingency planning and disaster recovery planning may be impeded during periods of system outages or disruptions. Non-electronic paper copies shall be considered for the following vital records (IRS-defined):

    • Continuity of operations plan and other emergency plans and directives

    • Staffing assignments

    • Policy documents

    • Selected program records

    • Contracting and acquisition files

    • Personnel files

    • Insurance files

    • Orders of succession

    • Delegations of authority

    • Contact information

IT Disaster Recovery Requirements

  1. All systems and applications shall be recoverable. (IRS-defined)

  2. All systems and applications shall have disaster recovery planning documents. See the IT Contingency Tests and Exercises section within this IRM for additional guidance on disaster recovery planning documents. (IRS-defined)

  3. Owners of all systems and applications supporting a critical function shall annually test some or all of their recovery capability in order to ensure the continuity of the operations of the IRS. This may be done through functional or DR Tests.

  4. Modifications to this annual requirement shall be submitted to and approved by the Director, Security Risk Management. (IRS-defined)

    1. Request shall include: (IRS-defined)

    • Name of BOD.

    • Name of System/Application and its locations.

    • Reason for Deviation Request.

    • Planned date to conduct the Test.

    • Desired frequency of test if less than annually.

    • Point of Contact and phone number.

    • Signature of Authorizing Official (AO).

  5. Procedures for conducting ISCP/DR tests are in IRM 10.8.62. (IRS-defined)

Disaster Recovery Plan (DRP)

  1. 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 shall 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)

  2. 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)

  3. The disaster recovery planning document shall 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)

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

    • Operational requirements.

    • Security requirements.

    • Technical procedures.

    • Hardware, software, and other equipment.

    • Names and contact information of team members.

    • Names and contact information of contractors and vendors.

    • Alternate and offsite requirements.

    • Vital records (electronic and hardcopy).

  5. 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)

DRP Requirement
  1. All FISMA-reportable systems shall have recovery capability. (IRS-defined)

    1. Funding of the DR solution is the responsibility of the IT organization with input/support from the Business Owner and will be addressed in the SLA or MOU as appropriate.

  2. All FISMA-reportable systems shall have disaster recovery planning documents. (IRS-defined)

    1. All systems used for recovery shall comply with existing IRS policies. (IRS-defined)

  3. DR-related information, including recovery times, shall be documented in the disaster recovery planning documents and other areas within the ISCP as appropriate. (IRS-defined)

  4. The owner of the system shall be responsible for the disaster recovery planning documents.

    1. It shall be maintained/updated by the owner and IT operations responsible for the recovery of the system referenced by the plan. (IRS-defined)

  5. IT assets that are not FISMA-reportable, which are determined to have interdependency with a FISMA-reportable asset, shall have disaster recovery planning documents. (IRS-defined)

    1. While it can be a part of the overall ISCP, it can also be a standalone document that provides guidance and procedures necessary for the technical recovery of a system or application at an alternate site.

    2. Depending on the size and complexity of the disaster recovery planning documents, they may be maintained separately from the ISCP.

    3. High-level guidance and reference to the disaster recovery planning documents and where they may be obtained shall be maintained in the ISCP.

  6. The disaster recovery planning documents shall be sufficiently detailed (detailed work steps/key strokes) and complete enough to recover the system and/or application to the working level prescribed by the ISCP/MOU/SLA for which it was written, by any administrator/operations staff with the appropriate skills and permissions. (IRS-defined)

  7. A risk assessment and BIA shall be performed for all FISMA-reportable systems and applications that do not support the IRS's critical functions to determine the extent of necessary recovery capability. (IRS-defined)

IT DRP Planning Process
  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

IT Service Continuity Management (ITSCM) Test
  1. Owners of FISMA-reportable systems that support a critical function shall be required to test the recovery of their system annually. (IRS-defined)

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. 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)

  4. 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)

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

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

    1. Within 10 business days after finalization, the results shall be shared with the Senior Management of the recovery personnel who participated in the Disaster Recovery Test from Enterprise Computing Centers and other Enterprise Operations organizations.

    2. A copy of the completed documents shall be provided to the SRM Test, Training & Exercise team.

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

  8. See IRM 10.8.1, CP-4 for additional guidance on contingency testing.

Access and Requests for IS Contingency/Disaster Recovery Information

  1. The ISCP contains potentially sensitive operational and personnel information. Its distribution shall be marked accordingly and controlled. (NIST 800-34: Section 3.6)

    1. Only employees or non-IRS individuals with an authorized need to know shall view or receive documentation relating to ISCPs or disaster recovery planning documents.

  2. Requests for ISCP or DR data shall be handled by the owner of the document/data. (IRS-defined)

    1. Requests shall be in writing and include sufficient information to determine type of documents requested, purpose/need and requestor's information/position.

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

  2. System administrators, managers, or other individuals with responsibility for IT Contingency or ITSCM shall 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)

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

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

TIGTA/GAO Audits and Information Requests
  1. TIGTA/GAO notification of audits and requests for information that involve IT DR in some way, shall be received by or routed through the Cybersecurity, Communications & Support Services, Program Oversight & Coordination Office for control and provided to the SRM. (IRS-defined)

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Hosting Non-IRS Agencies for Disaster Recovery

  1. IRS allows, and currently has, a number of existing DR/Business Continuity/Continuity of Operations Plan agreements in place with other federal Government agencies, allowing them to house DR equipment within IRS facilities. (IRS-defined)

  2. A MOU shall be prepared that specifically outlines the IRS and the other Agency's responsibilities. (IRS-defined)

  3. For information regarding the hosting of non-IRS Agencies, the appropriate Real Estate & Facilities Management team shall be contacted. (IRS-defined)

  4. The SRM shall have no regulatory control or responsibility for the hosting of non-IRS Agency equipment or staff within IRS space. (IRS-defined)

Technical Contingency Planning Considerations

  1. Technical Contingency Planning Considerations complement the process and framework guidelines presented in earlier sections by discussing technical contingency planning considerations for specific types of information systems (NIST 800-34: Chapter 5):

    • Client/server systems

    • Telecommunications systems

    • Mainframe systems

Common Considerations
  1. 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)

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

    1. Full - A full backup captures all files on the disk or within the folder selected for backup.
      i. Because all backed-up files are recorded to a single media or media set, locating a particular file or group of files is simple.
      ii. The time required to perform a full backup can be lengthy

    2. Incremental - An incremental backup captures files that were created or changed since the last backup, regardless of backup type.
      i. Incremental backups afford more efficient use of storage media, and backup times are reduced.
      ii. To recover a system from an incremental backup, media from different backup operations may be required.

      Note:

      For example, consider a case in which a directory needs to be recovered. If the last full backup was performed three days prior and one file had changed each day, then the media for the full backup and for each day’s incremental backups would be needed to restore the entire directory.

    3. Differential - A differential backup stores files that were created or modified since the last full backup.
      i. If a file is changed after the previous full backup, a differential backup will save the file each time until the next full backup is completed.
      ii. A differential backup takes less time to complete than a full backup.
      iii. Restoring from a differential backup may require fewer media than an incremental backup because only the full backup media and the last differential media would be needed.
      iv. Differential backups take longer to complete than incremental backups because the amount of data since the last full backup increases each day until the next full backup is executed.

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

    • Where and how will media be stored?

    • What data should be backed up and how often should it be backed up?

    • How quickly are the backups to be retrieved in the event of an emergency?

    • Who is authorized to retrieve the media?

    • Where will the media be delivered and what is the rotation schedule of backup media?

    • Who will restore the data from the media?

    • What is the media-labeling scheme?

    • How long will the backup media be retained?

    • When the media are stored onsite, what environmental controls are provided to preserve the media?

    • What is the appropriate backup medium for the types of backups to be performed?

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

    1. Equipment interoperability - To facilitate recovery, the backup device should be compatible with the platform operating system and applications and should be easy to install onto different models or types of systems.

    2. Storage volume - To ensure adequate storage, the amount of data to be backed up should determine the appropriate backup solution.

    3. Media life - Each type of medium has a different use and storage life beyond which the media cannot be relied on for effective data recovery.

    4. Backup Software - When choosing the appropriate backup solution, the software or method used to back up data should be considered.

  5. 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)

    Note:

    HA is a process for achieving high availability and should not be confused with FIPS 199 high-impact category systems.

  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):

    1. Critical hardware, such as servers, should be configured with dual power supplies that are used simultaneously. If the main power supply becomes overheated or unusable, the second unit will become the main power source, resulting in no system disruption.

    2. If high availability is required, a gas- or diesel-powered generator shall be used as part of a UPS/generator system support system. The generator can be wired directly into the site’s power system and configured to start automatically when a power interruption is detected. Fuel availability should be considered.

    3. Software and software licenses should be stored in an alternate location.
      i. Original installation media
      a) License terms and conditions
      b) License keys

      ii. Image loads for client systems (such as desktops and portable systems)
      a) Documentation of the software included in the image load
      b) Configuration information for the type of computer for which the image is intended
      c) Installation instructions

    4. When third-party vendors are used to recover data from failed storage devices, proper security vetting of the service provider shall be conducted before turning over equipment. The service provider and its employees shall do the following:
      i. Sign non-disclosure agreements
      ii. Be properly bonded
      iii. Adhere to IRS-specific security policies

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

    1. Client workstations are normally desktop computers, along with portable devices such as laptops, notebook computers, and handheld devices (e.g., smart phones and specialized equipment such as inventory collection bar code readers).

    2. Wireless and smart phone technology advances have allowed users access to key server functionality and services such as email from their mobile phones. This is normally done by using proprietary third-party software that establishes the communications and data transfer to and from the phone via the network provided by mobile cell carriers.

    3. Servers support file sharing and storage, data processing, central application hosting (such as email or a central database), printing, access control, user authentication, remote access connectivity, and other shared system services. Local users log into the server through networked client machines to access resources that the server provides.

Client/Server Systems Contingency Considerations
  1. Backup of data shall be automated for servers for client/server systems. (NIST 800-34: Section 5.2.1)

    1. See IRM 10.8.1, CP-9 Information System Backup for additional guidance on information system backups.

  2. Hardware, software, and peripherals shall be standardized. (NIST 800-34: Section 5.2.1)

    Note:

    IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) dictates the official products and versions of software within the IRS. Enterprise Architecture Enterprise Standards Profile (ESP) can be found at: ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. The amount of data stored on a client computer shall be minimized. Critical user data shall be stored on central servers that are backed up as part of an organization’s enterprise backup strategy, rather than on the client computer hard drive. (NIST 800-34: Section 5.2.1)

  4. The IRS shall provide guidance to users on saving data on client computers (e.g. particular folders). (NIST 800-34: Section 5.2.1)

  5. See section Telecommunications Contingency Considerations in this IRM for further contingency considerations for servers for client/server systems. Servers shall have the same contingency considerations as telecommunications. (NIST 800-34: Section 5.2.1)

    1. Document system configurations and vendor information.

    2. Coordinate with security policies and system security controls.

    3. Use results from the BIA.

Client/Server Systems Contingency Solutions
  1. Client/server system data backups can be accomplished in various ways, including the following (NIST 800-34: Section 5.2.2):

    1. Digital video disc (DVD) - DVDs are low-cost storage media and have a higher storage capacity of around 4.7 gigabytes (GB). To read from a DVD-ROM, the operating system’s file manager is sufficient; to write to a DVD-ROM, a rewritable DVD (DVD-RW) drive and the appropriate software are required.

    2. Network Storage - Data stored on networked client/server systems can be backed up to a networked disk. The amount of data that can be backed up from a client/server system is limited by the network disk storage capacity or disk allocation to the particular user. If users are instructed to save files to a networked disk, the networked disk itself shall be backed up through the network or server backup program. Common types of network storage architecture include network attached storage (NAS) and storage area network (SAN). These storage systems incorporate resiliency and redundancy within their design and can be configured to maintain redundancy across several locations.

    3. External Hard Drives - Data replication or synchronization to an external hard drive is a common backup method for portable computers and stand-alone devices. Many external hard drives have backup software included for use in backing up primary drives.

    4. Internet Backup - Internet Backup, or Online Backup, is a commercial service that allows desktop and portable device users to back up data to a remote location over the Internet for a fee. A utility is installed onto the desktop or portable device that allows the user to schedule backups, select files and folders to be backed up, and establish an archiving scheme to prevent files from being overwritten. Data can be encrypted for transmission; however, this will impede the data transfer. The advantage of Internet Backup is that the user is not required to purchase data backup hardware or media and that the data is readily available to be downloaded for recovery in a contingency situation.

  2. The remotely hosted storage services shall provide the same level of protection of data as the original site. (NIST 800-34: Section 5.2.2)

  3. See IRM 10.8.1 CP-9 Information System Backup for additional guidance on information system backups.

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

    1. Physical diagrams should display up-to-date physical layouts of facilities that house LAN/WANs.

    2. Physical diagrams should display up-to-date cable jack numbers.

    3. Physical diagrams should display up-to-date network- connecting devices, IP addresses, Domain Name System (DNS) names, and types of communications links and vendors.

    4. Logical diagrams should display up-to-date telecommunications infrastructure and its nodes.

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

    1. Configurations of network connective devices that facilitate telecommunication (e.g., circuits, switches, bridges, and hubs) shall be documented.

    2. Vendors and their contact information shall be documented to provide for prompt hardware and software repair or replacement.

    3. Communications providers, including POC and contractual or SLA information, shall be documented.

  3. Telecommunications contingency solutions shall 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)

  4. The BIA shall be reviewed to determine telecommunications recovery priorities. The BIA shall 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)

Telecommunications Contingency Solutions
  1. Single points of failure shall be identified. (NIST 800-34: Section 5.3.2)

    1. Threats to the cabling system, such as cable cuts, electromagnetic and radio frequency interference shall be considered. Redundant cables may be installed when appropriate.

    2. Damage resulting from fire, water, and other hazards shall be considered.

  2. Redundancy in critical components shall be implemented. Contingency solutions shall be developed for each device based on its BIA criticality. The following redundancy strategies shall be considered (NIST 800-34: Section 5.3.2):

    1. Redundant communications links, to ensure that the links have physical separation and do not follow the same path

    2. Redundant network service providers

    3. Redundant hubs, switches, routers, and bridges

    4. Redundancy from network service providers (NSPs) or internet service providers (ISPs)

  3. Telecommunications networks shall be monitored. (NIST 800-34: Section 5.3.2)

    1. The monitoring software issues an alert (e.g. an electronic page or email) if a node or connection begins to fail or is not responding.

    2. SLAs can facilitate prompt recovery following software or hardware problems associated with the telecommunications.
      i. An SLA also may be developed with the NSP or ISP to guarantee the desired network availability and establish tariffs if the vendor’s network is unavailable.
      ii. If the NSP or ISP is contracted to provide network-connecting devices, such as routers, the availability of these devices shall be included in the SLA.

  4. Remote access and wireless local area network technology shall be integrated. (NIST 800-34: Section 5.3.2)

    1. If an emergency or serious system disruption occurs, remote access may serve as an important contingency capability by providing access to organization-wide data for recovery teams or users from another location. Refer to AC-17 Remote Access in IRM 10.8.1 for additional guidance on remote access.

    2. Wireless (or WiFi) local area networks can serve as an effective contingency solution to restore network services following a wired LAN disruption. Refer to AC-18 Wireless Access in IRM 10.8.1 for additional guidance on wireless access.

Mainframe Systems
  1. See IRM 10.8.32, , Information Technology (IT) Security, International Business Machines (IBM) Mainframe System Security Requirements, and IRM 10.8.30, Information Technology (IT) Security, Unisys Operating System (OS) Security Requirements, for addition guidance on mainframes.

Mainframe Contingency Solutions
  1. Redundant system components are critical to ensure that a failure of a system component, such as a power supply, does not cause a system failure. (NIST 800-34: Section 5.4.2)

  2. UPS and power monitoring and management systems shall be used to ensure that power fluctuation will not affect the mainframe. Because mainframes typically process large critical applications, a long-term backup power solution may be needed. A gas or diesel generator can ensure that mainframe processing is not interrupted by a power outage. (NIST 800-34: Section 5.4.2)

  3. Disk redundancy can be provided for the direct access storage devices (DASDs) by implementing a RAID solution. (NIST 800-34: Section 5.4.2)

  4. Each mainframe architecture is unique and centralized. (NIST 800-34: Section 5.4.2)

    1. A replacement system shall be available at an alternate warm or hot site.

    2. Vendor-support contracts shall be maintained to support repairs of damaged units.

      Note:

      The General Services Administration’s Federal Technology Service Federal Computer Acquisition Center has a government-wide acquisition contract on behalf of the federal government. The program has been in place since 1993 and provides disaster recovery services to more than forty federal organizations.

    3. Vendor SLAs shall be kept up to date and reviewed to ensure that the vendor provides adequate support to meet system availability requirements.

  5. Backup and retention schedules for mainframes shall be based on the criticality of the data being processed and the frequency that the data is modified. (NIST 800-34: Section 5.4.2)

    1. Remote journaling or electronic vaulting to the alternate site shall be considered for implementation.

    2. Disk replication, virtualization, or NAS or SAN technologies that replicate various platforms to one replicating server shall be considered for implementation.

Glossary and Acronyms

Term Definition or description
A&I Architecture and Implementation
ABM Authorization Boundary Memo
ACIO Associate Chief Information Officer
AEA Architecture and Engineering Advisory
Alternate Processing Site (APS) Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Bureau-defined information system operations] for essential missions/business functions within [Bureau-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable
AO Authorizing Official
Authorization Boundary Memo (ABM) Documents the authorization boundary and SA&A scope of the system.
   
Backup The process of duplicating and storing the files and programs of an IT system on another medium or device to facilitate complete restoration of the system and its data following a disruption.
BC Business Continuity
BIA Business Impact Analysis
BOD Business Operating Division
Business Continuity Business Continuity is a collection of strategies and specialized plans that ensures a local IRS site can continue to manage efficiently and operate optimally in response to an impending/actual incident without significant impact to overall IRS client services.
Business Continuity Plan (BCP) The documentation of a predetermined set of instructions or procedures that describe how an organization’s business functions will be sustained during and after a significant disruption. NIST 800-34, Contingency Planning Guide for Federal Information Systems, Rev 1, Errata Nov 1, 2010. In addition per IRM 10.6.1, Continuity Operations Program, Continuity Planning Requirements, states the BCP is an ongoing process supported by senior management and funded to ensure that the necessary steps are taken to identify the impact of potential losses, maintain viable recovery strategies and plans, and ensure continuity operations through personnel training, plan tests, and maintenance. The IRS BCP contains a suite of plans (e.g., Occupant Emergency Plan, Incident Management Plan, Continuity Plan, and Disaster Recovery Plan).
Business Impact Analysis (BIA) An analysis of an information system’s requirements, functions, and interdependencies used to characterize system contingency requirements and priorities in the event of a significant disruption.
CBP Critical Business Process
Critical Infrastructure Protection (CIP) Addresses the security, protection, and resiliency of those components of the national infrastructure critical to national and economic security.
Critical Infrastructure Protection (CIP) Assessment A methodical review of an organization’s resources, services, and functions to determine those that are nationally critical.
CMMI Capability Maturity Model Integration
CO Contracting Officer
Cold Site A backup facility that has the necessary electrical and physical components of a computer facility, but does not have the computer equipment in place. The site is ready to receive the necessary replacement computer equipment in the event that the user has to move from their main computing location to an alternate site.
Components Information System components include, but are not limited to, mainframes, servers, workstations, network components, operating systems, middleware, and applications. Information system components are either purchased commercially off-the-shelf or are custom-developed.
Continuity of Operations Plan (COOP) The COOP focuses on restoring an organization’s (usually a headquarters element) essential functions at an alternate site performing those functions for up to 30 calendar days before returning to normal operations. Because a COOP addresses headquarters-level issues, it is developed and executed independently from the business continuity plan. Standard elements of a COOP include Delegation of Authority statements, Orders of Succession, and Vital Records and Databases. Minor disruptions that do not require relocation to an alternate site are typically not addressed. However, the COOP may include the business continuity plan, business resumption plan, and disaster recovery plan as appendices.
Contingency Planning The process of developing advanced arrangements and procedures that enable an organization to respond to an undesired event that negatively impacts the organization.
Continuity Plan See Business Continuity Plan.
Continuity of Support Plan OMB Circular A-130, Appendix III, requires the development, maintenance, and periodic tests of continuity of support plans for general support systems and contingency plans for major applications (referred to as systems and applications in this IRM). Because an ISCP is developed for each major application and general support system (or FISMA-reportable system and/or application), multiple contingency plans may be maintained within the organization’s business continuity plan.
COOP Continuity of Operations Plan
COR Contracting Officer's Representative
CP Contingency Planning
CPE Continuing Professional Education
Critical Business Process (CBP)/Critical Functions IRS business processes defined by the IRS Business Units that are the most critical to the tax administration mission of the IRS and the Federal Government.
Critical Infrastructure Protection (CIP) Addresses the security, protection, and resiliency of those components of the national infrastructure critical to national and economic security.
Critical Infrastructure Protection (CIP) Assessment A methodical review of an organization’s resources, services, and functions to determine those that are nationally critical.
CSMW Computer Security Material Weakness
DHS Department of Homeland Security
DASD Direct Access Storage Device
Disaster Recovery The ability of an organization to respond to a disaster or an interruption in services by implementing a disaster recovery plan to stabilize and restore the organization’s critical functions.
Disaster Recovery Capability Analysis Report An analysis of the IRS’s Disaster Recovery capability, identifying IT systems that are certified and accredited, have disaster recovery planning documents, have tested disaster recovery planning documents, and are backed up.
Disaster Recovery Plan (DRP) A plan created and maintained by IT or any information technology service provider that 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 current or alternate facility after a disruption. The DRP can be a part of the ISCP, a standalone document, or separate disaster recovery keystroke procedures.
Disaster Recovery Test Full-scale functional exercise that involves recovering the system and/or application on non-production equipment, simulated environment, or at the alternate processing site.
Disruption An unplanned event that causes an information system to be inoperable for a length of time (e.g., minor or extended power outage, extended unavailable network, or equipment or facility damage or destruction).
DRP Disaster Recovery Plan/ Detailed Recovery Plan
DRWG Disaster Recovery Working Group
EA Enterprise Architecture
ECP Emergency Communication Plan
ELC Enterprise Life Cycle
ELMS Enterprise Learning Management System
EOPS Enterprise Operations
ERC Employee Resource Center
ERM Enterprise Risk Management
ESA Essential Supporting Activity
ESP Enterprise Standards Profile
Exercise A people-focused activity designed to execute one or more portions of a business continuity plan and evaluate the performance against approved standards or objectives. Through the exercise, validate the viability of one or more aspects of a Business Resumption Plan, Disaster Recovery Plan or IT Contingency Plan.
FCD Federal Continuity Directive
Federal Information Security Modernization Act of 2014 (FISMA) FISMA, among other things, amends Chapter 35 of title 44, United States Code, adding a new sub chapter: ‘‘SUBCHAPTER III — INFORMATION SECURITY‘‘ which provides additional security requirements on Federal Agencies.
FIPS Federal Information Processing Standard
FISMA Federal Information Security Modernization Act
FISMA Master Inventory A record of IRS General Support Systems, Major Applications, and other applications as defined by FISMA guidelines.
FISMA Non-Reportable (FNR) Applications not covered by any FISMA-reportable system or application.
FISMA Period July 1 through June 30 of the following year.
FISMA Reportable System and/or Application Systems or applications included in the FISMA Master Inventory. This term generally replaces general support system.
FNR FISMA Non-Reportable
FP Facility Plan
FPS Federal Protection Service
Functional Exercise Functional exercises allow personnel to validate their operational readiness for emergencies by performing their duties in a simulated operational environment. Functional exercises are designed to exercise the roles and responsibilities of specific team members, procedures, and assets involved in one or more functional aspects of a plan (e.g., communications, emergency notifications, system equipment setup). Functional exercises vary in complexity and scope, from validating specific aspects of a plan to full-scale exercises that address all plan elements. Functional exercises allow staff to execute their roles and responsibilities as they would in an actual emergency situation, but in a simulated manner. (NIST SP 800-34).
GAO Government Accountability Office
General Support System (GSS) A general support system or system means an interconnected set of information resources under the same direct management control which shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people. A system can be, for example, a local area network (LAN) including smart terminals that supports a branch office, an agency-wide backbone, a communications network, a departmental data processing center including its operating system and utilities, a tactical radio network, or a shared information processing service organization (IPSO).
GSS General Support System; see FISMA-reportable System and/or Application.
HAZMAT Hazardous Materials
Hot Site A fully operational offsite data processing facility equipped with hardware and software, to be used in the event of an information system disruption.
HSPD Homeland Security Presidential Directive
I/O Input/Output
IBM Internal Business Machines
IG Inspector General
IMP Incident Management Plan
Impact The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability.
Impact Level High, Moderate, or Low security categories of an information system established in FIPS 199 which classify the intensity of a potential impact that may occur if the information system is jeopardized.
Incident Management Plan The Incident Management Plan is a site’s specific plan that focuses on the command and control, coordination activities, and management of a disruption at any IRS site.
Incident Response Plan The documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of malicious cyber attacks against an organization’s information system(s).
Information System A discrete set of resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
IPSO Information Processing Service Organization
Information System Contingency Plan (ISCP) Documents created and maintained by IT, Cybersecurity, and system owners that provide procedures and capabilities for recovering an information system and define the resources, roles, responsibilities, and procedures for recovering a single information system after a disruption.
ISCP Information System Contingency Plan
   
IT Information Technology
ITDRO IT Disaster Recover Organization
ITIL Information Technology Infrastructure Library
Keystroke Recovery (KR) Detailed step-by-step instructions, including keystroke-by-keystroke details, to restore an IT system to its full operational status following a disruption.
LAN Local Area Network
Major Application An application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. (OMB Circular A-130, Appendix III) Major applications are part of the FISMA Master Inventory.
Maximum Tolerable Downtime (MTD) The maximum amount of time a business can tolerate the outage of a critical business function. Sometimes referred to as Maximum Tolerable Outage (MTO), the MTD consist of two elements, the systems recovery time and the work recovery time. Therefore, MTD = RTO + WRT.
MEF Mission Essential Functions
MI Master Inventory
MOU Memorandum of Understanding
MTD Maximum Tolerable Downtime
NCS National Communications System
NEF National Essential Functions
NIPP National Infrastructure Protection Plan
NIST National Institute of Standards and Technology
NSP Network Service Provider
NSPD National Security Presidential Directive
Occupant Emergency Plan (OEP) Provides a set of response procedures and actions taken during the onset of an emergency to minimize the impact of the incident. It includes building evacuation, shelter in place, and employee safety procedures.
OMB Office of Management and Budget
PM COMP Contingency Management Plan for Planned Maintenance Projects
PMBOK Project Management Body of Knowledge
PMEF Primary Mission Essential Function
PMI Project Management Institute
POA&M Plan of Action & Milestones
POC Point of Contact
RAID Redundant arrays of independent disks
Reciprocal Agreement An agreement that allows two organizations to back up each other.
Recovery Point Objective (RPO) The point in time to which systems and data shall be recovered after an outage. (e.g., end of previous day’s processing). RPOs are often used as the basis for the development of backup strategies, and as a determinant of the amount of data that may need to be recreated after the systems or functions have been recovered.
Recovery Time Objective (RTO) The period of time within which a system (as defined in the Authorization Boundary Memo) shall be recovered after an outage (e.g., one business day). RTOs are often used as the basis for the development of recovery strategies, and as a determinant as to whether or not to implement the recovery strategies during a disaster situation.
Resilience The ability to quickly adapt and recover from any known or unknown changes to the environment through holistic implementation of risk management, contingency, and continuity planning.
Risk Analysis/Assessment Process of identifying risks/vulnerabilities to an organization, assessing critical functions necessary to continue business operations, defining controls in place to reduce exposure to risk, and evaluating cost for such controls.
RMF Risk Management Framework
RMP Risk Management Plan
SA&A Security Assessment & Authorization
SC Service Continuity
Scenario A sequential, narrative account of a hypothetical incident that provides the catalyst for the exercise and is intended to introduce situations that will inspire responses and thus allow demonstration of the exercise objectives.
Security Controls The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.
Single Point of Failure (SPOF) Identified within the critical function using the following criteria: [Location: A critical function is conducted in only one location]; [IT Systems: IT system located in only one location]; [Unique Employee Skills: A critical function relies on a small set of people with unique knowledge, skills or abilities]; [Third Parties/Vendors: A critical function depends on a third party to complete the process]; [Vital Records: a critical function depends on paper (non-electronic) vital records to complete the process].
SL Service Level
SLA Service Level Agreement
SLO Service Level Objective
SLR Service Level Requirement
SOP Standard Operating Procedure
SRM Security Risk Management
System Development Life Cycle (SDLC) 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.
Tabletop Exercise A discussion-based exercise where personnel with roles and responsibilities in a particular plan ( ISCP, DRP or disaster recovery planning documents, or CP) meet to validate the content of the plan in the context of a particular emergency situation.
TAF Trusted Agent FISMA
Test In the context of DR, a test is the method used to evaluate the organization's readiness and ability to recover a system from varying degrees of non-functioning to its original functional state by following authorized ISCP/DR keystroke procedures.
TIGTA Treasury Inspector General for Tax Administration
Toolkit Suite with Command Centre (TSCC) IRS enterprise-level repository and incident management decision support tool and plan repository for Business Continuity and Disaster Recovery. These plans include, but are not limited to: IS Contingency Plans (ISCPs); Disaster Recovery Plans (DRPs) or other disaster recovery planning documents; Facility Plans (FPs), Business Continuity Plans (BCPs); Occupant Emergency Plans (OEPs), Emergency Communication Plans (ECPs); pandemic and other Vector Plans (VPs).
TSCC Toolkit Suite with Command Centre
TT&E Testing, Training, and Exercises; also Test, Exercise, and Evaluation
UPS Uninterrupted Power Supply
UWR Unified Work Request
Vital Records Records in either electronic or non-electronic format that are needed to meet operational responsibilities and perform essential functions under national security emergencies and/or disaster conditions; and protect the legal and financial rights of the Government and those affected by the Government. Examples of vital records include the continuity of operations plan and other emergency plans and directives, staffing assignments, policy documents, selected program records, contracting and acquisition files, personnel files, insurance files, orders of succession, delegations of authority, and contact information.
WAN Wide Area Network
Warm Site An environmentally conditioned work space that is partially equipped with information systems and telecommunications equipment to support relocated operations in the event of a significant disruption.
Work Recovery Time (WRT) The period of time within which critical business functions are recovered and running once the systems are restored.

References

IRS

  • IRM 10.6.1 - Continuity Operations Program, Continuity Planning Requirements

  • IRM 10.8.1 – Information Technology (IT) Security, Policy and Guidance.

  • IRM 10.8.2 – Information Technology (IT) Security, Security Roles and Responsibilities.

  • IRM 10.8.30 - Information Technology (IT) Security, Unisys Operating System (OS) Security Requirements

  • IRM 10.8.32 - Information Technology (IT) Security, International Business Machines (IBM) Mainframe System Security Requirements

  • IRM 10.8.62 – Information Technology (IT) Security, Information Systems Contingency Plan (ISCP) and Disaster Recovery (DR) Test, Training, and Exercise (TT&E) Program.

  • IRM 10.9.1 - National Security Information, National Security Information.

  • Business Impact Analysis (BIA) Project site:
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  • IRS Enterprise Life Cycle site:
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  • Security Risk Management, DR Compliance site:
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  • Security Risk Management, FISMA site:
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  • Security Risk Management, IRS IT Disaster Recovery Training Curriculum site:
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Department of Treasury

  • TD P 85–01, Treasury Information Technology (IT) Security Program, December 12, 2017.

National Institute of Standards and Technology

  • NIST FIPS 199, Standards for Security Categorization of Federal Information and Information Systems February 2004.

  • NIST FIPS 200, Minimum Security Requirements for Federal Information and Information Systems March 2006.

  • NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, April 1998.

  • NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems, May 2010 (Errata page - Nov. 11, 2010).

  • NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems, August 2002.

  • NIST SP 800-50, Building an Information Technology Security Awareness and Training Program, October 2003.

  • NIST SP 800-53 Rev 4, Final Public Draft, Security and Privacy Controls for Federal Information Systems and Organizations , January 22, 2015.

  • NIST SP 800-60 Vol 1 Rev 1, Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008.

  • NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities September 2006.

Other

  • E-Government Act of 2002 (Public Law 107-347), Title III, Federal Information Security Management Act of 2002 (FISMA).

  • Department of Homeland Security, DHS Risk Lexicon, September 2010.

  • Department of Homeland Security, Federal Continuity Directive 2 (FCD 2), Federal Executive Branch Mission Essential Functions and Candidate Primary Mission Essential Functions Identification and Submission Process, dated June 13, 2017.

  • Information Technology Management Reform Act of 1996 (Public Law 104-106), August 1996.

  • Office of Management and Budget, Circular A-11, Preparation, Submission, and Execution of the Budget, July 2014.

  • Office of Management and Budget, Circular A-130, Transmittal Memorandum #4, Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources, July 28, 2016.

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

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