PCI DSS 10.2.1.5: Audit logs capture all changes to identification and authentication credentials
PCI DSS v4.0.1 control 10.2.1.5: 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 changes to identification and authentication credentials including, but not limited to:
- Creation of new accounts.
- Elevation of privileges.
- All changes, additions, or deletions to accounts with administrative access.
Summary
Changes to accounts and credentials are logged: new accounts, privilege escalations, and anything done to an administrative account.
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.5 | Examine audit log configurations and log data to verify that changes to identification and authentication credentials are captured in accordance with all elements specified in this requirement. |
Three named elements, and the third is broader than the first two: all changes, additions, or deletions to accounts with administrative access. For an ordinary account the control wants creation and elevation. For an administrative account it wants everything. This is the logging counterpart to the approval trail in 8.2.4: that control asks that a change was approved, and this asks that it was recorded, which is what lets the two be compared. An unapproved change is only findable if it was logged, so an entity with strong approvals and weak identity logging cannot actually detect the case both controls exist for.
What to prepare
- Configuration showing account lifecycle events are logged in each identity store, not only the primary directory.
- Real entries for a creation, an elevation and a deletion.
- The definition of which accounts count as administrative, since the third element depends on it.
How to implement it
1. Log every identity store. The directory usually does this well. Applications with their own user tables usually do not, and that is where an account can be created without trace.
2. Capture the actor, not just the change. "Privileges granted" is much less useful than who granted them, and it is the field that makes the comparison with 8.2.4 possible.
3. Include group membership. Elevation most often happens by adding someone to a group rather than by editing their account, and a log that watches only the user object misses it.
4. Alert on administrative changes. They are rare and consequential, which makes them one of the few things worth alerting on individually.
Where this commonly fails
- Application-local user tables outside the logging pipeline.
- Group membership changes not treated as privilege changes.
- Deletions unlogged, so an account that existed and was removed leaves no evidence it ever did.
- No definition of administrative access, leaving the third element unassessable.
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.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.4 · All controls · 10.2.1.6 →
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.