PCI DSS Requirement 10 requires organizations to log and monitor access to system components and cardholder data so suspicious activity can be detected, investigated, and traced back to a person, system, or event. Under PCI DSS v4.0.1, that means more than switching logging on. Teams need usable audit records, protected log storage, defined review routines, enough retention for investigation, consistent time, and a way to notice when critical security controls stop working.
The requirement is deliberately operational. An assessor will not only ask whether logs exist. They can also look at which events are captured, whether daily reviews happen where required, how anomalies are handled, how long history is kept, and whether the process still works when a logging or security control fails.
Requirement 10 sits inside the wider PCI DSS control set. For the standard-level view of scope, validation, and all 12 requirement groups, see our PCI DSS requirements guide. The sections below focus on the logging and monitoring work behind Requirement 10.
Requirement 10 is easier to work with when you separate collection, protection, review, retention, time, and failure handling. The table below shows the job of each main section without reproducing the standard line by line.
| Section | Main job | What it means in practice |
| 10.1 | Govern the process | Document the logging and monitoring process, roles, and responsibilities. |
| 10.2 | Create usable audit logs | Enable logging and capture the events and event details needed for detection and investigation. |
| 10.3 | Protect the logs | Restrict access, prevent unauthorized changes, back up logs securely, and detect tampering. |
| 10.4 | Review activity | Review required logs daily, automate review where required, define periodic review frequency for other in-scope systems, and address anomalies. |
| 10.5 | Keep enough history | Retain at least 12 months of audit log history, with the most recent three months immediately available for analysis. |
| 10.6 | Keep timestamps consistent | Synchronize system clocks and protect time-synchronization settings and data. |
| 10.7 | Notice control failures | Detect, alert on, and respond promptly when critical security control systems fail. |
PCI SSC lists PCI DSS v4.0.1 as the current standard in its Document Library. The detailed assessment documents are the right source for the exact requirement wording and testing procedures.
At a practical level, Requirement 10 asks for an audit trail that can answer a fairly basic incident question: who did what, when did it happen, where did it come from, did it succeed, and what system or data was affected? If your logs cannot answer those questions, having terabytes of them will not help much during an investigation or an assessment.
The requirement also assumes that logging is part of an operating process. Someone has to own the sources, review the right activity, follow up on anomalies, keep enough history, and notice when the logging stack itself is no longer trustworthy.
The scope of those controls starts with the systems covered by the assessment. Our CDE and PCI DSS scope guide explains why logging, identity, time services, and other security systems can be in scope even when they never store a card number.
PCI DSS does not leave event selection entirely to preference. Requirement 10.2 identifies activity that must be captured because it matters for accountability and investigation. The goal is not to collect every possible debug message. It is to make security-relevant actions traceable.
The required event categories include:
For each auditable event, PCI DSS expects enough context to reconstruct what happened: user identification, event type, date and time, success or failure, event origin, and the affected data, system component, resource, or service.
This does not mean every environment needs identical application, operating-system, and database logs. PCI SSC FAQ 1081 explains that the combination should be appropriate to the environment and able to record the events required by Requirement 10.
Requirement 10.4.1 sets a daily review expectation for the logs most likely to matter during a security event. That includes all security events, logs from systems that store, process, or transmit cardholder data or sensitive authentication data, logs from critical system components, and logs from systems that perform security functions such as network security controls, IDS/IPS, and authentication servers.
That daily requirement is easy to misunderstand. It does not mean a person must open every log file and read it line by line. PCI DSS v4.x introduced a separate requirement for automated mechanisms to perform audit-log reviews, and that requirement became mandatory on 31 March 2025.
The useful outcome is a review process that finds anomalies and suspicious activity, then gets those findings to someone who can decide what needs action. Requirement 10.4.3 closes the loop by requiring identified exceptions and anomalies to be addressed.
Yes, for the audit-log reviews covered by Requirement 10.4.1. Requirement 10.4.1.1 requires automated mechanisms to perform those reviews. The requirement was introduced as a future-dated control and is now part of current assessment work.
That still leaves teams with an operating choice. Automation can correlate events, apply rules, identify unusual activity, group related records, and reduce the amount of raw data a person has to inspect. It does not remove the need to decide what an exception means, who owns it, or what to do when the result points to a real security issue.
A SIEM is one common way to run this process, but Requirement 10 does not name one mandatory product. The control is about the outcome and the evidence. A tool that collects logs but does not support the required review process does not solve the problem by itself.
Other in-scope system logs still need periodic review under Requirement 10.4.2. The difference is that PCI DSS does not give every one of those systems the same fixed review interval.
Requirement 10.4.2.1 requires the organization to define that frequency through a targeted risk analysis performed using Requirement 12.3.1. That is now a mandatory requirement, not an optional future control.
PCI SSC clarified this point in FAQ 1304: depending on the environment, some in-scope systems may fall outside the categories that require daily review, and their periodic review frequency must be justified through the targeted risk analysis.
Our PCI DSS risk assessment guide covers how targeted risk analyses fit into the wider PCI DSS risk process and what teams should document instead of choosing a frequency by habit.
Requirement 10.5.1 requires at least 12 months of audit log history, with the most recent three months immediately available for analysis. This is one of the places where a technically correct logging setup can still create an assessment problem if retention is too short or archived data is difficult to retrieve.
"Immediately available" matters in practice. If the latest three months sit in an archive that takes days and a manual restore request to access, the operating model does not match the requirement very well. Older history can use a different storage tier, but the team still needs a reliable way to retrieve and analyze it when required.
Retention also has a cost dimension. High-volume sources can become expensive quickly, which is why teams should decide which records are required for PCI DSS, which are needed for security investigation, and which are optional noise before they start deleting data to control a SIEM bill.
A timeline is only useful when the timestamps line up. Requirement 10.6 requires time-synchronization mechanisms so events from different systems can be compared without guessing whether a five-minute gap is attacker activity or clock drift.
The requirement covers designated time sources, consistent time distribution, and protection of time settings and data. Changes to time settings on critical systems also need to be logged, monitored, and reviewed.
This can look like infrastructure housekeeping until an incident crosses several systems. Authentication, firewall, application, endpoint, and database events become much harder to reconstruct when each source tells a slightly different version of time.
Requirement 10.7 deals with a different failure mode: the security controls themselves stop working. Logging is one of those controls, but the list is wider and includes network security controls, IDS/IPS, change-detection mechanisms, anti-malware, physical and logical access controls, segmentation controls when used, audit-log review mechanisms, and automated security testing tools when used.
As of 31 March 2025, Requirement 10.7.2 applies to all entities and supersedes the older 10.7.1 service-provider-only requirement. The organization needs to detect failures, generate alerts, and address them promptly. Requirement 10.7.3 then requires a documented response process for those failures.
PCI SSC explains the post-March-2025 treatment in FAQ 1593, including the fact that 10.7.2 is now the effective requirement and 10.7.1 is reported as not applicable in current ROC or SAQ work.
No. PCI DSS Requirement 10 does not require a product called SIEM. It requires logging, protection, review, retention, time synchronization, and failure detection that meet the defined controls. A SIEM is common because it can centralize data, automate review, retain history, correlate activity, and create an evidence trail for investigations and assessments.
A SIEM also does not replace the rest of the security stack. PCI SSC has specifically noted that centralized log correlation does not replace intrusion detection or prevention controls. Logs from those systems should feed the review process, but Requirement 11 still has its own testing and detection responsibilities.
For teams deciding who should run the logging platform and review process, comparing in-house, hybrid managed, and fully managed SIEM operating models is a useful next step: ownership, data, cost, monitoring, and operational trade-offs differ significantly between them.
Requirement 10 evidence usually comes from several places. The assessor needs to see that the configured controls and the operating records agree with the documented process. A policy that says "logs are reviewed daily" is not very useful if the review history shows long gaps.
Typical evidence can include:
If you need the assessment-level view of how evidence is tested and documented in SAQ, ROC, and AOC work, see our PCI DSS audit and assessment guide.
The easiest way to make Requirement 10 painful is to treat it as an annual evidence exercise. By the time the assessment arrives, nobody remembers why a source stopped sending logs in February or why an alert queue went unreviewed during a team change.
A healthier operating rhythm is simple enough to explain:
If the team needs continuous monitoring rather than a platform that somebody checks when time allows, Q-SOC provides managed 24/7 monitoring, triage, and security-operations support across connected telemetry. The exact PCI DSS evidence boundary should still be agreed in the service scope.
Requirement 10 is not a contest to collect the most data. The useful question is whether the organization can reconstruct important activity, notice suspicious behavior, protect the record, and prove that the review process actually runs.
A smaller set of complete, well-owned, correctly retained logs is more useful than a giant archive nobody reviews. Start with the PCI DSS scope, map the required events and review frequencies, then make sure ownership survives holidays, staff changes, tool migrations, and the occasional broken collector. That is usually where the real gaps appear.
Turn Requirement 10 into an operating control
If logging, review ownership, or assessment evidence is the weak point, we can help define what needs to change and how it should be operated.
No. PCI DSS does not require a specific SIEM product. It requires defined logging, review, retention, time synchronization, and failure-detection outcomes. A SIEM is simply a common way to run those controls at scale.
No. Requirement 10.4.1 defines the logs that need at least daily review. Other in-scope logs are reviewed periodically, with the frequency set through a targeted risk analysis under Requirement 10.4.2.1.
At least 12 months. The most recent three months must be immediately available for analysis. Older history can use another storage tier as long as it remains retrievable when needed.
Yes. Requirement 10.4.1.1 became mandatory on 31 March 2025. Automated mechanisms are required for the audit-log reviews covered by 10.4.1.
It requires failures of critical security control systems to be detected, alerted, and addressed promptly. Since 31 March 2025, 10.7.2 applies to all entities and supersedes the older 10.7.1 requirement.
Yes, the work can be outsourced if the service scope covers the required review and evidence. The customer still needs to understand the control, manage the provider, and make sure responsibilities are clear during assessment.
Not automatically. PCI SSC says the right combination depends on the environment. What matters is that the implemented logging captures the events and details Requirement 10 expects.
Common problems are missing log sources, short retention, review gaps, unclear ownership, poor timestamps, or alerts with no follow-up record. The issue is often the operating process rather than the logging tool itself.