PCI DSS 10.2.1.3: All access to the audit logs is itself logged, whether reading, changing or deleting them.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.2

Audit logs capture all access to audit logs.

Summary

All access to the audit logs is itself logged, whether reading, changing or deleting them.

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.2.1.3	Examine audit log configurations and log data to verify that access to all audit logs is captured.

Short, and the point of it is tampering: malicious users try to alter logs to hide their actions, and a record of every access lets the entity trace tampering to an individual account. It pairs with 10.3.1 and 10.3.2, which restrict and protect the logs, but it covers something those do not. Restricting access says who may look or change; this says that any access, reading included, leaves a mark. The practical difficulty is that the mark has to survive somewhere the same person cannot reach, which usually means the log-access record belongs outside the system holding the logs.

What to prepare

• The list of everyone and everything with read access to audit logs, including support and analytics tooling.
• Configuration showing all access is recorded: reads, changes, additions and deletions.
• Real entries showing a recent read, and where that record is held.

How to implement it

1. Send log access records somewhere separate. A record of who read the logs, stored in the same place as the logs and readable by the same people, protects against far less than it appears to.

2. Include the SIEM and the query interface. Reads through a console rather than on the host are recorded only in that console's own audit trail, which has to be turned on and collected.

3. Cover the automated readers too. Integrations and exports read logs continuously, and knowing which reads are routine is what makes an unusual one visible.

4. Watch for reads by people who do not investigate. That is the signal this control exists to make available, and it is only useful if someone looks at it.

Where this commonly fails

• Log access recorded into the same store the reader can edit or clear.
• Console and SIEM reads uncaptured, so the only logged reads are the rare ones done on the host.
• Read access granted broadly for convenience, making the record too noisy to be worth reviewing.
• The control assumed satisfied by the access restrictions in 10.3, which are a different requirement.

Related controls

Others in section 10.2:

Control	What it requires
10.2.1	Audit logs are enabled and active for all system components and cardholder data
10.2.1.1	Audit logs capture all individual user access to cardholder data
10.2.1.2	Audit logs capture all actions taken by any individual with administrative access…
10.2.1.4	Audit logs capture all invalid logical access attempts
10.2.1.5	Audit logs capture all changes to identification and authentication credentials…
10.2.1.6	Audit logs capture…
10.2.1.7	Audit logs capture all creation and deletion of system-level objects
10.2.2	Audit logs record the following details for each auditable event…

---

← 10.2.1.2 · All controls · 10.2.1.4 →

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.