CP-2 is the core of the Contingency Planning family. It asks for a written plan that says how the system keeps essential functions running and how it gets back to normal after a disruption, compromise or failure. Auditors read it closely, and customers often ask for a summary of it.
800-53 binds US federal systems and others by contract. For a small or mid size company it is a reference, and the plan is the document a business continuity questionnaire is really asking about.
What the control asks
The plan must do six things.
- Identify essential mission and business functions and their contingency requirements.
- Give recovery objectives, restoration priorities and metrics.
- Name contingency roles and responsibilities, with the assigned people and their contact information.
- Cover maintaining essential functions despite a disruption, compromise or failure.
- Cover eventual full restoration without weakening the controls originally planned and implemented.
- Cover how contingency information is shared.
Around the plan there are further duties. Have it reviewed and approved by parties you define. Distribute copies to the roles you define. Coordinate contingency planning with incident handling. Review the plan at a set frequency and update it for organizational, system and environmental changes and for problems found during implementation, execution or testing. Communicate changes. Feed lessons from testing, training and real events into future testing and training. Protect the plan from unauthorized disclosure and modification.
What it means in practice
NIST says contingency planning is part of a wider continuity program and belongs in system design from the start. Systems can be built for redundancy, backup and resilience. Not every system needs full recovery. Recovery objectives should reflect risk tolerance and the impact of the system, so a tiered approach is normal.
The guidance lists actions plans address, such as orderly degradation, shutdown, fallback to manual mode, alternate information flows and operating in modes reserved for attack. It also asks you to link planning to incident handling so the right steps are ready when an incident hits.
Evidence to collect
- The plan, with version, approval record and distribution list.
- A business impact analysis or tier list that supports the objectives.
- Recovery time and recovery point objectives per system.
- The contact roster, with current names and numbers.
- Review and update records, including changes after tests or events.
- Lessons learned from the last test or incident, and the plan changes they caused.
- Access controls on the document, showing it is protected.
Common gaps
- The roster lists people who left.
- Objectives were chosen once and never validated by a test.
- The plan sits in the system it is meant to recover, so it is unreachable in an outage.
- No link to the incident response plan.
- Full restoration is described, but restoring the original controls is not.
- Nobody owns updates after architecture changes.
How to implement it
- Rank systems by business impact and assign objectives to each tier.
- Write the plan around roles and decisions, not tool screenshots.
- Store a copy outside the primary environment and restrict edit rights.
- Review it twice a year and after every incident or test, and record the outcome.
- Cross reference the incident response plan and the test schedule in CP-4.
Enhancements add depth. CP-2.1 is Coordinate with Related Plans. CP-2.2 is Capacity Planning. CP-2.3 is Resume Mission and Business Functions. CP-2.4 is Resume All Mission and Business Functions. CP-2.5 is Continue Mission and Business Functions. CP-2.6 is Alternate Processing and Storage Sites. CP-2.7 is Coordinate with External Service Providers. CP-2.8 is Identify Critical Assets. CP-2.7 matters for cloud first companies, since your provider is part of your plan.
Mapping to other frameworks
Business continuity requirements appear in SOC 2, ISO 27001 and others. Mappings vary by source and version, so check an authoritative crosswalk for the editions you are assessed against.
Quick check
Does every system need full recovery?
No. The guidance says recovery objectives reflect risk tolerance and impact, and not all systems need to fully recover to meet continuity goals.
Why protect the plan itself?
The statement asks you to protect it from unauthorized disclosure and modification, since it shows how you respond and who holds key roles.
