Log Retention for Financial Services: SEC, DORA, OCC
Financial services log retention spans SEC, DORA, OCC, and FFIEC. This guide maps each mandate to log types and retention periods.
Financial services organizations operate under the most demanding log retention requirements of any industry. Multiple overlapping regulations, SEC cybersecurity disclosure rules, DORA, OCC heightened standards, and FFIEC examination guidelines, each impose specific requirements on what must be retained, for how long, and in what form.
The challenge is not awareness. Most financial institutions know they have retention obligations. The challenge is implementation, building a telemetry architecture that satisfies the most stringent interpretation of every applicable requirement without creating an unsustainable cost structure.
This guide maps each major regulation to its specific telemetry requirements, clarifies what examiners and auditors actually expect, and identifies the architectural approach that satisfies all requirements by default.
Why financial services log retention is different
Financial services log retention differs from general enterprise retention in three fundamental ways.
The first is multi-regulator overlap. A US bank may be subject to SEC disclosure rules, OCC examination standards, FFIEC guidance, and state-level requirements simultaneously. A European bank operating in the US faces DORA requirements on top of SEC and OCC. Each regulator has different expectations, different examination cycles, and different definitions of compliance. The institution must satisfy all of them.
The second is enforcement intensity. Financial regulators examine actively and enforce aggressively. An OCC examiner requesting 18 months of authentication logs expects to see those logs, complete, searchable, and producible within the examination timeline. The gap between "we have a retention policy" and "we can produce the data" is where enforcement findings originate.
The third is materiality and disclosure timelines. The SEC cybersecurity disclosure rule requires material incident disclosure within four business days. This timeline presumes that the organization can assess materiality rapidly, which requires immediate access to the telemetry needed to reconstruct the incident timeline, determine scope, and evaluate business impact. Retention that requires days of data restoration does not support a four-day disclosure window.
These three factors, regulatory overlap, enforcement intensity, and disclosure speed, mean that financial services retention requirements are not just about storing data. They are about maintaining an operational capability: the ability to produce complete, granular, searchable security telemetry on demand, at any point within the retention window, for any regulator that requests it.
SEC cybersecurity disclosure rule: what it requires in your telemetry stack
The SEC's cybersecurity disclosure rule, adopted in 2023, requires registrants to disclose material cybersecurity incidents within four business days of determining materiality. It also requires annual disclosure of cybersecurity risk management processes, including how the organization detects, assesses, and remediates incidents.
The rule does not specify a telemetry retention period. It does something more demanding: it creates an implicit requirement for immediate access to whatever data is needed to assess materiality and reconstruct incident timelines.
In practice, this means the organization must be able to answer several questions rapidly when an incident occurs. When did the incident begin? What systems were affected? What data was accessed or exfiltrated? What was the scope of the compromise? How was it detected? What response actions were taken?
Answering these questions requires telemetry that spans the full duration of the incident, which may be weeks or months before detection. It requires telemetry from all relevant sources, authentication, network, endpoint, cloud, and application. And it requires that this telemetry is immediately queryable, not in cold archive awaiting restoration.
The practical interpretation for most financial institutions is that security-relevant telemetry should be retained in hot, searchable storage for a minimum of 12-24 months. This provides the retrospective visibility needed to reconstruct incident timelines for incidents that may have persisted for months before detection.
DORA (EU): log retention requirements for ICT risk management
The Digital Operational Resilience Act (DORA), effective January 2025, establishes ICT risk management requirements for EU financial entities, banks, insurance companies, investment firms, and payment service providers.
DORA requires financial entities to maintain comprehensive ICT incident management capabilities, including the ability to detect, classify, and report ICT-related incidents. It mandates that entities maintain records of ICT incidents, audit trails, and supporting log data sufficient to support regulatory reporting and post-incident analysis.
The regulatory technical standards under DORA specify that entities must retain ICT incident records and supporting data for periods aligned with regulatory review cycles, typically five or more years. The most recent data, the last 12-24 months, must be immediately accessible for incident analysis and regulatory inquiry.
DORA also introduces specific requirements around ICT third-party risk management, which creates retention obligations for telemetry related to third-party service providers, cloud platforms, SaaS vendors, and managed service providers. Entities must be able to demonstrate monitoring coverage and incident response capabilities across their third-party ecosystem.
The practical implication is that DORA requires both breadth (all ICT-relevant telemetry, including third-party sources) and depth (multi-year retention with immediate accessibility for recent data). Financial entities that rely on SIEM-only retention, with its volume-based cost constraints and limited retention windows, will struggle to meet DORA's requirements without supplementary telemetry infrastructure.
OCC and FFIEC: retention mandates for US banks and thrifts
The Office of the Comptroller of the Currency (OCC) heightened standards and the Federal Financial Institutions Examination Council (FFIEC) IT examination handbook establish the retention framework for US banks and thrifts.
OCC heightened standards require banks to maintain comprehensive audit trails for information security events. Examiners evaluate whether the bank can produce log data spanning multiple examination cycles, typically two to four years. The expectation is not just that data exists, but that it is accessible and searchable within the examination timeline.
The FFIEC IT examination handbook recommends retention of system and security logs sufficient to support examination, incident investigation, and forensic analysis. While specific retention periods are not mandated, the handbook references examination and enforcement timelines that span three to seven years. The practical expectation is that banks retain security telemetry for the longer end of this range, with operational accessibility for at least the most recent 12-24 months.
Both OCC and FFIEC examiners test retention capabilities during examinations. The test is practical: the examiner requests specific log data for a specific time period and evaluates the institution's ability to produce it. Institutions that can produce complete, searchable data within hours pass. Institutions that require days to restore cold archive data, manually reconstruct logs from multiple systems, or discover gaps in their retained data face examination findings.
The findings are consequential. Matters Requiring Attention (MRAs) and Matters Requiring Immediate Attention (MRIAs) related to log retention create remediation timelines, increase examination scrutiny, and can affect the bank's supervisory rating.
What 'audit-ready' actually means for your log infrastructure
"Audit-ready" is a term frequently used in compliance discussions but rarely defined precisely. For financial services log retention, audit-ready means four things.
Completeness. The retained data covers all required log types for the full retention period. No sources are missing because they were filtered before SIEM ingestion. No time periods have gaps because of retention policy inconsistencies or storage failures. The data is a complete record.
Accessibility. The retained data is queryable at operational speed. When an examiner requests authentication logs for a specific user over the last 18 months, the institution can produce them within hours, not days. The data is in hot or warm storage, indexed and searchable, not in cold archive requiring restoration.
Integrity. The retained data has not been altered since capture. Immutability controls ensure that no one, including administrators, can modify, delete, or tamper with retained telemetry. The integrity chain is auditable: the institution can demonstrate that the data produced to the examiner is the same data that was captured at the time of the events.
Governance. Access to retained data is itself logged and controlled. The institution can demonstrate who accessed what data, when, and for what purpose. Governance controls ensure that sensitive telemetry (which may contain PII, credentials, or other regulated data) is accessed only by authorized personnel for authorized purposes.
When all four properties are present, the institution's log infrastructure is audit-ready by any reasonable regulatory standard. When any property is missing, the institution carries examination risk, the risk that a regulator will request data the institution cannot produce in the required form and timeframe.
The cost problem: why compliance retention requires a different architecture
The cost of compliance-grade retention in a traditional SIEM architecture is the primary reason most financial institutions fall short of their retention requirements.
A mid-size financial institution generates 3-10 TB of security-relevant telemetry per day. At traditional SIEM pricing (which scales with ingestion volume), retaining this data in hot, searchable storage for 12-24 months costs millions of dollars annually. Extending to the three-to-seven-year horizon that OCC and FFIEC examiners expect pushes costs into the tens of millions.
The response is predictable: institutions filter telemetry before SIEM ingestion, reduce retention windows, tier data to cold storage, and accept gaps in coverage. These cost management strategies directly conflict with regulatory expectations for completeness, accessibility, and the ability to produce data on demand.
The architectural solution is to separate retention from the SIEM. A telemetry substrate, purpose-built for high-volume collection, long-term hot retention, and predictable cost, handles the compliance retention function. The SIEM handles detection and alerting against a curated subset of the data. The substrate retains everything, in full fidelity, in hot searchable storage, at a cost structure that does not scale with volume.
Bloo implements this architecture. It captures all telemetry without ingestion penalties, retains it in hot storage inside the customer's own cloud environment, and provides query performance that satisfies even the most demanding examination timeline. The cost is predictable and volume-independent, eliminating the economic constraint that forces institutions into compliance-threatening retention compromises.
Reference table: regulation × log type × retention period × storage standard
| Regulation | Required Log Types | Minimum Retention | Hot Accessibility | Audit-Ready Standard |
|---|---|---|---|---|
| SEC Cyber Disclosure | All security-relevant: auth, network, endpoint, cloud, application | 12-24 months (practical minimum) | Full period | Complete, searchable, immediate; supports 4-day materiality assessment |
| DORA | ICT incident records, audit trails, third-party monitoring | 5+ years | 12-24 months minimum | Complete, immutable, accessible for regulatory reporting |
| OCC Heightened Standards | Security audit trails, access logs, change management | 3-5 years | 12-24 months minimum | Producible within examination timeline, multi-year coverage |
| FFIEC IT Handbook | System logs, security logs, incident records | 3-7 years | 12 months minimum | Supports examination, investigation, and forensic analysis |
| PCI DSS 4.0 | In-scope system audit trails | 12 months | 3 months minimum | Immediately available for the most recent quarter |
| SOC 2 | Security monitoring and access logs | 12 months (typical) | Full period | Supports auditor inquiry within audit timeline |
This matrix represents practical interpretation based on regulatory text, examination practice, and enforcement precedent. Specific requirements should be validated with legal counsel and applicable regulatory authorities.
Bloo satisfies the most stringent row in this matrix by default. All data is hot, searchable, immutable, and retained for the full policy period. The institution's compliance posture is a function of the architecture, not of how carefully the data pipeline was configured.