PCI DSS 10.2.1.6: Audit logs capture

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

Audit logs capture the following:

• All initialization of new audit logs, and
• All starting, stopping, or pausing of the existing audit logs.

Summary

The logs record their own starting, stopping and pausing, and the creation of any new log.

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.6	Examine audit log configurations and log data to verify that all elements specified in this requirement are captured.

This is the anti-tampering element of 10.2.1. An attacker who cannot delete log entries can often stop the logging service, act, and start it again, which leaves a clean log with a hole in it. Recording the stop and the start is what turns that hole into a visible event, and it is why the gap matters more than the missing entries. The natural failure here is circular: a service that is stopped cannot record its own stop. The answer is that the record belongs somewhere else, either in the operating system's own service log or at a collector that notices the stream ended.

What to prepare

• Configuration showing log service start, stop and pause events are captured.
• Where those events are recorded, which should not be only inside the service that stopped.
• Evidence of monitoring for a stream that goes silent.
• Real entries from a recent restart, planned or otherwise.

How to implement it

1. Detect silence, not just events. A collector alerting when a source stops sending is the most reliable form of this control, because it works even when the source could not write its own final entry.

2. Forward off the host quickly. Logs that leave the machine in near real time make a local stop far less useful to an attacker, and the collector holds what was already sent.

3. Treat planned restarts as expected and recorded, not as noise to suppress. Suppressing them is how the unplanned one gets missed.

4. Cover new log initialisation. It is the first named element and the one usually forgotten, since creating a fresh log is a way to start a clean record.

Where this commonly fails

• The stop recorded only by the service that stopped, so a deliberate stop leaves nothing.
• No alerting on a source that goes quiet, so a gap is found only when someone looks.
• Restart events filtered out as routine noise at the collector.
• Log rotation and reinitialisation indistinguishable from a fresh log being started deliberately.

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.3	Audit logs capture all access to audit logs
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.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.5 · All controls · 10.2.1.7 →

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.