PCI DSS 10.5.1: Retain audit log history for at least 12 months, with at least the most recent three months
PCI DSS v4.0.1 control 10.5.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 10.5.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.5
Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
Summary
Keep twelve months of audit logs, with the last three months available immediately rather than from cold storage.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 10.5.1.a | Examine documentation to verify that the following is defined: • Audit log retention policies. • Procedures for retaining audit log history for at least 12 months, with at least the most recent three months immediately available online. |
| 10.5.1.b | Examine configurations of audit log history, interview personnel and examine audit logs to verify that audit logs history is retained for at least 12 months. |
| 10.5.1.c | Interview personnel and observe processes to verify that at least the most recent three months’ audit log history is immediately available for analysis. |
Deceptively simple, and it has two distinct obligations that fail separately. Twelve months of retention is a storage question. Three months immediately available for analysis is an access question, and it is the one an assessor tests: logs archived to cold storage that take a restore request and a day to read are retained but not immediately available. 10.5.1.a examines the retention policy, 10.5.1.b verifies logs are available, and 10.5.1.c verifies the twelve months are actually retained. Pairs with 10.4.1: daily review is only possible on logs you can reach.
What to prepare
- The retention policy stating both periods.
- A demonstration that a log from three months ago can be searched now, not restored later.
- Evidence that logs from twelve months ago still exist.
- The retention configuration itself, since a policy and a tool setting disagreeing is common.
How to implement it
1. Check what your platform actually keeps by default. Managed logging services frequently default to 30 or 90 days, which satisfies neither obligation, and the default is rarely revisited after the first month of a deployment.
2. Separate hot from cold deliberately. Three months searchable and nine archived is the shape the requirement describes, and it is usually much cheaper than keeping twelve months hot.
3. Test the restore before an assessor asks. "Immediately available" is demonstrated, not asserted, and the first restore attempt is where the gaps in an archive appear.
4. Include every source. Retention is often configured for the application and forgotten for network devices, databases and the security tooling, which are the logs that matter in an investigation.
Where this commonly fails
- Ninety-day retention inherited from a platform default and never changed.
- Twelve months held, but all of it in cold storage, so nothing is immediately available.
- Retention set on the aggregator while individual sources roll over sooner.
- A policy stating twelve months and a configuration doing something else, which 10.5.1.c compares.
Related controls
← 10.4.3 · All controls · 10.6.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.