FFIEC Cybersecurity Assessment: What Community Banks Get Wrong

Financial services recorded 739 data compromises in 2025, more than any other sector for the second straight year. The Marquis Software breach alone cascaded through 80 community banks and credit unions after attackers exploited a single unpatched SonicWall firewall, exposing up to 1.35 million customer records. One vendor. One vulnerability. Eighty institutions explaining the damage to their boards.

That breach landed six months after the FFIEC officially retired its Cybersecurity Assessment Tool on August 31, 2025. The framework community banks relied on for nearly a decade is gone. Regulators still expect formal cybersecurity maturity measurement, but they stopped providing the standard measuring stick. Banks now choose among NIST CSF 2.0 (adopted by 67% of financial institutions), the CRI Cyber Profile (purpose-built for banking but only at 12% adoption), and several other frameworks with no single mandated replacement.

Meanwhile, the bar keeps rising. The NCUA's 2026 supervisory priorities now require annual board cybersecurity training, IT risk assessments evaluated against eight specific criteria, and scenario-specific incident response playbooks covering ransomware, business email compromise, and vendor breaches. Generic procedures no longer pass examination. The OCC created a new Senior Deputy Comptroller for Information Technology and Security, elevating IT oversight to a top-level position for the first time.

If your bank is still working from last year's CAT spreadsheet, the problems this article covers haven't gone away. They've gotten harder to document, harder to measure, and harder to explain to examiners using a framework that no longer exists. Here's what community banks get wrong on their cybersecurity assessment and what regulators are looking for now.

Most community banks complete their FFIEC cybersecurity assessment the same way every year. Someone in IT or compliance pulls out last year's spreadsheet, updates a few dates, checks a few more boxes than before, and calls it done. The board reviews it. The file gets saved. Everyone moves on.

Then the examiner shows up and starts asking questions the spreadsheet can't answer.

The FFIEC Cybersecurity Assessment Tool wasn't built to be a checkbox exercise. It's designed to surface real gaps between your bank's risk exposure and your security capabilities. But the way most community banks approach it turns a useful diagnostic into a compliance fiction. They overstate their maturity, skip the hard parts, and produce documentation that falls apart under examiner scrutiny.

After working with thousands of financial institutions on their cybersecurity posture since 1999, ABT has seen the same patterns repeat. Here's what community banks get wrong on their FFIEC cybersecurity assessment and how to fix it before your next exam.

Note: While this article focuses on community banks, the FFIEC framework applies to all financial institutions. Credit unions examined by the NCUA (National Credit Union Administration) and mortgage companies subject to the FTC Safeguards Rule face equivalent cybersecurity assessment requirements.

What the FFIEC Cybersecurity Assessment Actually Measures

Before getting into what banks get wrong, it helps to understand what the FFIEC cybersecurity assessment framework actually tests. The specific CAT tool was retired in August 2025, but its five-domain maturity model remains the foundation for replacement frameworks like NIST CSF 2.0 and the CRI Cyber Profile. Regardless of which framework your bank adopts, the assessment has two parts that work together, and most banks treat them as separate exercises.

Part 1: Inherent Risk Profile

This section measures your bank's risk exposure based on what you do and how you operate. It evaluates five categories: technologies and connection types, delivery channels, online and mobile products, organizational characteristics, and external threats. A bank with mobile deposit capture, wire transfer capability, and 15,000 deposit accounts has a higher inherent risk profile than a bank offering only in-branch services.

The inherent risk profile determines the minimum maturity level your bank should achieve. This is the part most banks rush through, and it's the part that sets the bar for everything else.

Part 2: Cybersecurity Maturity

The maturity assessment covers five domains:

• Cyber Risk Management and Oversight -- board engagement, risk appetite, staffing, and budget allocation
• Threat Intelligence and Collaboration -- how you gather, analyze, and act on threat information
• Cybersecurity Controls -- preventive and detective controls across infrastructure, access management, and data protection
• External Dependency Management -- vendor oversight, third-party connections, and outsourced services
• Cyber Incident Management and Resilience -- planning, detection, response, and recovery

Each domain has maturity levels from baseline through innovative. Your maturity scores across these five domains get compared against your inherent risk profile. If you're a "moderate" risk bank sitting at "baseline" maturity, you have a documented gap that examiners will flag.

