Compliance engineering

PCI DSS logging requirements without the panic: what Requirement 10 actually asks

Gociux · June 2026 · 7 min read

Requirement 10 — log and monitor all access to system components and cardholder data — is where many PCI DSS assessments get uncomfortable, because it can't be satisfied with a policy document. Either the logs exist, cover the right events, and someone demonstrably reviews them, or they don't. The good news: read as an engineering specification instead of a legal text, Requirement 10 describes a perfectly buildable system.

What follows is the practitioner's summary. It is not a substitute for the standard itself — always verify against the current official documents from the PCI Security Standards Council and your QSA's interpretation.

What has to be logged

The standard enumerates the audit-event categories every in-scope system must capture, and they are exactly what an investigator would ask for after an incident:

• All individual user access to cardholder data
• All actions taken by anyone with administrative privileges
• Access to the audit logs themselves
• Invalid access attempts — the failed logins that precede most breaches
• Changes to authentication: new accounts, privilege elevation, credential changes
• Starting, stopping, or pausing of the audit logs — because that's what attackers do first
• Creation or deletion of system-level objects

Each entry needs enough detail to reconstruct the event: who, what, when, where from, and the outcome. If your SIEM field mapping can answer those five questions for every event above, the "what to log" half of Requirement 10 is essentially done.

Retention: twelve months, three hot

Audit log history must be retained for at least twelve months, with a minimum of the most recent three months immediately available for analysis — online or restorable fast enough that an investigation isn't waiting on tape recalls. In practice this drives a two-tier architecture: hot indices in the SIEM for 90+ days, compressed archives in object storage for the remainder of the year. Size this early; log volume in a payment environment surprises everyone.

The daily review — the part everyone fails

Logs that nobody reads satisfy nothing. The standard requires security events and logs of critical components to be reviewed at least daily, and explicitly allows automated mechanisms to perform that review. This is the requirement that quietly mandates a SIEM: at payment-environment volume, "daily review" is only honest if correlation rules, alerts, and a triage process are doing the reading, with humans handling the exceptions. An assessor will ask to see the alerts, the tuning, and tickets proving follow-up — a calendar entry saying "review logs" convinces no one.

Time synchronization and log integrity

Two supporting requirements make the logs trustworthy. First, all clocks must be synchronized from agreed, industry-accepted time sources — without consistent time, cross-system event correlation is fiction, and so is your incident timeline. Second, audit logs must be protected from modification and promptly backed up to a centralized location, with file integrity monitoring or change detection alerting on tampering. Centralize fast, restrict access, monitor the monitor.

The mindset shift

Teams that struggle with Requirement 10 treat it as a documentation exercise performed before the assessment. Teams that find it easy treat it as the specification for their detection infrastructure — which it is. The same pipeline that satisfies the QSA is the one that catches the brute-force attempt at 02:00. Compliance and security stop being separate budgets the moment the logging is real.