PCI DSS 10.4.1: The following audit logs are reviewed at least once daily
PCI DSS v4.0.1 control 10.4.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.4.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.4
The following audit logs are reviewed at least once daily:
- All security events.
- Logs of all system components that store, process, or transmit CHD and/or SAD.
- Logs of all critical system components.
- Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).
Summary
Somebody looks at the security-relevant logs every day, and can show they did.
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.4.1.a | Examine security policies and procedures to verify that processes are defined for reviewing all elements specified in this requirement at least once daily. |
| 10.4.1.b | Observe processes and interview personnel to verify that all elements specified in this requirement are reviewed at least once daily |
The word doing the work is daily. 10.4.1.a examines whether a process is defined for reviewing all four categories at that frequency; 10.4.1.b observes the process and interviews people to verify it happens. Collecting logs is 10.2.1 and is comparatively easy; this control is the one entities actually fail, because daily human review does not survive contact with a normal workload. 10.4.2 covers everything else on a periodic basis, so the daily obligation is deliberately scoped to these four categories rather than to all logs.
What to prepare
- The defined review process, naming the four categories and who reviews them.
- Evidence of the reviews themselves, dated, including days when nothing was found.
- The escalation route for something the review surfaces, and examples of it being used.
- The list of what counts as a critical system component for you, since the third bullet depends on it.
How to implement it
1. Automate the triage, keep the human decision. The requirement permits tooling to do the reviewing; what it does not permit is nobody looking. An alerting pipeline that surfaces exceptions daily, with a person acknowledging them, satisfies the control and survives a busy week.
2. Record the quiet days. Evidence of review is a continuous record. A file that only contains days with findings looks identical to a process that ran three times.
3. Define critical system components before you scope the review. The third bullet inherits whatever that list says, so an undefined list makes the review scope undefined too.
4. Make the escalation the same one your incident plan uses. A review that finds something and has nowhere to send it produces a note, not a response, and 12.10.1 is examined against real incidents.
Where this commonly fails
- Daily in the policy, weekly in practice, which 10.4.1.b catches at interview.
- Reviewing only the systems in the cardholder data environment and omitting the security systems named in the fourth bullet, such as authentication servers and IDS.
- Alerting configured but muted, so the process technically runs and nobody sees the output.
- Gaps around holidays and handovers, which is where the record shows the process depends on one person.
Related controls
Others in section 10.4:
| Control | What it requires |
|---|---|
| 10.4.1.1 | Automated mechanisms are used to perform audit log reviews |
| 10.4.2 | Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed… |
| 10.4.2.1 | The frequency of periodic log reviews for all other system components… |
| 10.4.3 | Exceptions and anomalies identified during the review process are addressed |
← 10.3.4 · All controls · 10.4.1.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.