Top management should own crisis management and business continuity because the business impact spans operations, legal obligations, and customer trust. Security, risk, compliance, and operations teams can execute the plan, but executives must define priorities, approve recovery objectives, and ensure the plan is tested. Shared execution works best when leadership is visibly responsible for decisions and resourcing.
Why accountability in a bank has to sit with top management
Accountability for crisis management and business continuity belongs with top management because the bank is deciding which services must stay available, what recovery target is acceptable, and how much loss the institution can tolerate. Those are management decisions, not just operational tasks. Executives own the trade-offs between customer harm, regulatory exposure, liquidity pressure, and reputational damage.
That accountability also needs to be visible. If leadership is absent until an incident occurs, continuity planning tends to become a paper exercise with no clear priorities when systems, staff, or third parties fail. Executive ownership gives the plan authority, budget, and the ability to resolve conflicts between business units when time is limited.
In practice, the board and senior management should set the business continuity policy, approve recovery objectives, and ensure that the plan reflects the bank’s most critical products, processes, and dependencies. The execution can be delegated, but the accountability cannot be pushed down without weakening governance. NIST Cybersecurity Framework 2.0 is useful here because it separates governance from response and recovery, which is exactly the split a bank needs for continuity ownership.
What shared execution looks like in a bank crisis response
Shared execution works best when each function has a defined role. Operations typically coordinates restoration, technology restores platforms, security assesses compromise and containment, risk evaluates impact, compliance tracks regulatory obligations, and business leaders decide which services recover first. The point is not to distribute accountability, but to make sure the right experts can act quickly under a single leadership model.
A bank should be especially clear about dependencies that can break continuity even when core systems are intact. Examples include payment rails, cloud services, identity services, data feeds, outsourced operations, and key counterparties. If those dependencies are not mapped and tested, the bank may believe it has resilience when it actually has only local uptime. NIST Cybersecurity Framework 2.0 supports that broader view because recovery and resilience depend on more than technology restoration alone.
Good governance also means the crisis process is pre-authorised. During an incident, teams should not be improvising who can declare an emergency, who can invoke manual processing, or who can accept degraded service. The more time-sensitive the bank’s products are, the more important it is that decision rights, escalation thresholds, and communications paths are agreed in advance.
What makes accountability fail in real continuity programs
The most common failure is treating continuity as an operations project instead of a management obligation. When that happens, recovery objectives drift, testing becomes inconsistent, and the institution learns too late that business leaders never accepted the actual downtime or data-loss assumptions embedded in the plan. A second failure is delegating ownership to a committee without a single accountable executive who can force decisions.
Banks also struggle when the continuity plan is not exercised against realistic scenarios. A tabletop that only checks document familiarity will not expose gaps in manual workarounds, third-party coordination, communications, or decision speed. Banks need to test the hard questions, such as which services stop first, who can approve a controlled shutdown, and how customer and regulatory communications are handled if recovery is partial. EU NIS2 Directive reinforces why this matters, because senior management accountability and incident readiness are no longer optional governance themes in regulated sectors.
Risk and Threat Considerations
Weak accountability in crisis management creates a control gap that adversaries, outages, and third-party failures can exploit. If no senior owner is clearly responsible, response decisions slow down, recovery priorities become contested, and the bank is more likely to overreact in one area while leaving a critical service unavailable in another.
Failure mechanism: unclear executive ownership allows continuity planning, testing, and escalation authority to fragment across departments, which delays decisions and weakens recovery under pressure.
Impact: the bank can suffer prolonged outage, poor customer communication, regulatory scrutiny, missed recovery targets, and avoidable reputational damage during a crisis.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | A bank must tie continuity ownership to business priorities and critical services. |
| GV.RM-01 — Risk Management Strategy | BCM decisions depend on approved recovery trade-offs and risk appetite. | |
| RC.RP-01 — Recovery Plan Execution | Crisis management in a bank hinges on rehearsed recovery execution and role clarity. | |
| Recommendation — Define executive accountability for continuity based on critical business services and tolerated downtime. Set recovery priorities and continuity thresholds through the enterprise risk strategy. Test recovery plans with assigned owners and decision rights before a disruption occurs. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Crisis response requires prepared leadership, escalation, and response roles. |
| A.5.30 — ICT readiness for business continuity | Business continuity in a bank requires governance over ICT recovery readiness. | |
| Recommendation — Assign accountable leadership and prepare escalation procedures before incidents occur. Ensure continuity objectives and recovery capabilities are approved and tested. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | Bank continuity needs an owned contingency plan with approved recovery objectives. |
| CP-4 — Contingency Plan Testing | The answer depends on leadership ensuring continuity plans are tested. | |
| Recommendation — Maintain an approved contingency plan with named owners and recovery targets. Test continuity plans regularly with executive oversight and documented results. | ||
Practitioner Guidance
What to verify: confirm that one executive, usually at C-suite or board-linked level, is explicitly accountable for business continuity outcomes, not just chairing a committee. That owner should be able to approve recovery priorities, challenge unrealistic service targets, and force cross-functional action when trade-offs are required.
What good looks like: the continuity plan names decision owners, escalation paths, testing cadence, and approval authority for degraded operations, manual fallback, and external communications. If those decisions are still debated during an incident, accountability is not mature enough.
Practitioner takeaway: in a bank, continuity succeeds when leadership owns the consequences of downtime, not when operational teams merely execute the paperwork.
