10.8.60  IT Service Continuity Management (ITSCM) Policy and Guidance

Manual Transmittal

December 24, 2013

Purpose

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

Background

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

  1. This IRM places the Information Technology (IT), Cybersecurity, Security Risk Management Organization, and Cybersecurity, Disaster Recovery and Technical Assessment Organization, as key organizations responsible for defining relevant policy requirements, for the IRS enterprise-wide IT Service Continuity Management (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) through the systems and applications that support them.

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

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

Material Changes

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

  1. Interim Guidance Memo # IT-10-0912-22, Live Data, dated November 30, 2012, deletes the live data bullets from sections IRM 10.8.60.2.4 (formerly IRM 10.8.60.2.1.3), Information Technology, and IRM 10.8.60.4.6 (formerly IRM 10.8.60.4.1.6), IT Contingency Tests and Exercises.

  2. Restructured Manual Transmittal section, introductory sections, Risk Acceptance and Risk-Based Decisions section, and Glossary and Acronyms (combined) to match standardized Security Policy language.

  3. Updated links throughout the document to reflect new organization names and links.

  4. Clarified details in the Roles and Responsibilities section.

  5. Clarified Disaster Recovery Plan (DRP) section.

  6. Updated Architecture & Implementation (A&I) Organization section.

  7. Removed A&I responsibilities from Business Operating Division (BOD) Information System Owners section.

  8. Updated version of Department of Homeland Security (DHS) Risk Lexicon in Contingency Planning and Resilience section.

  9. Clarified FISMA Non-Reportable (FNR) application requirements in the ITSCM Test section.

  10. Updated terminology in Hosting Non-IRS Agencies for Disaster Recovery section.

  11. Changed terminology to reflect program name change to IT Service Continuity Management (ITSCM).

  12. Changed IRM title from Disaster Recovery Policy and Guidance to IT Service Continuity Management (ITSCM) Policy and Guidance to reflect program name change.

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

Effect on Other Documents

This IRM supersedes all prior versions of IRM 10.8.60. Additionally, this IRM was updated to incorporate Interim Guidance # IT-10-0912-22, Live Data. 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.3, Information Technology Audit Logging Security Standards. Also, 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-24-2013)

Terence V. Milholland
Chief Technology Officer

10.8.60.1  (12-24-2013)
Overview

  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.

10.8.60.1.1  (12-24-2013)
Purpose

  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-Based Decisions section within this IRM for additional guidance.

