Skip to main content
Commerce Security Authority
Category: Incident Response and Skimming

Log Review

Also known as: Log Analysis
Simply put

Log review is the process of examining computer-generated records, called logs, to understand what activity occurred on systems and networks. Security and compliance teams review these records to spot suspicious behavior, investigate incidents, and confirm that systems are operating as expected. It is an ongoing practice rather than a one-time check.

Formal definition

Log review is the process of reviewing, interpreting, and understanding computer-generated log records to identify anomalies, security-relevant events, and evidence of unauthorized or unexpected activity. In a payment security context it typically supports monitoring and audit-trail objectives; note that the specific logging, review frequency, and retention controls, along with their requirement numbering and wording, differ between PCI DSS versions and should be confirmed against the current published standard rather than assumed. Log review may reduce time to detect and investigate incidents but is subject to coverage gaps, log integrity limitations, and false-positive or false-negative trade-offs depending on how log sources, tooling, and review procedures are implemented and validated.

Why it matters

Logs are often the primary record of what actually happened on a system or network. When an intrusion, misconfiguration, or unauthorized access occurs, the log record may be the only evidence available to reconstruct the sequence of events and understand its scope. Without a consistent review practice, that evidence can accumulate unexamined, and suspicious activity can go unnoticed until the effects become severe.

In a payment security context, log review supports the broader monitoring and audit-trail objectives that help teams detect and investigate security-relevant events. Reviewing logs on an ongoing basis may reduce the time it takes to identify and respond to an incident, which can matter when unauthorized activity is otherwise easy to overlook among routine operations. It is important to treat log review as a continuous discipline rather than a one-time check, since a single review captures only a moment in a constantly changing environment.

The value of log review depends heavily on how it is implemented. Coverage gaps, limitations in log integrity, and the inherent trade-off between false positives and false negatives all shape how much a program can rely on it. Note that specific logging, review frequency, and retention controls, along with their requirement numbering and wording, differ between PCI DSS versions and should be confirmed against the current published standard rather than assumed.

Who it's relevant to

Security Engineers and Analysts
These teams rely on log review to spot suspicious behavior, investigate incidents, and confirm that systems are operating as expected. They are also responsible for selecting log sources, tuning review procedures, and managing the false-positive and false-negative trade-offs that come with detection.
Compliance Officers
Log review supports monitoring and audit-trail objectives in payment environments. Compliance staff should confirm the applicable logging, review frequency, and retention controls against the current published PCI DSS version, since requirement numbering and wording differ between versions.
Fraud Analysts and Incident Responders
Because logs are often the primary evidence of what occurred, these teams use log review to reconstruct events and reduce the time needed to detect and investigate activity. They should remain aware of coverage gaps and log integrity limitations that can affect how much the record can be relied upon.

Inside Log Review

Log Sources in Scope
The systems and components whose audit logs are subject to review, typically including system components in the cardholder data environment and connected or security-impacting systems. What must be logged and reviewed is defined by PCI DSS logging and monitoring requirements, which differ in numbering and wording across versions; confirm against the current published standard.
Audit Log Content Elements
The individual events and data fields expected in audit records, which commonly include user identification, type of event, date and time, success or failure indication, origination of event, and affected data, system component, or resource. Audit logs should not capture sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks, which must not be stored after authorization.
Daily and Periodic Review Cadence
The frequency at which logs are examined. PCI DSS distinguishes reviews expected on a more frequent basis for certain critical events and logs from those that may be reviewed at a defined periodic interval based on the entity's risk analysis. The exact cadence expectations and any allowance for automated support depend on the current standard version.
Automated Log Review Mechanisms
Tools such as SIEM platforms, log aggregation, and automated alerting used to support review at scale. Automation is intended to help identify anomalies and reduce manual burden, but tuning affects false-positive and false-negative rates; automation supports rather than replaces documented human review of flagged events.
Exception and Anomaly Follow-Up
The process for investigating anomalies, exceptions, and suspected security events identified during review, including escalation and linkage to incident response. Detection through log review is intended to help surface potential issues and does not by itself confirm or remediate an incident.
Log Integrity and Retention Controls
Controls protecting logs from unauthorized modification, including access restriction, integrity monitoring, and time synchronization, plus retention over a defined period with a portion readily available for analysis. Retention duration expectations are set by the current PCI DSS version and should be confirmed there.
Review Documentation and Evidence
Records demonstrating that reviews occurred, what was examined, who performed them, and how exceptions were handled. This evidence supports assessment and helps demonstrate that the review process is operating as an ongoing activity rather than a point-in-time exercise.

Common questions

