Contingency plan

The term is used at two levels, and the difference matters when reading standards. In NIST SP 800-34 Rev. 1, "contingency planning" is the umbrella discipline, and the information system contingency plan (ISCP) is a specific plan for recovering one system. The same guide lists neighbouring plan types with their own scope: business continuity plan, continuity of operations plan, crisis communications plan, critical infrastructure protection plan, cyber incident response plan, disaster recovery plan and occupant emergency plan. In Danish practice, "beredskabsplan" usually refers to the top-level document that binds these together, so a Danish beredskabsplan often corresponds to the NIST umbrella rather than to a single ISCP.

NIST SP 800-34 describes a seven-step process: develop the contingency planning policy; conduct the business impact analysis; identify preventive controls; create contingency strategies; develop the plan; plan testing, training and exercises; and plan maintenance. The ISCP itself is structured in three phases after the supporting information: activation and notification, in which the outage is assessed and the plan formally invoked; recovery, in which operations are restored in the documented order; and reconstitution, in which the system is validated, tested, returned to normal operation and the plan deactivated. In NIST SP 800-53 Rev. 5 the same ground is covered by the CP control family, notably CP-2 Contingency Plan, CP-4 testing, CP-9 system backup and CP-10 system recovery and reconstitution.

The umbrella plan's own content is mostly organisational: activation criteria and who may declare an incident or a crisis, the response organisation with named roles and deputies, decision mandates (for example who may disconnect the organisation from the internet or shut down production), escalation and contact lists including suppliers, insurer, lawyers and authorities, and references to the subordinate plans and playbooks. Version control, an owner and a review cycle are part of the plan, and copies must be available offline, since the document server may be among the systems that are down.

NIS2 Article 21(2) requires incident handling and business continuity measures, and in Danish public administration the obligation to plan for continuity of critical functions has a longer history under the national emergency management framework. The most frequent weaknesses found in exercises are outdated contact lists, missing deputies, unclear decision authority between IT and management, and subordinate plans that assume the same infrastructure the incident has taken away. A contingency plan is not the same as incident response: incident response is the process of handling a security event, while the contingency plan is the prepared framework that includes incident response alongside continuity, recovery and communication.