PCI DSS Requirement 10: Log and Monitor All Access

PCI DSS Requirement 10 requires you to log and monitor all access to system components and cardholder data, so that suspicious activity is spotted quickly and any incident can be investigated afterwards. Under PCI DSS v4.0.1 that means audit logs on every in-scope system recording set events and details (10.2), protected from tampering (10.3), reviewed using automated mechanisms, at least daily for security events and the systems that handle card data or perform critical or security functions (10.4), kept for at least 12 months with the latest three months immediately available (10.5.1), stamped from synchronised clocks (10.6), and backed by alerts when a critical security control fails (10.7).

This guide takes each section in turn, then sets out the evidence a QSA asks for and the gaps that commonly lead to findings. For the other eleven requirements, see our guide to PCI DSS requirements.

What is PCI DSS Requirement 10?

It sets the PCI DSS logging requirements and is one of two requirements under the goal “Regularly monitor and test networks”. Its full title is “Log and monitor all access to system components and cardholder data”, and it has seven sections:

It covers every in-scope system component: anything in or connected to your cardholder data environment (CDE), or able to affect its security, including servers, network devices, cloud services and security tools. The full text, with guidance, is free from the PCI SSC document library.

What must a PCI audit log record?

Requirement 10.2.1 requires audit logs to be enabled and active for all system components and cardholder data. Sub-requirements 10.2.1.1 to 10.2.1.7 list the events they must capture:

Requirement 10.2.2 then sets what each logged event must record: user identification, type of event, date and time, success or failure indication, origination of the event, and the identity or name of the affected data, system component, resource or service. In plain terms: who, what, when, whether it worked, from where, and to what. Shared accounts defeat the first, so unique IDs (Requirement 8) matter here too.

PCI DSS log management: how must audit logs be protected?

Requirement 10.3 stops logs being read, changed or destroyed by the wrong people:

• 10.3.1: read access to audit log files is limited to those with a job-related need.
• 10.3.2: audit log files are protected to prevent modification by individuals.
• 10.3.3: audit log files, 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.4: file integrity monitoring or change-detection mechanisms are used on audit logs, so existing log data cannot be changed without generating alerts.

The aim is that an attacker with administrator rights on a server cannot erase the record of what they did. Forwarding logs as they are written to a central store that the server’s administrators cannot alter is the usual answer.

Does PCI DSS require automated log review?

Yes. Requirement 10.4.1.1 requires automated mechanisms to perform audit log reviews. It was future-dated in v4.0 and has been mandatory since 31 March 2025. The standard names no product: a SIEM is the usual answer, but any mechanism that reviews logs automatically and raises alerts can meet it.

Requirement 10.4.1 sets which logs are reviewed at least once daily:

• 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.

Logs of all other system components are reviewed periodically (10.4.2), at a frequency set in a targeted risk analysis performed to Requirement 12.3.1 (10.4.2.1, also mandatory since 31 March 2025). Our targeted risk analysis template shows how to document one. Exceptions and anomalies must then be addressed (10.4.3), so expect your assessor to ask for alerts that were triaged and closed.

How long must PCI audit logs be kept?

PCI DSS log retention requirements are set by Requirement 10.5.1: keep audit logs for at least 12 months, with at least the most recent three months immediately available for analysis. Older logs can move to archive storage as long as they can be retrieved. Check cloud logging and SaaS retention settings, whose defaults may be shorter than 12 months.

If a hosting provider or cloud platform holds some of your logs, the contract should say who keeps which logs and for how long. Our guides to PCI compliant hosting and AWS PCI compliance cover the questions to ask and the AWS log sources to switch on.

What does PCI DSS require for time synchronisation?

Logs from different systems can only be pieced together if their clocks agree. Requirement 10.6.1 requires clocks to be synchronised using time-synchronisation technology, such as NTP. Under 10.6.2, only designated central time servers take time from external sources, those sources must be specific, industry-accepted and based on International Atomic Time or UTC, multiple time servers peer with one another, and internal systems take time only from the designated servers. Requirement 10.6.3 restricts access to time data to personnel with a business need, and requires changes to time settings on critical systems to be logged, monitored and reviewed.

What are critical security control failures under Requirement 10.7?

Requirement 10.7.2 requires failures of critical security control systems to be detected, alerted and addressed promptly. The list includes, but is not limited to: network security controls, IDS/IPS, change-detection mechanisms, anti-malware solutions, physical access controls, logical access controls, audit logging mechanisms, segmentation controls (if used), audit log review mechanisms and automated security testing tools (if used).

Requirement 10.7.3 sets the response: restore security functions; identify and document how long the failure lasted, from start to end; identify and document its cause and the remediation required; identify and address any security issues that arose during the failure; decide whether further action is needed; put controls in place to stop the cause recurring; and resume monitoring.

Under v3.2.1 these duties applied only to service providers (10.7.1 carries that version into v4.0 until 10.7.2 supersedes it). Since 31 March 2025, 10.7.2 and 10.7.3 apply to every entity. The classic case is a log source that silently stops sending: without an alert, nobody notices until the assessor asks for the missing logs.

What evidence does a QSA ask for, and what are the common findings?

For the same view across all twelve requirements, use our PCI DSS compliance checklist; our guide to PCI documentation lists the policies, procedures and records each requirement needs.

What changed in the PCI DSS 4.0 logging requirements?

PCI DSS v3.2.1 was retired on 31 March 2024, and every change below now applies:

Our guide to what changed in PCI DSS 4.0.1 covers the changes across every requirement.

Does Requirement 10 apply to every merchant?

It is assessed in full in a Report on Compliance and in SAQ D, and other SAQs, such as SAQ A-EP, include some or all of its sub-requirements. SAQ A, for card-not-present merchants that fully outsource all handling of account data to PCI DSS compliant third parties, does not include Requirement 10, but those third parties must still meet it. Check the requirement list in your questionnaire, or our guide to which PCI SAQ applies to you. Our free PCI compliance check also suggests your likely SAQ.

How can you test that your logging works?

Configuration evidence shows logging is switched on, not that anyone would notice an attack. After an internal penetration test, compare the testers’ timeline with your logs and alerts to see which actions were recorded, which raised alerts and which went unseen. The NCSC’s introduction to logging for security purposes is a useful companion when deciding what to collect beyond the PCI DSS minimum.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, a Qualified PIN Assessor (QPA) and a Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. We assess Requirement 10 as part of our PCI DSS assessments, help organisations close logging gaps before an assessment, and test detection through internal penetration testing. We are also ISO 27001 certified.

Next step

If you are not sure your logging would satisfy an assessor, our PCI DSS consultancy team can review your set-up against each Requirement 10 section and tell you what to fix first. Or call +44 161 523 5276.