Contingency planning fails quietly: the plan is approved, the backups run, and nobody finds out until a real outage that the restore takes three times longer than the recovery objective promised. This guide works through the Contingency Planning (CP) family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for. It is written for system owners, continuity and disaster recovery leads, backup engineers, security plan authors and assessors. For continuity programme design, see the Business Continuity and Disaster Recovery Guide; for recovery after a cyber attack, see the Cyber Event Recovery Guide. This page stays at the level of the controls and their evidence.
Key takeaways
- Six CP controls apply at Low. CP-1, CP-2, CP-3, CP-4, CP-9 and CP-10 sit in all three security baselines. Moderate adds alternate storage, alternate processing and telecommunications services; High adds capacity planning, continuance of functions and restore-within-time requirements.
- CP-2 must survive compromise, not only failure. The plan must address maintaining essential functions despite disruption, compromise or failure, and full restoration without deterioration of the controls originally implemented. A ransomware recovery that brings systems back without their security controls fails CP-2a.5.
- CP-9 covers documentation as well as data. Backups must include user-level information, system-level information and system documentation, including security and privacy documentation, each at a frequency you define, with confidentiality, integrity and availability protected.
- CP-4 tests effectiveness and readiness. Test at a frequency you define with tests you name, review results and act. At Moderate, CP-9(1) also requires testing backup information for reliability and integrity.
- Identity is a recovery dependency. Restores need working identity providers, privileged accounts, service account credentials, keys and certificates. If backups share credentials with production, an attacker who owns production can delete them.
The CP family at a glance
The table lists every current CP base control with its baseline allocation, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High). CP-5 is withdrawn and omitted. CP has no controls in the privacy baseline, and SP 800-171 Rev. 3 has no Contingency Planning family.
| Control | Title | Baselines | Enhancements selected in baselines |
|---|---|---|---|
| CP-1 | Policy and Procedures | L, M, H | None (no enhancements) |
| CP-2 | Contingency Plan | L, M, H | (1), (3) and (8) at M, H; (2) and (5) at H |
| CP-3 | Contingency Training | L, M, H | (1) Simulated Events at H |
| CP-4 | Contingency Plan Testing | L, M, H | (1) Coordinate with Related Plans at M, H; (2) Alternate Processing Site at H |
| CP-6 | Alternate Storage Site | M, H | (1) and (3) at M, H; (2) at H |
| CP-7 | Alternate Processing Site | M, H | (1), (2) and (3) at M, H; (4) at H |
| CP-8 | Telecommunications Services | M, H | (1) and (2) at M, H; (3) and (4) at H |
| CP-9 | System Backup | L, M, H | (1) and (8) at M, H; (2), (3) and (5) at H |
| CP-10 | System Recovery and Reconstitution | L, M, H | (2) Transaction Recovery at M, H; (4) Restore Within Time Period at H |
| CP-11, CP-12, CP-13 | Alternate Communications Protocols; Safe Mode; Alternative Security Mechanisms | Not in a baseline | Add by tailoring |
For selection and tailoring method, see the NIST SP 800-53B Control Baselines and Tailoring Guide. NIST's companion method for building the plan, including business impact analysis templates for Low, Moderate and High systems, is SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (final, updated November 2010).
CP-2: the contingency plan
CP-2a lists seven things the plan must do. Use them as a table of contents.
| CP-2a item | What the plan must contain | Common gap |
|---|---|---|
| 1 | Essential mission and business functions and their contingency requirements | Systems listed, functions not |
| 2 | Recovery objectives, restoration priorities and metrics | RTO and RPO stated but never measured |
| 3 | Roles, responsibilities and named individuals with contact details | Contacts out of date |
| 4 | Maintaining essential functions despite disruption, compromise or failure | Only hardware failure scenarios |
| 5 | Full restoration without deterioration of original controls | Security controls rebuilt last, or not at all |
| 6 | Sharing of contingency information | No rules on who is told what |
| 7 | Review and approval by named roles | Approver not named |
CP-2b to CP-2h add distribution to key personnel, coordination with incident handling, review at a frequency you define, updates after changes or problems found in testing, communication of changes, incorporation of lessons learned from testing, training and real activations into testing and training, and protection of the plan from unauthorised disclosure and modification. Keep an offline copy.
- CP-2(1) Coordinate with Related Plans (M, H): align with the business continuity, crisis communications, incident response and continuity of operations plans.
- CP-2(3) Resume Mission and Business Functions (M, H): plan to resume all or essential functions within a time period you define of plan activation.
- CP-2(8) Identify Critical Assets (M, H): identify the system assets that support those functions. See the Crown Jewels Analysis Guide.
- CP-2(2) Capacity Planning and CP-2(5) Continue Mission and Business Functions (H): make sure processing, telecommunications and environmental capacity exist during contingency operations, and plan for continuance with minimal or no loss of operational continuity.
- CP-2(7) Coordinate with External Service Providers: a tailoring candidate worth adding for any system that depends on SaaS or managed services.
CP-3 and CP-4: training and testing
- CP-3 Contingency Training: role-based training within a time period you define of someone taking a contingency role, when system changes require it, and at a frequency you define thereafter, with content reviewed on a schedule. CP-3(1) at High incorporates simulated events.
- CP-4 Contingency Plan Testing: test at a frequency you define using tests you name to determine effectiveness and readiness, review results and start corrective action. CP-4(1) at Moderate and High coordinates testing with related plan owners, and CP-4(2) at High tests at the alternate processing site.
- Tailoring candidates: CP-4(4) includes a full recovery and reconstitution to a known state in testing, and CP-4(5) uses mechanisms you define to disrupt the system deliberately as a self-challenge.
Name the test types in the plan: checklist review, tabletop walk-through, functional restore of named components, and full failover. Record actual recovery time against the CP-2a.2 objective for every test. See the Backup and Recovery Testing Checklist.
CP-6, CP-7 and CP-8: alternate sites and telecommunications
| Control | Requirement | Cloud-era reading |
|---|---|---|
| CP-6 Alternate Storage Site (M, H) | Alternate storage with agreements for storing and retrieving backups, with controls equivalent to the primary site | Backup copies in a separate region, account or provider with equivalent access controls |
| CP-6(1) and CP-7(1) Separation (M, H) | Sufficiently separated from the primary site to reduce susceptibility to the same threats | Separate failure domain and separate administrative identity domain |
| CP-6(3) and CP-7(2) Accessibility (M, H) | Identify accessibility problems in an area-wide disruption and outline mitigations | Can staff reach the recovery environment if the identity provider or VPN is down? |
| CP-7 Alternate Processing Site (M, H) | Transfer and resume operations you define within a time period you define, with equipment or contracts in place and equivalent controls | Pre-built infrastructure as code and images for a recovery region |
| CP-7(3) Priority of Service (M, H) | Agreements with priority-of-service provisions matching recovery objectives | Reserved capacity or contractual commitments in the recovery region |
| CP-8 Telecommunications Services (M, H) | Alternate telecommunications to resume operations within a time period you define; CP-8(1) priority of service, CP-8(2) no shared single point of failure | Diverse network paths and providers for connectivity to the recovery site |
"Separated from the same threats" now includes the attacker. A recovery environment administered by the same accounts as production is not separated from a credential compromise. Use a separate administrative identity domain for backup and recovery infrastructure. See the Backup Identity Isolation Guide.
CP-9 and CP-10: backup, recovery and reconstitution
- CP-9 System Backup: back up user-level information on components you define, system-level information and system documentation, each at a frequency you define, and protect the confidentiality, integrity and availability of backups.
- CP-9(1) Testing for Reliability and Integrity (M, H): test backup information at a frequency you define for media reliability and integrity.
- CP-9(8) Cryptographic Protection (M, H): cryptographic mechanisms to prevent unauthorised disclosure and modification of backup information you define.
- CP-9(2), CP-9(3) and CP-9(5) (H): restore a sample as part of plan testing, store copies of critical software and security-related information in a separate facility or fire-rated container, and transfer backups to the alternate storage site at a time period and rate consistent with recovery objectives.
- CP-9(7) Dual Authorization for Deletion or Destruction: a tailoring candidate that directly counters backup deletion by a single compromised administrator. Immutable storage with retention lock is a common implementation.
- CP-10 System Recovery and Reconstitution: recover and reconstitute to a known state within a time period consistent with recovery objectives after disruption, compromise or failure. CP-10(2) adds transaction recovery at Moderate and High; CP-10(4) at High restores components from configuration-controlled, integrity-protected information within periods you define. CP-10(6), a tailoring candidate, protects components used for recovery.
"System-level information" includes the configuration that makes the system work: identity provider tenant settings, policies, secrets manager contents, key material handled under your key management policy, and infrastructure as code. Restoring data without these leaves a system that cannot authenticate anything. See the IdP configuration backup and restore for Entra ID and Okta and the Backup Security and Immutable Backup Guide.
How to evidence CP controls
SP 800-53A Rev. 5 assessment procedures use examine, interview and test. The table turns them into evidence an assessor can accept in one pass.
| Control | Examine | Interview or test | Common gap |
|---|---|---|---|
| CP-2 | Plan against the seven CP-2a items; approval, distribution and change log; business impact analysis | Ask a named contact to describe their role | No compromise scenario |
| CP-3 | Training records by role | Check a new role holder was trained within the period | Only the DR lead trained |
| CP-4 | Test plans, results with measured times, corrective actions | Trace a test finding to closure | Tests never measure recovery time |
| CP-6, CP-7 | Agreements, site separation, access design | Log in to the recovery environment without the primary identity provider | Recovery site shares admin accounts with production |
| CP-9, CP-9(1) | Backup scope, schedules, encryption, integrity test records | Attempt to delete a backup as a production administrator | System documentation and configuration not backed up |
| CP-10 | Recovery procedures and known-good images | Restore a component and compare to baseline configuration | Restored system missing security agents and logging |
For assessment depth, see the NIST SP 800-53A Guide.
Implementing the CP family: a phased approach
This sequence is NHI Mgmt Group's recommendation for a Moderate system.
- Run the business impact analysis. Identify essential functions, maximum tolerable downtime and recovery objectives, using the SP 800-34 templates as a start.
- Write the parameters. Fill CP-2(3), CP-3, CP-4, CP-7, CP-8, CP-9 frequencies and the CP-10 time period in the system security plan.
- Map recovery dependencies. List what must exist before the system can start: identity provider, DNS, privileged accounts, service account secrets, certificates and keys.
- Separate backup administration. Put backup and recovery infrastructure in its own identity domain, encrypt backups and turn on immutability or dual authorisation for deletion.
- Back up configuration and documentation. Add system-level configuration and security documentation to CP-9 scope.
- Test and measure. Run a functional restore, time it against RTO and RPO, coordinate with incident response (CP-2c, CP-4(1)) and record corrective actions.
- Restore controls with the system. Make security agents, logging and access controls part of the recovery runbook, not a follow-up task, to meet CP-2a.5.
Introduce immutability with a short retention lock first and lengthen it once storage costs and restore workflows are confirmed. A retention lock in compliance mode cannot usually be shortened, so test the setting on a non-production vault.
Decision guidance
- Low versus Moderate: Low requires a plan, training, testing, backups and recovery to a known state. Moderate adds alternate storage, alternate processing and telecommunications, plus backup integrity testing and encryption.
- Inherit or implement: a cloud provider supplies resilient infrastructure and multiple regions, but using a second region, backing up your data and configuration, and testing recovery remain yours. Record the split.
- Warm versus cold recovery: choose from the RTO. Hours usually need pre-built infrastructure (CP-7(4) style preparation); days may allow rebuild from code and images.
- Small organisations: immutable backups held in a separate account, a documented restore procedure and an annual measured restore test meet most of the Low intent.
Detection and measurement
- Measured recovery time in the last test against the RTO for each essential function.
- Share of in-scope systems with a successful backup integrity test within the CP-9(1) frequency.
- Number of identities able to delete or alter backups, against the approved list.
- Share of CP-4 corrective actions closed within the agreed period.
- Days since the plan was last reviewed, against the CP-2d frequency.
Framework mapping
| SP 800-53 CP | CSF 2.0 | CIS Controls v8.1 |
|---|---|---|
| CP-2 | ID.IM-04, RC.RP-01, GV.SC-08 | 11.1 |
| CP-2(8) | ID.AM-05 | None |
| CP-3 | PR.AT-02 | None |
| CP-4 | ID.IM-02 | 11.5 |
| CP-6, CP-7, CP-8 | PR.IR-03, PR.IR-04 | None |
| CP-9 | PR.DS-11 | 11.2, 11.3, 11.4 |
| CP-10 | RC.RP-01, RC.RP-03, RC.RP-04 | 11.5 |
Mappings are "intersects with", not equivalence, and are our reading. Check them against NIST's published informative references before using them in an audit. See the CIS Control 11 Data Recovery Guide and the ISO 22301 Business Continuity Guide.
Common failure patterns
- Backups in the blast radius: the same domain administrators run production and the backup console, so a single compromise deletes both.
- Objectives never measured: the plan promises a four-hour RTO but no test has ever restored the system end to end.
- Data without configuration: databases restore, but identity, secrets and network configuration were never backed up.
- Controls restored last: systems come back without logging, EDR or hardened configuration, failing CP-2a.5.
- Recovery depends on the failed system: recovery staff need the primary identity provider or VPN to reach the alternate site.
- IR and CP in silos: incident responders and recovery teams never test together, so the decision to restore is slow and uncoordinated.
Practitioner checklist
- Base the plan on a current business impact analysis with measured RTO and RPO targets.
- Cover compromise scenarios, not only hardware and site failure.
- Include identity, secrets, keys and configuration in CP-9 system-level backups.
- Administer backups from a separate identity domain with encryption and immutability or dual authorisation.
- Test restores at the set frequency and record actual times against objectives.
- Coordinate plan testing with incident response and continuity plan owners.
- Make security controls part of the recovery runbook.
- Keep an offline, current copy of the plan and contacts.
Standards and references
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
- NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
- NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
- NIST: SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Business Continuity and Disaster Recovery Guide · Backup Identity Isolation Guide · Disaster Recovery Plan Template