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 voluntary 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.

This is a heavier change for a small institution than a large one, and not for the reason most people assume. A regional bank had a GRC function that treated the CAT as one input among several; removing it cost them a cross-reference. A community bank often used the CAT as the programme — it was the annual cybersecurity exercise. For them the retirement removed the scaffolding, not a document.

Choosing your spine

Three options are defensible. Pick one, write down why, and move on — the deliberation is worth an hour, not a quarter.

NIST Cybersecurity Framework 2.0. The default for most community banks. Free, published February 2024, and its PR.AA category covers identity management, authentication and access control as a first-class function rather than a subsection. Nearly every security vendor publishes a CSF mapping, so your existing tooling reports probably already carry the crosswalk. Its weakness is that it is sector-neutral: nothing in it tells you a core processor integration deserves particular scrutiny.

The Cyber Risk Institute Profile. Built for financial services, and its distinguishing feature is that regulatory citations are already attached to each diagnostic statement. If your board asks “which rule requires this,” the Profile answers without a second lookup. It is heavier than CSF and assumes more security vocabulary in the room.

The Handbook directly. Viable for genuinely small institutions. You skip the translation layer and answer against the same material the examiner is reading. The cost is that you get no structure for anything outside IT examination scope, and no vendor will hand you a pre-built mapping.

The wrong move is adopting two and maintaining neither. A half-finished CSF mapping alongside a half-finished Profile is worse than either alone, because it signals activity without producing an answer.

The three identity questions that survive any framework

Whatever spine you choose, an examination of access control comes back to these. Each one has a specific artifact that answers it.

1. Is authentication layered by risk, or flat?

Layered authentication means the challenge scales with what the user is trying to do. Higher-risk actions — moving funds, changing a profile, altering an entitlement, adding a payee — 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 rather than the presence of a strong control. The institution that applies one prompt to everything has not decided which actions are risky; it has declined to decide.

What is testable, and what you should be able to produce:

• A written policy tiering actions by risk, with the tiers mapped to specific transaction types rather than to job titles
• Step-up authentication triggered by device, location and session signals, not by role alone
• Sampled session logs showing the step-up challenge actually fired for a high-risk action on a named date
• The exception list — the actions that should trigger step-up but do not, with a reason and an owner

The fourth item is the one institutions skip, and it is the one that turns a finding into a conversation. An examiner who sees a documented, owned exception reads a programme. An examiner who finds an undocumented gap reads an accident.

2. Can you account for every privileged action?

Not “do you have a privileged access tool.” The question is narrower and harder: 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. When four people know the password to the same account, no log can attribute the action, and no subsequent control compensates. This is why the remediation sequence below puts elevation ahead of everything except the inventory.

The follow-up question is usually about standing access: how many accounts hold administrative rights right now, without asking anyone. In most community banks the honest number is two to three times what the IT lead estimates, because service accounts, vendor accounts and the personal accounts of people who once needed elevation are all counted late.

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, with rights that made sense for a migration and were never reduced afterwards.

Examiners increasingly sample these directly, and the sample is unkind because it is easy to run: take the vendor list from the contracts file, take the account list from the directory, and compare. Mismatches in either direction are findings. An account with no contract is the obvious one. A contract with no corresponding account is also worth explaining, because it usually means access is being shared through somebody else’s credential.

What it actually takes

For a bank with a two or three person IT function, this sequence produces the most defensible position for the least effort. The ordering matters more than the completeness — step two is what makes steps three through five possible.

1. 1

   Choose one spine and write it down

   1 day

   NIST CSF 2.0 for most institutions, the CRI Profile if you want regulatory citations pre-attached. Record the decision and the reason in one paragraph. 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. Include service accounts and vendor accounts. 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, or it will be routed around.

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. A control that detects a violation after the payment left is not a control.

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. Run the comparison in both directions.

6. 6

   Write the mapping down and date it

   2–3 days

   One page per framework function, naming the control, the system that enforces it, and the query that evidences it. Undated mappings get treated as aspirational; a dated one gets treated as a programme.

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

The part nobody budgets for

Every institution that does this discovers the same thing in week two: a category of access that nobody can categorise. A shared login used by the branch network. A vendor account that also serves as the backup path for a nightly job. An administrator account that predates the current directory and cannot be disabled because something unnamed depends on it.

These are not edge cases; they are the normal output of a decade of operations. Budget for three or four of them, and resist the urge to leave them out of the inventory because they are inconvenient. An examiner who finds one you did not list has a different conversation than an examiner reading your own note explaining why it still exists and what you are doing about it.

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 Handbook’s authentication and access material, ranked by risk reduction per engineering hour, and an honest note on what no automated check can cover.