Requirement 10 of PCI DSS asks you to log activity on every system in your card data environment, protect those logs from tampering, review them every day, and keep them for at least a year. The logs must show who accessed card data, what administrators did, and every failed login. Since 31 March 2025, the daily review must use automated tools, and every business must detect and respond quickly when a critical security control, such as a firewall or anti-malware tool, stops working.
What has to be logged?
Requirement 10.2.1 says audit logs must be turned on and active for all system components and card data. Requirements 10.2.1.1 to 10.2.1.7 list the events: every individual user access to card data, every action by anyone with administrative access, all access to the audit logs themselves, invalid login attempts, changes to accounts and credentials (including new accounts and raised privileges), starting, stopping, or pausing the logs, and creating or deleting system-level objects. That covers servers, workstations, firewalls, routers, switches, wireless access points, databases, and the applications that handle card data. If an attacker turns logging off, that action itself should leave a record.
What does each log entry need to include?
Requirement 10.2.2 says each entry must record the user, the type of event, the date and time, whether it succeeded or failed, where the event came from (such as an IP address), and the name of the data, system, or service affected. Without these, a log can tell you that something happened but not who did it or where. That's why unique user IDs under Requirement 8 matter so much. A shared "admin" account makes every log entry anonymous.
How should logs be protected?
Logs are evidence, and attackers try to erase them. Requirement 10.3.1 limits who can read them to people with a job-related need. Requirement 10.3.2 protects them from being changed. Requirement 10.3.3 says they must be backed up promptly to a secure, central, internal log server or other media that is hard to alter. Requirement 10.3.4 asks for file integrity monitoring or change detection on the logs, so that any change to existing entries raises an alert. New entries being added shouldn't trigger one.
How often do logs need to be reviewed?
At least once a day for the important ones. Requirement 10.4.1 lists them: all security events, logs from systems that store, process, or send card data, logs from critical system components, and logs from systems that perform security functions, such as firewalls, intrusion detection systems, and authentication servers. Logs from your other in-scope systems are reviewed on a schedule you set through a targeted risk analysis (Requirements 10.4.2 and 10.4.2.1). Requirement 10.4.3 says exceptions and anomalies found in a review must be followed up. A review that spots something odd and moves on doesn't count.
What changed on 31 March 2025?
Three parts of Requirement 10 became mandatory. Requirement 10.4.1.1 says the daily reviews must use automated mechanisms, such as a SIEM or a log management service with alerting. Reading raw logs by hand every morning no longer meets it. Requirement 10.4.2.1 asks you to set the review frequency for other systems through a targeted risk analysis under Requirement 12.3.1. And Requirement 10.7.2, which used to apply only to service providers, now applies to every business: you must detect, alert on, and promptly address failures of critical security controls. Those include network security controls, intrusion detection, change detection, anti-malware, physical and logical access controls, audit logging, log review tools, and automated security testing tools. If the anti-malware agent quietly stops on a server, someone needs to find out.
How long do logs need to be kept?
Requirement 10.5.1 says at least 12 months, with at least the most recent three months available right away for analysis. The rest can sit in cheaper archive storage, as long as you can restore it when needed. Twelve months matters because breaches are often found long after they start, and an investigator will want to trace the attacker back to the first day.
Why does time sync matter for logs?
If every system's clock is a few minutes off, you can't line up events across systems to see what happened in what order. Requirements 10.6.1 to 10.6.3 ask for time synchronization technology such as NTP. One or more designated internal time servers take time from external sources based on International Atomic Time or UTC, and every other system takes its time from those internal servers. Time settings must be protected so only authorized staff can change them.
How does an ASV scan fit with Requirement 10?
A quarterly ASV scan under Requirement 11.3.2 sends a large number of probes at your public systems over an hour or more, so it should show up clearly in your logs and alerts. That makes it a handy check on your monitoring: if your log review didn't notice your own scan, it probably wouldn't notice an attacker doing the same thing. ServerScan is a PCI Approved Scanning Vendor, and the pricing page shows what a plan includes. Requirement 11 covers the scan itself.
Go on to Requirement 11 - Regular Security Testing.
Go back to Requirement 9 - Physical Access Restrictions.