The CAT’s retirement freed the framework and orphaned the risk profile

The week

For ten years, a community bank that wanted to know whether its cybersecurity was good enough had a familiar place to start. It was a structured questionnaire called the Cybersecurity Assessment Tool, usually shortened to the CAT, published by the Federal Financial Institutions Examination Council. The FFIEC is the body through which the main US banking regulators coordinate their examination standards, so a tool carrying its name had real weight in boardrooms and exam rooms, even though using it was always voluntary.

On August 31, 2025, the council removed the CAT from its website. Nobody was caught off guard. The FFIEC had announced the sunset a year earlier, on August 29, 2024. In explaining the decision, it pointed to newer resources that had appeared since the tool was released in 2015. Two stood out: the National Institute of Standards and Technology’s Cybersecurity Framework 2.0, a widely used government-published structure for organizing a security program, and the Cross-Sector Cybersecurity Performance Goals from CISA, the federal Cybersecurity and Infrastructure Security Agency, which set out a common baseline of protections for organizations of every kind. The council also mentioned industry-developed tools as alternatives, while taking care not to endorse any one of them.

The Federal Reserve passed the news to the institutions it supervises in a supervisory letter, SR 24-7, in November 2024. Its message was measured. The Fed said it did not endorse any particular self-assessment tool, and that whatever an institution chose to use should be commensurate with its risk. The message amounted to this: pick what fits, but make sure it fits the risks you actually run.

Credit unions were in a slightly different position. Their regulator, the National Credit Union Administration, kept its own Automated Cybersecurity Evaluation Toolbox, known as the ACET, available. The ACET was built on the same structure as the CAT, so credit unions that relied on it could carry on largely as before.

That made the first week of September 2025 an unremarked milestone: the first week in a decade without the FFIEC tool. For many banks it was also the week they began scoring themselves against something new, and the week a less visible question opened up: with the old tool gone, who now tells a bank how high its security bar should be?

Take the board of a community bank with a dozen branches and a growing small-business payments line. For years, once a year, the chief information security officer brought them a tidy summary from the CAT. It said, in effect, “Here is how risky our business is, and here is how mature our defenses are, and the two are in reasonable balance.” Directors did not need to understand firewalls to follow that logic. The tool turned a technical subject into a question of proportion that any board could weigh.

When the CAT was retired, most of the discussion was about which framework to adopt next. That question has sensible answers and plenty of consultants and software vendors ready to help. A less visible loss deserves more attention. The tool had two halves. The second half, the maturity assessment, has many substitutes. The first half, the inherent risk profile, has almost none. It was the step that told a community bank, before any control was scored, how much security its business model demanded.

The decisions about that first half belong to executives and boards as much as to the security team, and an institution can rebuild the sizing step on ground it owns.

Frameworks, controls, maturity and inherent risk

Four terms carry most of the weight in this story, and each is simpler than it sounds.

A cybersecurity framework is an organized list of the things a security program should achieve, grouped into themes such as identifying what you own, protecting it, detecting attacks, responding and recovering. A framework does not say how hard your bank should work on each theme; it says what the themes are.

A control is any safeguard that reduces risk: requiring a second login factor, reviewing who has access to the core banking system, testing backups, training staff to spot phishing emails. Controls are what a security program actually does day to day.

Maturity describes how well and how consistently those controls are performed. A bank where one diligent employee reviews access whenever she remembers is less mature than one where the review happens on a schedule, is documented and is checked by someone else.

Inherent risk is the exposure a business carries before any controls are applied, simply because of what it does. A bank that moves large business payments, connects to dozens of outside vendors and runs a mobile app has more inherent risk than one that takes deposits and makes local loans through a few branches. The comparison many executives find useful is insurance: two homes may have the same locks and alarms, but the house on a floodplain carries more inherent risk than the one on a hill, and it needs more protection to reach the same level of safety.

The CAT’s great virtue was that it measured inherent risk and maturity separately, then put them side by side.

What the risk profile did

The inherent risk profile asked an institution to rate its activities in five categories. They were technologies and connection types, delivery channels, online and mobile products and technology services, organizational characteristics, and external threats. Each activity was placed on a scale from least to most risk. A bank with a handful of branches, no mobile deposit and a single core processor would land low. A bank offering business payments, many vendor connections and a fintech partnership program would land much higher.

A core processor, for readers who have not had to sign one of those contracts, is the company that runs a bank’s central ledger system, the “core,” which records every account, balance and transaction. Many community banks rent this capability from a specialist provider rather than building it. Every outside system that connects to the core is another way into the bank’s most valuable system, which is why the number and type of connections mattered so much in the profile.

