The Cybersecurity Dashboard Your Board Actually Needs

Green lights can be dangerous things. A lot of board packets include a cybersecurity page full of comforting metrics: patch percentages, blocked phishing emails, endpoint covera...

Green lights can be dangerous things.

A lot of board packets include a cybersecurity page full of comforting metrics: patch percentages, blocked phishing emails, endpoint coverage, open tickets trending down. Everything looks neat. Everything looks under control.

Then a real incident hits and the board learns an ugly lesson: activity metrics are not the same thing as governance.

That is the gap I want more community bank and credit union boards to close.

Cybersecurity at the board level is not about learning to think like an engineer. It is about learning to govern resilience, accountability, and decision quality. Different job. Different questions.

I learned that years ago when I was at Bankers Bank. When your institution supports banks moving billions in daily transactions, you stop treating uptime and security as separate conversations. They are the same conversation. The board does not need to know how every control works. But the board absolutely needs to know what happens to customers, counterparties, liquidity, and reputation when those controls fail.

That is where too many board discussions still break down.

The problem with most cyber reporting

Most cyber dashboards are built to make management feel organized. Not to help directors make better decisions.

A board can be told that phishing clicks are down, critical patches are current, and multifactor adoption is up. All of that may be true. It can also be completely irrelevant if the institution cannot answer five basic governance questions:

1. What are our most operationally critical services? 2. How long can each one be down before customer harm becomes serious? 3. Which third parties could take us offline? 4. Who has authority to shut systems down, notify regulators, and communicate with customers? 5. Have we practiced any of this under pressure?

Those are governance questions. They are also the questions that matter when your pretty dashboard suddenly turns into a crisis call.

Verizon's 2026 Data Breach Investigations Report notes that the most common causes of breaches still heavily involve the human element, including phishing, stolen credentials, and exploitation of vulnerabilities. That should be a wake-up call for boards. The issue is not whether your team has a dashboard. The issue is whether your institution can consistently make good decisions when normal operations get messy.

Three real examples boards should pay attention to

1. Patelco Credit Union: cyber incidents are business continuity incidents

Patelco Credit Union's public security update states it detected a ransomware attack on June 29, 2024, after unauthorized access to some databases that stretched from May 23 through June 29, 2024. What matters for directors is not just the attack itself. It is the member disruption that followed.

When online banking, mobile access, payments, and service channels are impaired, this is no longer a technical event. It is an enterprise event. Members do not experience ransomware as a security classification. They experience it as: I cannot get to my money, I cannot move funds, and I do not trust what I am being told.

That is a board issue.

2. Change Healthcare: your vendors can become your single biggest point of failure

Change Healthcare was not a community bank, but the governance lesson applies directly to every community financial institution. A critical third party suffered a major cyberattack, and the blast radius spread far beyond one company. When a provider sits inside a payment, claims, settlement, communication, or identity workflow, their outage becomes your outage.

Boards love to ask whether a vendor passed due diligence at onboarding. Fair question. But the harder and better question is this: if this vendor goes dark for a week, what breaks at our institution on day one, day three, and day seven?

That is the question that exposes concentration risk.

3. Community bank reality: recovery beats theater

During my bank technology years, one of the biggest mistakes I saw was treating cyber readiness like an exam you cram for. Institutions would focus on documentation, point-in-time assessments, and polished committee updates. Then something simple would happen: a critical system slows down, a provider misses an escalation, or an alert gets misclassified at the worst possible time.

The difference between institutions that wobble and institutions that recover is rarely one magic tool. It is clarity. Clear owners. Clear escalation paths. Clear thresholds for action. Clear communication. Boring stuff. Important stuff.

Boards should reward that kind of operational discipline a lot more than flashy presentations.

What the board should actually oversee

If I were helping a board reshape its cyber oversight, I would push for five reporting categories.

1. Business service resilience

Do not start with control inventories. Start with essential services.

What customer-facing and institution-critical services must stay available? Digital banking. Wire operations. Card processing. Treasury access. Call center functions. Core connectivity.

For each one, management should define recovery expectations in plain English. Not just technical targets buried in a policy.

2. Decision rights during an incident

Boards should know who can declare an incident, who can shut down access, who contacts regulators, who owns customer communication, and who coordinates with law enforcement and cyber insurance carriers.

In a real event, confusion compounds damage. Delay is expensive.

IBM's 2025 Cost of a Data Breach report puts the global average breach cost at $4.4 million. Community institutions may not see that exact number, but the lesson is the same: delay, disorder, and poor coordination make every incident more expensive.

3. Third-party dependency risk

I would want a board-level view of the vendors that could materially interrupt operations, not just the vendors with the biggest contracts.

Those are not always the same thing.

A modest software provider with deep access to authentication, payments, or customer communications can create more real risk than a larger vendor with limited operational impact. Directors should see dependency maps, backup options, contractual notification requirements, and results from tabletop exercises that include key third parties.

4. Identity and access discipline

This is not the most glamorous topic, which is probably why it gets neglected at the board level.

But stolen credentials still drive too many incidents. Boards do not need to review individual access logs. They do need assurance that privileged access is tightly governed, offboarding is fast, exceptions are documented, and service accounts are not multiplying in the dark.

That is not technical trivia. That is basic control over who can hurt you.

5. Exercise quality, not just exercise frequency

A lot of institutions proudly report that they completed tabletop exercises.

Fine. What did they learn?

Did the exercise reveal that nobody agreed on the threshold for notifying the board? Did it expose outdated call trees? Did it show that customer communications were too slow? Did legal, operations, IT, and executive leadership use the same definitions for severity?

A board should ask for lessons learned and remediation status, not a gold star for holding the meeting.

The shift directors need to make

The board's job is not to ask, "Are we secure?"

That question is too broad to be useful, and any honest answer is "not completely."

The better questions are:

• Where are we most fragile?
• How quickly would we know?
• Who decides what happens next?
• How long could we operate in degraded mode?
• Which dependencies could embarrass us in front of customers and regulators?

That is what mature oversight sounds like.

Cyber governance is not about becoming more technical. It is about becoming more specific.

Specific about business impact. Specific about accountability. Specific about the difference between control activity and institutional resilience.

Most boards do not need more cyber data. They need better framing.

Because when the next incident comes, nobody is going to care that 98.7% of patches were current last quarter if your members cannot log in, your leadership team is improvising, and your vendor is suddenly impossible to reach.

That is the moment your governance gets graded.

Questions for your next board discussion

1. If one of our top three critical vendors went down tomorrow, do we know exactly how customer impact would unfold over the first 72 hours? 2. Does our board reporting show business resilience and decision readiness, or does it mostly show technical activity? 3. When was the last time we practiced a cyber scenario that included operations, communications, legal, and a key third party at the same table?

Sources

• Verizon, 2026 Data Breach Investigations Report: https://www.verizon.com/business/resources/reports/dbir/
• IBM, Cost of a Data Breach 2025: https://www.ibm.com/reports/data-breach
• Patelco Credit Union, Security Incident Updates & Information Center: https://www.patelco.org/securityupdate