PCI DSS Requirement 10: Logging and Monitoring That Survives an Investigation

Logging is the requirement everyone technically satisfies and few actually get right, and the gap only becomes visible at the worst possible moment: during a breach investigation, when the forensics team asks for the logs that prove what the attacker touched, and how far back they can see. PCI DSS Requirement 10 exists for exactly that moment. It specifies what a payment environment must record, how those records are protected from tampering, how long they are kept, and the duty to actually review them rather than merely collect them. Logs are simultaneously your detection system, your investigation evidence, and the thing that decides how large your breach is officially judged to be.

Quick answer: Requirement 10 mandates logging access to cardholder data and to the systems that protect it, capturing defined events with defined details for each. Audit logs must be protected from alteration, synchronized to accurate time, retained for at least 12 months with at least 3 months immediately available, and reviewed, with version 4.0 pushing toward automated review. The events to log include all individual access to card data, administrative actions, authentication attempts, and changes to the logging system itself.

What must be logged?

The requirement targets the events that reveal both legitimate administration and an intruder’s footprints:

• All individual user access to cardholder data.
• All actions taken by anyone with administrative or root privileges.
• Access to the audit logs themselves (watching the watchers).
• Invalid and successful authentication attempts, so credential attacks and successful intrusions both leave traces.
• Changes to identification and authentication mechanisms (new accounts, privilege elevation, credential changes).
• Initialization, stopping, or pausing of the logging mechanisms, because turning logging off is an attacker’s first housekeeping step.
• Creation and deletion of system-level objects.

And for each event, enough context to be useful: who (user), what (event type and affected data or resource), when (timestamp), where (origin), and the success or failure outcome. A log that records that something happened without recording who did it to what is an expensive null.

How must logs be protected and timed?

Logs are evidence, and evidence must be trustworthy, so the requirement hardens the logs themselves:

• Protect from alteration: promptly ship logs to a central, access-controlled store (a SIEM or log server) so that compromising a source system does not let the attacker edit the record of their own actions. File-integrity or write-once controls back this up.
• Restrict access: only those with a job need should read audit trails, and their access is itself logged.
• Accurate, synchronized time: all systems sync to a controlled, authenticated time source. Without synchronized clocks, correlating an intrusion across firewall, server, and database logs becomes guesswork, and the timeline a forensic investigator builds is only as good as the timestamps under it.

How long, and why does retention decide breach size?

At least 12 months of retention, with at least the most recent 3 months immediately available for analysis. That window is not arbitrary paperwork; it is what bounds an investigation. When a breach is discovered, the central question is how long the intrusion persisted and what it reached. If logs only reach back weeks but the intrusion ran for months (the dwell-time problem our detection time article treats as the master metric), the investigator cannot bound the exposure, and the brands may be forced to treat the entire at-risk population as compromised. Good retention literally shrinks the official size of your breach, with direct consequences for the assessments and claims our cyber insurance guide describes.

What does review actually mean in 4.0?

Collection without review is the requirement’s oldest failure mode: terabytes of logs no human ever opens until the breach. The standard has always required review of security-relevant logs; version 4.0 presses harder toward automated mechanisms, because manual daily review of modern log volumes is fiction. In practice this means:

• Automated analysis (SIEM correlation, anomaly detection) surfacing the events worth human attention, rather than people scrolling logs.
• Daily attention to critical security events and to logs from systems performing security functions, with defined escalation.
• A frequency for reviewing lower-criticality logs set through the targeted risk analysis the standard now uses for several periodic activities, the same TRA discipline behind the customized approach.
• Response, not just detection: an alert nobody acts on is review theater. The pipeline must feed the incident process rehearsed in tabletop exercises.

Where do logging programs fail?

• Card data in the logs. The irony that bites hardest: applications that log full PANs, or worse, security codes, turn the audit trail into an unprotected cardholder data store. Logs are exactly where our data discovery sweeps find forbidden data; mask at the source.
• Incomplete coverage. Cloud control planes, containers, serverless functions, and SaaS admin consoles that touch the environment are in scope and routinely unlogged, a gap amplified in the shared-responsibility confusion of cloud deployments.
• Clock drift. Unsynchronized time quietly destroys correlation; it is cheap to fix and expensive to discover during forensics.
• Unmonitored log pipeline. If nobody notices when a source stops sending, the first sign of a disabled log feed is its absence during the investigation.
• Retention that looks right but is not. Backups that are not readily retrievable do not satisfy the immediately-available window; test restoration.

Frequently asked questions

How long must PCI DSS logs be kept?

At least 12 months total, with at least the most recent 3 months immediately available for analysis. Many organizations keep longer to support investigations and other regulatory needs.

Does Requirement 10 force us to buy a SIEM?

It does not name a product, but its demands (tamper-proof central storage, correlation, automated review at modern volumes) are extremely hard to meet without SIEM-class tooling. Small, simple environments can sometimes meet it with lighter centralized logging.

Can we store card numbers in logs if the logs are encrypted?

Avoid logging PANs at all; mask or truncate at the source. Encrypted logs still create an unnecessary cardholder data store, and security codes must never appear in logs under any protection, per the storage prohibitions.

What is the biggest logging mistake in a breach?

Insufficient retention and coverage: when logs cannot show how long an intruder was present or what they reached, the breach is scoped to the worst case, enlarging cost and liability. Time synchronization failures run a close second.

Is daily log review literally required every day?

Critical security events and security-system logs warrant daily attention, realistically through automation; review frequency for lower-risk logs can be set by documented risk analysis. The intent is timely detection and response, not a human reading everything each morning.

Requirement 10 is where security quietly becomes accountability. Logs are the one control whose full value appears only in retrospect, which is why the discipline has to be built before the incident: in the aftermath, you cannot generate the history you failed to keep.