FFIEC / OCC Modernization & Remediation

When a banking examiner reviews an institution’s IT, the conversation almost always finds its way to the oldest system on the floor — the core platform on an unsupported version, the patching that lags, the change process that lives in a binder. Examiners aren’t grading the technology for its own sake. They’re assessing whether the institution can manage the risk that system carries. And a system the vendor no longer supports is hard to defend in that conversation.

The accurate framing matters here more than most, because so much of this is guidance rather than statute. FFIEC and OCC cybersecurity expectations are examination and supervisory guidance — outcome-based, technology-neutral, and tuned to your size and complexity. They do not name a stack, and they do not require modernization. They ask you to manage risk to a level the institution can stand behind, and they leave the means to you.

What FFIEC and OCC guidance actually requires of your systems

The FFIEC — the interagency body whose members include the OCC, Federal Reserve, FDIC, NCUA, and CFPB — publishes the IT Examination Handbook, a set of booklets that guide examiners assessing an institution’s IT and information-security program. The Information Security booklet sets the supervisory expectations: an effective, risk-based information-security program with access controls, change management, monitoring, resilience, and vendor oversight, assessed against the institution’s risk profile.

The OCC, which supervises national banks and federal savings associations for safety and soundness, layers on heightened standards for the largest institutions — risk-governance-framework and board-oversight expectations under its guidelines. (A note on accuracy: the asset threshold for those heightened standards has historically been a fixed figure, but the OCC has moved to raise it in 2025–2026, so the current number should be verified against the live rule before anyone relies on it.)

A concrete recent change worth knowing: the FFIEC sunset its Cybersecurity Assessment Tool (CAT) on August 31, 2025, declining to update it for newer frameworks and pointing institutions instead toward resources like the NIST Cybersecurity Framework, the Cyber Risk Institute Profile, and the CIS Critical Security Controls. There is no single mandated replacement — the expectation is that you choose an assessment approach appropriate to your risk.

The throughline: these are supervisory expectations about outcomes and risk management. None of them orders modernization. All of them make an unsupported, poorly controlled system a problem an examiner will press on.

Where legacy systems fail the requirement

A legacy banking system draws examiner scrutiny for recurring reasons:

• Unsupported software — an end-of-life core or database the institution can’t patch is a standing safety-and-soundness concern.
• Weak patching — slow or incomplete remediation that monitoring and exam testing surface.
• Brittle change management — manual deployments and thin approval trails that the IT-operations expectations don’t credibly cover.
• Limited resilience and monitoring — systems that were never instrumented for the detection and recovery examiners expect.

How we remediate it

We treat an exam finding the same way we treat any legacy system: a sequence of small, reversible steps, not a single risky cutover that puts a core banking platform at risk.

A strangler facade sits in front of the system so the legacy path and the modernized path run side by side. The part of the system the examiner is focused on moves in bounded slices rather than all at once, and before any slice carries live transactions, we prove it behaves identically to the legacy — same results, same state, reconciled record by record. The modernized slice runs on a supported, patchable platform with real access control, change management, and monitoring built in — so the controls examiners assess become properties of the system rather than promises in a binder. AI-accelerated discovery reads the application, the data, and the integration surface end to end and captures what the system actually does — including the undocumented logic the original authors never wrote down — as a living spec under senior-engineer review, which is itself the documentation an examiner wants to see. Traffic shifts only on green, rollback stays a flag away, and the legacy system carries the institution’s risk only until nothing depends on it.

Sometimes the fix is procedural

Modernization is not the first answer to most exam findings, and we’ll say so plainly. Much of what examiners want is risk management and documentation — a tightened patching program, a formalized change process, better monitoring — that can be built around existing systems. For a stable, well-controlled platform, the remediation is usually procedural. The slice-by-slice approach earns its place when an unsupported core can no longer be patched at all, when the system can’t take the downtime your customers depend on, or when the same platform is drawing scrutiny across FFIEC, OCC, and other obligations at once. And we’ll never tell you FFIEC or OCC guidance requires modernization — it doesn’t, and most of it isn’t even statute. It sets expectations a legacy system makes hard to meet, and modernization is the answer only when the cost of meeting them around the old system exceeds the cost of the fix.

Where to start

The first step is small and bounded: understand which systems your examiners are focused on, which expectations they strain to meet, and whether the right move is risk-management remediation or modernization. A discovery call scopes your exam-relevant systems and tells you where each path is warranted — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.