Audit log retention

Description

Audit log retention is the unglamorous infrastructure piece that turns "we have logging" into evidence usable by a regulator, auditor, or litigator months or years after the fact. Most modern privacy, security, and sectoral regulations require some form of audit logging covering user-data access (who looked at what record, when, from where), administrative actions (who changed what configuration), security events (authentication failures, privilege escalations, anomalous queries, lateral movement signals), and material business operations whose later reviewability is itself a substantive obligation. The program decomposes into three operational concerns. Coverage names which event categories generate audit records and which systems contribute to the centralized log feed; gaps surface most often at the edges where SaaS vendor admin actions, third-party integrations, and shadow-IT surfaces fail to emit anything useful and the operator then has no visibility into who modified what. Immutability is the architecturally load-bearing fact: a log that the actor whose actions were logged could later edit is not, in regulator terms, an audit log at all. Implementation typically involves write-once or append-only storage (cloud object storage with object-lock and retention-policy enforcement, or a dedicated SIEM with tamper-evident hashing where each batch's hash chains to the prior batch), with chain-of-custody documentation for any export to an investigator. Retention itself is the third concern: a log that was supposed to be kept for seven years but rotated out at one will surface as a gap only when someone actually goes looking, and the going-to-look event is almost always a regulator notice or a litigation hold rather than a routine audit. The trade-off pressure is cost (full-fidelity retention at SIEM-grade indexing is expensive at scale, and operators routinely under-budget the storage layer), and the optimization that usually works is hot-warm-cold tiering: recent logs indexed and immediately queryable, older logs in cheaper object storage with on-demand rehydration, oldest logs in glacier-class archive with the retention-period contract enforced by the storage provider. Retention-period anchors vary by source and the operator typically resolves to the strictest applicable. SOX requires seven years for logs relevant to financial reporting (Sarbanes-Oxley Act §802 plus PCAOB Auditing Standard 1215). HIPAA requires six years (45 CFR §164.316(b)(2)). GDPR breach-investigation logs typically run for the lifetime of the underlying processing plus a residual window aligned to the supervisory authority's likely inquiry horizon (Article 33 plus EDPB guidance). PCI DSS v4.0 Requirement 10.5 requires one year online with three months immediately retrievable. NIS2 and DORA add layered cybersecurity-incident retention obligations on top of these for in-scope entities, with the DORA ICT-incident reporting framework requiring records that support the major-incident classification and reporting timelines. Sectoral regulators in financial services (SEC, FINRA, FCA), telecommunications (FCC, Ofcom), and healthcare (HHS OCR, MHRA) maintain their own tables that an in-scope operator resolves separately.

Required by (5 regulations)

• NIS2

  NIS2 Directive Article 21 + Annex requires essential and important entities to maintain logging of network and information system activity sufficient to detect and analyze cybersecurity incidents. National-law transposition varies on retention period; typical floor is 12 months. Logs must be available to competent authorities upon request.

  Directive (EU) 2022/2555 Article 21 (security risk-management measures including logging); national-law transposition deadline 2024-10-17

• CIRCIA

  CIRCIA's underlying statutory authority (6 U.S.C. § 681) anticipates covered-entity record-keeping requirements that will be operationalized in CISA's final rule; the NPRM (2024-04-04) proposed a 2-year retention floor for records supporting incident reports. Final rule has not been issued as of mid-2026.

  6 U.S.C. § 681 (CIRCIA); CISA NPRM 89 Fed. Reg. 23644 (April 4, 2024); final rule pending

  Source →

• GDPR

  GDPR Article 32 + Article 30 require security-record-keeping appropriate to risk; Article 33 breach-notification requires logs sufficient to characterize the incident within the 72-hour notification window. No fixed retention period under GDPR itself; EDPB guidance on incident response suggests 12-24 month retention as a baseline for systems processing personal data at scale.

  Regulation (EU) 2016/679 Article 30 (records of processing activities); Article 32 (security of processing); Article 33 (breach notification)

• China CIIPA

  China CIIPA requires logging and retention of network-security events for critical information infrastructure.

  Regulations on the Security Protection of Critical Information Infrastructure (State Council Order No. 745); implementing Cybersecurity Law Articles 31-39

  Source →

• UK GDPR

  UK GDPR Article 5(2) accountability and Article 32 security obligations are supported by audit-log retention.

Fulfilled by (3)

• datadog · partial · low effort · $$
• splunk · full · medium effort · $$$
• In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• log-retention policy
• log-storage configuration
• tamper-evidence design notes