PCI DSS already requires you to review certain security logs every day. Requirement 10.4.1.1 adds that the review must be performed by automated mechanisms, and it becomes mandatory on March 31, 2025. In practice that means a log management platform, SIEM or equivalent tooling that collects the logs, applies rules, and raises alerts for people to investigate.
Automation doesn't remove people from the process. Requirement 10.4.3 still expects someone to address the exceptions and anomalies the tools find. Two related requirements arrive on the same date: 10.4.2.1, which sets review frequency for other systems through a targeted risk analysis, and 10.7.2, which requires you to detect when your security controls, including log review, stop working.
What does requirement 10.4.1 require today?
Requirement 10.4.1 is already in effect. It requires the following audit logs to be reviewed at least once daily:
- All security events
- Logs of all system components that store, process or transmit cardholder data and/or sensitive authentication data
- Logs of all critical system components
- Logs of all servers and system components that perform security functions, such as network security controls, intrusion detection and prevention systems, and authentication servers
Many organizations meet this today with a mix of scripts, saved searches and someone scrolling through dashboards each morning. That approach struggles as the number of systems grows, and it's hard to prove it happened consistently.
What changes with requirement 10.4.1.1?
Requirement 10.4.1.1 states that automated mechanisms are used to perform audit log reviews. It is best practice until March 31, 2025, after which it will be required and assessed.
The standard doesn't name a product type. What it expects is that software does the first pass: parsing the logs, matching events against rules or baselines, and flagging what needs a human decision. Daily manual reading of raw logs won't satisfy it after the deadline.
PCI DSS v4.0.1, published in June 2024, didn't move this deadline. The Council stated that the revision added and removed no requirements and did not affect the effective dates of the new ones. PCI DSS v4.0 will be retired on December 31, 2024.
How do 10.4.2 and 10.4.2.1 cover everything else?
Not every system needs daily review. Requirement 10.4.2 says logs of all other system components, meaning those not covered by 10.4.1, are reviewed periodically.
Requirement 10.4.2.1, also future-dated to March 31, 2025, says the frequency of those periodic reviews must be defined in a targeted risk analysis performed according to requirement 12.3.1. That analysis has to document:
- The assets being protected
- The threats the requirement protects against
- Factors that contribute to the likelihood or impact of a threat being realized
- The resulting frequency, with justification
- A review at least once every 12 months to confirm the results are still valid, and an updated analysis when needed
Once the tooling is in place for the daily logs, extending automated review to these other components is often straightforward. The targeted risk analysis still has to exist, even if the answer is "daily."
What does "addressed" mean under 10.4.3?
Requirement 10.4.3 requires that exceptions and anomalies identified during the review process are addressed. This is where people come in.
A workable process usually includes:
- Triage. An analyst decides whether an alert is a false positive, expected activity or something that needs investigation.
- Investigation. The analyst gathers context from related logs, asset owners and change records.
- Escalation. Anything that looks like a security incident goes into the incident response process under requirement 12.10.
- Closure with a record. Each alert ends with a documented outcome, even when that outcome is "benign, rule tuned."
Assessors will look for that trail. An alert queue nobody works through doesn't meet 10.4.3, however good the rules are.
What tools can automate log review?
Several categories of tooling can meet 10.4.1.1. Most organizations use more than one.
| Category | What it does well | Watch out for |
|---|---|---|
| Centralized log management | Collects, stores and searches logs; supports saved searches and scheduled alerts | Alerting may be basic; correlation across sources can be limited |
| Security information and event management (SIEM) | Correlates events across sources, applies detection rules, manages alerts and cases | Needs ongoing tuning; cost often scales with data volume |
| Cloud provider logging and alerting services | Native coverage of cloud control planes and managed services | Covers only that provider; needs to feed a central view |
| Managed detection or monitoring services | Adds staff who triage alerts around the clock | You remain responsible for compliance; responsibilities need to be written down |
Whichever you choose, the platform should also support the rest of requirement 10. That includes protecting logs from modification (10.3), retaining at least 12 months of history with the most recent three months immediately available for analysis (10.5.1), and relying on synchronized time sources (10.6).
How do you tune automated log review so people actually use it?
An untuned system produces so many alerts that analysts stop reading them, which fails 10.4.3 just as surely as having no tool. Tuning is an ongoing job, not a setup step.
Start with the events PCI DSS already names
Requirement 10.2.1 lists the events that must be logged: individual user access to cardholder data, actions taken by anyone with administrative access, access to audit logs, invalid logical access attempts, changes to identification and authentication credentials, initializing, starting, stopping or pausing audit logs, and creation and deletion of system-level objects. Build detection rules around those events first, then add rules for the risks specific to your environment.
Suppress known-good activity carefully
Scheduled jobs, backup agents and vulnerability scanners generate predictable noise. Suppress them with narrow conditions, such as a specific account, source and time window, rather than broad exclusions that could hide misuse of the same account.
Set severity and routing
Not every alert needs the same response time. Define severities, decide who receives each one, and make sure high-severity alerts reach someone outside business hours.
Record tuning decisions
Keep a change log for detection rules: what changed, why and who approved it. Tuning is a change to a security control, and assessors may ask how you know a suppression didn't create a blind spot.
Review coverage regularly
New systems get added to the cardholder data environment and old ones get decommissioned. Compare your log source list against your system component inventory under requirement 12.5.1 on a schedule, so gaps don't open quietly.
Don't forget requirement 10.7.2: monitoring the monitor
Requirement 10.7.2 requires that failures of critical security control systems are detected, alerted and addressed promptly. The list includes network security controls, intrusion detection and prevention, change-detection mechanisms, anti-malware solutions, physical and logical access controls, audit logging mechanisms, segmentation controls if used, audit log review mechanisms, and automated security testing tools if used.
Service providers already have to meet a version of this under requirement 10.7.1. For all other entities, 10.7.2 is best practice until March 31, 2025, when it becomes mandatory for everyone and supersedes 10.7.1. Note that the list explicitly names audit log review mechanisms, so your new automation must itself be monitored.
Common ways to do that:
- Alert when a log source goes silent for longer than expected
- Alert on parsing failures or sudden drops in event volume
- Monitor the health of collectors, agents and forwarders
- Track whether scheduled searches and correlation rules actually ran
Requirement 10.7.3, on the same timeline for non-service providers, covers what happens next. You restore the function, document how long the failure lasted and why it happened, address any security issues that arose during the gap, and put controls in place to prevent a repeat.
What evidence will your assessor want?
Plan the evidence while you build the tooling. A typical request list for requirements 10.4 and 10.7 includes:
- A list of log sources mapped to the categories in 10.4.1
- Configuration showing logs are collected and reviewed automatically
- The detection rules or use cases in place, with their change history
- A sample of alerts and the records showing how each was addressed
- The targeted risk analysis supporting your 10.4.2.1 review frequency
- Alerts and tickets showing log source failures were detected and handled
- Roles and responsibilities for log review, as required by 10.1.2
- For outsourced monitoring, the written split of responsibilities between you and the provider
Frequently asked questions
Does 10.4.1.1 mean people no longer review logs?
No. Automation replaces manually reading raw logs, not human judgment. Analysts still review what the tools flag and document how each exception or anomaly was handled under 10.4.3.
Do we need a SIEM to comply?
Not necessarily. The requirement is for automated mechanisms, and a well-configured log management platform with scheduled detection rules and alerting can meet it. A SIEM becomes more useful as the number of log sources and the need for correlation grow.
Can we outsource log review?
Yes, and many small and mid-sized organizations do. You remain responsible for compliance, so document which requirements the provider handles, confirm its compliance status, and keep evidence that alerts it escalates are addressed on your side.
Should we wait for the deadline?
We wouldn't. Tuning takes months, and the first weeks of any new detection setup are the noisiest. Running the process well before March 31, 2025 also gives you a history of alerts and responses to show your assessor.
Next steps
- Inventory your log sources and map them to the 10.4.1 categories.
- Choose tooling that fits your size and existing platforms, and confirm it supports retention and log protection.
- Write the targeted risk analysis for 10.4.2.1.
- Build detection rules around the 10.2.1 events, then tune them against real traffic.
- Add health monitoring for log sources and review mechanisms to satisfy 10.7.2.
- Document roles, triage steps and escalation paths so 10.4.3 is repeatable.