Requirement 10 is where PCI DSS assessments most frequently stall. The requirement itself is straightforward: log everything relevant, protect the logs, review them regularly, and keep them long enough. The implementation is where companies struggle. Incomplete log sources, missing timestamps, inadequate retention, and the new v4.0 automated review mandate create a compliance gap that catches organizations off guard.
We see Requirement 10 failures in the majority of our PCI DSS penetration testing engagements. Not because logging is technically difficult, but because it requires coordination across teams, tools, and environments that rarely happens organically.
What Must Be Logged
PCI DSS Requirement 10.2 specifies the events that must generate audit log entries. Every one of these must be captured for all system components in the cardholder data environment:
- All individual user access to cardholder data (10.2.1) - not just database queries, but any access through applications, file systems, or APIs
- All actions taken by any individual with root or administrative privileges (10.2.2) - system administration, configuration changes, privilege use
- Access to all audit trails (10.2.3) - who viewed, modified, or attempted to access log files
- Invalid logical access attempts (10.2.4) - failed login attempts, access denied events, authorization failures
- Use of and changes to identification and authentication mechanisms (10.2.5) - account creation, privilege elevation, password changes, MFA enrollment
- Initialization, stopping, or pausing of audit logs (10.2.6) - any disruption to the logging pipeline itself
- Creation and deletion of system-level objects (10.2.7) - database tables, stored procedures, user accounts, firewall rules
Log entry contents
Each log entry must contain specific data elements per Requirement 10.3: user identification, type of event, date and time, success or failure indication, origination of event, and the identity or name of the affected data, system component, or resource. Missing any of these fields is a finding.
Time Synchronization
Requirement 10.6 mandates that all system clocks and times are synchronized using NTP or similar technology. This seems minor until you try to correlate events across systems during an incident investigation and discover your web server is three minutes ahead of your database server.
Configure all CDE systems to synchronize with the same authoritative time source. Use NTP with at least two upstream servers. Monitor for clock drift exceeding one second. Document your time synchronization architecture, because your assessor will ask for it.
Log Retention Requirements
| Requirement | Retention Period | Availability |
|---|---|---|
| 10.7.1 | At least 12 months total | At least 3 months immediately available for analysis |
| 10.7.2 (Service providers) | At least 12 months total | At least 3 months immediately available; failures detected and reported within 24 hours |
"Immediately available" means searchable and queryable without needing to restore from backup. If your logs older than 30 days are in cold storage on tape, you do not meet this requirement. Hot or warm storage for the most recent three months, with archived storage for the remaining nine months, is the standard architecture.
The v4.0 Automated Review Mandate
PCI DSS v4.0 introduced Requirement 10.4.1.1, which requires automated mechanisms to perform audit log reviews. This is the requirement that has caused the most operational disruption since the March 2025 transition deadline.
Under v3.2.1, daily log review could be performed manually. Under v4.0, you need automated detection of anomalies, suspicious activity, and security events. In practice, this means a SIEM or equivalent log analysis platform with correlation rules, alerting, and automated triage.
What assessors look for: Your QSA will ask to see your SIEM correlation rules, alert thresholds, escalation procedures, and evidence that alerts are being investigated. Having a SIEM is not enough. You need to demonstrate that it is actively monitored and that alerts result in documented investigations.
Minimum detection use cases
- Multiple failed authentication attempts followed by a success (brute force detection)
- Administrative access outside of normal business hours
- Changes to audit log configurations or log forwarding rules
- New user account creation by non-authorized personnel
- Access to cardholder data by accounts that do not normally access it
- Firewall rule modifications
- System component startup or shutdown outside of maintenance windows
Log Integrity and Protection
Requirement 10.3.2 requires that audit log files are protected from modifications. An attacker who compromises a system and can delete or alter logs can cover their tracks entirely. Your log architecture must prevent this.
Forward logs to a centralized log server or SIEM in near real-time. The log collection infrastructure should be in a separate security zone from the systems generating logs. Use write-once storage or append-only log destinations. In cloud environments, services like S3 Object Lock, Azure Immutable Blob Storage, or Cloud Storage retention policies provide tamper-evident log storage.
Common Requirement 10 Failures
- Incomplete log sources. Web servers are logged but database servers are not. Application logs capture page views but not data access events. Network devices are excluded from the logging scope
- Missing log fields. Logs capture the event but not the user identity, or capture the timestamp but not the source IP. Every field in Requirement 10.3 must be present in every log entry
- No automated review. The SIEM is deployed but has default rules only. No custom correlation rules for the organization's specific environment. Alerts are generated but nobody investigates them
- Insufficient retention. Logs are retained for 90 days instead of 12 months. Or logs are retained but not searchable beyond 30 days, failing the "immediately available" requirement for the most recent three months
- Clock drift. Systems are not configured for NTP synchronization, or NTP is configured but not monitored for drift. Event correlation becomes impossible when timestamps are inconsistent
Need help with PCI DSS logging compliance?
We assess logging and monitoring architectures as part of our PCI DSS penetration testing and compliance support. Get your Requirement 10 implementation validated before your assessment.