Why "Baseline" Maturity Isn't Good Enough for Most Community Banks

Baseline is the floor, not the target. It represents the minimum expectations that all financial institutions should meet. The FFIEC explicitly states that baseline maturity is the starting point, and banks with elevated risk profiles need to demonstrate maturity above baseline.

Here's where community banks fool themselves. Many look at baseline requirements, confirm they meet most of them, and declare the FFIEC maturity assessment complete. But if your bank offers online banking, mobile deposit, wire transfers, or automated clearing house (ACH) origination, your inherent risk profile is almost certainly "moderate" or higher. A moderate risk profile paired with baseline maturity is a gap your examiner will document.

Think of it this way: baseline maturity for a bank with moderate inherent risk is like passing a driving test but only knowing how to drive in a parking lot. You've met the minimum technical requirements, but you aren't equipped for what you'll actually encounter.

The target for most community banks with modern product offerings is "evolving" maturity across all five domains, with "intermediate" maturity in their highest-risk areas. Getting there requires deliberate investment in controls, processes, and documentation that go beyond baseline checkbox items.

Five Mistakes Community Banks Make on the FFIEC CAT

1. Underrating Inherent Risk

Banks routinely score their inherent risk lower than it actually is. They skip categories, minimize the complexity of their technology connections, or don't account for all delivery channels. A bank running mobile deposit capture through a third-party fintech integration has a different risk profile than one offering branch-only services, but the self-assessment might not reflect that.

Examiners notice. If your inherent risk profile seems low relative to your product set, they'll recalculate it themselves. When they arrive at a higher risk level, every maturity score you reported becomes insufficient.

2. Copy-Pasting Last Year's Assessment

The FFIEC cybersecurity assessment community bank teams complete each year should reflect current conditions. Threat landscapes change. You added new products. Your IT vendor changed. But many banks treat the CAT as a static document, updating dates while leaving the substance untouched.

Examiners compare your current assessment against previous versions. If the language is identical year over year but your environment has changed, that inconsistency becomes a finding.

3. Confusing Policy Existence With Implementation

Having a policy doesn't mean it's enforced. A community bank cybersecurity assessment might claim "multi-factor authentication is required for all remote access," but the examiner will check whether MFA is actually enforced across every remote access path. If three employees bypass MFA because of a legacy VPN exception, your stated control doesn't match your actual posture.

This happens constantly with Conditional Access policies in Microsoft 365. Banks write policies that sound comprehensive but configure them with so many exceptions that the policy is effectively hollow.

4. Ignoring External Dependency Management

Domain 4 (External Dependency Management) is where community banks score lowest. Most banks have no formal process for assessing their third-party IT providers' security posture. They don't collect SOC 2 reports from their core processor. They don't review their online banking vendor's penetration test results. They don't have service-level agreements that include security incident notification requirements.

Your IT provider, core banking system, online banking platform, card processor, and every fintech integration you've adopted are all external dependencies. The FFIEC CAT community bank assessment expects documented oversight of each one.

5. Treating the Assessment as IT's Problem

The FFIEC CAT is a bank-wide risk assessment, not an IT checklist. Domain 1 explicitly evaluates board and senior management engagement in cybersecurity governance. When the compliance team hands the entire assessment to IT and walks away, the bank misses the governance, risk appetite, and oversight components that examiners weight heavily.

Board meeting minutes should reflect cybersecurity discussions. Senior management should sign off on risk appetite statements. The bank's strategic plan should address cybersecurity investment. These aren't IT deliverables. They're governance obligations that affect your maturity scores.

Having Controls vs. Evidencing Controls

This is the gap that catches community banks off guard. Your bank might have strong security controls in place. You might have login and access policies (Conditional Access) configured correctly, threat detection software (EDR) running on every endpoint, and rules preventing sensitive data from leaving your organization (Data Loss Prevention, or DLP). But if you can't produce evidence that these controls work, have been tested, and are reviewed regularly, the examiner treats them as unverified.

Banking cybersecurity compliance isn't about what you've deployed. It's about what you can prove.

What Evidence Looks Like

