PCI DSS 10.2.2: Audit logs record the following details for each auditable event
PCI DSS v4.0.1 control 10.2.2: 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 record the following details for each auditable event:
- User identification.
- Type of event.
- Date and time.
- Success and failure indication.
- Origination of event.
- Identity or name of affected data, system component, resource, or service (for example, name and protocol).
Summary
Every log entry says who, what, when, whether it worked, where it came from, and what it touched.
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.2 | Interview personnel and examine audit log configurations and log data to verify that all elements specified in this requirement are included in log entries for each auditable event (from |
Where 10.2.1 requires logging to exist, this defines what makes an entry useful. Six elements, and two are habitually missing. Success and failure indication is what turns a stream of events into something you can investigate: a log of successful logins without the failures hides exactly the pattern you would look for. Origination of event is what lets you tell an administrator at their desk from the same credential arriving from elsewhere. Without both, the daily review at 10.4.1 has nothing to find, which is why this control precedes it in practice as well as in numbering.
What to prepare
- Sample entries from each log source, checked against all six elements.
- The mapping from your log format to the six, since names differ per system.
- Evidence for components that do not log natively in this shape.
How to implement it
1. Check a real entry against the list. Six elements is short enough to verify by reading one line from each source, and that exercise finds more than reviewing a configuration does.
2. Log failures as loudly as successes. Default configurations frequently record only successful operations, and the failures are what an investigation needs.
3. Keep origination meaningful. A source address of a load balancer or a proxy for every entry satisfies the letter and defeats the purpose; forward the original where the platform allows.
4. Name the affected resource. "Update succeeded" without saying what was updated cannot support an investigation, and it is the element most often lost when logs are summarised.
Where this commonly fails
- Successes logged and failures dropped, so the useful half is absent.
- Every entry showing the proxy as the origin.
- User identification recorded as a service account, which points back at 8.2.1.
- The affected resource omitted, leaving entries that cannot be acted on.
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.6 | Audit logs capture… |
| 10.2.1.7 | Audit logs capture all creation and deletion of system-level objects |
← 10.2.1.7 · All controls · 10.3.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.