PCI DSS Requirement 10: logging you can prove, every day

The deadline has already passed

On 31 March 2025, control 10.4.1.1 of PCI DSS stopped being a future obligation and became a requirement. It had sat in v4.0 as a future-dated item — visible, dated, and easy to defer. Now every assessment against v4.0.1 tests it in full, and many merchants still haven’t implemented it.

What 10.4.1.1 requires is specific: audit log reviews performed daily, through automated mechanisms — mechanisms capable of flagging anomalies, generating alerts, and evidencing that the daily review actually happened. Each of those words removes an old habit. Daily rules out the Friday batch read-through. Automated mechanisms rules out a human skimming a console, however diligent. Evidencing rules out the spreadsheet where someone ticks a box.

The part that makes this urgent rather than merely important: daily review evidence is dated, and gaps can’t be backfilled. Your next assessment looks across the assessment period, and every day without an evidenced automated review is a day of non-compliance sitting in the record — there’s no retroactive fix, no catch-up review that papers over March. If the mechanism isn’t running yet, every week of delay is another week of gap the assessor will see. Merchants who passed their last assessment before the deadline haven’t demonstrated compliance with this control; they’ve demonstrated compliance with the rulebook that no longer applies.

What Requirement 10 requires

Requirement 10 is one of the twelve PCI DSS requirements, and its remit is logging and monitoring of all access to system components and cardholder data. Everything under it serves one goal: when something happens in the cardholder data environment, there’s a trustworthy record, and someone — or something — notices in time for it to matter.

In practice, meeting 10.4.1.1 decomposes into four working parts. Collection: logs from the in-scope systems flowing into one place the mechanism can read — a review can’t cover logs that never arrive. Analysis: automated review that knows what normal looks like well enough to flag deviation, because a mechanism that flags nothing, ever, will draw the same assessor scrutiny as no mechanism at all. Alerting: flagged anomalies becoming alerts that reach a human, with a record of what that human did. Evidence: a per-day artefact — produced by the mechanism, not typed up afterwards — showing the review ran, what it found, and what followed.

That last part deserves the most design attention, because it’s the part the assessment consumes directly. “We review our logs every day” is a claim; a retrievable record for any named day in the period is evidence. Build the control so the evidence is a by-product of the mechanism running, and assessment prep becomes retrieval rather than reconstruction.

Scope discipline matters here too. Requirement 10 attaches to access to system components and cardholder data — so the collection net has to match your assessed scope, not just the systems that are easy to instrument. The awkward log source you deferred is exactly the one the assessor samples.

What the standard actually says

Paraphrasing PCI DSS v4.0.1: Requirement 10 requires that access to system components and cardholder data is logged and monitored. Control 10.4.1.1 requires that automated mechanisms are used to perform audit log reviews; the reviews are daily, and the mechanisms must be capable of flagging anomalies, generating alerts, and providing evidence that the daily review occurred. This is a paraphrase rather than the standard’s text — the authoritative wording is in PCI DSS v4.0.1, available from the PCI Security Standards Council.

The equivalent control in other frameworks

What most people get wrong

“Our last assessment passed, so we’re covered.” That’s the sentence doing the damage. An assessment completed before 31 March 2025 tested 10.4.1.1 as a future-dated item — noted, not enforced. Passing it proved nothing about the control that’s mandatory now, and the next assessment applies the current rulebook to the whole period since.

The related error is treating the requirement as a tooling line item: a SIEM licence gets bought and 10.4.1.1 gets marked done. The requirement isn’t owning a mechanism — it’s the daily review demonstrably happening: anomalies flagged, alerts handled, evidence produced, every day of the assessment period. A tool that’s licensed but half-deployed generates the worst of both worlds — cost incurred, gap intact. Test yourself the way an assessor would: pick a random Tuesday from two months ago and try to produce the review evidence for it. If that takes more than a few minutes, fix the control, not the answer.

How Secure60 handles this

Concretely: our log management platform collects and retains logs from your in-scope systems, and our SIEM runs the automated review daily — flagging anomalies against your environment’s baseline, raising alerts our analysts triage, and writing a per-day evidence record your assessor can read for any date in the period. No gaps to explain, no reconstruction before the assessment. If the mechanism isn’t running in your environment yet, the useful move is to start the clock: book a call and we’ll scope it against your cardholder data environment.