The FFIEC Retired the CAT. What Community Banks Should Map Identity Controls To Now

What this changed, and what it did not

The CAT was never a rule. It was a self-assessment with maturity levels that many institutions used as a proxy for readiness, and that examiners frequently asked to see. Its value was that it produced a filled-in artifact.

Losing it changes one thing: you no longer have a default structure to answer from. The obligations behind it sit in the Handbook and are untouched.

The three identity questions that survive any framework

Whatever spine you choose, an examination of access control comes back to these.

1. Is authentication layered by risk, or flat? Higher-risk actions — moving funds, changing a profile, altering an entitlement — should require more than low-risk reads. Uniform multi-factor authentication everywhere is not layering; it is a flat wall, and it reads as an absence of risk analysis. What is testable: risk-tiered policies mapped to action classes, step-up triggered by device and session signals rather than role alone, and sampled sessions showing the challenge actually fired.

2. Can you account for every privileged action? Not “do you have a privileged access tool.” Can you show that one specific administrative action, on one specific date, was requested, approved, scoped and recorded. Shared administrator credentials remain the most reliable way to fail this, because they make the question unanswerable rather than merely unanswered.

3. Do third parties hold more access than their contract? Vendor accounts accumulate. The pattern is not malice; it is a core processor integration set up in 2019 by someone who has since left. Examiners increasingly sample these directly.

What it actually takes

For a bank with a two or three person IT function, this is the sequence that produces the most defensible position for the least effort.

1. 1

   Choose one spine and write it down

   1 day

   NIST CSF 2.0 for most institutions. The decision is worth an hour of discussion and no more — the value is in having one mapping, not in the choice between two reasonable ones.

2. 2

   Inventory privileged accounts honestly

   1 week

   Every account that can change an entitlement, move money, or reset another account, across the core platform, the directory and the cloud console. Expect the number to be two to three times what anyone estimates.

3. 3

   Replace permanent admin access with access on request

   4–6 weeks

   Elevation with a short window, an approver, and session recording. The reason previous attempts failed is that the compliant path was slower than the workaround — so make requesting access faster than it was before.

4. 4

   Move separation of duties into the access system

   2–3 weeks

   The initiate-and-approve conflict should be impossible to hold, blocked at the point of request, rather than caught in a quarterly spreadsheet reconciliation.

5. 5

   Scope vendor access to contract

   1–2 weeks

   List third-party accounts, compare each against what the contract covers, cut back, add expiry dates and annual re-confirmation.

The mapping itself is a few days of work. The remediation it exposes is the real cost — and it is why doing the inventory before an examination is scheduled is worth more than any document you could write afterwards.

Where vaultIAM fits

We assess identity risk read-only against the platforms you already run, publish the query list before asking for access, and score ten categories weighted for banking — where permanent privilege, authentication strength and access certification carry the most.

You get findings mapped to the Authentication booklet and InfoBase VI.A.3, ranked by risk reduction per engineering hour, and an honest note on what no automated check can cover.