Plan Development and Implementation
Purpose
This domain turns BIA and strategy outputs into documents people can actually execute under stress, and gets them approved, distributed, and implemented.
Concepts you must know
- Plan hierarchy - emergency response plan, business continuity plan(s), crisis management/communications plan, IT disaster recovery plan, and recovery team plans.
- Standard sections - purpose, scope, assumptions, roles and responsibilities, activation authority, notification/contact lists, recovery procedures, dependencies, appendices, version control.
- Documented assumptions - what the plan presumes (e.g., site inaccessible, staff availability) so users know the plan's limits.
- Functional vs procedural vs scenario-based formats - procedures for known tasks; functional for flexible response.
- Plan ownership and approval - business unit owner signs; senior management approves.
- Distribution and access - offline copies, secure portal, call trees, no single point of failure for the plan itself.
- Implementation - assigning teams, acquiring resources, and confirming capability exists.
Traps in questions
- Treating a plan as a document repository rather than a usable action guide.
- Omitting assumptions, then discovering the plan fails when the assumption fails.
- Skipping approval and version control (a plan in draft is not a plan).
- Storing the only copy of the plan in the building it is meant to recover.
- Writing procedures that require people who are unavailable in the scenario.
Rule of thumb
Write so that a competent person, woken at 3 a.m., can execute it without asking anyone: numbered steps, named roles not names, time-ordered checklists, and contact data in a redundant location.
Worked example: A plan references "John, the facilities lead" for generator switchover. Better: "Facilities Lead (primary: X; alternate: Y)" so the procedure survives John being unreachable.