Requirement 10 is the PCI DSS requirement that turns a breach investigation from guesswork into a timeline. It asks you to log specific events on every in-scope system, protect those logs, review them, keep them, and notice when the controls producing them stop working.
Most teams collect plenty of logs. The findings come from the parts that are easy to skip: an event type that is not captured on one class of system, a log entry without a reliable timestamp, a review that happens in theory but leaves no record, or a logging agent that stopped weeks ago without anyone noticing.
This article walks through Requirement 10 in the order an assessor tests it: what to log, what each entry must contain, how to protect logs, how to review them, how long to keep them, time synchronization, and detecting failed security controls. General architecture for central logging is covered in centralized logging for compliance.
What must be logged
Requirement 10.2.1 asks that audit logs are enabled and active for all system components and cardholder data. The sub-requirements list the events that must be captured. The table also shows where those events usually come from, which is where coverage gaps hide.
| Event | Requirement | Where it usually comes from |
|---|---|---|
| All individual user access to cardholder data | 10.2.1.1 | Application and database audit logs |
| All actions by anyone with administrative access | 10.2.1.2 | Operating system, cloud control plane, database and network device logs |
| All access to audit logs | 10.2.1.3 | The logging platform and the storage behind it |
| Invalid logical access attempts | 10.2.1.4 | Identity provider, operating systems, applications |
| Changes to identification and authentication credentials, including new accounts, elevated privileges, and changes to administrative accounts | 10.2.1.5 | Identity provider, directory, cloud IAM, application user management |
| Initialization, starting, stopping or pausing of audit logs | 10.2.1.6 | Logging agents, cloud audit trail configuration |
| Creation and deletion of system-level objects | 10.2.1.7 | Operating systems, databases, cloud control plane |
The first row is the one most often incomplete. Infrastructure logging tends to be strong, while application-level logging of who viewed which cardholder record depends on the application having been built to produce it.
What every entry must contain
Requirement 10.2.2 lists the details each audit log entry must record:
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
An entry that says an administrator changed a configuration, without saying which administrator or which system, fails the requirement even if the event type is covered. Check a sample of real entries from each log source against the list. Shared accounts break the first field, which is one reason Requirement 8 restricts them.
Protecting the logs
Logs are only evidence if they cannot be quietly altered. Requirement 10.3 asks that:
Read access to audit log files is limited to those with a job-related need (10.3.1).
Audit log files are protected from modification by individuals (10.3.2).
Logs, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server or other media that is difficult to modify (10.3.3).
File integrity monitoring or change-detection mechanisms are used on audit logs, so changes to existing log data generate alerts (10.3.4).
A central logging platform with write-once storage or immutable retention settings addresses most of this. The access controls around that platform are part of the evidence, since 10.2.1.3 also requires that access to the logs is itself logged.
Reviewing logs: daily and the rest
Requirement 10.4.1 asks for review at least once daily of:
All security events
Logs of all system components that store, process or transmit cardholder data 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
Since March 31, 2025, Requirement 10.4.1.1 requires automated mechanisms to perform those reviews. Nobody is expected to read the raw logs. A security information and event management platform, or rules in your logging platform, that raise alerts for review fits the requirement. What the assessor tests is that the mechanism exists, covers the listed sources, and that its output is looked at every day.
Logs of other in-scope system components are reviewed periodically under 10.4.2. Requirement 10.4.2.1 asks you to set that frequency in a targeted risk analysis under 12.3.1. That analysis is narrower than the one used for the customized approach, which is explained in the PCI DSS customized approach.
Requirement 10.4.3 closes the loop: exceptions and anomalies found during review are addressed. An alert that was acknowledged and closed without notes is weak evidence. An alert with a short record of what was checked and what was concluded is strong evidence. Alert design itself is covered in security monitoring and alerting.
How long to keep logs
Requirement 10.5.1 asks you to retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. The rest can sit in cheaper storage, provided you can restore it when needed.
Test the restore. An archive you have never retrieved from is a retention claim, not retention evidence.
Time synchronization
Log entries from different systems are only comparable if the clocks agree. Requirement 10.6 asks that system clocks are synchronized using time synchronization technology (10.6.1), that systems are configured to the correct and consistent time (10.6.2), and that time synchronization settings and data are protected (10.6.3).
The configuration detail in 10.6.2 is specific. One or more designated time servers are in use. Only those servers receive time from external sources. Internal systems take time only from them. Cloud provider time services usually satisfy the design, but you still need to show which source each system uses.
Detecting failures of security controls
A logging agent that stopped is invisible in the logs it no longer sends. Requirement 10.7.2, mandatory for all entities since March 31, 2025, asks that failures of critical security control systems are detected, alerted and addressed promptly. Service providers had the equivalent in 10.7.1 already.
The systems listed include network security controls, intrusion detection and prevention, change-detection mechanisms, anti-malware, physical and logical access controls, audit logging mechanisms, segmentation controls, audit log review mechanisms, and automated security testing tools. Requirement 10.7.3 asks that failures are responded to promptly, including restoring the control, identifying the cause, and documenting the duration and any remediation.
Logging evidence an assessor asks for
Expect requests for:
A list of log sources per in-scope system component, mapped to the event types in 10.2.1
Sample log entries showing each field in 10.2.2
Configuration showing log protection, access restrictions and integrity monitoring
Records of daily review: alerts raised, who reviewed them, what was concluded
The targeted risk analysis for 10.4.2.1
Retention settings, and a dated record of a successful restore
Time synchronization configuration
Records of security control failures and how each was handled
The PCI DSS framework page shows how Requirement 10 relates to the testing requirements in Requirement 11.
How TrustLynce helps
TrustLynce collects logging configuration, retention settings and review records from your systems on a schedule through evidence collection, timestamped and attributed. Continuous monitoring routes a failed logging control to its owner, so a gap is handled before the assessor samples it.