Plan Development and Documentation
What a usable plan contains
Plans translate strategy into action. A complete plan set includes the purpose and scope, activation authority and triggers, roles and contact details, the sequence of response and recovery actions, resource and dependency lists, interfaces to other plans, and version control. Good plans are written for the reader under stress: short sections, action verbs, clear decision points, and appendices for reference data.
Concepts to understand
- Plan hierarchy: enterprise or crisis plan, business unit plans, and supporting plans for technology, facilities, suppliers, and communications.
- Activation criteria must be objective and pre-agreed so that escalation is not delayed by debate.
- Plans should be outcome-oriented, not step-by-step scripts that break when a system changes.
- Distribution must be controlled and available offline; a plan stored only on the affected network is not available.
- Ownership, review cycle, and change triggers belong in the document itself.
Traps
- Writing a plan that duplicates procedures held elsewhere instead of referencing them.
- Omitting the authority to declare a disruption, so nobody acts.
- Contact lists without alternates or without a method that works when systems are down.
- Plans that name individuals rather than roles, becoming stale on promotion or departure.
- No version control, so responders use superseded copies.
Rule of thumb
A plan is ready when a competent person who did not write it can activate it, at night, without system access, and reach the right decisions within the first hour.
Worked example
A plan says "IT will restore the system." That is not actionable. A usable version names the role that declares the incident, the threshold for declaration, the first three actions, and where the offline copy of contacts is kept.