PCI DSS Requirement 10: Logging and Monitoring in v4.0.1
Version 4.0 renumbered PCI DSS Requirement 10 from end to end, and the Council retired v3.2.1 on 31 March 2024. Sub-requirement numbers written before then mostly point somewhere else now.
Four more Requirement 10 rules changed status on 31 March 2025, automated log review among them. Checking your numbering against v4.0.1 costs an afternoon and saves a finding.
In this blog, you will:
Map each old v3.2.1 number to its v4.x replacement.
See exactly what changed on 31 March 2025, and for whom.
Work out what to log, who can touch it, and how long it stays.
Match each sub-requirement to the evidence an assessor wants.
What Is PCI DSS Requirement 10?
PCI DSS Requirement 10 covers audit logging and monitoring across the cardholder data environment. In v4.x it carries the title Log and Monitor All Access to System Components and Cardholder Data. It binds merchants, processors, acquirers, issuers, and service providers alike.
That title doubles as a version check. Version 3.2.1 called the same requirement Track and Monitor All Access to Network Resources and Cardholder Data. Guidance still using those words describes a standard the Council retired in March 2024.
Scope reaches past the cardholder data environment (CDE) itself. It picks up anything that can affect CDE security, which catches more than most teams plan for.
Identity providers, jump hosts, and the log platform itself go missing from most first scope lists we review.
One job sits underneath all seven sub-requirements. Every access to cardholder data has to trace back to a named person after the fact.
What Are the Seven Sub-Requirements of Requirement 10?
Requirement 10 splits into seven sub-requirements, numbered 10.1 through 10.7. The table gives each one and what it asks of you.
Sub-requirement | Title | What it asks for |
10.1 | Processes and mechanisms are defined and documented | Written policies for Requirement 10, kept current, with named owners. |
10.2 | Audit logs are implemented | Logging switched on across system components, capturing seven event types and six data fields. |
10.3 | Audit logs are protected | Read access limited, files protected from change, backed up centrally, watched by file integrity monitoring. |
10.4 | Audit logs are reviewed | Daily review of security and CDE logs, periodic review of everything else, anomalies addressed. |
10.5 | Audit log history is retained | Twelve months of history, with the most recent three months immediately available. |
10.6 | Time synchronization is consistent | Designated time servers, a controlled external source, and protected time settings. |
10.7 | Control failures are detected and answered | Detection, alerting, and documented response when a critical security control stops working. |
Sub-requirements 10.2 through 10.5 carry most of the daily work. Each gets its own section below, starting with what moved.
What Changed in Requirement 10 Between v3.2.1 and v4.x?
Version 4.0 reorganized Requirement 10, and nearly every sub-requirement landed on a new number. The controls survived the move. Their addresses did not.
This trips people in a specific way. A control matrix written against v3.2.1 still describes real controls, so nothing looks broken. The numbers just stop matching what your assessor works from.
v3.2.1 | What it covered | v4.x |
10.1 | Link access to individual users | 10.2.1.1 and 10.2.1.2 |
10.2.1 to 10.2.7 | Automated audit trails for seven event types | 10.2.1.1 to 10.2.1.7 |
10.3 | The data fields recorded per event | 10.2.2 |
10.4 | Time synchronization | 10.6 |
10.5 | Secure audit trails against alteration | 10.3 |
10.5.5 | File integrity monitoring on logs | 10.3.4 |
10.6 | Review logs and security events | 10.4 |
10.7 | Retain twelve months of history | 10.5.1 |
10.8 | Control failure detection, service providers only | 10.7.1 and 10.7.2, now all entities |
10.8.1 | Control failure response, service providers only | 10.7.3, now all entities |
10.9 | Documented policies and procedures | 10.1.1 |
Two rows there go beyond renumbering. Retention moved from 10.7 to 10.5.1, so 10.7 now points somewhere else entirely. The old service-provider rule at 10.8 became a rule for everyone.
Which Requirement 10 Rules Became Mandatory in March 2025?
Four Requirement 10 rules changed status on 31 March 2025: 10.4.1.1, 10.4.2.1, 10.7.2, and 10.7.3. Three of them were pure best practice before that date. The fourth already bound service providers.
The Council added 64 new requirements in v4.0. Thirteen applied the moment an entity adopted the version. The other 51 got until March 2025 so teams could build toward them.
Each of the four asks for something different.
10.4.1.1 Automated log review: Automated mechanisms have to perform the audit log reviews. A person reading logs no longer satisfies it.
10.4.2.1 Risk-defined review frequency: A targeted risk analysis sets how often you review components outside the daily list. You document the reasoning.
10.7.2 Control failure detection for all entities: Every entity now detects and alerts on failures of critical security controls. This one supersedes 10.7.1 outright, and it names two more control systems than 10.7.1 did.
10.7.3 Documented failure response: Each failure earns a written response covering restoration, duration, root cause, and the controls that prevent a repeat. Service providers already owed this under v3.2.1. Everyone else picked it up in March 2025.
That last distinction matters when you read older guidance. Requirement 10.7.3 gets listed as a March 2025 change, which holds true only for merchants and other non-service-providers.
Requirement 10.4.1.1 changes daily work the most. Opening a dashboard each morning and scanning it will not meet the bar. The review mechanism itself has to run automatically.
Requirement 10.7.2 widened in two directions at once. Its list of critical security controls now names audit logging mechanisms and audit log review mechanisms outright. A log pipeline that stops collecting counts as a control failure. You were required to catch it.
That pairing carries a trade-off worth naming. Automating review satisfies 10.4.1.1 and hands you a new thing that breaks quietly, which 10.7.2 then makes your problem.
We have watched teams automate the review and skip the monitoring around it. They moved the gap instead of closing it.
What Events Must You Log Under Requirement 10.2?
Requirement 10.2.1 names seven event types your audit logs have to capture. Switching on logging in general will not cover it. All seven need to appear.
10.2.1.1: All individual user access to cardholder data.
10.2.1.2: All actions by anyone with administrative access, including interactive use of application or system accounts.
10.2.1.3: All access to audit logs.
10.2.1.4: All invalid logical access attempts.
10.2.1.5: All changes to identification and authentication credentials, including new accounts and privilege changes.
10.2.1.6: All starting, stopping, and pausing of audit logs, plus the initialization of new ones.
10.2.1.7: All creation and deletion of system-level objects.
Requirement 10.2.2 then sets what each entry has to contain. Six fields go into every event: user identification, event type, date and time, success or failure, event origination, and the identity of whatever it touched.
Those six fields absorb most of the collection effort. A firewall and a database both log access. They name the user, the source, and the outcome in different places and different formats. So log normalization has to run before the two entries answer the same question.
We see 10.2.1.6 missed more often than the other six combined. Teams log user activity thoroughly. Then they forget that stopping the logging service is itself a loggable event. An attacker generates that event first.
How Often Must You Review Audit Logs?
Requirement 10.4.1 sets a daily floor for four log categories. Requirement 10.4.2 covers everything else at a frequency you justify yourself. The daily list does not move.
All security events.
Logs of all system components that store, process, or transmit cardholder data or sensitive authentication data.
Logs of all critical system components.
Logs of all servers and system components performing security functions.
Since March 2025, 10.4.1.1 pushes that review through automated mechanisms. In practice you build correlation and alert rules that surface the exceptions. A rota of people reading output no longer clears the bar.
Outside the daily list, 10.4.2.1 asks you to set the frequency through a targeted risk analysis. Weekly holds up fine when the analysis supports it. An unexplained number does not.
Requirement 10.4.3 then closes the loop. Anomalies found during review have to get addressed. So log monitoring only counts here when its output reaches a queue with an owner. A review producing findings nobody works becomes a finding of its own.
How Long Must You Retain PCI DSS Audit Logs?
Requirement 10.5.1 asks for twelve months of audit log history. At least the most recent three months stay immediately available for analysis. Immediately available means searchable now, not restorable in two days.
Those two numbers describe two tiers, not one setting. The table shows how each half behaves.
Window | What 10.5.1 requires | What that means in practice |
Most recent 3 months | Immediately available for analysis | Searchable on demand, with no restore step in front of the query. |
Months 4 to 12 | Retained and available for analysis | Can sit in slower, cheaper storage, provided you can still produce it. |
Assessors test the top row by running a query and watching the clock. Twelve months marks a floor, never a target.
Investigations routinely reach further back than the breach itself. Plenty of teams stretch the period for security sources and keep operational output short.
Splitting the setting this way pays off quickly. Our guidance on log management policies covers how to write each period down so it survives a budget review.
One period across the whole estate costs you twice. You overpay on debug output, and you barely clear the minimum on the logs that matter.
How Do You Protect Audit Logs From Tampering?
Requirement 10.3 shields audit logs from destruction and unauthorized change across four sub-requirements. The reasoning runs straight: an attacker who reaches your systems will try to edit the record of it.
Sub-requirement | Control |
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 against modification by individuals. |
10.3.3 | Audit log files, including those from 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 run on audit logs, so existing log data cannot change without raising an alert. |
Requirement 10.3.2 carries a consequence people miss on a first read. An administrator who can delete the log of their own actions fails it. So the copy that counts has to live somewhere they do not control.
That gap explains why 10.3.3 exists, and why forwarding beats local storage every time.
Our guide to file integrity best practices goes deeper on the monitoring side of 10.3.4. The usual failure we find there involves watching the right files with nobody assigned to the alert.
What Evidence Do Assessors Ask For Under Requirement 10?
Assessors test Requirement 10 by asking for artifacts. They do not ask whether you comply. The table pairs each sub-requirement with the evidence that satisfies it.
Sub-requirement | Evidence requested | Where it comes from |
10.1.1 | Current Requirement 10 policy, with a version date | Policy repository |
10.1.2 | Named owners for each Requirement 10 activity | Responsibility matrix |
10.2.1 | Logging configuration for a sample of in-scope components | System and agent configuration |
10.2.1.1 to 10.2.1.7 | Sample log entries showing each of the seven event types | Log search export |
10.2.2 | A raw event with all six required fields populated | Log search export |
10.3.1 | Access control list for the log platform, with job roles | Platform role configuration |
10.3.3 | Proof that external-facing logs reach the central server | Forwarding configuration and receipt records |
10.3.4 | File integrity alert configuration and a triggered alert | Integrity monitoring tool |
10.4.1 | Records showing daily review happened across the period | Review records or ticket history |
10.4.1.1 | Configuration of the automated review mechanism | Correlation and alert rule set |
10.4.2.1 | Completed targeted risk analysis with the chosen frequency | Risk analysis document |
10.4.3 | Anomalies raised, worked, and closed with dates | Ticket history |
10.5.1 | A query returning data from twelve months back, and a three-month query returning at speed | Live query against the log platform |
10.6.2 | Time server configuration and the external source in use | NTP configuration |
10.7.2 | Alert configuration covering each named control type | Monitoring and alert rules |
10.7.3 | A worked failure record showing duration, cause, and fix | Incident record |
Two rows in that table cause most of the delay we run into. Requirement 10.4.1 wants evidence that review happened on the days it should have. Teams rarely keep that record unless the review runs through a system that logs itself.
Requirement 10.5.1 causes the other, because it gets tested live. The assessor asks for a query reaching twelve months back. Then they time the three-month query. An archive needing a restore fails the immediately available test.
Where Requirement 10 Programs Usually Fail
Requirement 10 failures cluster in a handful of places. Almost none of them involve missing a rule outright. They start with a control that worked at setup and then stopped working quietly.
1. Sources Drop Off and Nobody Notices
An agent stops forwarding after a server rebuild. The gap surfaces weeks later, when someone searches for an event that should sit there. Under 10.7.2 the audit logging mechanism counts as a critical security control. So a silent collection gap becomes a control failure you were required to catch.
2. New Systems Never Get Onboarded
The CDE gains a component and logging gets configured last, or never. We hit this most often on systems that affect CDE security without holding cardholder data. They feel out of scope until an assessor explains otherwise.
3. Review Runs but Leaves No Trace
The daily review happens, the reviewer finds nothing, and no record survives to prove it. Requirement 10.4.1 gets evidenced by records across the whole period. An unlogged review looks identical to a review that never ran.
4. Retention Gets Set Once and Never Checked
Someone configures a retention period at install, and nobody touches it while log volume triples. Storage pressure quietly shortens the effective window. The twelve-month query then fails on the day an assessor tests it.
5. Clocks Drift Between Systems
Two systems disagree on when an event happened, so the sequence cannot be rebuilt. Requirement 10.6.2 asks for designated time servers and a controlled external source. It costs little to configure and almost nobody revisits it after the first build.
How to Implement Requirement 10 in Eight Steps
Start with scope, because every later decision depends on it. The order below front-loads the work that other steps lean on.
List the in-scope components: Cover the CDE plus everything that can affect its security. Keep the list somewhere it gets updated.
Turn on logging for the seven event types: Check 10.2.1.1 through 10.2.1.7 per component class. Defaults rarely cover all seven.
Normalize the six required fields: Pull a raw event from each source type. Confirm all six 10.2.2 fields land populated.
Forward everything to a central server: Move logs off the host that produced them. An administrator should not be able to edit their own trail.
Lock down and watch the log store: Set read access by job role. Then point file integrity monitoring at the log files themselves.
Automate the daily review: Build correlation and alert rules that surface exceptions. Route them to a queue with a named owner.
Set retention as two tiers: Three months searchable at speed, twelve months retained. Test both with a real query.
Monitor the controls themselves: Alert on collection gaps, stalled review rules, and time drift. This is what 10.7.2 now expects.
Step six absorbs most of the effort, and step eight gets skipped most often. Both got harder in March 2025. They also connect, because automating the review creates the mechanism step eight has to watch.
Running collection, normalization, routing, and retention as one configured path describes what a log management platform does. Build it or buy it, the operational shape holds on any unified observability and ITSM platform. One path in, one protected store, one set of rules reading it.
One limit deserves stating plainly. No tool decides your scope or writes your targeted risk analysis, and assessors examine both. Tooling makes the evidence cheap to produce. The scoping judgment stays with your team.
Get the Version Right Before the Detail
Requirement 10 ranks as the most operational of the twelve PCI DSS requirements. Your IT team owns it outright. Work from the v4.x numbering, because a control matrix built on v3.2.1 addresses points at numbers your assessor abandoned two years ago.
Treat the March 2025 rules as the current floor. Automated review under 10.4.1.1 and control failure detection under 10.7.2 produce most of the readiness gaps we see now. Neither one gets built the week before an assessment.
Two questions will place you faster than a policy review. Can you run a twelve-month query today? And would you know within the hour if a source stopped reporting? Weak answers there point at the work, whatever your control matrix says.
FAQs
Does PCI DSS Requirement 10 require a SIEM?
No. The standard names no product category. Requirement 10.4.1.1 does demand automated log review, and 10.3.3 demands central collection. Most teams meet both with a SIEM or a log management platform.
Does Requirement 10 apply to SAQ A merchants?
Largely not, since SAQ A merchants outsource cardholder data handling and run very few in-scope systems. Your acquirer confirms which SAQ applies. Any system affecting the security of the payment flow can still pull Requirement 10 into scope.
Can audit logs contain cardholder data?
Full PAN should never reach a log, and sensitive authentication data must never persist after authorization. Mask or truncate at the source. A log store holding PAN inherits the full weight of Requirements 3 and 4.
What happens if you fail Requirement 10 during an assessment?
Your assessor documents the finding, and you remediate before they can issue a compliant report. Timelines depend on your assessor and acquirer. Logging gaps hurt most when found late, because retention evidence needs history you cannot create retroactively.
How does Requirement 10 relate to Requirement 11?
Requirement 10 records what happened. Requirement 11 tests whether your defenses work, through scanning and penetration testing. They meet at intrusion detection, where Requirement 11 deploys it and Requirement 10.7.2 makes you notice when it fails.
Author
Ramya Shah
Technical Writer
Ramya Shah is a technical content writer with a computer engineering background and roots in automotive journalism. He covers IT Service Management, observability, IT operations, and AI-driven automation. An early adopter of AI-assisted writing workflows, he turns complex IT processes into clear, engaging content optimized for search and answer engines (AEO), lifting content output and organic visibility.
