Crisis Communication Plan: The BCP Component Most Financial Institutions Treat as an Afterthought

Most bank business continuity plans exceed 60 pages of technical recovery procedures: failover sequences, RTO and RPO targets, alternate site activation steps, and recovery team contact trees. The section on crisis communication often runs three pages — and reads like it was drafted in an afternoon, then never touched again.

Examiners notice. The FFIEC Business Continuity Management booklet is explicit: crisis management and communication are core program components, not optional appendices. Institutions that show up to an exam with detailed technical recovery plans but vague communication protocols get findings.

TL;DR

• Crisis communication is a distinct program component from incident response — it covers who says what, to whom, in what order, with what approval authority, across employees, regulators, customers, and the public
• Banking organizations must notify their primary federal regulator within 36 hours of a notification-level computer security incident; SEC-regulated entities must file an 8-K within 4 business days of a material cybersecurity determination
• Every crisis communication plan needs four pre-built audience streams: internal (employees), regulators, customers, and media/public — sequenced in that order
• The plan is only as good as its last test: tabletop exercises should validate communication workflows, not just technical recovery steps

Why Crisis Communication Gets the Short End

Business continuity programs grew out of IT disaster recovery — and IT is good at documenting technical procedures. Runbooks, failover scripts, and system inventories are naturally structured and testable. Communication is messy, politically sensitive, and involves coordination across functions that don’t naturally talk to each other (Legal, PR, Compliance, Operations, the C-suite).

So BCM teams write the technical stuff first, add a communication section later, and never quite finish it. The result: during an actual crisis, the incident commander knows exactly which systems to bring up in which order, and has no idea who’s allowed to send the customer email, what it should say, or whether Legal needs to see it first.

The other problem: most communication plans are written for cyberattacks and don’t account for the full range of scenarios a BCP covers. A ransomware attack triggers the cybersecurity response. But a regional office flood, a critical vendor failure, a pandemic-driven workforce disruption, or a banking system outage all require the same communication infrastructure — the same teams, the same notification trees, the same approval chains. If the plan only exists for one scenario, it won’t hold up in the others.

The Regulatory Baseline: What Examiners Actually Test

FFIEC Business Continuity Management Requirements

The FFIEC BCM booklet — revised in 2019 — explicitly requires that business continuity programs include documented communication strategies for both internal and external audiences, with clear assignment of communication responsibilities and regular testing of communication capabilities.

Examiners specifically look for:

• Named communication leads with documented alternates (not just roles — actual people)
• Pre-approved message frameworks for major disruption scenarios
• Evidence that communication procedures have been exercised, not just documented
• Integration between the crisis communication plan and the incident escalation framework

Communication continuity is also on the exam list: can the institution communicate with employees, regulators, and customers if primary communication infrastructure (email, phone systems, intranet) is unavailable? Most plans don’t address this.

OCC 36-Hour Notification Rule

The OCC, Federal Reserve, and FDIC jointly issued the Computer-Security Incident Notification rule, effective May 2022. The requirement: banking organizations must notify their primary federal regulator as soon as possible, and no later than 36 hours after determining that a notification incident has occurred.

A “notification incident” is defined as a computer-security incident that has materially disrupted or degraded — or is reasonably likely to materially disrupt or degrade — the institution’s ability to deliver banking products or services, a business line whose failure would cause material revenue loss, or operations whose failure would threaten US financial stability.

The 36-hour clock starts when the institution makes a determination, not when the incident begins. That’s an important distinction — but it creates its own pressure: the determination process needs to be fast enough that the notification deadline remains achievable. Institutions without a clear materiality determination workflow routinely blow the deadline because the internal debate about whether the incident qualifies runs past the window.

The rule also covers bank service providers: if a service provider experiences an incident that materially disrupts covered services to a bank for four or more hours, it must notify the bank’s designated point of contact immediately.

SEC 4-Day Cybersecurity Disclosure

SEC-regulated entities — public companies, registered investment advisers, broker-dealers — face the cybersecurity disclosure rule requiring an Item 1.05 Form 8-K filing within four business days of determining that a cybersecurity incident is material.

materiality requires a substantive determination: there must be a substantial likelihood that a reasonable shareholder would consider the incident important in making an investment decision. That determination requires coordination between the CISO, General Counsel, CFO, and senior leadership — under time pressure.

The communication implication: the 8-K drafting process needs to be part of the crisis communication plan, with pre-identified drafters, a fast-track Legal review pathway, and a pre-agreed framework for what the filing must address (nature, scope, timing of the incident; actual or reasonably likely material impact).

Building the Crisis Communication Team

A crisis communication plan without a crisis communication team is a document, not a program. The team structure determines execution speed.

Every role needs a named alternate with explicit authority to act if the primary is unreachable. During a crisis that strikes outside business hours — which is most of them — the person with authority to approve the customer email cannot be three layers of escalation away.

The Four Communication Streams: Sequencing That Matters

Crisis communication fails most often not because the wrong things are said, but because things are said in the wrong order. Customers find out before employees. The media finds out before regulators. The CEO issues a public statement before Legal has reviewed it.

The correct sequence:

1. Internal (Employees) — First

Employees are simultaneously your most important audience and your most likely communication leak. They’re getting calls from family, friends, and customers. They need to know what happened (at an appropriate level), what they’re authorized to say, and who to direct inquiries to — before anyone else hears from you.

