PCI Compliance Logging: Complete Guide to Requirement 10
Of the 12 Payment Card Industry Data Security Standard (PCI DSS) requirements, Requirement 10 is one your platform team can engineer directly. Under the PCI DSS v4.0.1 standard, automated log review has been a tested requirement since March 31, 2025. Your assessor will test the mechanism that performs the review.
This PCI compliance logging guide covers each 10.x sub-requirement, maps the seven event classes to log sources, and lays out a nine-step program you can hand to your assessor.
What Is PCI DSS Requirement 10?
Requirement 10, “Log and Monitor All Access to System Components and Cardholder Data,” opens with 10.1. The v4.0.1 text requires you to define and understand processes and mechanisms for logging and monitoring all access to system components and cardholder data.
In June 2024, the PCI Security Standards Council (PCI SSC) published the v4.0.1 revision with no new or deleted requirements. PCI DSS logging requirements follow the cardholder data environment (CDE): systems, people, and processes that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus anything with unrestricted connectivity to them.
The PCI DSS v4.0.1 standard also places connected and supporting systems in scope, including Network Time Protocol (NTP) servers and logging servers, and your assessor will examine your central log store and NTP sources.
What Events Must You Log Under Requirement 10.2?
PCI audit log coverage starts with 10.2.1 of the PCI DSS v4.0.1 standard, which requires you to turn on audit logs and keep them active for all system components and cardholder data.
Each record needs the six 10.2.2 fields which are user identification, event type, date and time, success or failure, origination, and the affected data or component.
The table below maps each 10.2.1.x event class to common log sources:
These are common implementation mappings rather than assessor-endorsed ones. Your Qualified Security Assessor (QSA) can confirm them.
Microsoft’s Entra PCI guidance marks 10.2.1.1, 10.2.1.2, and 10.2.1.6 as not applicable to Entra ID. Those events must come from database, host, and cloud audit logs instead.
How to Protect Audit Logs (Requirement 10.3)
Requirement 10.3 requires you to keep audit logs protected from destruction and unauthorized modifications. Under 10.3.1, you limit read access to “those with a job-related need,” which many teams enforce with role-based access control (RBAC) scoped to log readers.
Requirement 10.3.2 requires you to protect files against modifications by individuals, while 10.3.3 calls for prompt backup of all audit logs, including those for external-facing technologies, to a secure, central, internal log server or other hard-to-modify media.
Immutable object storage with a write-once-read-many (WORM) model is a common way to support 10.3.2 and 10.3.3.
For 10.3.4, you need FIM or change-detection that generates alerts when anyone changes existing log data, while appends should not alert. CloudTrail log file validation hashes each delivered file with SHA-256 and signs hourly digest files. Each digest file carries the previous digest’s signature, which links the files into a tamper-evident chain. You still have to run validation explicitly.
Log Review Requirements (Requirement 10.4)
Requirement 10.4.1 of the PCI DSS v4.0.1 standard requires you to review four log categories “at least once daily”:
- all security events
- logs of every component that handles CHD or SAD
- logs of critical components
- logs of servers performing security functions such as intrusion detection and prevention systems (IDS/IPS) and authentication servers
Requirement 10.4.1.1 requires automated mechanisms to perform audit log reviews.
The v3.2.1 testing procedures accepted daily review “either manually or via log tools.” Requirement 10.4.1.1 now tests whether an automated mechanism, such as security information and event management (SIEM) correlation rules and anomaly detection against a baseline of normal activity, performs the review. The v4.0.1 guidance counts log analyzers, centralized log management systems, and SIEM systems.
PCI SSC’s 2016 daily log monitoring guidance, which the PCI DSS v4.0.1 standard still cites under 10.4.1.1, warns that alerts create noise unless you configure them only for events that require follow-up.
Tune your SIEM platform rules to keep alert fatigue off the on-call rotation.
Requirement 10.4.2 covers all other components “periodically,” at a frequency you set through a targeted risk analysis (TRA) under 10.4.2.1.
Under 10.4.3, you must address exceptions and anomalies, and a dated ticket for each one records that work.
Log Retention: How Long Must You Keep Audit Logs? (Requirement 10.5)
PCI log retention under 10.5.1 of the PCI DSS v4.0.1 standard means: “Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.” The standard lists “storing logs online, archiving logs, or restoring logs quickly from backups” as ways to keep logs immediately available. Many engineering teams split this across hot, warm, and cold tiers.
A hot or warm tier for recent logs can help meet the “immediately available” bar, while older logs can sit in cheaper cold archive. A cold tier that needs a slow restore for the latest three months is hard to square with the standard’s quick-restore wording, and the 10.5.1 testing procedure asks for those months to be “immediately available online.”
Identity provider retention needs the same check, and Microsoft’s Entra PCI guidance recommends exporting Entra logs to Azure Monitor for long-term archival.
Time Synchronization and Failure Detection (Requirements 10.6 and 10.7)
Requirement 10.6 requires time synchronization, with NTP as a common implementation, to keep timestamps aligned across hosts. Designated central time servers take time only from industry-accepted external sources under 10.6.2, and other systems sync to them.
Under 10.6.3, you restrict time data to personnel with a business need and log, monitor, and review time-setting changes on critical systems.
Requirement 10.7 in the PCI DSS v4.0.1 standard requires you to detect, report, and respond promptly to failures of critical security control systems.
Since March 31, 2025, 10.7.2 has replaced the service-provider-only 10.7.1 and added two control systems to its list. The full list covers network security controls, IDS/IPS, change-detection mechanisms, anti-malware, physical and logical access controls, audit logging, segmentation controls (if used), audit log review mechanisms, and automated security testing tools (if used).
If an attacker stops auditd on a CDE host, a per-source heartbeat alert fires when that source goes quiet, which is a common approach that PCI DSS doesn’t mandate.
Under 10.7.3, which sets no numeric window for “promptly,” you restore logging, document the failure’s start and end time, cause, and remediation, and address any security issues that arose during the gap.
What Changed in PCI DSS 4.0 for Logging
PCI SSC’s v4.0 summary of changes, published in 2022, lists five new Requirement 10 items: 10.1.2 (roles and responsibilities, effective immediately), 10.4.1.1, 10.4.2.1, 10.7.2, and 10.7.3.
Four of them were best practices until March 31, 2025 (10.7.3 only for non-service-providers), the date 51 of 64 requirements introduced in v4.0 took effect. The standard also renamed “audit trails” to “audit logs” and renumbered most of Requirement 10:
| Topic | v3.2.1 → v4.0.1 |
| Protection | 10.5.x → 10.3.x |
| Review | 10.6.x → 10.4.x |
| Retention | 10.7 → 10.5.1 |
| Time sync | 10.4.x → 10.6.x |
| Control failures | 10.8 → 10.7.x |
Vendor mappings that still use v3.x numbering need a check against the PCI DSS v4.0.1 standard, which remains the current version for 2026 to 2027 planning. No successor has been published, though PCI SSC opened a request for comments on v4.0.1 in June 2026 to start work on the next version.
Building a PCI-Compliant Log Management Program
A PCI log management program is easier to defend when every control traces to a sub-requirement. Each step below names one, and the outputs double as your evidence pack:
- Document Requirement 10 policies and assign each activity an owner in a responsible, accountable, consulted, and informed (RACI) matrix (10.1.1, 10.1.2).
- Inventory every in-scope CDE component and supporting system, including identity providers and log and time servers, and confirm that scope at least once every 12 months (12.5.2).
- Turn on the seven event classes in auditd, Kubernetes, database, and cloud API audit logging, with all six 10.2.2 fields per record (10.2.1.1 through 10.2.1.7).
- Forward logs with Fluent Bit or an OpenTelemetry Collector to a central, hard-to-modify store (10.3.3). Redact card numbers in transit, since Requirement 3.5.1 of the PCI DSS v4.0.1 standard requires card numbers to be unreadable anywhere they’re stored, audit logs included.
- Grant log reads only to triage staff via RBAC, deny deletes to log-generating accounts, and point FIM at the logs to watch for changes (10.3.1, 10.3.2, 10.3.4). The Coralogix S3 archive setup has you grant the Coralogix archive role delete permissions on a bucket in your own cloud account. Requirement 12.8.5 asks you to record which PCI DSS requirements each service provider manages and which you manage, and these 10.3 controls belong on your side of that record.
- Automate daily review with correlation rules and Coralogix log anomaly alerts on failed logins, privilege elevation, off-hours CHD access, and audit log stops (10.4.1, 10.4.1.1). Log anomaly alerts need seven days of history before they activate. Ticket every exception, and set the review frequency for all other components through a TRA (10.4.2.1, 10.4.3).
- Set retention tiers per asset: keep recent logs searchable and older logs archived for every in-scope source, including the SIEM (10.5.1).
- Synchronize clocks through designated central NTP servers, block other time sources, and log time-setting changes on critical systems (10.6).
- Alert when a source or detection goes quiet, and document each failure’s start and end time, cause, and remediation (10.7.2, 10.7.3). A new source has no anomaly baseline in its first week and needs a log threshold alert until then.
Whether you run Coralogix Cloud SIEM or another log management stack, assessors will ask for rule configuration and daily review records. Build evidence export into the pipeline.
Meeting Requirement 10 with Automated Review and Queryable Retention
A Requirement 10 program that holds up in assessment captures the required event classes (10.2) and protects logs in tamper-evident storage (10.3). Your program must automate daily review (10.4.1.1) and retain audit history with recent logs immediately available (10.5.1). Clock synchronization (10.6) and alerts when a control fails (10.7) support that logging pipeline.
The Coralogix Trust Center lists PCI DSS v4.0.1 and SOC 2 Type 2 compliance, along with a HIPAA report, for your vendor review.
Coralogix runs its Streama© engine on every log in-stream, which lets Cloud SIEM detections fire as events arrive. Streama then writes logs in open Parquet format to your own cloud bucket, queryable without rehydration throughout your retention window. Those capabilities support your logging program without replacing security staff.
For regulated cardholder data, dedicated security staff and/or a managed detection and response (MDR) service such as Snowbit MDR is beneficial for acting on alerts.
Start a free 14-day Coralogix trial and send audit logs from a non-production test environment. You’ll see Cloud SIEM detections fire in-stream, and once you connect your own S3 bucket, you can query archived logs without rehydration.
Frequently Asked Questions About PCI Compliance Logging
How long does PCI compliance certification last?
The PCI DSS v4.0.1 standard leaves validation requirements to payment brands and acquirers, and the cycle is typically annual. Depending on your transaction volume, you file a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC) from a QSA. The attestation captures a point in time, while Requirement 10 review runs every day.
How can I become PCI compliant for logging?
Start with the nine steps above, which begins with documented policies and a scope inventory and ends with alerts on control failures. Each step names the sub-requirement it covers, and its output becomes evidence for your assessor.
How much does PCI DSS compliance cost?
PCI DSS compliance runs from about $300 a year for a small business to $70,000 or more for an enterprise. An onsite QSA assessment alone runs roughly $15,000 to $40,000, and enterprise remediation can reach $500,000. For logging, budget for 12 months of audit history storage, an automated review tool, and staff time to work the tool’s exceptions.
What happens if you are not PCI compliant?
Card brands assess the acquirer, which passes costs down by contract. After a breach, Visa’s compromise requirements set non-compliance assessments of up to $100,000 per incident for Level 1 and 2 merchants, starting at $5,000 to $25,000 for Level 3 merchants depending on transaction volume.
Those fees apply when an entity misses post-breach duties such as reporting suspected unauthorized access within three calendar days. Visa’s compromise requirements also oblige you to preserve security event, web, database, and firewall logs and give the forensic investigator access to them.
