What FFIEC Cybersecurity Requirements Should Every Community Bank Meet in 2026?

The Core Cybersecurity Controls Community Banks Should Have in Place

Community banks should maintain a risk-based cybersecurity program covering at least eight core control areas: governance, risk assessment, identity security, endpoint and network protection, continuous monitoring, vulnerability management, business continuity and incident response. Banks should also maintain written evidence showing that these controls are implemented, tested, reviewed and reported to leadership.

There is no single universal “FFIEC compliance checklist” that applies identically to every institution. Expectations vary according to the bank’s size, complexity, systems, services, risk profile and third-party relationships. Examiners generally evaluate whether the bank can identify its material risks, implement appropriate safeguards, monitor those safeguards and demonstrate that leadership is exercising effective oversight.

For a community bank with 25–50 employees, the practical goal is not to purchase every available security product. It is to build a documented, repeatable program that addresses the institution’s most significant risks and produces reliable evidence before an examination or security incident.

What Does FFIEC Cybersecurity Compliance Mean?

The Federal Financial Institutions Examination Council, commonly called the FFIEC, develops principles, standards and examination guidance used by federal banking regulators. The FFIEC itself is not a single regulator and does not issue one cybersecurity certification that a bank can complete once and permanently retain.

A community bank’s cybersecurity responsibilities may be influenced by its primary regulator, applicable federal and state requirements, the Gramm-Leach-Bliley Act, interagency information-security standards, contractual obligations, payment-card requirements and cyber-insurance conditions.

In practice, examiners want to see that the bank has:

• Identified its systems, data, vendors and material cyber risks
• Implemented safeguards appropriate to those risks
• Assigned clear responsibility to management and the board
• Monitored systems and security events consistently
• Tested incident-response and recovery capabilities
• Managed risks created by third-party service providers
• Corrected known weaknesses within documented timeframes
• Retained evidence supporting its policies and decisions

The following eight-domain framework gives community banks a practical way to organize those responsibilities.

1. Governance and Board Oversight

A bank’s cybersecurity program begins with leadership, not technology. Senior management and the board should understand the institution’s material technology risks, approve the information-security program and receive enough information to challenge decisions effectively.

What Governance Should Include

• A written information-security program
• Defined roles for the board, executives, employees and service providers
• Board approval of significant security policies
• Regular cybersecurity reporting
• Documented risk acceptance and remediation decisions
• Annual review of the security program
• Escalation procedures for critical security events
• Qualified internal or external technical leadership

Board reports should be understandable to nontechnical leaders. A 40-page list of alerts is less useful than a concise dashboard showing unresolved critical vulnerabilities, phishing-test results, backup-test outcomes, significant vendor risks and progress against the security roadmap.

Useful Board-Level Metrics

Metric	What it helps leadership understand
Critical vulnerabilities past due	Whether known technical risks are being corrected promptly
Multifactor authentication coverage	Whether important accounts receive stronger identity protection
Security incidents by severity	Whether threats are increasing or controls are failing
Backup recovery success rate	Whether systems can actually be restored
Phishing simulation results	Whether employee risk is improving
Third-party reviews completed	Whether material vendors are receiving appropriate oversight

2. Cybersecurity Risk Assessments

A risk assessment should identify the bank’s most important information assets, the threats affecting those assets, existing safeguards and any remaining risk. It should not be a generic document that is updated only by changing the date.

A useful assessment should address:

• Customer information and other sensitive data
• Core banking and digital banking platforms
• Microsoft 365 and other cloud services
• Endpoints, servers and network infrastructure
• Online and mobile banking channels
• Wire-transfer and payment processes
• Remote-access systems
• Privileged and administrative accounts
• Third-party connections and service providers
• Business continuity and disaster-recovery dependencies

The assessment should lead to an actionable remediation plan. Each significant gap should have an owner, priority, target date and documented resolution or risk-acceptance decision.

When Should the Assessment Be Updated?

Community banks should review their risk assessment at least annually and whenever a material change occurs. Examples include opening a branch, changing a core provider, implementing a cloud platform, acquiring another institution, introducing a new customer service or experiencing a significant incident.

A cybersecurity assessment performed by an experienced provider can also help identify technical weaknesses that may not be visible in policy documents. Learn more about 911 IT’s cybersecurity services.

