Task 2 RMF_Contingency Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

Information Systems Contingency Plan Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

i. NIST Special Publication 800-34 Rev. 1, "Contingency Planning Guide for Federal Information Systems"

Table of Contents

Figure 1 - Three Phases 4

FOR OFFICIAL USE ONLY

{SYSTEM NAME}

INFORMATION SYSTEMS CONTINGENCY PLAN {DATE}

Template developed by:

http://www.i-assure.com FOR OFFICIAL USE ONLY

1.0 OVERVIEW

Information systems are vital elements in most mission/business processes. Because information system resources are so essential to an organization’s success, it is critical that identified services provided by these systems are able to operate effectively without excessive interruption. Contingency planning supports this requirement by establishing thorough plans, procedures, and technical measures that can enable a system to be recovered as quickly and effectively as possible following a service disruption. Contingency planning is unique to each system, providing preventive measures, recovery strategies, and technical considerations appropriate to the system’s information confidentiality, integrity, and availability requirements and the system impact level.

This document does not address facility-level information system planning (commonly referred to as a disaster recovery plan) or organizational mission continuity (commonly referred to as a continuity of operations [COOP] plan) except where it is required to restore information systems and their processing capabilities. Nor does this document address continuity of mission/business processes Information system contingency planning refers to a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of information systems, operations, and data after a disruption. Contingency planning generally includes one or more of the following approaches to restore disrupted services:

1) Restoring information systems using alternate equipment;

2) Performing some or all of the affected business processes using alternate processing (manual) means (typically acceptable for only short-term disruptions);

3) Recovering information systems operations at an alternate location (typically acceptable for only long–term disruptions or those physically impacting the facility); and

4) Implementing of appropriate contingency planning controls based on the information system’s security impact level.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix I, “Detailed Compliance Matrix”.

Table 1 - SP-800-53v4 Compliance Matrix

2.0 INTRODUCTION

Information assets are vital to {ACRONYM}’s mission/business processes; therefore, it is critical that services provided by {ACRONYM} are able to operate effectively without excessive interruption. This Information System Contingency Plan (ISCP) establishes comprehensive procedures to recover {ACRONYM} quickly and effectively following a service disruption.

2.1 Background

This {ACRONYM} ISCP establishes procedures to recover {ACRONYM} following a disruption. The following recovery plan objectives have been established:

1) Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:

a. Activation and Notification phase to activate the plan and determine the extent of damage;

b. Recovery phase to restore {ACRONYM} operations; and

c. Reconstitution phase to ensure that {ACRONYM} is validated through testing and that normal operations are resumed.

2) Identify the activities, resources, and procedures to carry out {ACRONYM} processing requirements during prolonged interruptions to normal operations.

3) Assign responsibilities to designated {ACRONYM} personnel and provide guidance for recovering {ACRONYM} during prolonged periods of interruption to normal operations.

4) Ensure coordination with other personnel responsible for {ACRONYM} contingency planning strategies. Ensure coordination with external points of contact and vendors associated with {ACRONYM} and execution of this plan.

2.2 Scope

This ISCP has been developed for {ACRONYM}, which is classified as an Availability = LOW impact system, in accordance with Federal Information Processing Standards (FIPS) 199 – Standards for Security Categorization of Federal Information and Information Systems. Procedures in this ISCP are for Low- Impact systems and designed to recover {ACRONYM} within {RTO DAYS}. This plan does not address replacement or purchase of new equipment, short-term disruptions lasting less than {RTO DAYS}; or loss of data at the onsite facility or at the user-desktop levels. As {ACRONYM} is a low-impact system, alternate data storage and alternate site processing are not required.

2.3 Assumptions

The following assumptions were used when developing this ISCP:

· {ACRONYM} has been established as a low-impact system for Availability purposes, in accordance with FIPS 199.

· Alternate processing sites and offsite storage are not required for this system.

· The {ACRONYM} is inoperable and cannot be recovered within {RTO DAYS}.

