The Ransomware Packet Should Start With the Exposed Door
A practical weekly article for community bank and credit union boards on ransomware governance, focused on exposed remote access paths, known exploited vulnerabilities, recovery...
The scariest ransomware story is usually not the encrypted server.
It is the boring door the attacker walked through first.
An old VPN appliance. A remote access path with weak authentication. A hypervisor management console nobody has tested lately. A third-party connection that somehow became permanent infrastructure.
That is where a community bank or credit union board should start the ransomware conversation now.
Not with a cinematic cyber war room. Not with another vague heat map. Start with the entry point.
Because if the institution cannot name its exposed doors, it is not really governing ransomware risk. It is buying tools around a mystery.
Akira is a useful warning because it is not exotic
CISA, the FBI, Europol, and other partners updated their joint #StopRansomware advisory on Akira ransomware with reporting as recent as November 2025. The advisory says Akira actors primarily target small and medium-sized businesses and have impacted organizations across sectors, including Financial Services. It also says FBI and cybersecurity researchers observed Akira actors gaining initial access through VPN services without multifactor authentication configured, often using known vulnerabilities.
That is the part directors should underline.
This is not a movie plot where the attacker invents a new branch of physics. It is ordinary exposure meeting disciplined criminals.
The same advisory tells organizations to prioritize known exploited vulnerability remediation, enforce phishing-resistant MFA, keep regular offline backups, and regularly test restoration. Source: CISA joint advisory AA24-109A, “#StopRansomware: Akira Ransomware”: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a
Community institutions do not need to memorize the indicator list. That is management’s job. They do need to understand the governance pattern: one weak route into the environment can be enough.
If the board packet only says “ransomware risk remains elevated,” that is a weather report. Useful, maybe. Governable, not really.
The ransomware metric that matters is exposure under time
Boards are often shown cybersecurity as a maturity score, a control status, or a project dashboard. Those have their place.
But ransomware is a clock problem.
How fast does management learn about a critical exposed vulnerability? How fast can the institution patch, isolate, compensate, or shut down the exposed service? How long can a remote access exception remain open? How recently were backups restored in a real test, not admired like a gym membership in January?
The FBI’s 2025 IC3 Annual Report says losses reported to IC3 surpassed $20 billion in 2025. For ransomware specifically, IC3 received more than 3,600 complaints, with losses exceeding $32 million. The report also warns that ransomware loss amounts normally do not include lost business, time, wages, files, equipment, or third-party remediation services, and that some entities report no loss amount to IC3, which can make overall ransomware losses look artificially low. Source: FBI IC3 2025 Annual Report: https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf
That caveat matters for boards.
The invoice from the attacker is not the whole cost. The real cost can include branch disruption, delayed loan work, payment operations strain, member communication, vendor forensics, cyber insurance negotiations, regulator communication, and reputational damage.
Ransomware governance should not be reduced to “can we avoid paying?” The better question is whether the institution can keep operating, communicating, and making decisions while management contains the blast.
The board packet should name the exposed doors
A practical ransomware packet does not need to turn directors into threat hunters.
Please do not put packet-capture screenshots in front of the board unless you are trying to create a medical event.
But the packet should translate technical exposure into business accountability.
Start with internet-facing systems. Which VPNs, firewalls, remote desktop paths, file transfer tools, web applications, cloud admin portals, and vendor access routes are reachable from outside the institution? Which ones support critical banking operations? Which ones have known exploited vulnerabilities? Which ones cannot be patched quickly?
Then name the owner. Not “IT.” Not “the vendor.” A person.
Someone should be accountable for the exposure register, the remediation clock, the compensating control, and the escalation when management chooses to keep a risky door open.
The board should not approve firewall rules. It should require management to explain which doors matter, who owns them, and what deadline turns delay into risk acceptance.
Recovery is not a binder. It is a capability.
The CISA #StopRansomware Guide recommends securing remote services, implementing MFA on VPN connections, updating network devices, maintaining offline backups, and testing restoration. Source: CISA #StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide
That guidance sounds obvious. Obvious is good. Ransomware tends to punish institutions that treat obvious controls as optional because the calendar was full.
For boards, recovery should be discussed as a business capability, not a technical promise.
Which systems are restored first? Who decides that order? What member-facing services can continue in degraded mode? How does the institution process wires, ACH, debit card exceptions, loan closings, fraud alerts, call center scripts, and regulatory notifications while systems are impaired?
The answer cannot be “we have backups.”
Backups are ingredients. Recovery is the meal. Sometimes the pantry is full and dinner still goes badly because nobody tested the recipe.
A useful packet should show when the last restoration test occurred, what failed, what was fixed, what remains unresolved, and whether the test included third-party dependencies. If a core provider, managed service provider, cloud platform, telecom carrier, or digital banking provider is essential to recovery, the board should know the handoff before an incident.
That is not vendor management trivia. That is survivability.
The third-party question is sharper than “are they secure?”
Community institutions depend on vendors. That is normal. The problem is when ransomware governance stops at collecting vendor attestations and SOC reports.
The sharper question is operational.
If a ransomware event hits us, hits the vendor, or hits both through a shared dependency, what happens next?
Who has authority to disconnect a vendor path? Who contacts the vendor after hours? What evidence will they provide? What does the contract say about forensic cooperation, notification timing, data return, backup access, and recovery sequencing?
The NCUA’s cybersecurity resources page points credit unions to information and cybersecurity regulations, third-party relationships, business continuity guidance, and resources from CISA, FBI InfraGard, and US-CERT. Source: NCUA Cybersecurity Resources: https://ncua.gov/regulation-supervision/regulatory-compliance-resources/cybersecurity-resources
That is the right cluster of topics. Cybersecurity, third parties, and business continuity are not separate board conversations anymore. Ransomware ties them together whether the agenda does or not.
What I would ask management now
If this were the next board risk committee packet, I would want plain answers to six questions.
1. What are our top exposed doors?
List the external access paths that matter most to operations, member service, and recovery.
2. Which known exploited vulnerabilities are inside our remediation window right now?
Do not bury the answer in a scanner export. Show the critical exposure, owner, due date, and compensating control.
3. Where are we still relying on authentication exceptions?
MFA is not a slogan. If a route into the institution lacks strong MFA, management should explain why, who approved it, and when the exception dies.
4. What gets rebuilt first?
Recovery priority should be a business decision before the event. Deposits, payments, digital access, core processing, lending, fraud operations, communications, and reporting cannot all be first.
5. Which third parties are required for containment or recovery?
Name the vendors, support paths, contract assumptions, after-hours contacts, and evidence handoffs.
6. What metric would force escalation?
Patch age, unresolved critical vulnerabilities, failed restore tests, backup gaps, privileged access exceptions, vendor response failures, or tabletop findings can all be escalation triggers. Pick the ones that matter.
The board’s job is not to chase ransomware groups
Directors do not need to know every ransomware family name. They do not need to debate indicators of compromise. They do not need to become part-time incident responders.
Their job is to make management translate ransomware risk into exposure, controls, recovery, third parties, testing, metrics, and accountability.
A strong ransomware discussion should leave the board knowing which doors are open, which controls protect them, which recovery assumptions have been tested, which vendors matter most, and who owns the uncomfortable tradeoffs.
If management cannot answer those questions now, the institution has work to do before the next tabletop, renewal, exam, or cyber insurance meeting.
Better to find that out in the packet than during the ransom note.
Discussion questions
1. Which external access path would management be least comfortable defending to the board if CISA listed a known exploited vulnerability against it tomorrow? 2. What restoration test in the last year proved the institution could recover a critical member-facing service without the normal vendor or admin path? 3. Who owns the decision to keep an exposed service online when the fix is disruptive, and what threshold forces that decision to the board or risk committee?