Answers to the questions practitioners most commonly ask about Log Review.

Does PCI DSS require that all logs be reviewed manually every day?
No. The intent is that certain security-relevant events, such as those tied to critical systems and access to cardholder data, receive attention on a defined frequency, but this does not mean every log entry must be read by a human. PCI DSS expressly allows the use of log-harvesting, parsing, and alerting tools to support review, so that human effort can focus on exceptions and anomalies. Confirm the current review-frequency and daily-review wording against the published version of the standard, since requirement numbering and phrasing differ between versions.
If I have automated log monitoring in place, does that satisfy the log review obligation on its own?
Not necessarily. Automated tooling is intended to support review, but the process still needs defined handling of the events and alerts it produces, including who investigates them, how follow-up is documented, and how exceptions are escalated. A tool that generates alerts no one acts on does not demonstrate that reviews are actually occurring. Validate the specific expectations for automated mechanisms against the current published standard rather than assuming a tool alone meets the requirement.
Which systems and events should be in scope for log review?
Log review generally focuses on systems in the cardholder data environment and those connected to or that could impact it, along with security functions and critical systems. Event types commonly emphasized include access to cardholder data, privileged or administrative actions, authentication attempts and failures, changes to accounts and audit logs, and use of security mechanisms. Because scope depends on your environment and segmentation, and because the exact event categories are defined in the standard's logging requirements, confirm coverage against your validated scope and the current published PCI DSS.
How should we handle and document exceptions and anomalies found during review?
Anomalies and exceptions identified during review should feed a defined follow-up process, so that each item is triaged, investigated as warranted, and resolved with a record of the outcome. Documenting who reviewed what, when, and what actions were taken helps demonstrate that the process operates over time and supports incident response if an event proves significant. Keep in mind that detection controls involve false-positive and false-negative trade-offs, so tuning and periodic review of alert logic are part of maintaining an effective process.
How long should logs and evidence of review be retained?
PCI DSS specifies audit log retention expectations, commonly framed as retaining history for a defined period with a portion readily available for analysis, but the exact retention period and availability wording are set in the standard and should be confirmed against the current published version. Beyond audit logs themselves, retaining evidence that reviews occurred, such as records of who reviewed logs and how exceptions were handled, supports both assessment and investigation. Legal, regulatory, and contractual obligations in your region may impose additional retention requirements.
How can we protect the integrity of logs so review remains trustworthy?
Log review is only as reliable as the underlying logs, so controls that limit tampering matter, such as restricting access to audit trails, separating log storage from the systems generating the logs, and using mechanisms that help detect or alert on changes to log data. Centralizing logs to a protected location can also support consistent review and reduce the risk that a compromised host quietly alters its own records. Confirm the specific log-protection expectations against the current published PCI DSS, as the wording and structure vary by version.

Common misconceptions

Collecting and centralizing logs satisfies the log review requirement.
Aggregation is a prerequisite, not the review itself. PCI DSS expects logs to be examined and anomalies followed up. Storing logs in a SIEM without documented review and exception handling does not meet the intent of the requirement.
Deploying a SIEM with alerting eliminates the need for human log review.
Automated mechanisms are intended to support review and help identify anomalies, but tuning trade-offs produce false positives and false negatives. A documented process for reviewing flagged events and defined periodic reviews is still expected; automation reduces manual effort rather than removing accountability.
Log review is a distinct control that has little relationship to other standards or data handling rules.
Log review is governed by PCI DSS logging and monitoring requirements and is separate from standards such as PCI PIN or PCI P2PE. It also intersects with data protection rules: audit logs must not contain sensitive authentication data, and any cardholder data captured must be handled under applicable masking, truncation, or other controls.

Best practices

Define and maintain a documented list of in-scope log sources across the cardholder data environment and connected or security-impacting systems, and reconcile it during scope validation so no required source is silently omitted.
Verify that audit records capture the expected event fields and confirm that logs do not inadvertently record sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks.
Base your review cadence on the current published PCI DSS version and a documented risk analysis, distinguishing events warranting more frequent review from those reviewed at a defined periodic interval, and confirm exact expectations against the standard rather than assuming a fixed requirement number.
Use automated tools such as SIEM and alerting to support review, and continually tune correlation rules to manage false-positive and false-negative trade-offs while keeping a documented human process for investigating flagged events.
Protect log integrity through access restriction, integrity monitoring, and synchronized time sources, and retain logs for the period defined by the current standard with a recent portion readily available for analysis.
Record evidence of who performed each review, what was examined, and how anomalies and exceptions were escalated and linked to incident response, so the process demonstrably operates on an ongoing basis.