PCI DSS Logging Requirements: Requirement 10 Explained

Last verified on Nov 8, 2026.

PCI DSS Requirement 10 is the logging and monitoring requirement: "Log and Monitor All Access to System Components and Cardholder Data." It is short enough to read in one sitting and specific enough to fail an assessment on. This guide walks through each sub-requirement as written, translates it into what you would actually configure in a log pipeline, and points to the places teams commonly come up short.

One note on sourcing. The PCI SSC Document Library publishes PCI DSS v4.0.1 behind a license agreement that has to be accepted by the reader's organization, so the requirement wording below is quoted from the official PCI SSC Self-Assessment Questionnaire D (v4.0, April 2022), which reproduces Requirement 10 in full. PCI SSC describes v4.0.1 as a limited revision with corrections, clarifications, and no additional or deleted requirements, and it is the only active version since v4.0 retired on 31 December 2024. Check the exact current wording and your applicability against the v4.0.1 standard and with your assessor. This page is an engineering guide and not a compliance determination.

The Structure of Requirement 10

10.1 is the documentation layer: security policies and operational procedures for Requirement 10 are kept up to date, in use, and known to affected parties, and roles and responsibilities are documented, assigned, and understood. Everything below it is technical.

10.2: What the Logs Must Capture

Requirement 10.2.1 sets the baseline: audit logs are enabled and active for all system components and cardholder data. Seven sub-requirements name the specific events:

Requirement 10.2.2 says each auditable event records at least: user identification, type of event, date and time, success and failure indication, origination of event, and the identity or name of the affected data, system component, resource, or service (for example, name and protocol).

In practice this means application logs for who read cardholder data, not only infrastructure logs. A structured entry covering every 10.2.2 field might look like:

{
  "timestamp": "2026-11-08T14:03:22.418Z",
  "user_id": "svc-recon-04",
  "event_type": "cardholder_data.read",
  "outcome": "success",
  "origin": "10.20.4.18",
  "resource": "payments-db/pan_vault",
  "protocol": "postgres"
}

Two items catch teams out. 10.2.1.3 means reading the logs is itself an audited event, so your log platform's access logs need to be kept. 10.2.1.6 means a log pipeline that gets paused or stopped must leave a trace. The security logging guide covers the broader event list, and the audit log entry explains the concept.

10.3: Protecting Logs

Four requirements, each concrete:

• 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 modifications 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 common implementation is to ship logs off the host as they are written, to central storage with write-once or append-only semantics and separate credentials from the systems being logged. The 10.3.3 wording about external-facing technologies matters: logs from a web server in a DMZ are the ones most exposed to an attacker, and should leave that host quickly.

10.4: Reviewing Logs

Requirement 10.4.1 requires that the following be reviewed at least once daily:

• All security events
• Logs of all system components that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD)
• Logs of all critical system components
• Logs of all servers and system components that perform security functions, such as network security controls, IDS/IPS, and authentication servers

Requirement 10.4.1.1 adds that automated mechanisms are used to perform audit log reviews. It was a best practice until 31 March 2025 and is required after that date. In plain terms, nobody is expected to read raw logs by hand every day. You are expected to run rules or analysis over them and review the output.

A daily review job that is auditable might look like this:

SELECT date_trunc('day', timestamp) AS day, event_type, outcome, count(*) AS events
FROM audit_events
WHERE timestamp > now() - INTERVAL '1 day'
  AND (outcome = 'failure' OR event_type IN ('privilege.elevate', 'account.create', 'auditlog.read'))
GROUP BY 1, 2, 3
ORDER BY events DESC

Requirement 10.4.2 covers logs of all other in-scope system components, which are reviewed periodically. 10.4.2.1 says the frequency is defined in the entity's targeted risk analysis, done according to 12.3.1, and was also a best practice until 31 March 2025. Requirement 10.4.3 says exceptions and anomalies found during review are addressed, which means keeping a record of what was found and what was done. A report that runs without anyone acting on it does not satisfy it.

10.5: Retention

Requirement 10.5.1 is a single sentence: "Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis."

That is two requirements in one. Three months must be online and queryable. The standard requires the rest of the history to be retained and available for analysis, so plan how you would actually retrieve it. Verify retention with data, not configuration. Check the oldest event in each source:

SELECT source, min(timestamp) AS oldest, now() - min(timestamp) AS retained
FROM audit_events
GROUP BY source
ORDER BY oldest DESC

Any source whose retained is under the required period is a finding. Look especially at sources with rotation set by default, such as local files and cloud log groups with short expiry.

10.6: Time Synchronization

Requirement 10.6.1 says system clocks and time are synchronized using time-synchronization technology. 10.6.2 specifies how:

• One or more designated time servers are in use.

• Only the designated central time server(s) receive time from external sources.

• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).

• The designated time server(s) accept time updates only from specific industry-accepted external sources.

• Where there is more than one designated time server, they peer with one another.

• Internal systems receive time only from the designated central time server(s).

  10.6.3 requires that access to time data is restricted to personnel with a business need, and that any changes to time settings on critical systems are logged, monitored, and reviewed. Clock errors break correlation across systems, which undermines every other control here. The clock skew guide covers detection.

10.7: Failures of Critical Security Controls

Requirement 10.7.2 requires failures of critical security control systems to be detected, alerted, and addressed promptly, including failures of:

• 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
• Automated security testing tools (if used)

PCI SSC notes that 10.7.2 includes two critical security control systems that were not in the service-provider-only 10.7.1. It applies to all entities and was a best practice until 31 March 2025. 10.7.3 requires that failures be responded to by restoring security functions, documenting the duration and cause of the failure, addressing any security issues that arose during it, deciding whether further action is needed, putting controls in place to prevent recurrence, and resuming monitoring.

For logging, this means that a log source going silent is a reportable failure. A check that compares each source's latest event against its expected cadence covers "audit logging mechanisms" and "audit log review mechanisms" in one query:

SELECT source, max(timestamp) AS last_seen, now() - max(timestamp) AS silent_for
FROM audit_events
GROUP BY source
HAVING now() - max(timestamp) > INTERVAL '15 minutes'

Where Teams Fall Short

• Missing application-level events. Infrastructure logs show a database connection. 10.2.1.1 asks who accessed cardholder data, and access anomalies covers spotting unusual reads.
• Logging the data itself. Audit logs record access to cardholder data. They should not contain card numbers. See secrets in logs.
• Review with no evidence. 10.4.3 expects exceptions to be addressed. Keep the alert, the triage note, and the outcome.
• Retention by luck. 12 months needs to be a configured, tested value on every source.
• Unsynchronized clocks. Timelines built from drifting hosts cannot be trusted.

Using Sazabi for the Review Side

Sazabi, an AI-native observability and security platform, is a place to search and analyze the logs you send it. Sazabi does not make anyone PCI compliant, and no log tool does by itself: compliance depends on your scope, controls, and assessor. Retention in Sazabi depends on your plan (see the pricing page), so compare it with the 12-month requirement for any source you intend to rely on, and keep long-term archives where you can prove integrity. See security issues for what to watch for in the logs once they are flowing, and logging best practices for field design.