3. Identity and Access Management

Identity is one of the most important parts of a bank’s security program because attackers frequently target passwords, email accounts, remote-access systems and administrative privileges.

Minimum Identity Controls to Evaluate

• Multifactor authentication for email, remote access and privileged accounts
• Unique user accounts with no unnecessary sharing
• Role-based access using the principle of least privilege
• Prompt access removal when an employee leaves
• Documented approval for new and changed access
• Regular access reviews
• Separate administrative accounts for privileged work
• Monitoring of suspicious sign-ins and impossible travel
• Strong controls over service accounts
• Password-manager use where appropriate

A bank should be able to show who has access to critical systems, why that access is necessary, who approved it and when it was last reviewed.

A Practical Access-Review Process

1. Export active users and permissions from each critical system.
2. Identify terminated, inactive, shared or unnecessary accounts.
3. Ask the responsible business owner to confirm each user’s need for access.
4. Remove or reduce access that is no longer required.
5. Document the review, approvals and completed changes.

Microsoft environments can support stronger identity controls when configured correctly. 911 IT’s cloud services include Microsoft 365 administration, security and access management.

4. Endpoint, Email and Network Security

Every device and connection represents a potential entry point. A community bank should use layered controls rather than relying on traditional antivirus alone.

Endpoint Security

• Endpoint detection and response
• Managed antivirus and anti-malware protection
• Disk encryption on laptops and portable devices
• Application and device controls
• Automated operating-system and software patching
• Restrictions on local administrative privileges
• Centralized device inventory
• Remote isolation or wipe capabilities where appropriate

Email Security

• Multifactor authentication
• Advanced spam, phishing and malware filtering
• Domain protections such as SPF, DKIM and DMARC
• External-sender warnings
• Protection against malicious links and attachments
• Monitoring for suspicious forwarding rules
• Procedures for verifying payment and account-change requests

Network Security

• Managed firewalls with current configurations
• Segmentation between critical systems, employee devices and guest networks
• Secure remote access
• Restricted inbound and outbound traffic
• Wireless security
• Configuration backups
• Redundant connectivity where operationally necessary
• Monitoring for unusual activity

Controls should be supported by configuration records, monitoring reports and periodic review. A policy stating that devices are patched is not sufficient if reporting shows critical updates remain missing for months.

5. Continuous Monitoring and a 24/7 Security Operations Capability

Security tools create value only when alerts are reviewed, investigated and escalated. Community banks should understand who monitors their systems after hours, what events generate alerts and what happens when suspicious activity is identified.

A managed security program may include:

• 24/7 collection and review of security alerts
• Endpoint and network threat detection
• Centralized log monitoring
• Cloud and Microsoft 365 alerting
• Investigation and triage
• Documented escalation procedures
• Account containment and device isolation
• Incident documentation
• Monthly or quarterly reporting

Questions to Ask a Security Provider

1. Which systems, accounts and devices are monitored?
2. Is monitoring active 24 hours a day or only during business hours?
3. Who reviews alerts?
4. How quickly are critical events investigated?
5. Can the provider disable an account or isolate a device?
6. Who at the bank is contacted during an emergency?
7. How are events documented?
8. What reports will management and the board receive?

911 IT provides 24/7 threat monitoring and incident-response support as part of its managed cybersecurity services.

6. Vulnerability and Patch Management

Banks should maintain an accurate asset inventory, identify vulnerabilities and remediate weaknesses according to their severity and business risk.

A Five-Step Vulnerability Management Process

1. Discover: Identify servers, workstations, network devices, cloud systems and applications.
2. Scan: Perform recurring authenticated vulnerability scans where appropriate.
3. Prioritize: Evaluate severity, exploitability, exposure and business importance.
4. Remediate: Apply patches, change configurations or implement compensating controls.
5. Verify: Rescan and document that the weakness has been corrected.

The bank should establish target remediation timeframes. For example, critical internet-facing vulnerabilities may require action within days, while lower-risk internal findings may follow a longer schedule. The exact timeframe should reflect the institution’s risk assessment rather than a generic number copied from another organization.

Common Examination Weaknesses

• Incomplete device inventories
• Unsupported operating systems
• Critical patches left unresolved
• Exceptions with no documented approval
• Scans that exclude important systems
• No verification after remediation
• Third-party findings that are never tracked to closure

