The June 2026 NIST ransomware profile revision moves ransomware out of the technical domain and into the governance domain. The institutions handling it well are the ones that can name the owner, evidence the recovery, and govern the vendor exposure.
On June 9, 2026, the National Institute of Standards and Technology (NIST) published the final version of its updated ransomware profile, Interagency Report 8374 Revision 1, re-mapping ransomware management onto the NIST Cybersecurity Framework version 2.0 (CSF 2.0). The February 2024 CSF 2.0 revision added a sixth function, Govern, to the five most practitioners know: Identify, Protect, Detect, Respond, and Recover. That single addition changes the nature of the conversation. Ransomware is no longer presented as a technical control set to be purchased and configured. It is presented as something an institution governs.
Most community and mid-sized banks and the larger credit unions already have anti-ransomware controls: endpoint detection, email filtering, network segmentation, backups. Far fewer can say, without reaching for a vendor report, who owns the ransomware lifecycle end-to-end, how recovery is tested, and what evidence would persuade an examiner the program works as designed. That gap is not a tooling problem. It is an operating discipline problem. The August 2025 Marquis Software Solutions breach reached more than 70 financial institutions and exposed personal and financial information on over 670,000 individuals, with many institutions not notifying customers until December 2025. The technical breach happened at the vendor. The accountability did not stay there.
What the updated profile actually changes
The headline of the revision is governance. By aligning ransomware management to CSF 2.0, NIST places the new Govern function at the center: the institution has to establish who is accountable, connect ransomware risk to its stated risk appetite, and define how oversight reaches the board. The profile is not a catalog of products. It is a structure for assigning ownership, measuring readiness, and producing evidence across the full lifecycle.
The most common ransomware weakness in mid-sized institutions is not a missing control. It is fragmented ownership. Detection sits with security operations. Backups sit with infrastructure. Vendor exposure sits with procurement or third-party risk. Notification sits with compliance and legal. Each function performs its part competently. No one owns the whole. When an incident forces those functions to operate as a single response, the seams become visible, and they become visible under time pressure.
Where the shortfalls show up
Three patterns appear consistently and compound one another. The first is recovery treated as a backup job rather than a tested capability. Backups answer one question: does a copy of the data exist? Recovery answers a harder one: can the institution restore its critical business services within a defined time, from clean and verified copies, while a regulatory clock is running? Most institutions can show their backups complete on schedule. Far fewer can show a tested recovery time for the core banking platform, evidence the backups are isolated from the encryption that hit production, and a documented decision on who authorizes a restoration sequence in the middle of a crisis.
The second is the vendor treated as someone else's risk. The Marquis attack is that lesson in concentrated form. A single provider's compromise became a notification and reporting obligation for dozens of institutions with no operational role in the breach itself. The 2023 Interagency Guidance on Third-Party Relationships is explicit: engaging a service provider does not reduce an institution's own responsibility for managing the associated risk.
The third is notification treated as a downstream task rather than a rehearsed decision. Banks operate under the interagency Computer-Security Incident Notification Rule, in effect since April 2022, which requires notifying their primary federal regulator no later than 36 hours after determining a notification incident has occurred. Federally insured credit unions operate under National Credit Union Administration (NCUA) Part 748, in effect since September 2023, which sets a 72-hour clock that also starts when a third party reports an incident to them. The difficult part is not the deadline. It is the determination that starts it.
What operating discipline looks like
The institutions that handle ransomware well share a few traits. Ransomware has a named owner accountable for the entire lifecycle, with the profile's outcomes mapped to specific roles and reported to the board as a governed risk rather than an occasional briefing. Recovery objectives for critical services are defined, tested, and evidenced, with backups verified as recoverable and protected from the production environment they are meant to restore. Third-party recovery and notification obligations are written into contracts, monitored over the life of the relationship, and exercised, so a vendor incident triggers a known playbook instead of a scramble. The notification determination is pre-wired: the decision-makers, the evidence threshold, and the escalation path are agreed before an incident, not improvised during one.
None of this depends on having the largest security budget in the peer group. It depends on the controls already in place being owned, measured, and evidenced.
The window is now
The updated profile is public. The threat data is not abstract; it carries names and dates. The notification clocks are already running on every institution in the sector. The revision makes one thing plain: ransomware has moved fully out of the technical domain and into the governance domain, and supervisory expectations are following it there.
The question an examiner or a board will ask after the next incident is not whether the institution had defenses. It is whether anyone owned them. Clear ownership. Tested recovery. Governed vendors. Evidence on demand.
Back to all insights