CP-2 Contingency Plan (L) (M) (H)

NIST 800-53 (r4) Control:

The organization:

a. Develops a contingency plan for the information system that:

1. Identifies essential missions and business functions and associated contingency requirements;

2. Provides recovery objectives, restoration priorities, and metrics;

3. Addresses contingency roles, responsibilities, assigned individuals with contact information;

4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;

5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and

6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];

b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];

c. Coordinates contingency planning activities with incident handling activities;

d. Reviews the contingency plan for the information system [FedRAMP Assignment: (L)(M)(H) at least annually];

e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;

f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and

g. Protects the contingency plan from unauthorized disclosure and modification.

CP-2 Additional FedRAMP Requirements and Guidance: For JAB authorizations the contingency lists include designated FedRAMP personnel.

NIST 800-53 (r4) Supplemental Guidance:

Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11.

References: Federal Continuity Directive 1; NIST Special Publication 800-34.

NIST 800-53 (r5) Discussion:

Contingency planning for systems is part of an overall program for achieving continuity of operations for organizational mission and business functions. Contingency planning addresses system restoration and implementation of alternative mission or business processes when systems are compromised or breached. Contingency planning is considered throughout the system development life cycle and is a fundamental part of the system design. Systems can be designed for redundancy, to provide backup capabilities, and for resilience. Contingency plans reflect the degree of restoration required for organizational systems since not all systems need to fully recover to achieve the level of continuity of operations desired. System recovery objectives reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, organizational risk tolerance, and system impact level.

Actions addressed in contingency plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By coordinating contingency planning with incident handling activities, organizations ensure that the necessary planning activities are in place and activated in the event of an incident. Organizations consider whether continuity of operations during an incident conflicts with the capability to automatically disable the system, as specified in IR-4(5). Incident response planning is part of contingency planning for organizations and is addressed in the IR (Incident Response) family.

38North Guidance:

Meets Minimum Requirement:

• The organization must have a documented and approved Contingency Plan (CP) in accordance with the NIST 800-34, Revision 1, Contingency Planning Guide for Federal Information Systems. The contingency plan includes:

  • • A prioritization of assets/services;

    • Recovery time objectives (RTO), recovery point objectives (RPOs), and Maximum Tolerable Downtime (MTDs);

    • A defined list of roles and responsibilities for CP team members including contact information (e.g., telephone and email) and alternates for primary POCs.

    • System restoration procedures for critical assets/services that are required to be restored in a chronological manner.

    • Data backup and retrieval procedures.

    • The frequency of review required for the CP document itself.

    • A revision table that details what was reviewed and/or updated and the approver and date of each version.

• Ensure the ISCP plan is approved and reviewed at least annually and within 90 days after a significant change.

• The CP is only accessible by those with a role or responsibility throughout the contingency planning process (to include any associated service teams or external organizations).

• CP documents dependencies of services and other internal/external teams such as the incident response team.

Best Practice:

• The CP should align with the overall business' Business Impact Analysis along with the Continuity of Operations Plan (COOP) to ensure operations of critical assets and services for the organization and its customers (if any).

Unofficial FedRAMP Guidance:

• Must produce Information System Contingency Plan (ISCP) using the following template: https://www.fedramp.gov/assets/resources/templates/SSP-A06-FedRAMP-ISCP-Template.docx.

• For JAB authorizations the contingency lists include designated FedRAMP personnel.

Assessment Evidence:

• Screenshots or the CP plan that includes updates made to the CP:

  • Screenshot or revision table from the CP dated with the annual review and the content that was reviewed and updated (if needed).

  • Any associated documentation reviewed and dated within the last year or within 90 days as a result of a major change to the system.

  • Updates made to the CP (as documented in revision history) in response to any weaknesses discovered during any contingency-related test exercise, contingency-related incident, or external or internal security assessment. The contingency plan test report (with lessons learned) may be an example of evidence to provide and should be dated within 30 days following the contingency event/exercise.

• Meeting minutes, meeting agendas, status reports, etc. demonstrating coordination between contingency planning and incident response activities (such as table top exercises).

• Evidence showing that updates to the CP are disseminated and received by intended personnel.

• Screenshots showing how CP documentation is stored and protected (e.g., document repository).

• Screenshots showing the configuration for restricted access controls in place to view the CP only by authorized personnel (may also include a screenshot showing that CP stakeholders have received and reviewed the CP).

CSP Implementation Tips:

• None.