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

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

SRM is responsible for coordinating the efforts of the enterprise-wide IT DR Program as follows:

Positions within the IT DR program include:

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

A&I is responsible for coordinating the efforts of the enterprise-wide IT DR Program as follows:

Responsibilities of A&I include:

IT is responsible for:

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

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

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

The BOD/Information System Owner is required to:

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

It is recommended that BODs work jointly with AWSS, IRS IT operations, and SRM to conduct integrated Business Continuity (BC)-DR exercises, whenever possible, to validate the recovery times of CBPs and supporting applications.

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.

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:

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

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

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

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

Single Entry Time Reporting Function/Program Codes and Internal Order Codes have been established that will be used to track IRS IT DR 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.

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

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

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.

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' ability to adapt to changes, risks, and unexpected events that can affect our ability to continue our critical business processes and mission.

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.

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.

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

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:

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

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.

The IT BIA takes into account business needs and requirements as well as information technology.

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.

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.

The site-based IT BIA serves to:

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

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

Important Terms

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

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

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

All backup media must be stored offsite.

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

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

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

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.

All FISMA-reportable systems shall have an ISCP.

All FISMA-reportable systems shall exercise their ISCP annually.

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

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.

IRM 10.8.1 requires exercises or tests of a system's contingency plan capabilities to be conducted at least annually.

Functional and DR tests requiring the use of production or live data shall get a Live Data Request Form, Form 13471, which is located at: http://publish.no.irs.gov/cat12.cgi?request=CAT2&itemtyp=F&itemb=13471&items=.

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

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

All systems and applications must be recoverable.

All systems and applications must have disaster recovery planning documents. See the IT Contingency Tests and Exercises section within this IRM for additional guidance on disaster recovery planning documents.

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

Modifications to this annual requirement must be submitted to and approved by the Director, Security Risk Management.

Procedures for conducting ISCP/DR tests are in IRM 10.8.62.

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 can be a part of the ISCP, a standalone document, or disaster 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.

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.

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.

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

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.

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.

Requests for ISCP or DR data shall be handled by the owner of the document/data.

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.

See the Security Awareness and Training section of IRM 10.8.1 for additional guidance.

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

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

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

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