Audit log retention requirements compared

PCI DSS sets a fixed floor for audit log history. Requirement 10.5 has one sub-requirement, 10.5.1, which requires audit log history to be retained for at least 12 months, with at least the most recent three months immediately available for analysis. The standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities that could affect the security of the cardholder data environment, including merchants, processors, acquirers, issuers and service providers. The PCI Security Standards Council owns the standard, but the payment brands decide which entities must validate and run any enforcement.

• Fixed floor: 12 months of history under 10.5.1 is the minimum, not a target for every log source.
• Hot window: the most recent three months must be immediately available, which usually drives how much data sits in fast storage.
• Version: PCI DSS v4.0.1 is the only active version, so size storage against its wording.
• Scope: systems that could affect the cardholder data environment often fall under the same clock, which can widen the log sources you keep.
• Evidence: the assessor will check retention against the ROC or SAQ, so keep the retention configuration as evidence.

Confirm with your acquirer or payment brand which validation level and questionnaire apply to you, and confirm which of your systems count as in scope.

NERC CIP sets a specific rolling window for certain logs. Under CIP-007-6, Part 4.3 requires retaining the Part 4.1 logs, where technically feasible, for at least the last 90 consecutive calendar days, except under CIP Exceptional Circumstances. The standards apply to entities that own or operate BES Cyber Systems, and their scope depends on the impact categories set in CIP-002-5.1a. Compliance is monitored by the Compliance Enforcement Authority through audits, spot checks, self-reports and data submittals, and there is no CIP certificate.

• Rolling window: 90 consecutive calendar days is the period for the Part 4.1 logs, and it is measured against the last 90 days, not a calendar quarter.
• Feasibility qualifier: the 'where technically feasible' wording must be documented for any system that cannot retain that long.
• Applicable Systems: the retention requirement attaches to the systems named in the CIP-007-6 tables, so map which assets are in scope first.
• Protection duty: logs must be protected from unauthorized access or change, and the standard sets no fixed period beyond the 90 days for this part.
• Upcoming changes: CIP-015-1 adds internal network security monitoring with future enforcement from 1 October 2028, so plan for it now.

Confirm with your Regional Entity which assets are high, medium or low impact and how it reads the feasibility exception for your legacy devices.

DORA does not set one fixed retention number for ICT logs. Under Commission Delegated Regulation (EU) 2024/1774, Article 12(2), the financial entity defines which events are logged, how long logs are retained and how they are protected, in line with its ICT risk assessment. DORA's Article 10 on detection adds the duty to detect anomalous activity, and competent authorities supervise the result using the powers in Article 50. The retention period is therefore a documented decision that supervisors will test, not a number taken from the Regulation.

• Entity-defined period: the period is set by your ICT risk assessment, so the rationale must be written down.
• Scope of events: the same assessment decides which events are logged, which drives volume more than the period alone.
• Protection: logs must be protected against unauthorized access or change for the whole retention period.
• Supervision: there is no certificate. Supervisors review the retention decision during inspections.
• Overlap: where a financial entity is also subject to PCI DSS or NIS2, the longer applicable period usually governs the shared store.

Confirm with your national competent authority whether it expects a specific minimum period in its supervisory guidance, and confirm how your ICT risk assessment justified the period you chose.

NIS2 sets no fixed log retention period in the Directive itself. Entities under NIS2 must manage cybersecurity risk, and the retention period is a decision each entity makes in its risk management and incident handling measures. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. The Directive creates no certificate, so the evidence you produce for a supervisor is the logging design and its records.

• No fixed number: the period is defined by the entity, so document the basis for it.
• Incident support: logs must be long enough to support incident detection, reporting and investigation under the NIS2 reporting timelines.
• National transposition: check your national law, since member states may add their own rules for logs and records.
• Supply chain: logs held by managed service providers fall under the same question, so confirm who keeps them and for how long.
• Evidence: supervisors may ask for logs or records during information requests or scans, so retrieval speed matters as well as the period.

Confirm with your national competent authority how it reads the Directive, and confirm whether any sector-specific rule sets a longer period for your organization.

CMMC does not set a fixed number of days for audit logs in the Level 2 assessment guidance. The CMMC Assessment Guide Level 2 says the organization must define which audit logs and events to capture, check that captured records contain the required events, and retain logs long enough to investigate a security event. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 3 assessments are performed by DCMA DIBCAC. The test is therefore whether your retention lets you investigate, which you must show with your own defined period.

• Investigation test: the period must allow an investigation of a security event, so set it from the incidents you expect to examine.
• Defined events: the organization defines the audit logs and events, and the assessor checks that they contain the required records.
• Contract flowdown: primes and subcontractors may impose longer retention in contracts, so review the terms.
• Level differences: confirm the level your contract requires, since Level 2 and Level 3 are assessed by different bodies.
• Records: keep the retention decision and the event list as documentation for the assessor.

Confirm with your contracting officer or prime which CMMC level applies, and confirm with your C3PAO how it expects the retention period to be justified.

The HIPAA Security Rule does not set a fixed period for system audit logs in the supplied guidance. It requires that Security Rule documentation be kept for six years, under 45 CFR 164.316(b)(2)(i), which adds ongoing storage and maintenance effort. Audit logs are then sized by the covered entity's own risk analysis, policies and procedures. The HIPAA framework produces no certificate. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation.

• Six-year documentation: policies, procedures and required documentation must be kept for 6 years, which is a different clock from log history.
• Log period is yours: the period for audit logs follows from your risk analysis, so record why you chose it.
• Storage cost: a six-year documentation duty does not mean six years of logs, so separate the two in your storage plan.
• Business associates: confirm which business associates hold ePHI logs and how long they keep them.
• No certification shortcut: no certificate removes the need to show retention decisions during an investigation.

Confirm with your privacy and security officers how the risk analysis set the audit log period, and confirm whether any state law or contract sets a longer requirement.