PCI DSS Log Monitoring Requirements: What Security Teams Must Know

What PCI DSS Requirement 10 Actually Requires

Requirement 10 of the Payment Card Industry Data Security Standard covers "Log and Monitor All Access to System Components and Cardholder Data." The requirement exists because every significant payment card breach in the last decade left a trail in log data — the problem is that nobody saw the trail until after the damage was done.

PCI DSS v4.0, published in March 2022 and mandatory since March 2025, restructured Requirement 10 into six sub-requirements:

• 10.1: Processes and mechanisms for logging and monitoring are defined and understood
• 10.2: Audit logs capture all individual user access to cardholder data
• 10.3: Audit logs are protected to prevent modifications
• 10.4: Audit logs are reviewed to identify anomalies or suspicious activity
• 10.5: Retain audit log history for at least 12 months, with at least 3 months available for immediate analysis
• 10.6: Time synchronization mechanisms support consistent time settings across systems
• 10.7: Failures of critical security controls are detected, reported, and responded to promptly

Most organizations understand the broad intent but misunderstand what "compliance" actually looks like during a QSA audit. Having logs is necessary but not sufficient. You need to demonstrate that the logs are complete, tamper-evident, reviewed on a defined schedule, and that anomalies are investigated.

What Must Be Logged: The Mandatory Event Types

Requirement 10.2 specifies the event categories that must generate audit log entries. These are not suggestions — they are the baseline that a QSA will test for. Missing any of these categories is a finding.

Required Event Categories Under PCI DSS 10.2

• All individual user access to cardholder data (CHD): Every read, query, or export of primary account numbers (PANs), cardholder names, expiration dates, or service codes must generate a log entry with the user identity, timestamp, and resource accessed.
• All actions taken by any individual with root or administrative privileges: This includes privilege escalation events, use of sudo, and any action performed while in an administrative context.
• Access to all audit trails: Anyone who reads, modifies, or deletes log data must generate an entry. This creates a chain of custody for the logs themselves.
• Invalid logical access attempts: Failed authentication events — failed logins, failed API key validations, and denied authorization requests — at all in-scope system components.
• Use of and changes to identification and authentication mechanisms: Password changes, MFA enrollment or removal, service account creation and deletion.
• Initialization, stopping, or pausing of audit logs: If the logging system itself is paused or restarted, that event must be logged in a separate, protected location.
• Creation and deletion of system-level objects: Database table creation/deletion, file system changes in cardholder data environments (CDE), and configuration changes to security controls.

Each audit log entry must contain enough data to reconstruct what happened. PCI DSS specifies the required fields: user identification, type of event, date and time, success or failure of the event, origin of the event (source IP or terminal ID), and the identity or name of the affected data, system component, or resource.

Requirement 10.6: Time Synchronization and Why It Matters for Log Integrity

Time synchronization sounds like a mundane infrastructure concern until you try to reconstruct an attack timeline using logs from six different systems with clock drift across them. When a database server thinks it is 14:32:07 and the firewall thinks it is 14:31:54, correlating events across those systems is guesswork.

PCI DSS Requirement 10.6 requires that all in-scope system components use time synchronization technology — specifically NTP (Network Time Protocol) or equivalent — and that all systems are synchronized to a consistent time source. The requirements include:

• Only designated internal time servers receive time from external sources
• Internal time servers receive time from industry-accepted external time sources
• Time data is protected to prevent unauthorized modification
• Changes to time settings on critical systems are logged and monitored

For QSA evidence, expect to be asked to demonstrate NTP configuration on representative in-scope systems and show the hierarchy from external source to internal NTP servers to downstream systems. Clock drift alerts — triggered when a system's time deviates from the authoritative source by more than a configurable threshold — satisfy the "monitored" portion of this requirement.

Requirement 10.5: Log Protection and Integrity

An attacker who can modify log files can erase the evidence of their own activity. PCI DSS Requirement 10.5 exists to prevent that scenario. The control requires that audit logs be protected from destruction and unauthorized modifications.

The practical implementation typically involves one or more of these approaches:

• Centralized log aggregation: Shipping logs immediately to a separate system where the originating system's administrators do not have write access. Even if a server is compromised, the attacker cannot retroactively modify the already-transmitted log entries.
• Write-once storage: Object storage configurations like AWS S3 with Object Lock in Compliance mode, or Azure Immutable Blob Storage, prevent modification or deletion for a defined retention period.
• Cryptographic log hashing: Hash chains that allow verification that a log file has not been modified since it was created. Some SIEM platforms and dedicated log integrity tools provide this automatically.
• File integrity monitoring (FIM): Alerts on any changes to log files that have already been written, providing near-real-time detection of tampering attempts.

QSAs will test this control by asking how you would know if logs had been modified or deleted. "We would see it in the SIEM" is only an acceptable answer if you can demonstrate that the SIEM has visibility into the log integrity mechanism and that it generates alerts on anomalies.

The Daily Review Requirement: What "Reviewing" Actually Means

Requirement 10.4.1 states that the following logs must be reviewed at least once daily: security events, logs of all system components that store, process, or transmit CHD or SAD, logs of all critical system components, logs of all servers and system components that perform security functions.

What adequate daily review looks like in practice:

• A documented workflow with named roles responsible for review
• Timestamped records showing the review occurred (system-generated or signed by the reviewer)
• A defined set of log categories and anomaly thresholds that trigger investigation
• Case or ticket records for any anomalies identified, showing disposition (false positive with explanation, or escalated incident)
• An escalation path that is documented and tested