7. Business Continuity, Backups and Recovery Testing

A successful backup job does not prove that a bank can recover. The institution should know which systems must be restored first, how long recovery may take, how much data could be lost and whether recovery procedures have been tested.

Four Recovery Measurements to Document

Measurement	Purpose
Recovery time objective	The targeted time for restoring a system or service
Recovery point objective	The acceptable amount of data loss measured in time
Actual recovery time	How long restoration took during a test
Actual recovery point	How current the restored data was during a test

Recovery testing should include more than confirming that backup files exist. The bank should periodically restore systems or data, validate usability and document any problems discovered.

Business Continuity Controls

• Encrypted onsite and offsite backups
• Protection against backup deletion or ransomware
• Documented restoration priorities
• Alternative communication methods
• Manual procedures for critical business functions
• Backup internet and power considerations
• Vendor contact and escalation information
• Regular tabletop and technical recovery exercises

911 IT’s business continuity services combine backup, disaster recovery, cybersecurity and support to help organizations maintain operations during an outage or attack.

8. Incident Response and Regulatory Notification

A bank should maintain a written incident-response plan that explains how it will identify, contain, investigate, recover from and report a security event. The plan should define decision-making authority before a crisis occurs.

The Seven-Step Incident Response Framework

1. Prepare: Assign roles, retain contact information and confirm access to necessary tools.
2. Identify: Determine what happened, which systems are affected and whether the event is ongoing.
3. Contain: Isolate affected devices, disable compromised accounts and block malicious activity.
4. Preserve: Protect relevant logs, evidence and system information.
5. Assess: Evaluate operational, customer, legal and regulatory impact.
6. Recover: Restore systems safely and monitor for renewed activity.
7. Improve: Document lessons learned and correct the root cause.

Under the interagency Computer-Security Incident Notification Rule, a banking organization must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a qualifying notification incident has occurred. Not every technical issue meets that threshold, so the bank should involve qualified legal, compliance and regulatory personnel when making the determination.

The rule also imposes notification responsibilities on covered bank service providers when certain incidents materially disrupt or degrade covered services for four or more hours. Vendor contracts and escalation procedures should account for that obligation.

Information the Plan Should Contain

• Internal incident-response team members
• Primary regulator contacts
• Legal counsel and insurance contacts
• Law-enforcement and forensic contacts
• Critical vendor escalation paths
• Customer and public communication responsibilities
• Criteria for declaring an incident
• Evidence-preservation instructions
• Regulatory and contractual notification procedures
• Post-incident review requirements

The plan should be tested through at least one structured tabletop exercise each year and after significant organizational or technology changes.

Third-Party Risk Management Is Part of Every Control Area

Community banks rely heavily on core processors, cloud providers, payment platforms, telecommunications vendors and IT service providers. Outsourcing a function does not eliminate the bank’s responsibility to oversee the associated risk.

Before Engaging a Critical Vendor

• Assess the vendor’s financial condition and experience
• Review security controls and independent assurance reports
• Evaluate incident history and resilience capabilities
• Confirm data ownership, location and return procedures
• Review subcontractor use
• Define security, support and reporting obligations
• Confirm breach and incident-notification requirements
• Establish termination and transition procedures

During the Relationship

• Review performance against service commitments
• Track significant incidents and control changes
• Obtain updated assurance reports
• Monitor unresolved findings
• Test escalation contacts
• Review business-continuity capabilities
• Report material risks to management and the board

What Evidence Should a Bank Have Ready for an Examination?

An institution may have strong controls but still struggle during an examination if evidence is scattered or outdated. A well-organized examination file may include:

• Current information-security policies
• The most recent cybersecurity risk assessment
• An asset and software inventory
• Network and data-flow diagrams
• User-access review records
• Patch and vulnerability reports
• Penetration-test results and remediation records
• Security-awareness training results
• Phishing-simulation reports
• Backup and recovery-test documentation
• Incident-response and tabletop exercise records
• Material vendor assessments and contracts
• Board and committee reports
• Cyber-insurance documentation
• Open findings with owners and target completion dates

Every report should answer four questions: What was reviewed? What was found? Who owns the issue? When will it be corrected?