· Key {ACRONYM} personnel have been identified and trained in their emergency response and recovery roles; they are available to activate the {ACRONYM} Contingency Plan.

The {ACRONYM} ISCP does not apply to the following situations:

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

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

3.0 CONCEPT OF OPERATIONS

The Concept of Operations section provides details about {ACRONYM}, an overview of the three phases of the ISCP (Activation and Notification, Recovery, and Reconstitution), and a description of roles and responsibilities of {ACRONYM}’s personnel during a contingency activation

3.1 System Description

{SYSTEM DESCRIPTION}

The {ACRONYM}’s hardware, software, architecture and diagrams can be found in the System Security Plan (SSP), which is available within eMASS.

3.1.1 Essential Mission

{ESSENTIAL MISSION}

3.1.2 Essential Business Function

{ESSENTIAL BUSINESS FUNCTION}

3.2 Overview of Three Phases

This ISCP has been developed to recover and reconstitute the {ACRONYM} using a three-phased approach. This approach ensures that system recovery and reconstitution efforts are performed in a methodical sequence to maximize the effectiveness of the recovery and reconstitution efforts and minimize system outage time due to errors and omissions. The three system recovery phases are:

Figure 1 - Three Phases Activation and Notification Phase. Activation of the ISCP occurs after a disruption or outage that may reasonably extend beyond the RTO established for a system. The outage event may result in severe damage to the facility that houses the system, severe damage or loss of equipment, or other damage that typically results in long-term loss.

Once the ISCP is activated, system owners and users are notified of a possible long-term outage, and a thorough outage assessment is performed for the system. Information from the outage assessment is presented to system owners and may be used to modify recovery procedures specific to the cause of the outage.

Recovery Phase. The Recovery phase details the activities and procedures for recovery of the affected system. Activities and procedures are written at a level that an appropriately skilled technician can recover the system without intimate system knowledge. This phase includes notification and awareness escalation procedures for communication of recovery status to system owners and users.

Reconstitution Phase. The Reconstitution phase defines the actions taken to test and validate system capability and functionality at the original or new permanent location. This phase consists of two major activities: validating successful reconstitution and deactivation of the plan.

During validation, the system is tested and validated as operational prior to returning operation to its normal state. Validation procedures may include functionality or regression testing, concurrent processing, and/or data validation. The system is declared recovered and operational by system owners upon successful completion of validation testing.

Deactivation includes activities to notify users of system operational status. This phase also addresses recovery effort documentation, activity log finalization, incorporation of lessons learned into plan updates, and readying resources for any future events.

3.3 Roles and Responsibilities

The ISCP establishes several roles for {ACRONYM} recovery and reconstitution support. Persons or teams assigned ISCP roles have been trained to respond to a contingency event affecting {ACRONYM}.

3.3.1 System Owner

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

· Pre-event

· Approve the plan

· Ensure the plan is maintained

· Ensure training is conducted

· Authorize periodic plan testing exercises

· Support the Technical Recovery Lead and all other participants prior to and during scheduled and unscheduled exercises and plan tests

· Post-event

· Declaration of a disaster

· Authorize travel and housing arrangements for team members

· Manage and monitor the overall recovery process

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

· Support the ISCP Coordinator and all other participants during debilitating conditions/situations

3.3.2 ISCP Coordinator

This individual is responsible for managing the total recovery effort; for ensuring that other personnel perform all checklist items and for coordination and overall communications. Following are their responsibilities:

· Pre-event

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

· Distribute copies of plan to team members

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

· Train team members

· Post-event

· Accomplish initial notification of Team members

· Assist in damage assessment

· Coordinate activities of recovery team members

· Periodically report to the System Owner the status of recovery efforts and details as required

3.3.2 Technical Recovery Lead

This individual has a full understanding of the technical aspects of the system. Following are their responsibilities:

· Pre-event

· Assist the ISCP Coordinator as directed

· Participate in contingency exercises

· Understand all CP roles and responsibilities

· Post-event