• Access reviews: Quarterly reviews of who has access to what, with documented approval and revocation records. Not "we review access." Dated reports showing who reviewed, what they found, and what was changed.
• Patch management records: Monthly reports showing patch deployment timelines, success rates, and exceptions. If you have 200 endpoints and 4 failed to patch, the report should show why and when they were remediated.
• Incident response testing: Annual tabletop exercises with documented results, lessons learned, and plan updates. The plan itself isn't evidence. The test results are.
• Configuration baselines: Documented security configurations for your Microsoft 365 tenant, endpoints, and network infrastructure, with regular compliance checks showing drift and remediation.
• Vendor due diligence files: Completed vendor risk assessments, SOC 2 report reviews, and tracking of identified risks for each critical third party.

ABT's Guardian platform automates much of this evidence collection by continuously monitoring Microsoft 365 tenants against 100+ security benchmarks. It produces the configuration compliance reports and drift tracking that examiners expect, without your team manually compiling spreadsheets before each exam.

How Your IT Provider Affects Your FFIEC CAT Score

Your managed IT provider's capabilities directly determine what maturity levels you can achieve. Here's why.

Most controls in Domains 3 (Cybersecurity Controls) and 4 (External Dependency Management) are IT controls. Access management, endpoint security, network monitoring, encryption, data loss prevention, vulnerability management. If your IT provider doesn't implement and monitor these controls, you can't claim them on your assessment.

A community bank using a generic managed service provider (MSP) that sells antivirus and break-fix support will struggle to score above baseline in Domain 3. There's no continuous monitoring. There's no security information and event management (SIEM). There's no automated compliance reporting. The controls simply don't exist at the level the CAT measures.

Providers who specialize in managed IT services for community banks build their service around the FFIEC framework. They configure controls that map to specific maturity domains, generate evidence reports that examiners expect, and track your maturity progression over time.

Questions to Ask Your Provider

• Can you map your services to the five FFIEC CAT domains?
• What maturity level do your standard controls support?
• Do you produce evidence reports for examiner review?
• How do you monitor for control drift between exams?
• Do you hold SOC 2 Type II attestation?

If your provider can't answer these questions with specifics, your FFIEC cybersecurity assessment community bank maturity claims don't have a foundation.

What Examiners Actually Look For When Reviewing Your Assessment

Bank examiners don't just read your CAT spreadsheet and accept it. They test it. Understanding how examiners approach the FFIEC cybersecurity assessment community bank teams submit helps you prepare one that holds up under scrutiny.

Consistency Checks

Examiners compare your inherent risk profile against your product set, delivery channels, and technology environment. If you claim "minimal" risk but offer mobile banking, online bill pay, and person-to-person payments, they'll recalculate your risk themselves.

They also compare maturity claims against evidence. If you claim "evolving" maturity in threat intelligence but can't show them your threat intelligence sources, analysis process, or how threat information influenced a security decision, the claim collapses.

Evidence Requests

Expect examiners to request documentation for any maturity claim above baseline. Common requests include:

• Board meeting minutes showing cybersecurity discussions and risk appetite approval
• Conditional Access policies with configuration screenshots
• Incident response plan plus evidence of testing
• Vendor risk assessment files for critical third parties
• Patch management and vulnerability scanning reports for the past 12 months
• Access review records with approval and remediation documentation
• Business continuity and disaster recovery test results

Staff Interviews

Examiners interview bank staff to verify that documented procedures match actual practice. They'll ask your IT team how they respond to a phishing incident. They'll ask your compliance officer how the board is informed of cybersecurity risks. They'll ask tellers what they do when they receive a suspicious email. If the answers don't match your documented procedures, that's a finding.

Your IT provider should prepare your team for these conversations. ABT runs through common examiner questions with bank staff before scheduled exams, so nobody is caught off guard by questions about incident response procedures or access management policies.

Technical Reference

The following tables provide definitions for regulatory frameworks and technical terms used in this article.

Regulatory Frameworks

Glossary

Justin Kirsch

CEO, Access Business Technologies

Justin Kirsch has guiding financial institutions through regulatory compliance. His company, ABT, manages IT and security operations for over 750 financial institutions -- and the pattern he sees most often is banks that treat the Cybersecurity Assessment Tool as an annual checkbox instead of the continuous risk management framework examiners expect it to be.