Replacing the FFIEC CAT: What Banks Are Choosing — and Why CSF Alone Isn't Enough

For more than a decade, the FFIEC Cybersecurity Assessment Tool was the default starting point for cybersecurity programs at U.S. banks. Examiners expected to see it. Boards understood it. Vendors built around it. It wasn't perfect — most teams found the maturity ratings cumbersome and the inherent risk profile hard to keep current — but it was the shared language the industry had agreed on.

That language is now gone.

On August 29, 2024, the FFIEC announced it would sunset the Cybersecurity Assessment Tool effective August 31, 2025. As of mid-2026, the CAT is no longer a supported framework for member-agency examinations of banks. The FFIEC declined to name a successor, instead pointing institutions at four existing frameworks and leaving the choice to each bank's risk and compliance leadership.

For credit unions, the story is different — the NCUA confirmed it will continue using the CAT as the basis for its Automated Cybersecurity Evaluation Toolbox (ACET). If you're a credit union, the rest of this post is informational rather than urgent. For everyone else regulated by the OCC, FDIC, FRB, or CFPB, the question of what to replace the CAT with is a live one.

What the FFIEC Pointed At

Rather than endorse a specific tool, the FFIEC referenced four frameworks already in widespread use:

NIST Cybersecurity Framework (CSF) 2.0 — the most recognizable of the four, organized around the Govern, Identify, Protect, Detect, Respond, Recover functions.
CISA Cybersecurity Performance Goals (CPGs) — a baseline set of high-impact practices, originally designed for critical infrastructure sectors but applicable to financial services.
CRI Profile — a financial-sector-specific extension of NIST CSF maintained by the Cyber Risk Institute, with mappings to FFIEC, NYDFS, and several international regulations.
CIS Controls — a prioritized set of defensive actions with implementation groups (IG1, IG2, IG3) tied to organizational maturity and risk.

The FFIEC framing is telling. It's not "pick one." It's "here are four credible options, choose what fits your risk profile and supervisory expectations."

What Banks Are Actually Choosing

The most useful data on where banks are moving comes from a Tandem survey of 365 financial institutions weighing CAT replacements:

NIST CSF — 73%
CRI Profile — 27%
CIS Controls — 27%
CISA CPGs — 24%

Those numbers add to more than 100% because most institutions are layering frameworks rather than picking one. That layering instinct is right — and it's the most important point in this whole transition.

Why NIST CSF Alone Isn't Enough

If you read the CSF and stop there, you'll have a framework that's broad, well-organized, and almost entirely high-level. CSF is excellent at giving you the categories of capability your program needs to cover. It's deliberately bad at telling you what good looks like inside any one of those categories.

Take secure configuration as an example. The CSF subcategory PR.PS-01 says, in essence, that the organization should maintain configuration management practices for its assets. That's it. There is no definition of what a baseline configuration should contain, no specification of which CIS Benchmark applies to which platform, no guidance on review cadence, exception handling, or drift detection.

A team that builds a control around PR.PS-01 and writes "we maintain hardened baselines for our endpoints" is technically compliant with the framework. They will also fail any examination that bothers to ask what the baseline actually is.

The same gap exists across most of CSF:

PR.AA-01 (identities and credentials) tells you to manage identities. It does not specify password length, MFA requirements, account lockout thresholds, or service account governance.
PR.DS-01 (data-at-rest protection) says to protect data. It does not specify cipher suites, key rotation intervals, or what counts as approved encryption.
DE.CM-01 (network monitoring) says to monitor the network. It does not specify what events to collect, retention windows, or alerting thresholds.

This isn't a flaw in CSF. It's the design. CSF was built to be flexible across sectors and organization sizes, and the price of that flexibility is depth. To run a program against CSF, you need a second layer — a prescriptive control set that tells you what each CSF outcome actually requires in practice.

Layering CIS or CRI Profile to Fill the Gap

The two most common ways financial institutions are filling the CSF depth gap:

Layer CIS Controls underneath CSF. This is the most common pairing for institutions that want operational specificity. CIS gives you concrete safeguards (e.g., Safeguard 4.1 — Establish and Maintain a Secure Configuration Process) along with CIS Benchmarks for specific platforms (Windows, Linux, AWS, Azure, M365, Kubernetes). When CSF says "maintain baselines," CIS tells you which benchmark to pin to, which settings are required for IG1 vs IG2 vs IG3, and what evidence an auditor expects to see. CIS also publishes a CSF-to-CIS mapping that makes the relationship explicit.

Layer the CRI Profile. If you want to stay closer to the financial-services regulatory context, the CRI Profile is CSF-shaped on the outside but adds diagnostic statements that go a level deeper — and crucially, it maps directly to FFIEC IT examination handbooks, NYDFS Part 500, and several international supervisory regimes. For institutions that face multi-regulator exams, the CRI Profile reduces the translation work substantially.

A reasonable middle path that several institutions have adopted: CSF as the program-level structure, CRI Profile for regulatory mapping, and CIS Benchmarks for the technical implementation layer. That sounds like a lot of frameworks, but in practice it's one program — CSF defines the categories of work, CRI Profile produces the language that examiners and regulators expect, and CIS supplies the technical specifications your engineering teams actually implement against.

Building the Migration Plan

If you've been running on the CAT and haven't yet committed to a replacement, the practical sequence is roughly:

Map your existing CAT controls to CSF categories. Most of the CAT's domains and assessment factors map cleanly into one of the six CSF functions. This isn't throwaway work — it preserves the institutional knowledge in your existing control library.
Decide your depth layer. For most banks, this is either CIS Controls (operational specificity) or CRI Profile (regulatory alignment) — sometimes both. Pick based on what your examiners are asking for and where your gaps actually are.
Re-state your control library against the new structure. Don't just rename CAT controls to CSF subcategories. Use the migration as the reason to retire stale controls, consolidate duplicates, and update language that has drifted from current practice.
Update the evidence model. CSF evidence expectations are different from CAT — assessments are continuous rather than periodic, and examiners increasingly want to see automated evidence collection rather than point-in-time spreadsheets. This is the part of the migration most institutions underestimate.
Brief the board. If your board has been seeing CAT maturity ratings for ten years, they need a translation layer for whatever you're moving to. Build one before the next quarterly cycle.

The Bottom Line

The FFIEC's decision to retire the CAT without a designated successor was, in its own quiet way, an acknowledgment that no single framework can carry a financial institution's cybersecurity program by itself. NIST CSF is a strong organizing structure. It is not a complete control set. The institutions navigating this transition well are treating CSF as the spine and adding the depth they need underneath — CIS Controls, CRI Profile, sometimes both — rather than pretending that "we adopted CSF" is an answer to an examiner's question.

The CAT is gone. The work it represented isn't.

Working through your CAT-to-CSF migration?

At episki, we help financial institutions run multi-framework GRC programs without the manual mapping overhead. Whether you're moving from CAT to CSF, layering CIS or CRI Profile underneath, or rebuilding your evidence model for continuous examination, we can help.

Book a demo →

A framework is a structure. A program is what you build inside it.