Organizations that treat resilience as merely a business continuity project are addressing outdated challenges. You can't restore your way to strategic resilience when disruptions alter the assumptions your recovery plan was built on.
This checklist helps risk managers integrate resilience into their existing risk management frameworks. Each item shifts focus from recovery to enabling your organization to adapt, operate under degraded conditions, and continue achieving objectives during disruptions.
What This Checklist Covers
This checklist addresses resilience as an organizational capability, not a set of recovery procedures. You'll verify that your risk function can answer three questions during a disruption: what business objectives are threatened, what capabilities remain available, and what decisions need to be made when the original plan no longer applies. The items below focus on absorptive capacity (withstanding disruption), recovery effectiveness (restoring damaged capability), and adaptive capacity (changing course during disruption).
Prerequisites
Before starting this checklist, confirm:
- Access to your organization's current business continuity plans and business impact analyses
- Identification of critical business services that support strategic objectives
- Mapping of dependencies across processes, technology, third parties, and facilities
- Authority to convene stakeholders from operations, technology, compliance, procurement, and finance
Checklist Items
1. Define critical business services by the objectives they enable, not the processes they contain.
Review your business impact analysis. If critical services are described primarily as "payroll processing" or "order fulfillment system" rather than "employee compensation delivery" or "customer transaction completion," you're defining components instead of capabilities.
Good looks like: Each critical service explicitly states which strategic objective it supports, which customers or markets it serves, and what constitutes acceptable degraded performance.
2. Specify resilience tolerances for how long each critical service can operate in a degraded state before unacceptable harm occurs.
Recovery time objectives tell you when a system should be restored. Resilience tolerances tell you how long your organization can continue achieving objectives while operating with reduced capability, manual workarounds, or alternate processes.
Good looks like: Documented tolerances for each critical service that specify acceptable degradation levels (e.g., "manual processing can handle 40% of normal transaction volume for 6 hours before customer commitments are breached").
3. Connect business services to the interconnected ecosystem that supports them with dependency maps.
If your continuity documentation shows application dependencies but not the shared infrastructure, third parties, facilities, controls, and fourth parties that create concentration risk, you can't see cascading failures before they occur.
Good looks like: Visual maps showing how apparently separate business services share underlying dependencies, with clear identification of single points of failure that affect multiple strategic objectives.
4. Ensure your risk function can answer "which objectives are threatened" within the first hour of a disruption.
Walk through a scenario where a critical supplier becomes unavailable or a technology platform begins failing. If the first hour is spent gathering information from separate teams who each hold one piece of the puzzle, you're not resilient.
Good looks like: A capability (not just a document) that allows risk managers to immediately identify which strategic objectives are affected, which services depend on the disrupted component, and which customers or markets experience the greatest impact.
5. Define and understand decision authority for adapting plans during disruption.
When the original recovery plan stops being useful because reality has changed, someone needs authority to reallocate resources, change priorities, or abandon assumptions. If that authority isn't clear until executives start debating it during the crisis, you've lost time you can't recover.
Good looks like: Documented decision rights that specify who can authorize operating in degraded states, bypassing normal controls, or changing service priorities when tolerances are being approached.
6. Test adaptive capacity, not just plan execution, with resilience exercises.
If your tabletop exercises verify that people can follow documented procedures, you're testing continuity. Resilience exercises inject uncertainty, incomplete information, changing conditions, and conflicting priorities to test whether the organization can adapt when assumptions prove wrong.
Good looks like: Exercise scenarios that force participants to make trade-offs between competing objectives, operate with partial information, and change course mid-response when new information invalidates the original plan.
7. Conduct cross-functional resilience reviews before strategic decisions that create new dependencies.
If procurement finalizes a supplier concentration, technology implements a new platform, or operations redesigns a critical process without resilience review, you're discovering vulnerabilities after you've committed to them.
Good looks like: Risk function participation in decisions involving technology architecture, third-party relationships, process redesign, and facility planning, with explicit analysis of how each decision affects absorptive, recovery, and adaptive capacity.
8. Measure capability, not artifact completion, with resilience metrics.
Tracking the percentage of business units with updated continuity plans tells you about documentation compliance. It doesn't tell you whether your organization can withstand disruption, operate through degraded conditions, or adapt when reality changes.
Good looks like: Metrics that measure demonstrated capability (e.g., time required to identify affected business services during exercises, percentage of critical services with documented degraded-state tolerances, decision latency during simulated disruptions).
Common Mistakes
Equating plan documentation with organizational resilience. A well-formatted business continuity plan doesn't mean your organization can actually operate when information is incomplete, assumptions are wrong, and normal processes are unavailable.
Measuring resilience by restoration speed alone. An application can be restored within its recovery objective while customers remain unable to complete transactions, suppliers remain unavailable, or the backlog created during the outage takes days to clear.
Positioning resilience exclusively within IT, security, or continuity functions. If resilience sits in one silo, every scenario looks like that silo's problem. Resilience belongs with risk management because disruptions don't respect organizational boundaries.
Next Steps
After completing this checklist, schedule a cross-functional workshop with representatives from operations, technology, compliance, procurement, and finance. Present a realistic disruption scenario and walk through the first hour. Ask: which strategic objectives are threatened, what capabilities remain available, and who has authority to adapt the plan when the original assumptions no longer hold. The gaps you identify will tell you where documentation ends and capability needs to begin.
