
Banks and credit unions in the United States are examined against the Information Technology (IT) Examination Handbook of the Federal Financial Institutions Examination Council (FFIEC). The handbook does not read like a rulebook. It has no list of required events and no retention number. Yet examiners ask detailed questions about logs, and weak answers turn into findings. This guide pulls the logging expectations out of the handbook and the related federal rules, and turns them into a list you can check before the next exam.
The short answer: The FFIEC sets no fixed list of events and no log retention period. Its Information Security booklet, section II.C.22, expects a central logging repository, timely transmission of log files, effective analysis, retention periods defined in your own policy to meet incident response needs, logs protected from editing and deletion, and periodic independent review of logging practices. It names security information and event management (SIEM) tools as one way to collect, aggregate, analyze and correlate events. Examiners test this in Objective 6, item 35 of the booklet’s examination procedures. Two rules add deadlines that need good logs: banks must notify their regulator within 36 hours of determining that a notification incident occurred, and credit unions must notify the National Credit Union Administration (NCUA) within 72 hours.
What the FFIEC is and why its handbook matters
The FFIEC is an interagency body of the Federal Reserve Board, the Federal Deposit Insurance Corporation (FDIC), the NCUA, the Office of the Comptroller of the Currency (OCC) and the Consumer Financial Protection Bureau, plus the chair of its State Liaison Committee. Its IT Examination Handbook is the reference examiners use to review a bank’s or credit union’s technology.
Two booklets cover logging:
- Information Security (September 2016). Still the current version. A February 27, 2026 update across the handbook removed references to reputational risk and, in the FFIEC’s words, does “not establish new requirements.”
- Architecture, Infrastructure, and Operations (June 2021). It replaced the old Operations booklet and covers day-to-day log management.
The handbook is guidance. The binding rule behind it is the Interagency Guidelines Establishing Information Security Standards, issued under the Gramm-Leach-Bliley Act (GLBA). Paragraph III.C.1.f of those guidelines asks each institution to consider “monitoring systems and procedures to detect actual and attempted attacks on or intrusions into customer information systems.” Credit unions have the same paragraph in 12 CFR part 748, Appendix A, with “member” in place of “customer.”
The FFIEC retired its Cybersecurity Assessment Tool on August 31, 2025. Its statement pointed institutions to the National Institute of Standards and Technology (NIST) Cybersecurity Framework 2.0 and the Cybersecurity Performance Goals of the Cybersecurity and Infrastructure Security Agency (CISA), and mentioned industry resources such as the Cyber Risk Institute Profile and the Center for Internet Security (CIS) Controls. The NCUA keeps its own voluntary Automated Cybersecurity Evaluation Toolbox for credit unions.
How the FFIEC logging picture has changed
Dates from the FFIEC, the agencies and the Federal Register
- September 2016Information Security booklet revisedSection II.C.22 sets the log management expectations still used today
- June 30, 2021Architecture, Infrastructure, and Operations bookletAdds an operations view of log management and event handling
- August 11, 2021Authentication and access guidancePrivileged users should not be able to change logs of their own activity
- May 1, 202236-hour bank notice rule appliesOCC, Federal Reserve and FDIC computer-security incident notification
- September 1, 202372-hour credit union notice rule appliesNCUA, 12 CFR 748.1(c)
- August 31, 2025Cybersecurity Assessment Tool retiredInstitutions pointed to NIST CSF 2.0, CISA goals and industry profiles
- February 27, 2026Handbook updateReputational risk wording removed; no new requirements
What examiners check in log management
Section II.C.22 of the Information Security booklet is short, but it covers five things. Item 35 under Objective 6 of the examination procedures asks the examiner to check whether management has “an effective log management process that involves a central logging repository, timely transmission of log files, and effective log analysis,” and then looks at retention, integrity, independent review and correlation.
What examiners look for in your log management
Information Security booklet, section II.C.22, and Appendix A, Objective 6, item 35
- Collect centrallyHost and network activity goes to a central logging repository
- Send on timeTimely transmission, with enough storage to avoid gaps
- Analyze and correlateEvents from separate systems are analyzed together to spot incidents and trends
- Keep by policyRetention periods written down, sized to incident response needs
- Protect and reviewRestricted access, no changes to past entries, periodic independent review
On protection, the booklet is direct: intruders “often attempt to conceal unauthorized access by editing or deleting log files.” It lists ways to keep logs intact: encrypt logs that hold sensitive data or cross the network, keep enough storage to avoid gaps, secure backup and disposal, log to a separate and isolated computer or to read-only media, configure logging so earlier entries cannot be changed, and limit access to a small number of authorized users.
The Architecture, Infrastructure, and Operations booklet adds the operations side (Appendix A, Objective 15, item 7). Examiners look for a policy that states the objectives for logging, the types of logs collected, who can change log settings, how fast logs are reviewed, retention time frames and how anomalies are escalated. They also ask how you handle false positives and whether you considered tools to automate log analysis.
The handbook sections that drive logging
The table paraphrases each source and adds what it means for your logs. All of them are public and linked in the sources.
| Source | What it asks (paraphrased) | What it means for logs |
|---|---|---|
| Interagency Guidelines, III.C.1.f and g | Consider monitoring to detect actual and attempted intrusions; have a response program | The legal hook for monitoring and incident response |
| Information Security, II.C.15 | Log and independently monitor privileged access; filter and review operating system logs; log application access and events; log and monitor all remote access | Sign-ins, administrator activity, application events and remote sessions from every important system |
| Information Security, II.C.17 | Applications should keep audit trails of security and access changes and user activity | Core banking and other applications must produce their own logs |
| Information Security, III.B | Continual monitoring of inbound and outbound traffic for malicious activity and data exfiltration; independent monitoring of administrators | Firewall, proxy and intrusion detection logs, watched by someone other than the administrators |
| Information Security, III.C | Use log correlation and analysis tools to identify, classify and escalate incidents | A way to connect events across systems |
| Information Security, Appendix A, Objective 6, item 11 | Change management keeps an audit trail of all changes | Change records and configuration change logs |
| Architecture, Infrastructure, and Operations, III.A | Review database audit logs and independently monitor database administrators | Database audit logs, especially for privileged accounts |
| Authentication and access guidance (2021) | Lists controls such as alerts when privileged accounts are added or removed, and logs that privileged users cannot modify or delete | Alerting on account changes, and log storage out of administrators’ reach |
What a remote access log entry should hold
Information Security booklet, section II.C.15. An illustration, not real data.
- Date and time of the session
- The user
- The user's location
- How long the session lasted
- What the user did
What to log for an FFIEC exam
The handbook leaves the event list to your risk assessment. For most banks and credit unions, the sources above turn into this list.
| Source | Events to capture | Handbook link |
|---|---|---|
| Directory and identity | Sign-ins and failures, lockouts, new and removed accounts, group and role changes | II.C.15, authentication guidance |
| Privileged accounts | Administrator sign-ins and actions, use of elevated rights, privileged accounts added or removed | II.C.15, III.B, authentication guidance |
| Servers, including IBM i | Access to system settings and utilities, by user, terminal, date and time | II.C.15(a), Objective 6, item 21 |
| Core banking and other applications | Access and significant events, security and access changes | II.C.15(b), II.C.17 |
| Databases | Audit logs, administrator activity | Architecture, Infrastructure, and Operations, III.A |
| Remote access and virtual private network (VPN) | Date, time, user, location, duration and activity of each session | II.C.15(c) and (d) |
| Network edge | Firewall, intrusion detection and prevention, data loss prevention events, outbound traffic | II.C.22, III.B |
| Online banking | Unusual login spikes, lockouts, transaction logs | Authentication guidance appendix |
| Changes | Configuration and software changes, matched to approved requests | Objective 6, item 11 |
| The logging system | Cleared logs, stopped audit services, sources that go silent | II.C.22 |
If your core runs on IBM i (AS/400), its audit journal is the system’s main security record. Our guide to SIEM for IBM AS/400 covers what to collect. For Windows domains, Active Directory SIEM use cases lists the event IDs behind the identity rows.
How long to keep logs for the FFIEC
No FFIEC booklet and no OCC, Federal Reserve, FDIC or NCUA rule sets a fixed number of days or years for security logs. Section II.C.22 says “policies should define retention periods for security and operational logs,” sized to incident response and analysis needs. That puts the decision, and the burden of explaining it, on you.
Other rules supply numbers. Suspicious Activity Report (SAR) rules require keeping each filed report and its supporting documentation for five years, for example 12 CFR 21.11(g) for national banks and 12 CFR 748.1(d)(3) for credit unions. If logs are part of that documentation, keep them with the report.
What sets your log retention period
No FFIEC document gives a number. These sources do, or tell you to set one.
Our suggestion, not an FFIEC rule: keep at least one year searchable. Attacks can go unnoticed for months, and a year matches the floor in the Payment Card Industry Data Security Standard (PCI DSS) that many banks already follow. Banks with a New York State Department of Financial Services (NYDFS) license need three years; see NYDFS logging requirements. For the card side, see PCI DSS logging requirements, and to size the storage, use our sizing calculator.
The incident notice clocks
Two federal rules give you hours, not days, and both start from what you know. Logs are how you know it.
- Banks: 36 hours. Under the computer-security incident notification rule (12 CFR 53.3 for the OCC, 225.302 for the Federal Reserve, 304.23 for the FDIC), a bank must notify its primary regulator “as soon as possible and no later than 36 hours after” it determines that a notification incident occurred. That means an incident that has materially disrupted, or is reasonably likely to disrupt, its operations, a major business line or financial stability.
- Bank service providers: as soon as possible. A provider must tell each affected bank as soon as possible when an incident has disrupted, or is reasonably likely to disrupt, covered services for four or more hours.
- Credit unions: 72 hours. Under 12 CFR 748.1(c), a federally insured credit union must notify the NCUA no later than 72 hours after it reasonably believes it has had a reportable cyber incident.
The Interagency Guidelines also expect response programs to preserve records and evidence while containing an incident. Public bank holding companies face a third clock, the Securities and Exchange Commission’s four business days after an incident is found material; see SOX log retention requirements.
Do you need a SIEM for an FFIEC exam?
Not by name. The booklet says SIEM systems “can provide a method” to collect, aggregate, analyze and correlate information, and that management should build those processes regardless of method. In practice, central collection, correlation across systems, independent review of administrators and fast answers during an incident are hard to show without a SIEM or a service that runs one.
The handbook also accepts outsourcing. Security operations can sit in-house, be spread across teams or be outsourced in whole or in part. Examiners then ask whether the provider’s analysts are trained, and the authentication guidance expects providers to report unauthorized access to systems they run for you.
Evidence to have ready
- An inventory of log sources tied to the systems your risk assessment rates as important.
- A written logging and retention policy with the reasons for each period.
- Proof that logs reach a central repository on time, and alerts when a source goes silent.
- Alert rules in use, and records of who reviewed alerts and what they did.
- Evidence that administrators are monitored by someone independent of them.
- The latest independent review of logging practices, often by internal audit.
- Incident tickets, timelines and the notification decisions you made.
For the federal rule that covers non-bank lenders and other financial companies, see GLBA security requirements. For how other frameworks compare, see SIEM compliance requirements.
How UTMStack fits
We build UTMStack, so weigh our view accordingly. Here is what it does for FFIEC log management, and where it stops.
- Central collection and correlation. UTMStack collects logs from Windows and Linux hosts, IBM AS/400 and AIX, firewalls such as Fortinet FortiGate, Palo Alto Networks, Cisco and SonicWall, Microsoft 365, Amazon Web Services, Azure and Google Cloud. It checks every event against more than 600 detection rules mapped to MITRE ATT&CK as it arrives, before it is stored. See log management.
- Alerts when logs are tampered with. Built-in rules fire when the Windows Security log is cleared, when Windows auditing is switched off from the command line, when Linux log files are deleted or the logging service is stopped, when Microsoft 365 audit data is purged, when Google Cloud or Azure logging is disabled, and when IBM AS/400 auditing is turned off.
- Retention you set. Up to five years. Older data moves to cold storage that stays searchable without a restore, so a five-year SAR look-back is a search, not a recovery project.
- Banking Audit reports. The Enterprise edition includes a Banking Audit framework with 80 checks, mostly on Windows events such as sign-ins, policy changes, new accounts and cleared logs, grouped into log collection, correlation and real-time alerting. It is not an FFIEC report and does not map to handbook sections. See compliance.
- Response. Response flows can block an address, disable an account or isolate a host. See automated response.
- Where it runs. On your own servers, including networks with no internet access through the installer’s air-gapped mode, or on UTMStack Cloud, a dedicated instance per customer on OVHcloud with regions that include the United States.
- Someone watching. If your team cannot cover nights and weekends, our security operations center (SOC) service, SOC Extension, backs up your existing team for after-hours coverage, overflow and incidents. Your team stays in charge.
- What it does not do. There is no ready-made parser for core banking applications, so check how your core exports its logs first. There are no built-in alert rules for new Windows accounts or privileged group changes, which the authentication guidance lists among its controls. The events are collected and searchable, and you can add custom rules for them.
UTMStack is priced per device, never by log volume, so keeping years of logs does not grow the bill. Ask for a quote or see pricing.
Frequently asked questions
Does the FFIEC require a SIEM? No. The Information Security booklet says SIEM tools can collect, aggregate, analyze and correlate security events, and that management must have those processes whatever method it uses. Most institutions meet them with a SIEM or a managed service.
How long does the FFIEC require logs to be kept? The FFIEC sets no number. Section II.C.22 asks each institution to define retention periods in policy to meet incident response and analysis needs. Other rules may set longer periods, such as five years for SAR supporting documentation or three years under NYDFS.
Is the FFIEC Cybersecurity Assessment Tool still used? No. The FFIEC retired it on August 31, 2025. Its statement pointed institutions to the NIST Cybersecurity Framework 2.0, the CISA Cybersecurity Performance Goals and industry resources such as the Cyber Risk Institute Profile and the CIS Controls.
Do credit unions follow the FFIEC handbook? Largely, yes. The NCUA is an FFIEC member, so the handbook reflects its expectations too. Credit unions also follow 12 CFR part 748, including the 72-hour cyber incident notice. In December 2025 the NCUA proposed moving its safeguarding guidelines out of the regulation into guidance; as of November 2026 that is still a proposal.
How often should logs be reviewed for an FFIEC exam? The handbook sets no frequency. It expects timely analysis and a policy that states the response time for log review. We suggest triaging alerts as they arrive and writing a review interval for each log type into the policy.
Sources
- FFIEC IT Examination Handbook, Information Security booklet (September 2016): sections II.C.15, II.C.17, II.C.22, III.B, III.C and Appendix A, Objective 6
- FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations booklet (June 2021): section III.A and Appendix A, Objective 15
- FFIEC IT Handbook InfoBase, What’s New (February 27, 2026 update)
- FFIEC, Authentication and Access to Financial Institution Services and Systems (August 11, 2021)
- FFIEC, Cybersecurity Assessment Tool sunset statement (August 29, 2024), and Federal Reserve SR 24-7
- Interagency Guidelines Establishing Information Security Standards: 12 CFR part 364, Appendix B (FDIC), 12 CFR part 30, Appendix B (OCC), and for credit unions 12 CFR part 748, Appendix A
- Computer-security incident notification: 12 CFR part 53, 12 CFR part 225, subpart N, 12 CFR part 304, subpart C, and the final rule, 86 FR 66424 (November 23, 2021)
- NCUA, 12 CFR 748.1, and the cyber incident notification final rule (March 1, 2023)
- NCUA, Proposed guidelines for safeguarding member information (December 11, 2025)
- OCC, 12 CFR 21.11, Suspicious Activity Reports
- New York State Department of Financial Services, 23 NYCRR Part 500, reading copy: section 500.6
- PCI DSS v4.0.1, Requirement 10.5.1, from the PCI SSC document library


