PCI DSS 10.2.1.1: Audit logs capture all individual user access to cardholder data
PCI DSS v4.0.1 control 10.2.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.2.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.2
Audit logs capture all individual user access to cardholder data.
Summary
Every time a person reaches cardholder data, the log records who it was.
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.1 | Examine audit log configurations and log data to verify that all individual user access to cardholder data is logged. |
The first of the seven controls under 10.2.1 that say what a log has to contain, and the one most often missing entirely. 10.2.1 asks that logging is enabled; this asks that individual user access to cardholder data is among what it captures, which is a different question and usually a different layer. Infrastructure logging gives you the login and the connection. It does not give you that this person read these rows, and that is what this control wants. The procedure examines log configurations and log data, so it is checked against real records rather than a settings page.
What to prepare
- The list of places cardholder data can be read: databases, applications, reports, file stores, support tools.
- The log configuration for each, showing data access is captured and not just authentication.
- Actual log entries for a recent access, with the individual identifiable.
How to implement it
1. Log at the layer that sees the data. Database audit logging, application-level access logging, or a proxy in front of the store. Operating-system logs record a session, not a read.
2. Make sure the individual is identifiable. Access through an application running as a service account produces a log naming the service account, which is why 8.6.1 and 8.2.1 matter here: the application has to carry the end user through into what it logs.
3. Cover reporting and support paths. Exports, BI tools and support consoles are how cardholder data is most often read, and they are the paths least likely to log at row level.
4. Check a real entry. The procedure examines log data. Reading one entry end to end tells you in a minute whether the field you need is actually populated.
Where this commonly fails
- Authentication logged and data access not, so the log shows people arriving and never what they did.
- Access through a shared application identity, so every read attributes to the same service account.
- Database audit logging enabled for administrative actions only, which is 10.2.1.2 rather than this control.
- Reporting replicas and exports logging nothing, because they were treated as read-only and therefore harmless.
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.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.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 · All controls · 10.2.1.2 →
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.