An employee communication should go out within the first few hours of a significant disruption, even if all it says is: “We are aware of an issue affecting [systems/operations]. Our response team is actively working to resolve it. Do not speak to media or customers about this issue — direct all inquiries to [name/number]. We will provide an update by [time].”

That message does three things: acknowledges the situation internally, prevents unauthorized disclosure, and sets an expectation for the next update. All three matter.

2. Regulators — Concurrent with Internal, Within Deadlines

Regulator notification should begin in parallel with internal communication, not after. The 36-hour OCC clock doesn’t care that you’re still drafting the customer email. Regulatory notifications should be templated, with fill-in sections for incident-specific details, and should have a designated compliance owner who initiates the filing process the moment a notification incident determination is made.

3. Customers — After Internal, Before Public

Customer communication should go out before any public statement or media inquiry response. Customers who hear about an incident from the news before they hear from you lose trust that is extraordinarily hard to rebuild. The sequence matters as much as the content.

4. Media and Public — Last, with Approval

Public statements go out after employees and customers have been notified, after Legal has reviewed the statement, and after the CEO or designated spokesperson has approved the language. The statement should be limited to confirmed facts, avoid speculation about cause or timeline, and direct media to a single designated spokesperson.

Pre-Approved Message Templates: Build These Before You Need Them

The most expensive hour in a crisis is the hour spent arguing over what the customer email should say. Pre-approved templates — reviewed by Legal and approved in advance — eliminate that cost.

Build templates for your most likely scenarios:

Technology Outage (Customer-Facing)

“We are experiencing a technical issue affecting [service/feature]. Our team is working to restore service as quickly as possible. We apologize for the inconvenience and will provide an update by [time]. If you need immediate assistance, please contact [phone/alternative channel].”

Cybersecurity Incident (Regulatory Notification)

“Pursuant to [12 CFR Part 53 / applicable regulation], [Institution Name] hereby notifies [Regulator] of a computer-security incident that has [materially disrupted / is reasonably likely to materially disrupt] [describe operations]. The incident was detected on [date/time]. [Describe nature and scope of known impact]. We are actively investigating and have [describe response measures taken]. We will provide further updates as our investigation progresses. Contact: [name, title, phone, email].”

Third-Party Vendor Disruption (Internal)

“[Vendor name], which provides [service], has notified us of an incident affecting their platform. We are assessing the impact on our operations. [Service/function] may be affected. [Alternative procedures, if available]. Our business continuity team is coordinating with [vendor] and will provide a status update by [time]. Do not share this information with customers or media until further notice.”

Each template has blanks for incident-specific details — date, nature of incident, affected systems, contact information. Legal reviews the templates in advance; specific facts are filled in at the time of use. The approval bottleneck disappears.

Testing the Communication Plan

Communication plans degrade without testing. Regulatory guidance under the FFIEC BCM framework requires annual testing; the OCC expects that test results are documented and that gaps are closed.

What good communication testing looks like:

• Include communication in every tabletop exercise. Don’t run a tabletop and stop at recovery decisions. Run the communication stream in parallel: who drafts the customer email? Who approves it? How long does that take? Can Legal turn it around in 30 minutes? Test it.
• Test the notification chains. Actually call the regulatory contact numbers. Confirm the bank service provider notification point of contact is current. Verify the SEC external counsel hotline is accessible after hours.
• Test communication continuity. What happens when email is down? Does the phone tree work? Is there an out-of-band communication method for the executive team?
• Measure approval cycle time. Set a target: external communications approved within 60 minutes of draft completion. Track whether you hit it in exercises. If Legal review is taking three hours, that’s a process problem to fix before the real crisis.

For facilitation techniques that surface communication gaps during exercises, see Tabletop Exercise Facilitation Techniques.

Common Exam Findings: What Gets Flagged

Based on examination guidance and common BCM deficiencies, regulators flag these communication plan weaknesses most often:

No named alternates. Plans that list roles without named backup individuals. In practice, the primary is often unavailable and no one has authority to act.

Templates that don’t exist. Plans that say “prepare customer notification” without pre-approved draft language. Under time pressure, blank-page writing produces bad outputs.

No regulatory notification workflow. Understanding that a 36-hour deadline exists is different from having a documented process for hitting it: who makes the determination, who drafts the notification, who reviews it, how it gets transmitted.

Communication limited to cyber scenarios. Plans that only address communication during cybersecurity events. Operational disruptions, vendor failures, and physical events need the same communication infrastructure.

Untested approval chains. Plans where the approval process exists on paper but has never been run under realistic time pressure in an exercise.

So What?

A business continuity plan with excellent recovery procedures and weak crisis communication will fail in front of regulators and customers, even if the technical recovery succeeds. The communication plan is the piece that determines whether your response is perceived as competent or chaotic — and perception shapes regulatory relationship quality and customer trust for years afterward.

The practical starting point: pick your three most likely disruption scenarios, map the four communication streams for each, draft the template messages, get Legal to pre-approve them, then put them in an appendix every communication team member can find in the dark.

Then test them. Not as an afterthought at the end of the next tabletop — as a primary exercise objective.

For a complete BCP template, tabletop scenario library, and communication plan framework, see the Business Continuity & Disaster Recovery Kit. The FFIEC Business Continuity Management requirements overview covers the full examination framework. For the technical incident response side — containment, forensics, recovery sequencing — see the Incident Response Plan Template.