Purpose of the Checklist
This assessment tool is designed for internal audit teams to evaluate whether your organization views operational resilience as a strategic capability or merely a compliance task. Use it during planning cycles, pre-audit reviews, or when advising management on the maturity of resilience programs.
The checklist differentiates between compliance-focused activities (documenting processes, meeting regulatory deadlines) and confidence-building activities (testing assumptions, validating recovery capabilities, ensuring leadership understands critical dependencies). Organizations scoring high on compliance but low on confidence have built a reporting structure, not resilience.
Prerequisites
Before using this checklist, ensure you have:
Access to existing documentation:
- Business impact analyses and service criticality assessments
- Dependency mapping outputs
- Impact tolerance statements
- Scenario testing records
- Board or executive committee meeting minutes discussing resilience
Stakeholder availability:
- Service owners who understand their dependencies
- Risk and compliance personnel managing the resilience program
- Executive sponsors accountable for critical services
- IT and operations teams responsible for recovery capabilities
Baseline knowledge:
- Your organization's regulatory obligations related to operational resilience
- The COSO ERM Framework principles, especially those addressing objectives and uncertainty
- Your organization's definition of "critical services" or "important business services"
If any prerequisite is missing, note it. These gaps reveal whether resilience is embedded in operations or exists only on paper.
The Assessment Checklist
Copy this template into your audit workpapers or a shared document. Score each item: Yes (evidence observed), Partial (some evidence, inconsistent application), or No (no evidence or activity observed).
Section A: Strategic Understanding
- Executive leadership can articulate which services are critical without consulting documentation
- Service owners understand the business impact if their service degrades or fails
- Impact tolerances reflect actual business consequences, not arbitrary timeframes
- The organization has tested whether stated tolerances match leadership's actual risk appetite
- Critical service definitions align with what customers, regulators, or counterparties consider essential
- Board discussions about resilience focus on capability and confidence, not compliance status
Guidance: If leadership needs to reference a spreadsheet to identify critical services, resilience hasn't been internalized. If impact tolerances were set to satisfy a regulatory requirement rather than reflect genuine business needs, you've documented compliance, not built confidence.
Section B: Dependency Awareness
- Service owners can describe their top three dependencies without prompting
- Dependency maps include third parties, internal services, data sources, and key personnel
- The organization has identified single points of failure and understands their implications
- Dependency information is current (updated within the past six months)
- Teams have validated dependencies through testing, not just documentation reviews
- Concentration risks (multiple services depending on the same provider or system) have been identified and assessed
Guidance: Dependency mapping is useful only if it's accurate and actionable. If your maps show what should exist rather than what does exist, or if they haven't been tested against real scenarios, they're compliance artifacts.
Section C: Response Capability
- Recovery plans exist for each critical service
- Plans have been tested under realistic conditions (not just tabletop reviews)
- Testing revealed gaps, and those gaps were addressed
- Response teams know their roles without consulting documentation during an incident
- The organization can execute recovery actions within stated impact tolerances
- Recovery plans account for scenarios where multiple services fail simultaneously
Guidance: Testing is the difference between confidence and hope. If your organization hasn't tested whether it can actually recover within impact tolerances, you don't know if you're resilient. You know you're compliant.
Section D: Information and Decision-Making
- Leadership receives resilience information that enables decisions, not just status reports
- Service owners have access to current dependency and vulnerability data when they need it
- The organization can quickly assemble accurate information during a disruption
- Resilience metrics focus on capability (can we recover?) rather than activity (did we document?)
- Cross-functional teams collaborate on resilience without waiting for a crisis
- Resilience information is integrated into strategic planning and risk decisions
Guidance: If resilience reporting consists of "we completed X activities this quarter," you're tracking compliance work. If it consists of "we validated that Service A can recover in four hours with these constraints," you're tracking confidence.
Section E: Continuous Improvement
- The organization learns from disruptions and near-misses
- Scenario testing includes events the organization hasn't experienced before
- Resilience capabilities are reassessed when business services or dependencies change
- Leadership challenges assumptions about what the organization can withstand
- The resilience program adapts based on testing results and incident learnings
- Investment decisions consider resilience implications, not just compliance requirements
Guidance: Static resilience programs age poorly. If your approach hasn't changed since initial implementation, you're maintaining compliance documentation while business reality evolves around you.
Customizing the Checklist
For regulated entities: Add items specific to your regulatory framework. Financial services firms should include questions about regulatory reporting capabilities during disruption. Healthcare organizations should address patient safety implications.
For different audit scopes: If you're auditing a specific business unit, narrow Section A to that unit's services. If you're reviewing the enterprise program, expand Section D to include governance and oversight mechanisms.
For maturity assessments: Weight the sections differently based on where your organization should be. Early-stage programs might emphasize Sections A and B (understanding). Mature programs should score high on Sections C and E (capability and learning).
For board reporting: Summarize Section A and Section C results. Boards care whether leadership understands critical services and whether the organization can actually recover when disrupted.
Validation Steps
After completing the checklist:
Calculate your confidence ratio: Count "Yes" responses in Sections A, C, and E (confidence indicators). Count "Yes" responses in Sections B and D (information and awareness). If your confidence score is significantly lower than your awareness score, you've documented resilience without building it.
Identify pattern gaps: If Section A scores low, leadership doesn't understand the business's critical dependencies. If Section C scores low, the organization can't execute what it documented. If Section E scores low, you're maintaining a static compliance program.
Test your findings: Select one critical service. Ask its owner to walk through a realistic disruption scenario without preparation. Can they describe dependencies, identify failure points, explain recovery steps, and estimate recovery time? If not, your "Yes" responses in other sections may be optimistic.
Recommend specific actions: Don't just report scores. If dependency maps haven't been tested, recommend a validation exercise. If leadership can't articulate critical services, recommend executive workshops that focus on business impact, not compliance requirements. If recovery plans haven't been stress-tested, recommend scenario exercises that challenge assumptions.
The distinction between compliance and confidence isn't philosophical. It's practical. Organizations that treat resilience as a compliance task satisfy regulators until disruption exposes the gap between documentation and capability. Organizations that build confidence ensure they can deliver what matters most when uncertainty becomes reality.
Your audit findings should clarify which type of organization you're working with.