· Perform restoration functions

· Maintain a record of all communications

4.0 ACTIVATION AND NOTIFICATION

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

4.1 Activation Criteria and Procedure

The {ACRONYM} ISCP may be activated if one or more of the following criteria are met:

1) The type of outage indicates {ACRONYM} will be down for more than {RTO DAYS};

2) The facility housing {ACRONYM} is damaged and may not be available within {RTO DAYS}; and The following persons or roles may activate the ISCP if one or more of these criteria are met:

· System Owner

· ISCP Coordinator

· Technical Recovery Lead

4.2 Notification

The first step upon activation of the {ACRONYM} ISCP is notification of appropriate mission/business and system support personnel. Contact information for appropriate POCs is included in Appendix A, “Personnel Contact List”.

For {ACRONYM}, the following method and procedure for notifications can be used:

· Phone Call

· Email

· In-person As stated previously, any role within the process can execute initial notification.

4.3 Outage Assessment

Following notification, a thorough outage assessment is necessary to determine the extent of the disruption, any damage, and expected recovery time. Assessment results are provided to the ISCP Coordinator to assist in the coordination of the recovery of {ACRONYM}.

The following procedures will be followed:

· Determines if there has been loss of life or injuries

· Assesses the extent of damage to the facilities and the information systems

· Estimates the time to recover operations

· Determines accessibility to facility, building, offices, and work areas

· Assess the need for and adequacy of physical security/guards

· Advises the ISCP Coordinator that physical security/guards are required

· Identify salvageable hardware

· Maintain a log/record of all salvageable equipment

· Estimates levels of outside assistance required

· Report updates, status, and recommendations to the ISCP Coordinator

5.0 RECOVERY

The Recovery Phase provides formal recovery operations that begin after the ISCP has been activated, outage assessments have been completed (if possible), personnel have been notified, and appropriate teams have been mobilized. The following Recovery Objectives have been identified:

1) restore system capabilities

2) repair damage

3) resume operational capabilities at the original location At the completion of the Recovery Phase, {ACRONYM} will be functional and capable of performing the functions identified in Section 3.1 of this plan.

5.1 Sequence of Recovery Activities

The following activities occur during recovery of {ACRONYM}:

1) Identify recovery location (if not at original location);

2) Identify required resources to perform recovery procedures;

3) Retrieve backup and system installation media;

4) Recover hardware and operating system (if required); and

5) Recover system from backup and system installation media.

5.2 Recovery Procedures

Recovery procedures are outlined in Appendix C, “Detailed Backup and Recovery Procedures” and will be executed in the sequence presented to maintain an efficient recovery effort.

5.2.1 Recovery After a Disruption

Recovery procedures are outlined in Appendix C, “Detailed Backup and Recovery Procedures”. In the event of a disruption, the System Owner will execute the following:

· System Validation Test Plan

· Create Lessons Learned and After Actions Reports

· Update the Test and Maintenance Schedule to reflect the real-world event

5.2.2 Recovery After a Compromise

Recovery procedures are outlined in Appendix C, “Detailed Backup and Recovery Procedures”. In the event of a security incident or compromise, the Incident Response Plan (IRP) will be followed and the IRP and Contingency Planning teams will coordinate recovery objectives and requirements together.

5.2.3 Recovery After a Failure

Recovery procedures are outlined in Appendix C, “Detailed Backup and Recovery Procedures”. In the event of a failure that requires the purchase of new and/or additional equipment, the System Owner will start the purchase request process.

5.2.4 Transaction Recovery

Database management systems and transaction processing systems are examples of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery. This requirement is only applicable to the above system types.

Is the system transaction based or contain a database management system?

☒ No

☐ Yes {Delete, or describe how transactions are recovered}

5.3 Recovery Escalation Notices/Awareness

During the Recovery Process, it is extremely important to keep both senior management and the general user population aware of all activities and status. The ISCP Coordinator is responsible for communicating status through either phone, email or in-person to the general user population. If the outage escalates and potentially causes outages to other systems or networks, the ISCP Coordinator will up-channel reporting to the CIO so that other teams are notified.

