Your QSA asks for 12 months of audit logs during an assessment. Your team starts pulling records from five different systems that includes servers, firewalls, databases and applications. All stored separately, in different formats, with no unified timeline. And that is a visibility problem.
PCI DSS Requirement 10 exists precisely to close this gap. It demands you to collect the right logs, protect them from tampering, review them daily and retain them in a way that survives an audit or a breach investigation.
This blog walks you through what Requirement 10 mandates under PCI DSS v4.0.1, where most fall short and what a compliant logging solution as per PCI DSS looks like in practice.
What PCI DSS requirement 10 covers
Requirement 10 sits under the broader PCI DSS objective to “track and monitor all access to system components and cardholder data.” It applies to every system component that processes, stores or transmits cardholder data and to any system that could affect the security of that environment.
Logging across all cardholder data environment components
PCI DSS v4.0.1 requires organisations to aggregate logs across all devices in the cardholder data environment (CDE), including servers, databases, routers, firewalls and authentication services. If a component touches cardholder data, its activity must be logged. Many systems have logging capabilities that are disabled by default. Verifying that logging is active across all in-scope components is one of the first things a QSA checks.
What events must be logged under PCI DSS Requirement 10?
Requirement 10.2.1 specifies the events that must be captured. These include all individual user access to cardholder data, all actions taken by users with root or administrative privileges, access to audit log paths, invalid logical access attempts, changes to identification and authentication mechanisms, and the initialisation or stopping of audit logs.
For each event, you must record the user identification, type of event, date and time, success or failure, origination of event and the identity of the affected data, system component or resource.
Key logging mandates under PCI DSS v4.0.1
PCI DSS v4.0.1 became fully mandatory on March 31, 2025. Several updates to Requirement 10 have direct implications for how you design and manage your logging infrastructure.
Retention – 12 months total, 3 months immediate access
PCI DSS v4.0.1 requires logs to be retained for at least 12 months, with three months of immediate access for operational or investigative use. Prematurely overwriting or purging logs – even unintentionally – can trigger non-compliance findings and weaken your forensic position after an incident.
Automated daily log review – manual is no longer acceptable
PCI DSS v4.0 has updated its requirements to only allow automated mechanisms to perform daily log reviews. Manually scanning logs each morning is no longer a valid approach. Your logging solution must be capable of automatically flagging anomalies, generating alerts and producing evidence of daily review activity.
Logs outside the daily review scope defined by 10.4.1 must be reviewed periodically, and the frequency must be determined by a targeted risk analysis.
Tamper-proof audit trails and log integrity
PCI DSS requires that logs are tamper-evident and protected against unauthorised access. This means maintaining audit trails, implementing encryption during transit and ensuring strict access controls.
Use the principle of least privilege when granting access to audit logs. Any changes to log files that could indicate a compromise must trigger an alert through file integrity monitoring or change detection mechanisms.
Where most organisations fall short
Most compliance gaps in Requirement 10 are not about intent. They are about architecture.
Logs scattered across disconnected systems
When logs from firewalls, servers, applications and network devices live in separate tools with no unified view, correlation becomes guesswork. Since different devices each generate their own logs, centralising them is essential for maintaining visibility and quickly identifying suspicious activity across the CDE.
No automated alerting on anomalies
Without automated rules tied to your specific network architecture, your log review process is reactive. Under PCI DSS 4.0, log monitoring rules should be customised to your environment rather than relying solely on generic templates. Your system should alert on administrative actions, access to cardholder data and any invalid access attempts.
What a compliant logging solution looks like
A logging solution as per PCI DSS is built around four capabilities: centralized collection, integrity protection, automated review and compliant retention.
Centralized log aggregation across the CDE
A centralized PCI DSS logging solution should have restricted access and the ability to retain log data from all device components in the cardholder data environment, with at least 90 days immediately available. Logs from external systems must be written to a secure internal server. You can explore how to design this architecture in detail in our guide on log storage strategy using the Elastic ELK Stack.
Time-synchronized, tamper-evident, audit-ready
Time synchronization across all components is now an explicit requirement under v4.0.1. Without it, timestamps across different systems will not align – making forensic reconstruction unreliable. Every log entry must carry an accurate, consistent timestamp. Access to time data and logging configuration must itself be restricted and monitored.
Conclusion
PCI DSS Requirement 10 is not a bureaucratic checklist. It is the foundation of your ability to detect threats, investigate incidents and prove compliance under audit.
The organisations that struggle with Requirement 10 are usually not missing logs – they are missing a unified, automated and tamper-resistant approach to managing them.
If your logging infrastructure is fragmented or your reviews are still manual, it is worth reviewing your setup before your next assessment.
CyberNX’s Full Stack Observability solutions give you centralized log management with automated detection, correlated event visibility and an architecture aligned to PCI DSS v4.0.1. Talk to our team to see how we can help you build a logging foundation your QSA will sign off on. Our services are built to centralise log ingestion, parse events across sources and enforce the controls Requirement 10 demands.
Logging solution as per PCI DSS FAQs
How long must PCI DSS logs be retained?
Audit logs must be retained for a minimum of 12 months. The most recent three months must be immediately accessible for analysis. Logs should not be overwritten, purged or archived in a way that delays retrieval – this applies to all systems in scope, including firewalls, servers and authentication services.
What events must be logged under PCI DSS Requirement 10?
At minimum, you must log all individual access to cardholder data, all administrator actions, invalid login attempts, access to audit trails, changes to authentication mechanisms and the starting or stopping of logging services. Each entry must capture who, what, when, where and whether the action succeeded or failed.
