Requirement 10 of PCI DSS is the logging requirement: log access to cardholder data and to the systems around it, protect those logs, review them every day and keep them for a year. Version 4.0 tightened it, and since March 31, 2025 the new parts are mandatory, including the one that matters most for tooling: log reviews must now be automated.
This guide walks through every Requirement 10 item in PCI DSS v4.0.1 in plain language, with what an assessor will expect to see, followed by the related requirements outside Requirement 10 that a SIEM usually covers. If you want the whole standard, see our PCI DSS compliance checklist.
The short answer: PCI DSS 4.0 requires audit logs on all in-scope system components; specific events and six fields per record; logs protected from change and copied promptly to a central log server; automated daily review of security events; detection of failed security controls; synchronized clocks; and at least 12 months of log history, with the last three months immediately available.
Requirement 10 on one page
The seven parts of PCI DSS v4.0.1 Requirement 10, and where the new items sit
Which version applies
PCI DSS v4.0.1, published in June 2024, is the current version. It was a limited revision of v4.0 with no requirements added or removed. Of the 64 requirements that were new in v4.0, 51 were “future-dated” and stayed best practice until March 31, 2025; they are all mandatory now. In Requirement 10, the new items are 10.1.2, 10.4.1.1, 10.4.2.1, 10.7.2 and 10.7.3.
10.1: Policies and roles
- 10.1.1 Security policies and procedures for logging are documented, current, in use and known to the people who need them.
- 10.1.2 Roles and responsibilities for Requirement 10 are documented, assigned and understood. New in v4.0.
What the assessor wants: a written logging policy, a named owner for log review, and staff who can describe what they do.
10.2: What to log
10.2.1 Audit logs are enabled and active for all system components and cardholder data. “All system components” means everything in scope: servers, databases, network devices, firewalls, applications, and security tools themselves.
The logs must capture:
| Item | Event that must be logged | Typical source |
|---|---|---|
| 10.2.1.1 | Every individual user access to cardholder data | Database and application audit logs |
| 10.2.1.2 | Every action by anyone with administrative access, including interactive use of application or system accounts | Operating system, database, network device logs |
| 10.2.1.3 | All access to the audit logs themselves | Operating system and SIEM audit trails |
| 10.2.1.4 | All invalid logical access attempts | Authentication logs (for example Windows 4625) |
| 10.2.1.5 | Changes to identification and authentication credentials: new accounts, privilege elevation, changes to administrative accounts | Directory and identity provider logs |
| 10.2.1.6 | Initializing, starting, stopping or pausing of the audit logs | Operating system and logging agent events (for example Windows 1102) |
| 10.2.1.7 | Creation and deletion of system-level objects | Operating system and database logs |
10.2.2 Each recorded event must include six details:
- User identification
- Type of event
- Date and time
- Success or failure indication
- Origination of the event
- Identity or name of the affected data, system component, resource or service
The six details every log record needs (10.2.2)
A sample database audit record, with each required detail marked
- User identification
- Type of event
- Date and time
- Success or failure
- Where the event came from
- The data, system or service affected
What the assessor wants: audit configuration on a sample of systems, and sample log records showing every event type and all six fields. Shared accounts break 10.2.2’s first field, so expect questions about them.
10.3: Protecting the logs
- 10.3.1 Read access to audit logs is limited to people with a job-related need.
- 10.3.2 Audit log files are protected from modification by individuals.
- 10.3.3 Audit logs, including those from external-facing technologies such as wireless, firewalls, DNS and mail servers, are promptly backed up to a secure, central, internal log server or other media that is difficult to modify.
- 10.3.4 File integrity monitoring or change-detection software runs on the logs, so existing log data cannot be changed without raising an alert.
What the assessor wants: proof that logs leave the system that produced them quickly (so a compromised server cannot erase its own trail), access lists for the log store, and change detection on log files.
10.3.3 is where a SIEM or central log server becomes unavoidable. Once logs land in a central store that ordinary administrators cannot edit, 10.3.1, 10.3.2 and much of 10.3.4 follow from how that store is protected.
10.4: Reviewing the logs
- 10.4.1 At least once a day, review: all security events; logs of all components that store, process or transmit cardholder data or could affect its security; logs of critical system components; and logs of servers and components that perform security functions, such as firewalls, intrusion detection, and authentication servers.
- 10.4.1.1 Automated mechanisms are used to perform audit log reviews. New in v4.0, mandatory since March 31, 2025.
- 10.4.2 Logs of all other in-scope system components are reviewed periodically.
- 10.4.2.1 The frequency of those periodic reviews is set by a targeted risk analysis, as described in Requirement 12.3.1. New in v4.0.
- 10.4.3 Exceptions and anomalies found during review are identified and addressed.
What “automated review” means
The guidance for 10.4.1.1 is direct: manual review is difficult even for one or two systems because of the volume of logs, and it names log harvesting, parsing and alerting tools, centralized log management, event log analyzers and SIEM tools as ways to automate it. It also says these tools need a baseline of normal activity and must be kept aligned with changes in your environment.
The PCI Security Standards Council’s supplement on daily log monitoring makes the same point more bluntly: daily reviews need not be manual, and at modern volumes manual analysis is impractical. PCI DSS does not require a product called a SIEM. It does require that software, not people scrolling through logs, does the first pass.
What an automated daily review looks like (10.4)
Software does the first pass; people handle what it raises
- Logs arrive centrallyfrom every in-scope system (10.3.3)
- Rules review every eventautomated mechanisms flag what matters (10.4.1.1)
- A person reviews alerts dailysecurity events and critical systems (10.4.1)
- Exceptions are followed upwith a record of what was done (10.4.3)
What the assessor wants: the tool or rules that perform the daily review, the alerts it produced, and records showing people followed up on exceptions (10.4.3). A ticket or incident trail for each alert is the cleanest evidence.
10.5: Retention
10.5.1 Keep audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. The guidance says “immediately available” can mean online, archived or quickly restorable from backup.
Twelve months of log history (10.5.1)
The minimum PCI DSS asks you to keep
What the assessor wants: a retention setting that matches policy, and a demonstration that you can pull logs from three months ago now and from twelve months ago within a reasonable time.
10.6: Time synchronization
- 10.6.1 System clocks are synchronized using time synchronization technology, kept current.
- 10.6.2 Systems get time from designated time servers; only those servers take time from external sources; time is based on Coordinated Universal Time (UTC) or International Atomic Time; and updates come only from specific, accepted external sources.
- 10.6.3 Time settings and data are protected: access is restricted, and changes to time settings on critical systems are logged, monitored and reviewed.
What the assessor wants: NTP configuration, the list of designated time servers, and log entries showing clock changes are captured. Without synchronized clocks, correlating events across systems falls apart.
10.7: Failures of security controls
- 10.7.1 For service providers only: failures of critical security control systems are detected, alerted and addressed promptly. Superseded by 10.7.2 on March 31, 2025.
- 10.7.2 For all entities: failures of critical security control systems are detected, alerted and addressed promptly. New for merchants in v4.0. The list includes network security controls, intrusion detection and prevention, change-detection mechanisms, anti-malware, physical access controls, logical access controls, audit logging mechanisms, segmentation controls (if used), audit log review mechanisms and automated security testing tools (if used).
- 10.7.3 Failures are responded to promptly: restore the security function, record how long it was down and why, fix the cause, check whether further action is needed, and resume monitoring.
What the assessor wants: alerts that fire when a control stops working, not only when it detects an attack. The most common gap is the logging itself: a server whose agent stopped sending logs three weeks ago is a 10.7.2 failure nobody noticed.
Related requirements a SIEM usually covers
| Requirement | What it requires |
|---|---|
| 11.5.1 | Intrusion detection or prevention monitors all traffic at the perimeter of the cardholder data environment and at critical points inside it, and alerts personnel to suspected compromises |
| 11.5.2 | A change-detection mechanism, such as file integrity monitoring, alerts on unauthorized changes to critical files and compares them at least weekly |
| 12.10.5 | The incident response plan covers monitoring and responding to alerts from security monitoring systems, including intrusion detection, network security controls and change detection |
| A3.3.1 | For designated entities: the same detection of critical control failures as 10.7.2 |
A practical checklist for Requirement 10
- List every in-scope system component and confirm each one sends logs to a central store (10.2.1, 10.3.3).
- Check a sample record from each source for the six fields in 10.2.2.
- Make sure database and application logs capture access to cardholder data, not just operating system events (10.2.1.1).
- Restrict the log store to a small group, and alert on changes to log data (10.3.1 to 10.3.4).
- Turn on automated detection rules and assign someone to review their alerts every day (10.4.1, 10.4.1.1).
- Document a targeted risk analysis for the review frequency of everything else (10.4.2.1).
- Alert when any source stops logging or a security control fails (10.7.2).
- Set retention to at least 12 months and test a three-month and a twelve-month lookup (10.5.1).
- Point every system at your designated time servers (10.6).
- Keep records of each alert’s follow-up as review evidence (10.4.3, 10.7.3).
How UTMStack helps with Requirement 10
UTMStack collects logs from servers, databases, firewalls, cloud services and security tools into one central store, away from the systems that produced them and with access limited by role, which addresses 10.3.3 and supports the protection items around it. It keeps the original log line next to the parsed version for your audit trail. Every event is checked against its detection rules as it arrives, so the daily review in 10.4.1.1 is automated, and alerts become incidents with a full history of who did what, the evidence for 10.4.3. Each data source has a log timeline and offline status, so a source that goes quiet is visible, as 10.7.2 expects. You set retention up to five years, with older data still searchable without a restore.
The compliance module evaluates PCI DSS 4.0 controls from your logs and produces PDF reports for your assessor; PCI DSS is one of the nine frameworks in the Enterprise edition. Try it on sample data in the live demo.
Frequently asked questions
How long must logs be kept for PCI DSS? At least 12 months, with the most recent three months immediately available for analysis (Requirement 10.5.1).
Does PCI DSS require a SIEM? Not by name. Since March 31, 2025, Requirement 10.4.1.1 requires automated mechanisms for log review, and 10.3.3 requires a central log server, which is what a SIEM provides.
How often must PCI DSS logs be reviewed? Security events and logs of cardholder data, critical and security systems must be reviewed at least daily (10.4.1), using automated mechanisms (10.4.1.1). Other in-scope systems are reviewed at a frequency set by your targeted risk analysis (10.4.2.1).
What must each PCI DSS log record contain? User identification, type of event, date and time, success or failure, origination of the event, and the identity of the affected data, component, resource or service (10.2.2).
What changed in Requirement 10 from PCI DSS 3.2.1 to 4.0? Five items are new: documented roles (10.1.2), automated log review (10.4.1.1), risk-based review frequency (10.4.2.1), and detection of and response to critical control failures for all entities, not only service providers (10.7.2 and 10.7.3).
Sources
- PCI DSS v4.0.1, Requirement 10 and requirements 11.5.1, 11.5.2, 12.10.5 and A3.3.1, available free from the PCI SSC document library
- PCI SSC: PCI DSS v4.0.1 published and future-dated requirements of PCI DSS v4.x
- PCI SSC: Effective Daily Log Monitoring