Requirement 10.4.2: Analyzing Logs for Anomalies

Beyond the daily review, PCI DSS v4.0 introduced a distinct sub-requirement (10.4.2) for analyzing logs to identify anomalies. The intent is to distinguish between "someone looked at the dashboard" and "someone applied analytical methods to identify deviations from expected behavior."

Anomaly detection for PCI DSS log monitoring purposes typically covers:

• Access pattern anomalies: Users accessing CHD at unusual hours, from unusual locations, or at volumes significantly higher than their baseline.
• Privilege escalation sequences: A standard user account authenticating successfully, then immediately using an administrative function it has never used before.
• Failed authentication clustering: Multiple failed login attempts across different accounts from the same source IP — a pattern consistent with credential stuffing or password spraying.
• Data exfiltration indicators: Unusually large query result sets, bulk exports, or high-volume outbound transfers from systems in the CDE.
• Log gap detection: Periods where expected log volume drops to zero or near-zero from a system that should be generating continuous events.

QSAs increasingly ask for proof that your anomaly detection is calibrated and actively used — not just that the capability theoretically exists. A system that generates alerts but where those alerts are never acted on is not satisfying the control intent.

Log Retention: 12 Months Total, 3 Months Immediately Available

Requirement 10.5.1 specifies a two-tier retention requirement. Twelve months of log history must be retained in total. At least three months of that history must be available for immediate analysis — meaning searchable and queryable without a restore operation.

The practical distinction matters for incident response. If you discover a potential breach today, you need to be able to search through the last 90 days of logs within minutes, not hours. Log data stored in cold archive (AWS Glacier Deep Archive, Azure Archive Storage) satisfies the 12-month retention requirement for the older nine months, but it does not satisfy the three-month immediate availability requirement.

Common implementation patterns:

• 30–90 days in hot SIEM storage (indexed, fully searchable)
• 90 days in warm storage (accessible within minutes, lower cost per GB)
• Months 4–12 in cold/archive storage (restoration required, acceptable for this tier)

Document your retention tiers explicitly. QSAs will ask for a retention policy document and will test that recent logs are accessible and that the archive contains the expected historical data.

Automated vs Manual Log Review: What QSAs Accept as Evidence

PCI DSS does not prohibit automated log review — in fact, v4.0 explicitly supports it. Requirement 10.4.1.1 states that automated mechanisms may be used to perform log reviews. However, automation does not eliminate the evidence requirement; it changes what evidence looks like.

When using automated log review (such as a SIEM with correlation rules, or an AI-native platform like ZonForge Sentinel), QSA-acceptable evidence includes:

• Documentation of the automated review mechanism — what rules, models, or algorithms are running, and against what log sources
• Records showing the automation generated output (alerts, reports, summaries) on a daily basis
• Incident or case records showing that alerts generated by automation were reviewed by a human and dispositioned
• Evidence that the automation covers all required log categories — not just a subset
• A tested process for what happens when the automated mechanism fails or generates no output

Manual-only review at scale is essentially impossible to sustain. A single security engineer reviewing raw log files across dozens of in-scope systems for eight hours per day cannot achieve the analysis depth that automation provides. The best-practice answer is automated detection plus documented human review of flagged items.

PCI DSS v4.0 Changes Affecting Log Monitoring

PCI DSS v4.0 made several substantive changes to log monitoring requirements that organizations upgrading from v3.2.1 need to understand:

• Explicit anomaly detection requirement (10.4.2): v3.2.1 required review; v4.0 separates the "review occurred" requirement from the "anomalies were identified" requirement. Both must be evidenced independently.
• Automated mechanism language (10.4.1.1): Explicitly permits automated log review tools, clarifying an area of ambiguity that existed in v3.2.1.
• Failure detection (10.7): New requirement to detect, alert on, and respond to failures of critical security controls — including logging failures. If your logging pipeline stops working, you need to know within a defined timeframe.
• Customized approach option: v4.0 introduced the ability to define a customized approach to controls if you can demonstrate equivalent or greater security. For large organizations with mature programs, this offers flexibility in how logging requirements are met.
• Targeted risk analysis: Some v4.0 controls allow organizations to define their own frequency of review based on a documented risk analysis rather than adhering to prescriptive intervals. This applies to some 10.x sub-requirements for entities that can justify it.

How ZonForge Sentinel Supports PCI DSS Requirement 10

ZonForge Sentinel is designed to address the specific operational challenges that make PCI DSS log monitoring difficult at scale — not just the technology problem, but the evidence problem.

Conclusion: PCI DSS Log Monitoring Is an Operations Problem, Not Just a Technology Problem

The organizations that fail PCI DSS Requirement 10 assessments usually have logging technology in place. What they are missing is the operational rigor: documented processes, daily review evidence, anomaly investigation records, and the ability to demonstrate that the technology is actively used rather than passively deployed.

PCI DSS compliance for logging requires treating log monitoring as a daily operational activity with documented outcomes, not a configuration you deploy and forget. That means knowing which event types must be captured, having automated detection that identifies anomalies before a human would, and generating the evidence documentation that a QSA can verify.

ZonForge Sentinel was built to make this operational rigor achievable without requiring an analyst to spend four hours per day manually reviewing log files. Automated security logging review, behavioral anomaly detection, and audit-ready reporting make Requirement 10 an area of confidence rather than a chronic assessment finding.