6.0 RECONSTITUTION

Reconstitution is the process by which recovery activities are completed and normal system operations are resumed. If the original facility is unrecoverable, the activities in this phase can also be applied to preparing a new permanent location to support system processing requirements. A determination must be made on whether the system has undergone significant change and will require reassessment and reauthorization. The phase consists of two major activities: validating successful reconstitution and deactivation of the plan.

6.1 Validation Testing

Validation data testing is the process of testing and validating data to ensure that data files have been recovered completely at the permanent location and the system is ready to return to normal operations. Procedures are located in Appendix E, “System Validation Test Plan”.

6.2 Recovery Declaration

Upon successfully completing testing and validation, the {ACRONYM} will formally declare recovery efforts complete, and that {ACRONYM} is in normal operations. {ACRONYM} business and technical POCs will be notified of the declaration by the ISCP Coordinator.

6.3 Notifications (Users)

Upon return to normal system operations, {ACRONYM} users will be notified by the System Owner or ISCP Coordinator using predetermined notification procedures (e.g., email, phone calls, etc.).

6.5 Data Backup

As soon as reasonable following recovery, the system should be fully backed up and a new copy of the current operational system stored for future recovery efforts. This full backup is then kept with other system backups. The procedures for conducting a full system backup are located in Appendix C, “Detailed Backup and Recovery Procedures”.

6.6 Event Documentation

It is important that all recovery events be well-documented, including actions taken and problems encountered during the recovery and reconstitution effort, and lessons learned for inclusion and update to this ISCP. It is the responsibility of each ISCP team or person to document their actions during the recovery and reconstitution effort, and to provide that documentation to the ISCP Coordinator. The process contained within Appendix G, “Lessons Learned and After Action Reports” will be followed.

6.8 Deactivation

Once all activities have been completed and documentation has been updated, the {ACRONYM} will formally deactivate the ISCP recovery and reconstitution effort. Notification of this declaration will be provided to all business and technical POCs.

APPENDIX A – PERSONNEL CONTACT LIST

ISCP Key Personnel

Table 2 - Key Personnel List

APPENDIX B – VENDOR CONTACT LIST

Table 3 - Vendor Contact List

APPENDIX C – DETAILED BACKUP AND RECOVERY PROCEDURES

Windows Backup uses the built-in Microsoft tools.

1. Open Backup and Restore by navigating to Control Panel, clicking System and Maintenance, and then clicking Backup and Restore.

2. Do one of the following:

· If you've never used Windows Backup before, click Set up backup, and then follow the steps in the wizard.

· If you've created a backup before, you can wait for your regularly scheduled backup to occur, or you can manually create a new backup by clicking Back up now.

To create a new, full backup After you create your first backup, Windows Backup will add new or changed information to your subsequent backups. If you're saving your backups on a hard drive or network location, Windows Backup will create a new, full backup for you automatically when needed. If you're saving your backups on CDs or DVDs and can't find an existing backup disc, or if you want to create a new backup of all of the files on your computer, you can create a full backup. Here's how to create a full backup:

1. Open Backup and Restore by navigating to Control Panel, clicking System and Maintenance, and then clicking Backup and Restore.

2. In the left pane, click Create new, full backup.

C.1.2 Windows Restore Windows Restore uses the built-in Microsoft tools.

You can restore backed-up versions of files that are lost, damaged, or changed accidentally. You also restore individual files, groups of files, or all of the files that you've backed up.

1. Open Backup and Restore by navigating to Control Panel, clicking System and Maintenance, and then clicking Backup and Restore.

2. Do one of the following:

· To restore your files, click Restore my files.

· To restore the files of all users, click Restore all users' files.

3. Do one of the following:

· To browse the contents of the backup, click Browse for files or Browse for folders.

When you're browsing for folders, you won't be able to see the individual files in a folder. To view individual files, use the Browse for files option.

