Requirement 10 is the part of PCI DSS that decides whether, after a compromise, anyone can say who did what to cardholder data and when, and since 31 March 2025 it also expects log review to be automated. This guide works through PCI DSS v4.0.1 Requirement 10 section by section: which events must be logged (10.2), how logs are protected (10.3), how and how often they are reviewed (10.4), retention (10.5), time synchronisation (10.6) and detecting failures of critical security controls (10.7). It is written for security engineers, SOC leads and PCI programme owners preparing evidence for a Qualified Security Assessor or a self-assessment. Requirement wording is summarised, not quoted, because the standard itself is published as a PDF in the PCI SSC Document Library; check every value against the current standard before relying on it.
Key takeaways
- The purpose is reconstruction: a PCI SSC FAQ describes Requirement 10 as keeping enough logs to rebuild a reliable history of who did what, when, where and how in the cardholder data environment (CDE).
- Seven event types are named in 10.2.1.1 to 10.2.1.7, including all administrator actions, all access to audit logs and all changes to authentication credentials; any mix of operating system, database and application logs may cover them.
- Daily review is required for the systems and events listed in 10.4.1, and 10.4.1.1 requires automated mechanisms to do it; other in-scope systems are reviewed at a frequency set by a targeted risk analysis (10.4.2.1).
- Logs must be hard to change: restricted read access, protection from modification, prompt backup to a central server and file integrity monitoring or change detection on the logs themselves (10.3.1 to 10.3.4).
- Control failures are logged events too: 10.7.2 requires failures of critical security control systems to be detected, alerted and addressed promptly for all entities; a PCI SSC FAQ says it superseded 10.7.1 after 31 March 2025.
How Requirement 10 is structured
Requirement 10, "Log and Monitor All Access to System Components and Cardholder Data", has seven sections. The wider standard is summarised in the PCI DSS 4.0 Guide; identity controls that produce many of the events below are in the PCI DSS Requirement 8 Guide.
| Section | Subject | Sub-requirements | What assessors usually ask for |
|---|---|---|---|
| 10.1 | Policies, procedures, roles | 10.1.1, 10.1.2 | Logging and monitoring procedures, named owners |
| 10.2 | Audit logs enabled and detailed enough | 10.2.1, 10.2.1.1 to 10.2.1.7, 10.2.2 | Audit policy settings per platform, sample log records |
| 10.3 | Protection of audit logs | 10.3.1 to 10.3.4 | Log server access lists, immutability settings, FIM configuration |
| 10.4 | Log review | 10.4.1, 10.4.1.1, 10.4.2, 10.4.2.1, 10.4.3 | SIEM rules, alert tickets, targeted risk analysis for review frequency |
| 10.5 | Retention | 10.5.1 | Retention settings, archive restore test |
| 10.6 | Time synchronisation | 10.6.1 to 10.6.3 | NTP configuration, time source list, access to time settings |
| 10.7 | Failures of critical security controls | 10.7.1 (superseded), 10.7.2, 10.7.3 | Alert rules for control failures, failure tickets and root cause records |
10.2: what must be logged
10.2.1 requires audit logs to be enabled and active for all system components and cardholder data. The sub-requirements name the events:
| Sub-requirement | Event | Typical sources |
|---|---|---|
| 10.2.1.1 | All individual user access to cardholder data | Database audit, application access logs, tokenisation service logs |
| 10.2.1.2 | All actions by anyone with administrative access, including interactive use of application or system accounts | OS audit (Windows Security log, Linux auditd), sudo logs, PAM session logs, cloud control plane logs |
| 10.2.1.3 | All access to audit logs | Log server and SIEM audit trail, object storage access logs |
| 10.2.1.4 | All invalid logical access attempts | Directory and IdP sign-in failures, VPN, database login failures |
| 10.2.1.5 | All changes to identification and authentication credentials | Account creation, privilege changes, password and key changes, MFA enrolment |
| 10.2.1.6 | Initialisation, stopping or pausing of audit logs | Audit service start and stop events, log forwarder health |
| 10.2.1.7 | Creation and deletion of system-level objects | Service, driver, scheduled task and database object creation |
10.2.2 requires each record to hold enough detail to identify the event. In practice assessors look for the user identity, event type, date and time, success or failure, origin of the event, and the identity or name of the affected data, component or resource.
Which layer logs what: a PCI SSC FAQ says PCI DSS does not require both database and application logging; operating system, database and application logs can be combined in any appropriate way, provided together they capture the Requirement 10 events. Document which layer covers each event per system, because assessors test the combination, not each layer alone.
Do not log what you must protect: logs must not become an unprotected copy of full PAN or sensitive authentication data. Mask PAN in application logs and keep authentication secrets out entirely. See the JWT and Session Tokens in Code and Logs Guide and the Payment Card Data Elements page.
Where identity fits
10.2.1.2 names interactive use of application and system accounts explicitly. A service account used by a person at a console is a logged event, and often a finding under 8.6.1. Make sure the SIEM can tell an automated job from a human using the same account, for example by session type, source host and PAM check-out records. See the PCI DSS Requirements for Service Accounts and NHIs Guide.
10.3: protecting audit logs
- 10.3.1 read access: limit read access to log files to people with a job-related need. Keep administrators of the logged systems out of the log store's admin roles where you can.
- 10.3.2 modification: protect log files from modification by individuals. Write-once storage, object lock or a SIEM that does not allow record edits all help.
- 10.3.3 central backup: back up logs promptly, including those from external-facing technologies, to a secure central internal log server or other media that is difficult to modify. Forward in near real time rather than relying on nightly copies.
- 10.3.4 change detection: use file integrity monitoring or change-detection mechanisms on audit logs so existing log data cannot be changed without an alert. See the File Integrity Monitoring Guide.
Treat the SIEM and log pipeline as in scope: it holds the evidence an attacker most wants to remove, and its service accounts and API keys need the same controls as other CDE credentials. See the SIEM integration security guide.
10.4: reviewing logs
10.4 is where most programmes spend their effort. A PCI SSC FAQ explains the split:
| Sub-requirement | Applies to | Frequency | How |
|---|---|---|---|
| 10.4.1 | The events and system types that 10.4.1 defines, which the FAQ says need daily log review | Daily | Reviewed daily; see 10.4.1.1 |
| 10.4.1.1 | The 10.4.1 reviews | Continuous or daily | Automated mechanisms (SIEM correlation, log analytics alerts) |
| 10.4.2 | All other in-scope components not covered by 10.4.1, for example the FAQ's examples of inventory control systems, print servers and some workstations | Periodic | Manual or automated |
| 10.4.2.1 | The frequency for 10.4.2 | Set by a targeted risk analysis | Performed according to all elements of 12.3.1 |
| 10.4.3 | Exceptions and anomalies found in review | As found | Addressed, with records |
The same FAQ notes that in some environments every in-scope system falls under 10.4.1, so daily review applies to all of them. Map each system against the 10.4.1 categories before treating it as a 10.4.2 system. The targeted risk analysis approach is explained in the PCI DSS Customised Approach and Targeted Risk Analysis Guide.
What "automated" means in practice: assessors look for rules that run without a person reading raw logs, alerts that create tickets, and evidence that someone handled each alert. A SIEM that ingests logs but has no tuned rules for the 10.2 events is ingestion, not review. Useful starter rules include failed logins above a threshold, new privileged group membership, audit service stopped, access to log stores by unusual accounts, and interactive logons by service accounts.
10.5 and 10.6: retention and time
10.5.1 retention: the standard sets a minimum retention period for audit log history and requires the most recent part of that history to be immediately available for analysis. Apply that retention in every log store, including cloud logging services whose defaults are often shorter. Test that archived logs can actually be restored and searched; an archive nobody can query fails the "available for analysis" intent. See the Log Management and Retention Guide.
10.6 time synchronisation: 10.6.1 requires system clocks to be synchronised using time-synchronisation technology, 10.6.2 requires systems to be configured to the correct and consistent time, and 10.6.3 requires time synchronisation settings and data to be protected. In practice: a small number of designated internal time servers take time from trusted external sources, all other systems take time only from those servers, and changes to time settings are restricted and logged. See the NTP Security Guide.
10.7: failures of critical security controls
10.7.2 requires failures of critical security control systems to be detected, alerted and addressed promptly. 10.7.1 was the service-provider-only version; a PCI SSC FAQ lists 10.7.1 as superseded by 10.7.2 after 31 March 2025 and says superseded requirements are marked Not Applicable in a Report on Compliance or SAQ. 10.7.3 requires responses that restore security functions, document the failure and its cause, address security issues that arose during the failure, and prevent recurrence.
10.7.2 names the critical security control systems it covers, and the FAQ shows that its list is longer than the one in 10.7.1. Our recommendation is to treat every security tool that protects the CDE as a candidate, for example network security controls, intrusion detection and prevention, file integrity monitoring, anti-malware, access controls, audit logging and automated log review tools. Build a heartbeat for each: an alert when an agent stops reporting, a log source goes silent, or a firewall stops sending logs.
Decision guidance
- SIEM or log analytics platform: a full SIEM fits entities with a SOC and many log sources; smaller merchants on SAQ routes may meet 10.4.1.1 with a managed detection service or cloud-native log analytics with alert rules. What matters is automated review with evidence of follow-up. See the SIEM Guide.
- Where to collect: use the operating system for administrator and object events, the database or application for cardholder data access, and the IdP or directory for authentication. Avoid relying on a single layer that misses direct database access.
- 10.4.1 versus 10.4.2: classifying many systems as 10.4.2 reduces daily review load but needs a defensible targeted risk analysis per system type. Where the number of 10.4.2 systems is small, reviewing everything daily through the SIEM is often simpler to evidence.
- Retention cost: keep the immediately available period in hot storage and the rest in cheaper immutable archive, rather than shortening retention.
How to implement Requirement 10
- Inventory log sources: list every in-scope system component and connected-to system, and record which of the seven 10.2.1.x events each one emits and from which layer.
- Close event gaps: enable audit policies (Windows Advanced Audit Policy, Linux auditd rules, database audit, cloud control plane and data access logs) for the missing events. Test on a pilot group first and watch volume and performance before full rollout; keep the previous audit configuration so it can be restored if a system is overloaded.
- Centralise and protect: forward to a central log platform, restrict access, enable immutability and change detection (10.3).
- Build review rules: write automated rules for the 10.4.1 systems, route alerts to tickets, and document the targeted risk analysis for 10.4.2 frequency.
- Set retention and time: configure retention per store, test restore, and point all systems to internal time servers (10.5, 10.6).
- Monitor the monitors: create heartbeat and silence alerts for each critical security control and log source (10.7.2), with a response procedure meeting 10.7.3.
- Evidence: keep sample records, rule lists, alert tickets, restore tests and failure records for the assessment period.
Detection and measurement
| Metric | Target (our recommendation) | Requirement |
|---|---|---|
| In-scope components forwarding logs to the central platform | 100% | 10.2.1, 10.3.3 |
| Log sources silent for more than 24 hours without a ticket | 0 | 10.7.2 |
| 10.4.1 alerts triaged within one business day | Above 95% | 10.4.1, 10.4.3 |
| Successful archive restore tests per year | At least 2 | 10.5.1 |
| Systems with clock drift above your tolerance | 0 | 10.6.2 |
| Accounts with write or delete rights on the log store | Minimal and reviewed quarterly | 10.3.1, 10.3.2 |
Framework mapping
| PCI DSS v4.0.1 | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK behaviour detected or resisted |
|---|---|---|---|
| 10.2 event logging and content | AU-2, AU-3, AU-12, AC-6(9) | PR.PS-04 | T1078 Valid Accounts, T1098 Account Manipulation |
| 10.3 protection of logs | AU-9, AU-9(4) | PR.PS-04 | T1070 Indicator Removal |
| 10.4 review | AU-6, AU-6(1), SI-4 | DE.CM-03, DE.AE-02 | T1078, T1136 Create Account |
| 10.5 retention | AU-11 | PR.PS-04 | Supports investigation |
| 10.6 time | AU-8 | PR.PS-04 | Supports correlation |
| 10.7 control failures | AU-5, SI-4 | DE.CM-09 | T1685 Disable or Modify Tools |
For the ISO/IEC 27001 view, see the PCI DSS 4.0 to ISO 27001 Mapping Guide.
Common failure patterns
- Logs collected, never reviewed: the SIEM ingests everything but has no rules for the 10.2 events, so 10.4.1.1 has nothing to show.
- Database access invisible: application logs cover users of the app, but DBAs and scripts querying the database directly are not logged anywhere (10.2.1.1, 10.2.1.2).
- Silent log sources: an agent stopped after an upgrade months ago and nobody noticed, which is both a 10.2.1 gap and a 10.7.2 failure.
- Cloud defaults: data access logging off by default in some cloud services, or retention shorter than the standard requires.
- Undocumented 10.4.2 frequency: weekly or monthly review of some systems with no targeted risk analysis behind it (10.4.2.1).
- PAN in logs: debug logging writes full PAN, which brings the log store into scope for Requirement 3 as well.
Practitioner checklist
- Map each in-scope component to the seven 10.2.1.x events and the layer that logs each one.
- Confirm records contain enough detail per 10.2.2, and contain no full PAN or authentication secrets.
- Forward logs promptly to a central, access-restricted, change-detecting store (10.3).
- Run automated daily review for 10.4.1 systems and keep alert tickets as evidence (10.4.1.1).
- Document the targeted risk analysis for every 10.4.2 review frequency (10.4.2.1).
- Set retention per the standard in every log store and test archive restores (10.5.1).
- Synchronise all systems to designated internal time servers and restrict time settings (10.6).
- Alert on failure or silence of each critical security control and keep failure response records (10.7.2, 10.7.3).
Standards and references
- PCI SSC: Document Library (PCI DSS v4.0.1)
- PCI SSC FAQ 1254: Intent of Requirement 10
- PCI SSC FAQ 1304: Devices to which Requirement 10.4.2 applies
- PCI SSC FAQ 1081: Database and application logging
- PCI SSC FAQ 1593: Reporting superseded requirements after 31 March 2025
- PCI SSC Glossary: Audit Log
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, CIS Control 8 Audit Log Management Guide, SIEM Log Source Onboarding Checklist, Cloud Logging and Audit Trail Guide. This guide summarises PCI DSS v4.0.1 Requirement 10 and is not legal or assessment advice.