The Problem
Ask most institutions whether they have logging in place and the answer is yes. Ask them what they are logging, how long they retain it, who reviews it, and what happens when something suspicious appears — and the answers become much less consistent. That gap between having logging and having a logging program is exactly what examiners are probing for, and it is one of the most reliably cited weaknesses across institution sizes and charter types.
The practical stakes are high. Logs are how you detect unauthorized access, investigate incidents, and demonstrate to regulators that your controls are actually functioning. An institution that experiences a breach and cannot reconstruct what happened — because logs weren’t retained long enough, weren’t comprehensive enough, or were never reviewed — faces a much more difficult conversation with both examiners and counsel than one that can produce a clear timeline.
What Regulators Require
The FFIEC Information Security Booklet requires institutions to implement audit logging sufficient to detect, investigate, and recover from security events. The NIST Cybersecurity Framework identifies logging and monitoring as a core component of the Detect function. The updated GLBA Safeguards Rule requires covered institutions to monitor and test the effectiveness of their information security program — which regulators increasingly interpret to include active log monitoring, not just passive collection.
There is no universal standard for how long logs must be retained, but examiners typically expect a minimum of 90 days of immediately accessible log data with at least 12 months of total retention. Institutions that have experienced a security incident are held to a higher standard: if you cannot produce logs from the relevant period, the assumption is unfavorable.
What Examiners Are Looking For
What You Are Logging
Comprehensive logging starts with knowing what sources matter. Examiners expect log coverage across authentication events (successful and failed logins), privileged account activity, changes to user access and system configurations, firewall and network traffic anomalies, and endpoint security alerts. Gaps in any of these categories — particularly around privileged access and authentication failures — are common findings. Examiners will ask for a log source inventory and compare it against your asset inventory to identify what is and isn’t being captured.
Centralized Log Management
Logs scattered across individual systems — firewall logs on one appliance, Active Directory logs on a domain controller, core banking logs in a separate system — are difficult to correlate and easy to miss. Examiners look favorably on centralized log management, whether through a SIEM (Security Information and Event Management) platform or a simpler log aggregation solution. Centralization also supports log integrity: logs stored only on the systems they describe can be altered by a compromised account on that system.
Active Review and Alerting
Collecting logs without reviewing them is a common gap that examiners probe directly. They will ask who reviews logs, how often, and what they are looking for. A documented log review process — daily review of critical alerts, weekly review of authentication anomalies, monthly summary reporting to management — is the kind of answer that demonstrates an operational program rather than a passive collection exercise. Automated alerting on high-priority events reduces the burden on staff and makes the review process more sustainable.
Retention Policy and Enforcement
Your log retention policy should specify how long different log types are retained, where they are stored, and who is responsible for ensuring retention requirements are met. Examiners will ask for the policy and may verify that actual retention matches it. Logs that are overwritten before the retention period has elapsed — often because storage wasn’t sized appropriately for the volume being generated — are a straightforward finding with a clear remediation path.
Log Integrity
Logs are only useful as evidence if they haven’t been tampered with. Examiners expect that logs are protected from modification, particularly by the accounts whose activity they record. At minimum, administrative access to logging systems should be restricted, logged separately, and reviewed. More mature programs use write-once storage or cryptographic integrity verification for critical log data.
Where to Start If Your Program Needs Work
Build a Log Source Inventory
List every system in your environment and document whether it is configured to generate logs, where those logs go, and how long they are retained. This inventory will immediately surface gaps — systems that aren’t logging at all, logs that are stored locally with no retention policy, or critical systems whose logs aren’t being reviewed. The inventory itself is useful documentation for examiners.
Establish a Documented Review Process
Define who reviews logs, at what frequency, and what they are looking for. Even a basic daily review of authentication failures and privileged account activity — documented in a simple log review form or spreadsheet — is far better than no review process at all. Document anomalies investigated and the conclusions reached. Examiners want to see that the review process is actually happening, not just described in a policy.
Set a Retention Standard and Enforce It
Choose a retention period (90 days accessible, 12 months total is a reasonable baseline), document it in your information security policy, and verify that your current storage configuration actually meets it. If you are using cloud-based systems, confirm with your vendors that log data is being retained according to your policy, not just theirs.
Practical Checklist
- Log source inventory documenting all systems generating logs and their retention configuration
- Authentication events (successes and failures) logged across all critical systems
- Privileged account activity logged and reviewed separately from general user activity
- Configuration and access changes logged for all critical systems
- Logs aggregated centrally or reviewed through a coordinated process across sources
- Documented log review process with defined frequency, scope, and responsible party
- Automated alerting configured for high-priority events (repeated authentication failures, after-hours privileged access, etc.)
- Log retention policy documented with minimum 90-day accessible retention and 12-month total retention
- Log integrity controls in place to prevent tampering, particularly by privileged accounts
- Log review activity documented with anomalies investigated and dispositioned in writing