· To search the contents of the backup, click Search, type all or part of a file name, and then click Search.

To restore a backup made on another computer You can restore files from a backup that was created on another computer running Windows.

1. Open Backup and Restore by navigating to Control Panel, clicking System and Maintenance, and then clicking Backup and Restore.

2. Click Select another backup to restore files from, and then follow the steps in the wizard.

To find files that were restored from a backup made on another computer If you're restoring files from a backup that was made on another computer, the files will be restored in a folder under the user name that was used to create the backup. If the user names are different, you'll need to navigate to the folder where the files are restored. For example, if your user name was Molly on the computer that the backup was made on but your user name is MollyC on the computer that the backup is being restored on, the restored files will be saved in a folder labelled Molly. You can find the restored files by following these steps:

1. Open Computer by clicking clicking Computer.

2. Double-click the icon of the drive that the files are saved on, for example C:\.

3. Double-click the Users folder.

You will see a folder for each user account.

4. Double-click the folder for the user name that was used to create the backup.

The restored files will be in the various folders based on where they were located originally.

To restore files from a file backup after restoring your computer from a system image backup After you restore your computer from a system image backup, there might be newer versions of some of your files in a file backup that you want to restore. Because you've reverted your computer to the state that it was in at the time the system image backup was created, Windows Backup won't show any file backups in the Restore Files wizard that were created after the system image backup was created. To restore files from a file backup that was created after the system image backup was created, follow these steps:

1. Open Backup and Restore by navigating to Control Panel, clicking System and Maintenance, and then clicking Backup and Restore.

2. Click Select another backup to restore files from.

3. In the Backup Period, select the date range of the backup that contains the files that you want to restore, and then follow the steps in the wizard

APPENDIX D – ALTERNATE PROCESSING PROCEDURES

This section identifies alternate manual or technical processing procedures available that allow the business unit to continue some processing of information that would normally be done by the affected system.

Information System Disruption Maintaining Essential Mission. {ACRONYM} is not considered Mission Essential. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document.

Maintaining Business Functions. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document. All documentation, meetings and face-to-face communications will continue to occur.

Information System Compromise Maintaining Essential Mission. {ACRONYM} is not considered Mission Essential. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document.

Maintaining Business Functions. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document. All documentation, meetings and face-to-face communications will continue to occur.

Information System Failure Maintaining Essential Mission. {ACRONYM} is not considered Mission Essential. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document.

Maintaining Business Functions. During a Contingency Event, unaffected assets will continue work as before. For affected assets, if they are a higher priority than the currently operational assets then operational assets will be re-purposed to prioritize continuing mission. In the event the full system is impacted for more than {RTO DAYS}, the System Owner will contact the Program sponsor to activate the overarching Business Continuity Plan, which is outside the scope of this document. All documentation, meetings and face-to-face communications will continue to occur.

APPENDIX E – SYSTEM VALIDATION TEST PLAN

This appendix includes system acceptance procedures that are performed after the system has been recovered and prior to putting the system into full operation and returned to users.

Table 4 - System Validation Procedures

APPENDIX F – TEST AND MAINTENANCE SCHEDULE

The ISCP will be reviewed and tested yearly or whenever there is a significant change to the system. For low-impact systems, a yearly tabletop exercise is sufficient. The following table details the review and testing.

Identify tabletop facilitator.

System Owner

Develop tabletop test plan.

ISCP Coordinator

Invite participants.

ISCP Coordinator

Conduct tabletop test.

ISCP, POCs

Finalize after action report and lessons learned.

ISCP Coordinator

Update ISCP based on lessons learned.

ISCP Coordinator

Approve and distribute updated version of ISCP.

System Owner

Table 5 - Test and Maintenance Schedule

APPENDIX G – LESSONS LEARNED / AFTER ACTION REPORTS

G.1.0 LESSONS LEARNED