10.8.60.1.2  (12-24-2013)
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 IT Service Continuity Management (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 Management Act of 2002 (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 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 of the following 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 Integrated (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), IT Service Continuity Management (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 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.

10.8.60.1.3  (12-24-2013)
Scope

  1. This IRM covers policy for the IRS's overall IT Service Continuity Management (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 provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS, and are to be applied when IT is used to accomplish the IRS mission.

    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. The IRS shall ensure that the product and version selected is in accordance with IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) that dictates the official products and versions of software within the IRS.

  4. The IRS shall ensure the application or system version is a version for which the vendor still offers standardized technical support.

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

10.8.60.1.4  (12-24-2013)
Risk Acceptance and Risk-Based Decisions

  1. Any exception to this policy 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 Form 14201, as described in Risk Acceptance Request and Risk-Based Decision Standard Operating Procedures (SOPs), available on the Enterprise FISMA Compliance SharePoint site via the Risk Acceptance Requests link at:
    http://it.web.irs.gov/cybersecurity/Divisions/SRM/Policy_Guidance/risk_acceptance.htm

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

10.8.60.2  (12-24-2013)
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 requirements provided in subsequent sections are specific to the implementation of the IRS ITSCM Program.

10.8.60.2.1  (12-24-2013)
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).

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

    5. Complete infrastructure integration tests.

10.8.60.2.2  (12-24-2013)
Security Risk Management (SRM) Organization

  1. The Director, Security Risk Management (SRM), within IT, Cybersecurity has the lead responsibility at the IRS for establishing and maintaining the IRS enterprise-wide ITSCM policy, standards, templates, and procedures, and for overseeing IT Business Impact Analysis (BIA) and test activities of the IRS ITSCM Program.

  2. SRM provides guidance and direction to the IRS enterprise-wide disaster recovery efforts, as well as a comprehensive, business-centric ITSCM Program designed to protect IRS operations, assets, and information.

  3. SRM is responsible for coordinating the efforts of the enterprise-wide IRS ITSCM Program as follows:

    1. Policy:
      - Provide expertise for IRM policy development.
      - Develop supporting guidance, standards, documentation, and templates.

    2. Education:
      - Develop training, and perform outreach and awareness for ITSCM Program activities.
      - Ensure that training is provided and tracked for personnel involved in ITSCM activities.

    3. IT Business Impact Analysis (BIA):
      - Manage an enterprise BIA that includes ranking of IRS CBPs, their subprocesses, and the supporting IT assets.
      - Perform Gap Analysis Evaluations to ensure keystroke/step-by-step instructions within the disaster recovery planning documents are in alignment with the ability to restore operations within allotted RTO/RPO/MTD timeframes.
      - Assure an IT BIA is conducted by the BODs, providing appropriate ITSCM information.
      - Facilitate agreement in prioritization of the restoration of systems/applications with Business Operating Divisions (BODs) and IT organizations.
      - Develop and maintain the Enterprise view for Single Point of Failure (SPOF).

    4. Compliance:
      - Monitor compliance of applicable IRS systems and applications with ITSCM requirements.
      - Conduct compliance reviews of documentation and activities related to ISCPs, disaster recovery planning documents, exercises, and tests.

    5. Test/Exercise:
      - Develop test/exercise standards, metrics, and evaluation of performance.
      - Coordinate annual ISCP exercises and DR tests.
      - Provide oversight for the completion of exercise and tests of ISCPs and disaster recovery planning documents. This includes monitoring, as well as facilitating the exercise and tests of plans; coordinating business and IT participation in exercises; documenting test results; and reporting exercise and test results to IRS Business and IT executive management.
      - Establishing and facilitating templates and documents for the development of IT disaster recovery planning documents, ISCPs, tests, exercises, etc.
      - Coordinating exercises of ISCPs, to ensure the ISCP is capable of providing guidance for recovery of IT system(s) in the event of a significant disruption or disaster.

    6. Material Weakness and Audit Reporting:
      - Manage remediation plans and resolution of ITSCM Computer Security Material Weaknesses (CSMW) that have been identified by the Government Accountability Office (GAO), Treasury Inspector General for Tax Administration (TIGTA), or Inspector General (IG) as it relates to the Disaster Recovery (DR) and Critical Infrastructure Protection (CIP) program.

    7. Plan of Action & Milestones (POA&M):
      - Responsible for monitoring and concurring with closure of all ISCP/DR related POA&M items and reporting potential issues that might require a POA&M.

    8. Continuity/Contingency Planning:
      - Partner with Agency Wide Shared Services (AWSS) on Business Continuity efforts.
      - Support Cybersecurity entities, such as Architecture and Engineering Advisory (AEA), on technical assessments of ISCPs.

  4. Responsibilities of SRM include:

    1. Prepare and maintain IT Service Continuity Management plans, which may include such as: Information System Continuity Plans (ISCPs); Disaster Recovery Plans (DRPs); Risk Management Plans (RMPs) and other similar plans or their equivalents that support the overall Business Continuity Plans (BCPs) of the organization.

    2. Complete regular IT Service Continuity Management assessments and analyses to support the determination of: Capability; Capacity; Controls; Risk; and Business Impact in order to ensure that IT Service Continuity is maintained in line with changing business priorities, criticalities, impacts and requirements.

    3. Conduct regular IT Service Continuity Management exercises to measure the effectiveness of the ITSCM Program. This will include (but not be limited to): testing; tabletop reviews; recovery exercises; risk assessment exercises; management exercises; and metrics reporting, These service continuity testing results should be used to assess and report on the overall sustainability of IT Service Continuity within the enterprise.

    4. Actively pursue the mitigation of gaps identified through the evaluation, assessment, or exercise of the ITSCM Program. This may include: program changes; proposed investment strategies, process adjustments, or risk acceptance/avoidance/transference options.

  5. Positions within the ITSCM Program include:

    • Disaster Recovery (DR) Specialist

    • Information Technology Specialist (Security)

    • Program/Management Analyst

10.8.60.2.3  (12-24-2013)
Architecture & Implementation (A&I) Organization

  1. The Director, Architecture & Implementation Organization (A&I), within IT Cybersecurity works with the SRM Director in support of the IRS enterprise-wide ITSCM policy, standards, and procedures, DR technical assessment, DR Plans, and test activities of the IRS ITSCM Program.

  2. A&I is responsible for coordinating the efforts of the enterprise-wide ITSCM Program as follows:

    1. Technical Assessment:
      - Facilitate, monitor, and assist in conducting annual risk assessments; validate backup strategies (backups are performed and stored offsite and can be retrieved on a timely basis to meet RTO/RPO/MTD) and perform gap analysis' to ensure that the BODs and IT are in agreement regarding Redundancy/Resiliency Analysis.

    2. Plan Development:
      - Facilitate the creation of disaster recovery planning documents, verify annual disaster recovery planning documents review, and maintain of disaster recovery planning documents repository within the Toolkit Suite with Command Centre (TSCC). The TSCC has been designated as the IRS enterprise level repository and incident management environment. TSCC is the plan repository for Business Continuity, Information System Contingency, and Disaster Recovery.

    3. Tools, Metrics, and Reporting:
      - Serve as the Program Management Office for the acquisition, development, deployment and administration of tools and applications designed for decision support, emergency notification, and contingency operations. Provide metrics based upon established performance indicators (such as BIA, RTO/RPO, current capabilities, and actual times to recover).
      - Provide ancillary data feeds, queries, reports, and briefings based upon aggregated information contained within automated tools.

    4. IT Service Continuity Management (ITSCM):
      - Serve as the Program Management Office (Process Owner and Process Manager) for the development, deployment and administration of ITSCM processes.

  3. Responsibilities of A&I include:

    • Establishing templates and documents for the development of ITSCM Plans and providing input into ISCPs tests, exercises, etc.

    • Conducting Technical Risk Assessment; recommending mitigation strategies.

    • Facilitating site-based infrastructure vulnerability reviews.

    • Developing IT disaster recovery planning documents in conjunction with system owners/administrators.

    • Partnering with AWSS on Business Continuity efforts.

    • Supporting the ITSCM training program through the development and delivery of ITSCM training.

    • Serving as Process Owner and Process Manager for ITSCM.

    • Chair the ITSCM Working Group.

    • Administer and oversee all Maturity Assessments of the ITSCM Program.

    • Maintain a centralized repository for all continuity plans and data. This centralized repository shall take the form of an enhanced decision support system, which shall minimally provide interactive response and recovery tools, management and reporting tools and impact assessment tools. Plans and data stored within this repository should include, but not be limited to: Business Resumption Plans (BRPs), Continuity of Operations Plans (COOPs), Information System Contingency Plans (ISCPs), IT Disaster Recovery Plans (DRPs), and ITIL Continual Service Improvement plans.

    • Support integration and synchronization with Business Continuity, Incident Management Continuity of Operations, and other plans within the organization

  4. ITSCM requires a Project Management Office comprised minimally of a Process Owner and Process Manager, an Executive Governance Board, a Working Group of Stakeholders, and the implementation of a portfolio process for management. Additionally, emplacement of cross-functional governance structures and agreements are required in order to properly acknowledge ITSCM ownership, purpose, or objective, and required participation and resources. The PMO shall document the commitments and resources required for the execution of processes which must be synchronized and coordinated across many functional lines of management.

  5. Positions within the A&I program include:

    • Disaster Recovery (DR) Specialist

    • Information Technology Specialist (Security)

10.8.60.2.4  (12-24-2013)
Information Technology (IT)

  1. IT is responsible for:

    • Performing annual execution and exercise of each ISCP.

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

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

    • Assigning a DR Test Director.

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

10.8.60.2.5  (12-24-2013)
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. The BOD/Information System Owner is required to:

    • Determine business impacts, recovery needs, and timeframes needed for business restoration and communicate this information to IT operations and SRM.

    • Work jointly with IT Operations, SRM, and A&I, in the development of viable disaster recovery planning documents determining what data needs to be recovered and the priority order for recovery.

    • Work jointly with IT Operations, SRM and A&I to review/update disaster recovery planning documents, at a minimum, annually to ensure accuracy and notify the SRM/A&I of completion via their mailbox *IT IT DR Mailbox with the name(s) of the system or application and a Point of Contact (POC).

    • Work jointly with IT Operations and SRM in the development of viable BIAs to assist in determining timeframes for recovering applications that support CBPs and align recovery expectations of BODs with recovery capabilities of IRS Information Technology (or IRS IT).

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

    • Follow the official POA&M process when closing all ISCP/DR-related POA&M items.

  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 CBPs and supporting applications.

10.8.60.2.6  (12-24-2013)
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. Verbiage included in the contract should contain the following:

    • Contractors will comply with this IRM and any others developed for the ITSCM Program.

    • Contractors agree to provide IRS with all data and documents pertaining to DR deliverables.

    • Contractors agree to provide IRS with proof of an existing DR keystroke or step-by-step documentation (i.e., disaster recovery planning document(s)) and succession planning document to ensure the contractor is protected from experiencing a single point of failure within their organization in the event of a disaster, which would negatively impact the IRS.

    • Contractors agree to test their disaster recovery planning documents annually and report the test results to Security Risk Management, DR Compliance at:
      it.acioc.dr.compliance@irs.gov

    • Contractors are expected to follow IRS guidance on security, audits, background checks, building access, system access, etc.

  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.

10.8.60.2.7  (12-24-2013)
Situation Awareness Management Center (SAMC)

  1. The Situation Awareness Management Center (SAMC) receives, manages, and escalates advisories and alerts of physical and cyber events from across the IRS.

  2. SAMC operates on a 24x7x365 schedule, providing immediate response required by the incident. All incidents affecting IRS operations, employees, facilities, or data processing should be reported to SAMC within a 30-minute timeframe of the incident discovery (allowing for notification of local responders (Federal Protection Service (FPS), TIGTA, Hazardous Materials (HAZMAT) Team, Police, Fire Department, etc.).

  3. For the purposes of ITSCM, SAMC is typically notified by the site Director, Senior Commissioner's Representative, AWSS.

  4. SAMC can be notified through 4 different modes of communication (email, phone, fax, and hotline).

    • Email: samc@csirc.irs.gov

    • Phone: (202) 283-4809 or toll free (866) 216-4809

    • Fax: (202) 283-0345

    • Hotline: (866) 216-4809

10.8.60.2.8  (12-24-2013)
Single Entry Time Reporting

  1. Single Entry Time Reporting Function/Program Codes and Internal Order Codes have been established that will be used to track ITSCM work efforts. Any IRS employee involved in this work will use Function Code 800 and Program Code 800-8237X (X represents the number for the different program codes, as listed in Single Entry Time Reporting's new codes and the activities/definition related to them below) series for tracking purposes.

  2. Users involved in any of the activities mentioned in the chart listed under activity-definition in (3) below, shall ensure they utilize the applicable ITSCM Program Code(s), so that time spent addressing ITSCM activities may be tracked.

    Note:

    These program codes are not to be used for activities associated with restoring services in the event Business Operations are interrupted because of natural, environmental or man-made incidents; see the AWSS Program Code 82350 for this guidance. For Taxpayer Disaster Relief activities, see Program Code 82360.

  3. The chart below provides the Single Entry Time Reporting's new codes and the activities/definition related to them:

    Program/Project Code Activity – Definition
    Code 82370 – DISREC - Disaster Recovery Office
    • Internal ITSCM Office Support Staff only

    Code 82371 — PLANDVLP - Prepare Disaster Recovery Plans
    • Prepare IT disaster recovery planning documents

    • IT disaster recovery planning documents are written, evaluated, and updated annually as business priorities and operational procedures change

    Code 82372 – TECHASMT- Technical Assessment
    • Prepare/Assist ITSCM Technical Assessments including assessing the readiness and capabilities of existing and future state infrastructures and evaluating new technologies and best practices to enhance existing capabilities

    • Technical Assessments perform critical in-depth analyses to identify existing capabilities and vulnerabilities to business processes and supporting infrastructure

    Code 82373 – DRITCPTT - Test, Exercise & Evaluation (TT&E)
    • Participate in FISMA ISCP Tests and/or DR TT&E including all pre-work for tests, the actual test, and post-work to bring the test activity to full completion

    • TT&E is conducted across all critical assets to evaluate readiness, identify issues, and provide recommendations for improvements

    Code 82374 – BIARISK - Business Impact Assessment
    • Participate in BIA activities including development, evaluating risks, continuity, and resiliency of business processes

    • BIAs to evaluate all processes, systems, locations, etc., in order to determine business impacts and priorities

    Code 82375 – DRPOLICY - Policy
    • Participate in ITSCM Policy initiatives (Internal SRM only) including establishing policies, standards, documentation, metrics, templates, etc.

    • The establishment of policies, documentation, and templates provide the framework for a standardized approach for program execution

    Code 82376 – DRCOMPL -Compliance
    • Participate in ITSCM Compliance initiatives including the internal audit process for all Disaster Recovery activities, auditing enterprise adherence, and consistency to established program standards

    Code 82377 – DRTRAIN -Training
    • Conduct or participate in ITSCM Training

    • Targeted ITSCM training ensures all roles and responsibilities are understood and established policies, procedures, and standards are effectively communicated

10.8.60.3  (12-24-2013)
PM – Information Security Program Management Controls

  1. Refer to IRM 10.8.1 for this security control with regard to policy.

10.8.60.4  (12-24-2013)
IT Security Controls

  1. Refer to IRM 10.8.1 for the other security control families other than Contingency Planning.

  2. The Contingency Planning controls in this manual supplement the Contingency Planning requirements defined in IRM 10.8.1.

10.8.60.4.1  (10-04-2012)
Contingency Planning and Resilience

  1. The IRS must have the ability to withstand all hazards and sustain its mission through environmental changes. These changes can be gradual, such as economic or mission changes, or sudden, as in a disaster event. Rather than just working to identify and mitigate threats, vulnerabilities, and risks, organizations can work toward building a resilient infrastructure, minimizing the impact of any disruption on mission-essential functions.

  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 business processes and mission.

  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.

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

    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.

10.8.60.4.1.1  (10-04-2012)
Contingency Planning/Disaster Recovery and Business Continuity

  1. ISCPs and disaster recovery planning documents are supporting documents in an organization's overall Business Continuity Plan (BCP). 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.

  2. Note the difference between Contingency Planning and Continuity Planning, both critical components of the overall BCP:

    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 business processes and functions during and after an emergency event.

  3. Numerous plans contribute to the organizations overall BCP.

    1. Four core documents from a DR perspective are:

      - Incident Management Plan (IMP) - Incident Focus (AWSS)

      - Occupant Emergency Plan (OEP) - Personnel Safety Focus (AWSS)

      - Continuity Plan - Process Focus (BODs)

      - Disaster Recovery (DR)/ ISCP - Technology Focus (IRS IT/BODs)

    2. These documents relate as indicated in the table:

      Business Continuity Plan
      Incident Management Plan
      Occupant Emergency Plan Continuity Plan/Business Continuity Plan Disaster recovery planning documents/ISCP

    Note:

    The OEP, BCP, disaster recovery planning documents, and/or ISCP are standalone plans that may be implemented separately or together. These plans feed into the IMP which then feeds into the BCP.

10.8.60.4.2  (10-04-2012)
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:

    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.

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

10.8.60.4.3  (12-24-2013)
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.

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

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

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

  5. The site-based IT BIA serves to:

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

    • Determine recovery priorities for site-specific applications that support the CBPs, 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.

  6. The Business Unit IT BIA serves as a core initiative to:

    • Identify the impact that disruptions to a business process would have on the ability of the IRS to perform its CBPs 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.

  7. The enterprise-wide IT BIA serves as a core initiative to:

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

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

  8. Important Terms

    IT Business Impact Analysis (BIA) - A structured process to identify the critical business processes 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 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 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.

    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:
    http://it.web.irs.gov/cybersecurity/Divisions/SRM/BIA/default.htm

10.8.60.4.3.1  (10-04-2012)
BIA Requirement

  1. All FISMA-reportable systems and applications 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.

  2. Conducting and funding of BIA activities shall be the responsibility of the Business Owner.

  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.

10.8.60.4.3.2  (10-04-2012)
Conducting the IT BIA

  1. These four primary steps shall be completed as part of an IT BIA.

    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 Business Processes
      •Business process RTOs
      •Outage impact (see above)

10.8.60.4.3.3  (10-04-2012)
IRS Critical Business Processes

  1. CBPs 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. Originally established in 2002 and updated in May 2008, there are 18 IRS Critical Business Processes.

  2. The three CBP categories based on their relative priority to the execution and support of the overall mission of the IRS are defined as:

    1. Priority 1 – Mission Enablers (Infrastructure / People)

      • Provides the foundation and basic needs to support all operational functionality ensuring the continuity of the mission of the IRS.

      • Enables and assures that the necessary infrastructure and personnel are available and ready to perform the business functions of the IRS.

      • Defines activities to provide facilities, human resources, technology, safety, information security, communications, business continuity, and assurance of fair taxpayer treatment.

    2. Priority 2 – Mission Critical (Primary / Core Functions)

      • Core business functions to execute the mission of the IRS.

      • Business functionality that shall be restored first in the event of a disaster.

      • Any disruption or failure of these functions would negatively impact the IRS’s ability to fulfill its mission in a timely manner and thus could impact public trust and confidence in government, economic stability, and taxpayer compliance requirements.

    3. Priority 3 – Mission Supportive (Discretionary Functions)

      • Represents the business functions that directly enhance or support the mission of the IRS.

      • Objectives of these functions have less immediate impact on taxpayers if they are disrupted.

      • A short-term disruption or loss of these functions would not preclude the IRS from executing its mission, but a long-term loss would have a significant impact on operations.

  3. This table shows the 18 Critical Business Processes by Priority.

    18 Critical Business Processes by Priority

    Priority 1 - Mission Enablers - Infrastructure / People Priority 2 - Mission Critical - Primary / Core Functions Priority 3 - Mission Supportive / Discretionary Functions
    E-1 Perform Human Resource and Operational Support Activities CBP-1 Process Remittances CBP-8 Conduct Collection Activities
    E-2 Maintain a Business Continuity Capability CBP-2 Process Tax Returns CBP-9 Conduct Examination Activities
    E-3 Provide External Communications CBP-3 Process Refunds CBP-10 Issue Pre-Filing Determinations
    E-4 Advocate Fair Taxpayer Treatment CBP-4 Respond to Inquiries CBP-11 Conduct Criminal Investigation Activities
      CBP-5 Detect and Stop Fraudulent Refunds CBP-12 Perform Litigation
      CBP-6 Issue Taxpayer Notices CBP-13 Provide Appeals Process
      CBP-7 Develop and Deliver Tax Forms and Publications CBP-14 Process Vendor Payments

10.8.60.4.3.4  (10-04-2012)
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.

10.8.60.4.3.5  (10-04-2012)
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, impact to the critical business processes), recovery priorities can be effectively established.

  2. The data gathered during the BIA shall be used to establish recovery priorities within systems, applications, and the enterprise.

10.8.60.4.3.6  (10-04-2012)
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:

    • Generators to provide long-term backup power.

    • Fire suppression systems, smoke detectors.

    • Water sensors in computer rooms.

    • Uninterruptible power supplies (UPS) for system components.

10.8.60.4.4  (10-04-2012)
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.

  2. Frequency and type of backups shall be defined in the Operations/Customer SLA and documented in applicable SA&A documents.

  3. All Mobile Media shall be encrypted; see the Encryption of Mobile Media section in IRM 10.8.1 for additional guidance.

  4. All backup media shall be stored offsite.

  5. See the Information Backup section in IRM 10.8.1 for additional guidance.

  6. Offsite backup storage shall be identified and documented in the ISCP with the name of the location and location site.

10.8.60.4.4.1  (12-24-2013)
Recovery Site

  1. Recovery sites shall be IRS facilities or an approved contractor site.

    Note:

    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.

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

  4. Use or development of designated and potential Recovery 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.

  5. The recovery site should 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.

  6. To the greatest extent possible, recovery sites should be IRS facilities and one of the three Enterprise Computing Centers. In all cases, recovery sites and data backup sites shall comply with the CP-9 Information System Back – Control Enhancements in IRM 10.8.1.

10.8.60.4.4.2  (10-04-2012)
Offsite Storage

  1. The offsite 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.

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

  3. Yearly verification shall be performed and documented to ensure that:

    1. Backup media are stored at designated offsite locations and readily retrievable.

    2. The backup/offsite storage organization/vendor’s delivery time, is based on the business needs during normal and non-normal prime and non-prime business hours.

    3. The backup office storage information is documented in the ISCP with the site name and location of the offsite storage site.

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

  5. The annual review shall also ensure that the offsite copy of the DR plan is current.

10.8.60.4.5  (10-04-2012)
Information System Contingency Plan (ISCP) Requirements

  1. IRM 10.8.1 requires the development and maintenance of continuity of support plans/ISCPs.

  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.

    Note:

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

  3. All FISMA-reportable systems shall have an ISCP.

  4. All FISMA-reportable systems shall exercise their ISCP annually.

    Note:

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

  5. Information on the FISMA-reportable and other FISMA-related requirements and activities shall be located on the IT Cybersecurity site at:
    http://it.web.irs.gov/Cybersecurity/Divisions/SRM/FISMA/default.htm

  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.

10.8.60.4.6  (12-24-2013)
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.

  2. All tests and exercises shall be coordinated by the SRM staff. SRM can be reached via their mailbox *IT IT DR Mailbox.

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

10.8.60.4.6.1  (10-04-2012)
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.

  2. Treasury and OMB ISCP exercise requirements shall be based on the FIPS 199 security availability category below:

    Security Availability Type of Exercise Required
    LOW Tabletop
    MODERATE Tabletop plus functional exercise
    HIGH Tabletop plus DR Test

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

  4. Exhibit 10.8.60-1 for a definition of a tabletop and functional exercise.

  5. Procedures for conducting ISCP Exercises are in IRM 10.8.62.

  6. Additional guidance based on Treasury, OMB, or IRS requirements are issued by the SRM Director each FISMA period.

10.8.60.4.7  (10-04-2012)
IT Disaster Recovery Requirements

  1. All systems and applications shall be recoverable.

  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.

  3. Owners of all systems and applications supporting a CBP 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.

    1. Request shall include:

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

10.8.60.4.8  (12-24-2013)
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.

  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.

  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.

  4. The disaster recovery planning document shall be developed with the following factors considered:

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

10.8.60.4.8.1  (10-04-2012)
DRP Requirement

  1. All FISMA-reportable systems shall have recovery capability.

    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 Memorandum of Understanding (MOU) as appropriate.

  2. All FISMA-reportable systems shall have disaster recovery planning documents.

    1. All systems used for recovery shall comply with existing IRS policies.

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

  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.

  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.

    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.

  7. A risk assessment and business impact analysis shall be performed for all FISMA-reportable systems and applications that do not support the IRS's Critical Business Processes to determine the extent of necessary recovery capability.

10.8.60.4.8.2  (10-04-2012)
IT DRP Planning Process

  1. Following the guidance provided by NIST 800-34, disaster recovery planning documents refers to an IT-focused plan designed to restore operability of the target system, application, or computer facility at an alternate site after a major, and usually catastrophic disaster. The steps below provide an overview of the planning process for the disaster recovery planning documents:

    • Review current documentation, the ISCP, particularly the BIA, and any other applicable documents or information.

    • Determine backup and recovery strategies.

    • Determine recovery site.

    • Identify current subject matter experts.

    • Gather information relevant to system recovery (i.e., key stroke recovery guide, backup location, RTO/RPO/MTD, etc.).

    • Develop disaster recovery planning documents.

    • Review disaster recovery planning documents, at a minimum, annually, and update. Notify the SRM of completion via their mailbox *IT IT DR Mailbox with the name(s) of the system or application and a POC.

    • File updated copy at recovery site, offsite storage location, and provide electronic copy to the SRM via their mailbox *IT IT DR Mailbox and other appropriate staff.

    • Load into Trusted Agent FISMA (TAF) by SRM DR TT&E.

10.8.60.4.8.3  (12-24-2013)
ITSCM Test

  1. Owners of FISMA-reportable systems that support a CBP shall be required to test the recovery of their system annually.

  2. All tests and exercises are coordinated by the SRM staff. See IRM 10.8.62 for additional guidance. The IRM documents how to begin and proceed through the ISCP and DR exercise and test process for every system in the IRS Master Inventory. For additional information, the SRM can be reached via their mailbox *IT IT DR Mailbox.

  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.

  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.

  5. Procedures for requesting and conducting DR Tests are in IRM 10.8.62.

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

    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.

10.8.60.4.9  (10-04-2012)
Access and Requests for IS Contingency/Disaster Recovery Information

  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.

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

10.8.60.4.9.1  (12-24-2013)
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.

  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.

  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.

  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.

10.8.60.4.9.2  (10-04-2012)
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.

  2. Only TIGTA/GAO shall be permitted to submit requests for documents, such as ISCPs or disaster recovery planning documents for current or upcoming DR or IT Contingency Plan audits. These are to be sent to the system/application owner for release.

10.8.60.4.10  (10-04-2012)
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 the Security Awareness and Training section of IRM 10.8.1 for additional guidance.

10.8.60.4.10.1  (10-04-2012)
Disaster Recovery Training

  1. The SRM shall be responsible for developing and disseminating training information through IRS IT/FISMA Program Management Office BOD representatives to identified employees.

  2. The SRM shall establish training in support of the DR program.

  3. The training established by SRM shall support annual FISMA security training requirements.

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

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

10.8.60.4.10.2  (12-24-2013)
Disaster Recovery Training Guidelines

  1. Employees with DR responsibilities shall be required to complete DR-focused training each year.

    1. Minimum training requirements for Employees with DR responsibilities is documented in IRS IT Disaster Recovery Training Curriculum located at:
      http://it.web.irs.gov/cybersecurity/Divisions/SRM/Training/default.htm

    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 IRS ITSCM Training Curriculum.

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

10.8.60.4.10.3  (12-24-2013)
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.

    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.

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

  3. Costs of certification, testing, and yearly maintenance fees may be paid for by IRS, if approved by the employee's management.

10.8.60.4.11  (12-24-2013)
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.

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

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

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

Exhibit 10.8.60-1 
Glossary and Acronyms

Term Definition or description
A&I Architecture and Implementation
ABM Authorization Boundary Memo
AEA Architecture and Engineering Advisory
AO Authorizing Official
Authorization Boundary Memo (ABM) Documents the authorization boundary and SA&A scope of the system.
AWSS Agency Wide Shared Services
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
BCP Business Continuity Plan
BIA Business Impact Analysis
BOD Business Operating Division
BRS Business Resumption Strategy
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.2.10, 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).
CBP Critical Business Process
CO Contracting Officer
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.
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.
COOP Continuity of Operations Plan
COR Contracting Officer's Representative
CP Contingency Planning
CPE Continuing Professional Education
Critical Business Process (CBP) 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.
CSMW Computer Security Material Weakness
DHS Department of Homeland Security
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 recovery location.
DRP Disaster Recovery Plan/ Detailed Recovery Plan
DRWG Disaster Recovery Working Group
ELC Enterprise Life Cycle
ELMS Enterprise Learning Management System
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.
Federal Information Security Management Act of 2002 (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 Management 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.
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).
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
IMP Incident Management Plan
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.
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
ISSO Information System Security Officer
IT Information Technology
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.
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.
MI Master Inventory
MITS Modernization and Information Technology; changed to IRS IT July 1, 2012.
MOU Memorandum of Understanding
MTD Maximum Tolerable Downtime
NIST National Institute of Standards and Technology
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.
OEP Occupant Emergency Plan
OMB Office of Management and Budget
POA&M Plan of Action & Milestones
POC Point of Contact
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.
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.
RPO Recovery Point Objective
RTO Recovery Time Objective
SA&A Security Assessment & Authorization
SAMC Situation Awareness Management Center
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.
Situation Awareness Management Center (SAMC) Receives, manages, and escalates advisories and alerts of physical and cyber events from across the IRS. The SAMC is a 24/7/365 operation.
Single Point of Failure (SPOF) Identified within the critical business processes (CBP) using the following criteria: [Location: A CBP is conducted in only one location]; [IT Systems: IT system located in only one location]; [Unique Employee Skills: A CBP relies on a small set of people with unique knowledge, skills or abilities]; [Third Parties/Vendors: A CBP depends on a third party to complete the process]; [Vital Records: a CBP depends on paper (non-electronic) vital records to complete the process].
SLA Service Level Agreement
SPOF Single Point of Failure
SRM Security Risk Management
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.
VROM Very Rough Order of Magnitude
Work Recovery Time (WRT) The period of time within which critical business functions are recovered and running once the systems are restored.

Exhibit 10.8.60-2 
References

IRS

Department of Treasury

  • TD P 85–01, Treasury Information Technology (IT) Security Program, March 10, 2008.

National Institute of Standards and Technology

  • NIST FIPS 199: Standards for Security Categorization of Federal Information and Information Systems.

  • NIST FIPS 200: Minimum Security Requirements for Federal Information and Information Systems.

  • NIST SP 800-12: An Introduction to Computer Security: The NIST Handbook, Chapter 11, Preparing for Contingencies and Disasters.

  • NIST SP 800-14: Generally Accepted Principles and Practices for Securing Information Technology Systems.

  • 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-35: Guide to Information Technology Security Services.

  • NIST SP 800-37 Rev 1: Guide for Applying the Risk Management Framework to Federal Information Systems, February 2010.

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

  • NIST SP 800-53 Rev 3: Recommended Security Controls for Federal Information Systems and Organizations, May 2010.

  • NIST SP 800-53 Rev 4, Final Public Draft: Security and Privacy Controls for Federal Information Systems and Organizations (Updated with Errata page May 7, 2013), April 2013.

  • NIST SP 800-53A Rev 1: Guide for Assessing the Security Controls in Federal Information Systems and Organizations, June 2010.

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

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.

  • 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, August 2012.

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


More Internal Revenue Manual