The maturity half then had a built-in benchmark. The tool’s guidance expected maturity to rise as inherent risk rose. A low-risk bank at Baseline maturity could defend that position. A high-risk bank at the same level had a visible gap. That pairing gave boards and examiners a simple test of proportionality. The interagency information security standards under the Gramm-Leach-Bliley Act ask for exactly that: a program appropriate to the institution’s size, complexity, and the nature and scope of its activities.

The profile also forced change to show up. Launching instant payments, adding an API channel or acquiring a branch network moved specific ratings. A bank could see its required maturity drift upward before an incident made the case.

An API, short for application programming interface, is a doorway through which one computer system talks directly to another without a person in between. When a bank lets a fintech app or a business customer’s accounting software pull balances or send payment instructions automatically, it does so through an API. It is convenient, it is how modern banking partnerships work, and it is also a new route by which something can go wrong at machine speed. The old profile made a bank stop and count such doorways.

Why the replacements do not supply it

NIST’s Cybersecurity Framework 2.0 is a strong structure for describing outcomes. It asks organizations to build a current profile and a target profile. It does not tell them where the target should sit. Its tiers, from Partial to Adaptive, describe the rigor of risk governance practices, not the exposure created by a business model. An institution can pick a modest target and still be internally consistent.

In everyday terms, the NIST framework asks an institution to write down its current condition and its goal, and is silent on how ambitious the goal should be. That depends on the institution’s circumstances, and the framework leaves it to them.

CISA’s Performance Goals go the other way. They are a common baseline intended for organizations of every size, so they say little about what a more exposed institution needs beyond the floor. They set a floor that is essential, and offer no help in deciding how far above it a particular institution should go.

The Cyber Risk Institute’s Profile, built for financial firms on the NIST structure, comes closest. It begins with a tiering questionnaire that scopes which diagnostic statements apply. Its tiers center on an institution’s potential impact on the financial sector and its customers, which is related to exposure but is not the same thing. Two community banks of similar size may tier alike under that approach while carrying very different attack surfaces. Credit unions that keep using the NCUA’s toolbox retain a version of the original profile, which makes their position simpler for now.

“Attack surface” is security shorthand for the total set of places where an attacker could try to get in: every website, app, vendor link, remote login and payment channel. Two banks with identical balance sheets can have very different attack surfaces if one has added three fintech partners and an open API program while the other has not.

The result is a gap at the start of the process. Many banks moved to a new framework in 2025 and kept scoring controls, but stopped asking how much control their activities required.

Budgets, examiners and strategy

Three reasons put this squarely on executives and directors rather than the security team.

The first is money. Security budgets are hard to size. Without a documented link between what the bank does and what it needs to defend, budget conversations drift toward last year’s number plus a little, or toward whatever the most persuasive vendor proposed. The old profile gave a reason for spending to rise when the business took on new exposure, and an equally good reason for it not to.

The second is regulatory. The interagency standards already require a risk assessment that reflects the institution’s activities. Examiners will continue to ask how the program fits the bank. A bank that can show a clear line from its products and connections to its security targets has an easy conversation. A bank that can only show a scorecard against a framework, with no explanation of why the targets sit where they do, has a harder one.

The third is strategic. Community banks are adding instant payments, embedded finance and fintech partnerships to compete. Each of those decisions is approved on revenue and customer grounds. If nobody is asking at the same moment what the new product does to the bank’s security requirements, the gap only appears later, often in an incident review.

Suppose a regional bank with modest technology signs a partnership with a payments fintech in the spring. The deal is approved by the credit and product committees. The fintech connects to the bank’s core through an API with permission to initiate transfers. Under the old CAT, that connection would have pushed several inherent risk ratings upward, and the annual report to the board would have shown that detection and third-party oversight needed to mature to match. Under a framework scorecard with a fixed target, nothing in the security report changes. The controls are scored exactly as before, and they look fine, because nobody raised the bar.

How to rebuild the sizing step

The fix does not require a new tool. It requires putting the exposure inventory back inside the institution’s own information security risk assessment, where the interagency standards already locate it. That assessment is an obligation in its own right, separate from any framework choice.

A practical rebuild has three pieces. The first is an exposure register that tracks the drivers the old profile captured, in the institution’s own terms: payment rails offered, such as wires, ACH and instant payments; customer channels and APIs; third-party connections into the core; fintech and banking-as-a-service partners; and recent mergers or conversions. Each entry needs an owner in the business line, because the security team rarely hears about a new channel first.