One of the most important parts of contingency planning is also the most often omitted: learning and improving. The {ACRONYM} contingency planning team will evolve to reflect new threats, improved technology, and lessons learned. Holding a “lessons learned” meeting with all involved parties after a major contingency, and optionally periodically after lesser contingencies as resources permit, can be extremely helpful in improving security measures and the contingency planning process itself. Multiple contingencies can be covered in a single lessons learned meeting. This meeting provides a chance to achieve closure with respect to a contingency by reviewing what occurred, what was done to intervene, and how well intervention worked. The meeting should be held within several days of the end of the contingency. Questions to be answered in the meeting include:

1) Exactly what happened, and at what times?

2) How well did staff and management perform in dealing with the contingency? Were the documented procedures followed? Were they adequate?

3) What information was needed sooner?

4) Were any steps or actions taken that might have inhibited the recovery?

5) What would the staff and management do differently the next time a similar contingency occurs?

6) How could information sharing with other organizations have been improved?

7) What corrective actions can prevent similar contingency in the future?

8) What precursors or indicators should be watched for in the future to detect similar contingencies?

9) What additional tools or resources are needed to detect, analyze, and mitigate future contingencies?

Small contingencies s need limited post- contingency analysis, with the exception of contingencies s performed through new attack methods that are of widespread concern and interest. After serious attacks have occurred, it is usually worthwhile to hold post-mortem meetings that cross team and organizational boundaries to provide a mechanism for information sharing. The primary consideration in holding such meetings is ensuring that the right people are involved. Not only is it important to invite people who have been involved in the contingency that is being analyzed, but also it is wise to consider who should be invited for the purpose of facilitating future cooperation.

The success of such meetings also depends on the agenda. Collecting input about expectations and needs (including suggested topics to cover) from participants before the meeting increases the likelihood that the participants’ needs will be met. In addition, establishing rules of order before or during the start of a meeting can minimize confusion and discord. Having one or more moderators who are skilled in group facilitation can yield a high payoff. Finally, it is also important to document the major points of agreement and action items and to communicate them to parties who could not attend the meeting.

Because of the changing nature of information technology and changes in personnel, the contingency planning team will review all related documentation and procedures for handling contingencies s at designated intervals.

G.2.0 AFTER ACTIONS REPORTS

The After Actions Report (AAR) provides evaluation criteria based on the exercise objectives and a means to evaluate how well exercise objectives were met, and identify areas where additional exercises might be necessary. Evaluating the exercise is a critical step to ensuring success of the contingency response program. After the test or exercise is complete, the participants will conduct a debriefing to discuss observations for things that worked well and things that could be improved. The comments that surface during the debriefing, along with lessons learned documented during the exercise, will be captured in the AAR. The AAR will also document observations made throughout the exercise and participants during the exercise and recommendations for enhancing the IR plan that was exercised.

The template used to document the AAR can be found in Enclosure 2, “After Actions Report Template”.

G.3.0 METRICS

The {ACRONYM} contingency planning team will collect the below data, which will be used to measure the success of the contingency team:

a) Total amount of labor spent working on the contingency

b) Elapsed time from the beginning of the contingency to contingency discovery, to the initial impact assessment, and to each stage of the contingency handling process (e.g., containment, recovery)

c) How long it took the contingency planning team to respond to the initial report of the contingency

d) How long it took to report the contingency to management and, if necessary, appropriate external entities (e.g., Tier-2).

a) Reviewing logs, forms, reports, and other contingency documentation for adherence to established contingency planning policies and procedures

b) Identifying which precursors and indicators of the contingency were recorded to determine how effectively the contingency was logged and identified

c) Determining if the contingency caused damage before it was detected

d) Determining if the actual cause of the contingency was identified

e) Determining if the contingency is a recurrence of a previous contingency

f) Calculating the estimated monetary damage from the contingency

g) Measuring the difference between the initial impact assessment and the final impact assessment

h) Identifying which measures, if any, could have prevented the contingency.

Table 6 - Metrics

APPENDIX H – BUSINESS IMPACT ANALYSIS

