If your team has been through an FFIEC IT exam, you’ve probably seen this play out: the hardening standard exists in an internal company document, but nobody can show, on request, that every in-scope server is still configured to it six months later. That gap is where most configuration management findings in failed audits come from.
This page covers what examiners are actually testing for in FFIEC configuration management, what changed in late 2025 that affects how exams are scoped.
FFIEC Basics, Briefly
FFIEC is a council comprised of the Fed, FDIC, OCC, NCUA, CFPB, and state banking regulators that publishes the IT Examination Handbook, a set of booklets examiners use to assess IT risk at banks and credit unions. There’s no FFIEC certification. Your prudential regulator examines you against the Handbook’s expectations as part of your normal exam cycle; there’s no separate FFIEC pass/fail event.
The Information Security and Operations booklets are the ones that touch configuration management directly. Examiners use the URSIT rating system (Uniform Rating System for Information Technology) to score what they find.
What Changed: OCC Bulletin 2025-24
On October 6, 2025, the OCC issued Bulletin 2025-24, eliminating mandatory policy-based examination requirements for community banks (assets under $30 billion), effective January 1, 2026. Examiners no longer have to run fixed-frequency procedures just because OCC policy says so. Instead, they scope exams to the institution’s actual size, complexity, and risk profile, with a stated focus on material financial risk.
For configuration management, the practical implication is that institutions should be prepared to explain not only what controls they have in place, but why those controls are appropriate for their specific risk profile. As examiners move toward a more risk-based approach, they have greater discretion to focus on areas that present higher risk rather than following the same examination activities every cycle. That makes documented risk assessments, clearly defined scope, and evidence that configuration controls are operating as intended increasingly important. A bank that can point only to a policy but cannot explain how it determined the scope of its controls or demonstrate that those controls are consistently enforced may face more scrutiny during an examination.
(It’s important to note that OCC Bulletin 2025-24 applies to OCC-supervised national banks and federal savings associations. While other regulators, including the NCUA, also use risk-based examination approaches, this specific bulletin does not apply to federally insured credit unions.)
What the Handbook Requires in Practice
“Management should ensure that systems and software used to support the operations of the entity not only have appropriate configuration management capabilities, including configuration of audit log settings, but that the configuration management is enforced.”
FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations booklet
The word “enforced” is where most institutions lose points.
Examiners distinguish between a documented baseline and a verified one. In practice they’re checking for:
- A defined, current security baseline mapped to system roles (not only a generic CIS benchmark)
- Evidence that baseline is still in place on production systems, not just at initial deployment
- Change control: who can alter a configuration, and a log of when they did
- Detection and response for configuration drift not just monitoring, but a documented response when drift is found
- Independent testing or validation, separate from whoever manages the systems
- A traceable line from risk assessment to control to monitoring result — this is the part OCC Bulletin 2025-24 makes more important, not less
Where Exams Go Wrong: The Evidence Gap
The most common finding is a control that exists on paper and can’t be demonstrated in the room.
A typical exam scenario: the examiner asks for evidence that a specific hardening standard — say, disabling SMBv1 or restricting RDP — is enforced across all in-scope servers. The IT team pulls up the policy document. The examiner asks for the configuration state of the actual servers, today, not the policy intent. If that requires someone manually checking a sample of machines and hoping nothing drifted since the last GPO push, that’s the gap. Examiners are trained to ask for exactly this kind of evidence, and “we have a policy” is not an answer to “show me the systems.”
This is where sampling can become a problem. If an examiner reviews 15 servers out of 200 and finds three that don’t meet the approved baseline, the real question becomes whether the institution can demonstrate that the other 197 are configured correctly.
Checklist: What You Should Be Able to Produce on Request
- Current, documented security baseline mapped to specific system roles (e.g., domain controllers, SQL hosts, file servers — not one generic baseline applied uniformly)
- Point-in-time configuration state evidence (scan output, GPO reports, or agent-collected data) showing the baseline is enforced in production, not just defined in policy
- Change log with timestamp, user/service account, modified setting, and before/after value for every configuration change
- Drift detection with alert-to-remediation latency tracked, plus a documented remediation workflow (not just an alert firing into an inbox)
- Independent validation of configuration state by a function separate from the team managing the systems (internal audit, a different ops team, or automated third-party attestation)
- Documented mapping from risk assessment findings to specific control scope decisions, with rationale for inclusions and exclusions
- Audit-ready evidence package organized by system/asset ID, with timestamped exports, not scattered across tickets, spreadsheets, and email threads
- Download CalCom’s system hardening checklist
For MSPs and IT Services Firms Managing Bank Clients
If you manage IT for community banks or credit unions, FFIEC exam findings are your problem too. The institution’s examiner doesn’t care that hardening is outsourced. What changes for MSPs under the post-2025 exam approach: institutions are going to ask you for documented risk reasoning behind your configuration choices, not just a list of what’s hardened. If you’re managing configuration drift across multiple bank clients manually, the sampling risk described above multiplies per client. CHS gives MSPs a single console to enforce and prove baseline state across every client environment without per-client manual checks.
How CHS Helps
CalCom Hardening Suite automates server and system hardening by enforcing approved security baselines, continuously monitoring for configuration drift, and generating the evidence examiners want to see: current configuration state, change history, and validation that production systems match approved policy. Learning Mode lets you preview the impact of a policy change before enforcement, reducing the risk of unintended outages while supporting disciplined change management.
CHS isn’t a governance, risk, and compliance (GRC) platform. It doesn’t write risk assessments, manage incident response, or replace independent audits or regulatory examinations. If you need policy management, board reporting, or third-party risk management, those remain part of your broader compliance program.
What CHS does is help solve one of the most common challenges institutions face during an examination: demonstrating that secure configuration policies are consistently implemented across production systems. Instead of relying on manual checks and point-in-time evidence, organizations can show continuous enforcement, ongoing monitoring, and a clear audit trail—making it easier to demonstrate that policy and production stay aligned over time.
Configuration evidence is the most common gap between a passed and flagged FFIEC exam. If you want to see what CHS captures automatically and compare it to what your team is still pulling together by hand, contact us to talk to an expert.