A 90-Day FFIEC Cybersecurity Readiness Plan

Days 1–30: Assess and Organize

• Confirm the bank’s asset inventory
• Review the cybersecurity risk assessment
• Identify unsupported systems and critical vulnerabilities
• Inventory administrative accounts
• Collect current vendor and security documentation
• Review open examination and audit findings
• Confirm incident-response contacts

Days 31–60: Remediate Priority Gaps

• Expand multifactor authentication coverage
• Remove unnecessary or inactive accounts
• Patch critical systems
• Correct high-risk firewall and cloud configurations
• Update incomplete policies and procedures
• Resolve overdue vendor findings
• Confirm 24/7 monitoring and escalation coverage

Days 61–90: Test and Report

• Conduct an incident-response tabletop exercise
• Perform a documented backup restoration
• Review security metrics with management
• Present material risks and progress to the board
• Verify that completed findings have supporting evidence
• Create a prioritized 12-month security roadmap

Real Financial-Industry Experience

A financial-industry client reported working with 911 IT for more than 20 years and described the team as dependable, responsive and willing to go above and beyond. The client also emphasized that the help desk follows issues through to complete resolution rather than closing requests prematurely.

Another financial-services client specifically credited 911 IT with helping an accounting firm implement and maintain backend network protocols supporting strict IRS and PCI security requirements. The client valued having a team that already understood the environment and could respond to problems without requiring the firm to explain its systems from the beginning each time.

Other financial-industry clients repeatedly describe 911 IT as proactive, responsive and knowledgeable about the security standards required to protect client information. Those outcomes matter because effective cybersecurity depends on consistent execution, not simply owning more tools.

Learn more about 911 IT’s experience supporting CPAs and financial firms.

Frequently Asked Questions

Does the FFIEC require every bank to use the same cybersecurity tools?

No. Cybersecurity expectations are risk-based. The institution should select safeguards appropriate to its size, complexity, data, systems, services and threat environment. The bank should also be able to explain and document why those controls are appropriate.

Does the FFIEC require multifactor authentication?

Financial institutions are generally expected to use layered security appropriate to the risk of the system and activity. Multifactor authentication is a widely recognized control for email, remote access, privileged accounts and other high-risk access. A bank that does not use it in those areas should expect to explain its alternative controls and risk decision.

How often should a community bank perform a cybersecurity risk assessment?

The assessment should be reviewed at least annually and after material changes to systems, services, locations, vendors or the threat environment. A significant incident should also trigger review.

How often should backups be tested?

Backup jobs should be monitored continuously, and restoration procedures should be tested on a scheduled basis. Critical systems may require more frequent testing than lower-priority systems. The bank should document actual recovery results rather than merely confirming that backups completed.

How quickly must a bank report a qualifying computer-security incident?

A banking organization must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a qualifying notification incident has occurred. Banks should obtain legal and regulatory guidance when applying the rule to a specific event.

Can an MSP make a bank FFIEC compliant?

An MSP can implement controls, monitor systems, maintain documentation and help remediate technical gaps. It cannot transfer the bank’s governance and oversight responsibilities. Management and the board remain accountable for understanding and managing the institution’s risks.

What is the most common FFIEC cybersecurity mistake?

One of the most common problems is a gap between written policy and actual practice. Examples include policies requiring timely patches when critical updates are overdue, incident plans that have never been tested and vendor-review procedures that are not consistently completed.

Build a Defensible Cybersecurity Program Before the Next Examination

The best time to find a security or documentation gap is before an examiner or attacker finds it. A focused readiness review can help a community bank identify its highest-risk weaknesses, organize supporting evidence and create a realistic remediation plan.

911 IT provides local cybersecurity, managed IT, cloud management and business-continuity support for organizations in Salt Lake City and throughout Utah. Our team offers 24/7 monitoring and support, local engineering resources, strategic guidance and fixed-fee service backed by a satisfaction guarantee.

Schedule a discovery call with 911 IT to discuss your bank’s security controls, monitoring coverage, examination readiness and highest-priority risks. You can also contact our team to request a bank-specific cybersecurity assessment.

This article provides general educational information and is not legal, regulatory or compliance advice. Financial institutions should consult their regulator, legal counsel and qualified compliance professionals regarding requirements that apply to their specific circumstances.