Business Impact Analysis (BIA)

System Manager POC: {POC}

System Description: {SYSTEM DESCRIPTION}

Internal {Identify the individuals, positions, or offices within your organization that depend on or support the system; also specify their relationship to the system}

{PERSONNEL}

{ROLE}

B. Identify System Resources {Identify the specific hardware, software, and other resources that comprise the system; include quantity and type}

C. Identify critical roles {List the roles identified in Section A that are deemed critical}

Critical Role:

System Owner ISCP Coordinator Technical Recovery Lead

Critical Resource:

{POC}

{POC}

{POC}

E. Identify outage impacts and allowable outage times {Characterize the impact on critical roles if a critical resource is unavailable; also, identify the maximum acceptable period that the resource could be unavailable before unacceptable impacts resulted}

{RTO DAYS}

F. Prioritize resource recovery {List the priority associated with recovering a specific resource, based on the outage impacts and allowable outage times provided in Section E. Use quantitative or qualitative scale (e.g., high/medium/low, 1-5, A/B/C)}

APPENDIX I – DETAILED COMPLIANCE MATRIX

The following table provides traceability between this document and the Assessment Procedures contained within NIST Special Publication 800-53A Revision 4, "Assessing Security and Privacy Controls in Federal Information Systems and Organizations".

Moderate Low High Moderate Low High Moderate Low The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the personnel or roles as all stakeholders identified in the contingency plan.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low DoDI 8500.01 and NIST SP 800-34 meet the DoD requirements for contingency planning policy and procedures.

DoD Components are automatically compliant with this control because they are covered by the DoD level policy, DoDI 8500.01 and NIST SP 800-34.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low

Moderate Low High Moderate Low High Moderate Low The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the personnel or roles as all stakeholders identified in the contingency plan.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low DoDI 8500.01 and NIST SP 800-34 meet the DoD requirements for contingency planning policy and procedures.

DoD Components are automatically compliant with this control because they are covered by the DoD level policy, DoDI 8500.01 and NIST SP 800-34.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low

Moderate Low High Moderate Low High Moderate Low The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the frequency as every 5 years.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low DoDI 8500.01 and NIST SP 800-34 meet the DoD requirements for contingency planning policy and procedures.

DoD Components are automatically compliant with this control because they are covered by the DoD level policy, DoDI 8500.01 and NIST SP 800-34.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the frequency as annually.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low High Moderate Low DoDI 8500.01 and NIST SP 800-34 meet the DoD requirements for contingency planning policy and procedures.

DoD Components are automatically compliant with this control because they are covered by the DoD level policy, DoDI 8500.01 and NIST SP 800-34.

Automatically compliant with this CCI because they are covered at the DoD level

High Moderate Low

High

Low

High

Low

High Moderate High Moderate

1 hour (Availability High ) 24 hours (Availability Moderate) 1 - 5 days (Availability Low) as defined in the contingency plan.

The system is not considered a HIGH level. Therefore, this AP is not applicable.

DoD has defined the time period as 1 hour (Availability High ) 24 hours (Availability Moderate) 1 - 5 days (Availability Low) as defined in the contingency plan.

Automatically compliant with this CCI because they are covered at the DoD level

DoD has determined the alternative communications protocols are not appropriate to define at the Enterprise level.

NIST has not allocated this AP. Therefore, this AP is not applicable.

For information system components that have applicable STIGs or SRGs, the organization conducting the inspection/assessment evaluates the components to ensure that the organization being inspected/assessed has configured the information system in compliance with the applicable STIGs and SRGs pertaining to CCI 2853.

NIST has not allocated this AP. Therefore, this AP is not applicable.

DoD has determined the conditions are not appropriate to define at the Enterprise level.

NIST has not allocated this AP. Therefore, this AP is not applicable.

DoD has determined the restrictions on safe mode of operation are not appropriate to define at the Enterprise level.

NIST has not allocated this AP. Therefore, this AP is not applicable.