“Payment rails” simply means the networks that move money: wire transfers, the ACH network that handles direct deposits and bill payments, and newer instant payment services that settle in seconds. Each has its own fraud patterns and its own speed, and faster rails leave less time to catch a mistake. Banking-as-a-service is an arrangement in which a bank lets a non-bank company offer accounts or payments to its own customers using the bank’s charter and systems behind the scenes.

The second is a rule that links the register to the framework target. A bank might decide that offering instant payments raises its target for detection and response outcomes, or that any third-party connection with write access to the core raises its target for supply chain risk management. The rules can be simple. What matters is that the target follows from documented exposure, so a reviewer can trace why it sits where it does.

“Write access” is worth pausing on. A connection with read access can look at data; one with write access can change it, including moving money or altering records.

The third is a trigger. New products, channels and vendors should pass through the register before launch, through the new product and third-party approval processes most banks already run. That restores the early warning the old profile gave, while it can still change a design.

Keeping the register honest

A well-run version of this is unglamorous. The register is a short document or simple database, reviewed quarterly, with a named business owner beside each line. The rules linking exposure to targets fit on a page. The board sees a one-page view each year showing what changed in the business, how that moved the targets, and whether controls kept pace.

The trade-off is effort. The CAT came with categories already written. A home-built register needs maintenance, and it can be gamed by an institution that wants a low target. Internal audit should test it the way it tests any risk assessment: by checking that known products and vendors appear in it and that ratings moved when the business changed.

Four failures recur. One is treating the framework choice as the whole project, so that a great deal of effort goes into mapping controls to a new structure while the question of how high the bar should be is never asked. Another is letting the security team own the register alone; it will always be the last to hear about a new partnership. A third is a register that never changes. If the bank launched products and signed vendors during the year and the ratings stayed the same, the register is decoration. A fourth is setting targets once, at adoption, and never revisiting them, which recreates, unnoticed, the fixed bar the old profile was designed to prevent.

Credit unions have one extra task. Those still using the NCUA’s toolbox keep a version of the original risk profile, which is convenient, but they should understand how it relates to any other framework they adopt, so the two do not tell different stories.

What directors can ask

Directors and executives do not need to master any framework to keep this on track. A handful of simple questions will reveal whether the sizing step survived the transition.

• Since the CAT was retired, what tells us how much security our business model requires, as distinct from how well our controls are performing?
• Can you show me a list of our payment rails, customer channels, APIs, core connections and fintech partners, with a business owner for each, and which of those connections can change data or move money in the core?
• When we approved our last new product or partnership, did anyone check what it did to our security targets, and where is that recorded?
• How do our framework targets follow from our exposure, and could an examiner trace why each one is set where it is?
• Has internal audit tested the risk assessment for completeness, and did any ratings move when the business changed this year?

The retirement of the CAT was a sensible housekeeping decision by regulators. Better frameworks exist, and banks have more choice than before. But a bank that adopts a framework without sizing its inherent risk can keep scoring controls against a bar that is too low. The institutions that come through this well will be the ones that kept asking the question the old tool asked first: given what we do, how much protection do we need?

With hindsight

A year on, the transition looks orderly from the outside. Examinations continued through late 2025 and 2026 under existing procedures and the FFIEC IT Examination Handbook, and institutions presented assessments built on a range of frameworks, including NIST CSF 2.0 and the CRI Profile. The NCUA kept its toolbox available to credit unions and continued to update it. We have not seen evidence of examiners penalizing any particular framework choice, which is consistent with supervisors’ statements that they did not endorse any one tool.

That is reassuring for anyone who worried that choosing the “wrong” framework would bring trouble. The choice of structure turned out to matter less than many expected. What matters more is whether the program fits the institution, which is what the Federal Reserve said in the first place when it asked that tools be commensurate with risk.

The sizing gap is harder to observe from outside, because it shows up as targets that never move rather than as findings. A bank can score itself diligently against a new framework year after year and look steady, even as its business has changed underneath it. No alarm sounds. The problem is visible only when someone compares the list of new products and partners with the security targets and notices that one moved and the other did not.

Institutions that wired product and vendor approvals into their risk assessment kept a link between business change and security investment. Those that only swapped scoring frameworks kept measuring controls without a clear view of how much control their business model needed.

The retirement of a tool is a good moment to check what the tool was doing in the background. The CAT’s most valuable function was never the scorecard. It was the habit of asking, before anything was scored, how much risk the bank had taken on. That habit can survive any framework choice, but only if someone deliberately keeps it, gives it an owner in the business, and has internal audit confirm it is still working.