PCI DSS v4.0.1 Continuous Validation Requirements

Your QSA arrives for the annual assessment. She asks when your last automated log review ran. You check the SIEM. The automated review job failed silently 47 days ago. Nobody noticed because nobody was monitoring the monitor. Under PCI DSS v3.2.1, this was a finding. Under PCI DSS v4.0.1 Requirement 10.4.1.1, it's a control failure with a specific mandate: "Automated mechanisms are used to perform audit log reviews."

The word "automated" didn't appear in v3.2.1's log review requirement. Now it does. And it's not alone. PCI DSS v4.0.1 introduced 64 new requirements, many of which replaced periodic human review with continuous or automated validation mandates. The full compliance deadline for these future-dated requirements was March 31, 2025. If you're still running annual validation cycles, you're already out of compliance with the current standard.

Not "at risk." Out of compliance. The standard's language is unambiguous.

What changed: from periodic to continuous

PCI DSS v3.2.1 was built around annual validation. Conduct your assessment, produce your ROC or SAQ, maintain controls until next year. The assumption: if controls operated at assessment time, they'd continue operating between assessments.

PCI DSS v4.0.1 abandoned that assumption. The PCI SSC states the update "promotes security as a continuous process." This isn't aspirational. It's embedded in specific requirements that mandate ongoing, automated, or frequent validation.

The structural shift appears in three forms:

Targeted risk analysis (Requirement 12.3.1). Organizations must perform a targeted risk analysis for each requirement that provides flexibility in control activity frequency. The risk analysis determines the frequency. "Annual" is no longer the default.

Customized approach validation. Each customized control requires its own targeted risk analysis and its own monitoring to confirm ongoing effectiveness. You can't customize once and walk away.

Explicit automation mandates. Multiple requirements now specify "automated mechanisms" rather than allowing manual processes. These are SHALL requirements that a QSA will validate against.

The 13 requirements that break annual validation

Not all 64 new requirements demand continuous monitoring. But 13 specifically break the annual model by requiring ongoing, frequent, or automated validation:

Requirement	Title	What It Demands	Why Annual Fails
5.2.3.1	Risk analysis for malware scans	Targeted risk analysis determines scan frequency when not using continuous monitoring	Frequency is risk-based, not calendar-based
5.3.2.1	Automated malware solution behavior analysis	Automated analysis of behavior of malware solutions	Requires continuous automated monitoring of the anti-malware system itself
6.3.2	Custom software inventory	Bespoke/custom software inventory maintained	Inventory must reflect current state, not annual snapshot
6.4.2	Web app attack detection	Automated technical solution for web-facing apps that continually detects and prevents web-based attacks	Explicitly requires "continually"
7.2.4	Access review frequency	All user accounts and related access privileges reviewed at least every six months	Breaks annual cycle, requires semi-annual evidence
8.6.3	Service account password management	Passwords/passphrases for service and system accounts changed per targeted risk analysis	Risk-determined frequency, not annual
10.4.1.1	Automated log review	Automated mechanisms are used to perform audit log reviews	Explicitly "automated mechanisms," not human periodic review
10.4.2.1	Automated detection of security event review failures	Automated mechanisms detect and alert on failures of critical security control systems	Monitors the monitoring, must be automated
10.7.2	Detection of critical control failures	Failures of critical security controls are detected, alerted, and addressed promptly	"Promptly" precludes periodic review schedules
11.3.1.1	Authenticated vulnerability scanning	Internal vulnerability scans via authenticated scanning	Must be able to detect vulnerabilities that unauthenticated scans miss, ongoing
11.4.7	Multi-tenant service provider testing	Multi-tenant service providers support external penetration testing by their customers	Not a one-time setup, requires ongoing availability
11.6.1	Change detection on payment pages	Change-and-tamper-detection mechanism deployed on payment pages	Must run continuously, not at point-in-time
12.3.1	Targeted risk analysis	Targeted risk analysis performed for each requirement specifying frequency flexibility	Determines all other frequencies, must be maintained

The common thread: each specifies "automated," "continually," "promptly," or ties frequency to a risk analysis that must itself be maintained. None are satisfied by an annual cycle.

Requirement 12.3.1: The meta-requirement

Requirement 12.3.1 is the requirement about requirements. For each PCI DSS requirement where the entity has flexibility in how frequently an activity is performed, the entity must document a targeted risk analysis: identification of assets being protected, identification of threats, likelihood analysis, and a resulting frequency determination.

Every time a requirement says "periodically," you need a documented risk analysis explaining why you chose your frequency. Annual isn't wrong per se, but it requires justification. If your risk analysis can't articulate why annual is appropriate, the QSA can (and will) challenge the frequency.

You need frequency governance. Not "we review annually" but "we review at this frequency because our risk analysis dated [X] determined that [threat Y] against [asset Z] requires this cadence." That's a lot of moving parts to track in a spreadsheet.

Requirement 10.4.1.1: The one that catches everyone

This is the requirement mid-market organizations fail most often. It requires "automated mechanisms" to perform audit log reviews. Not "regular review of audit logs" (that was v3.2.1's language in 10.6.1). Automated mechanisms.

In practice: correlation rules, detection logic, and alerting that run without human initiation. A SIEM that ingests logs, applies detection rules, and surfaces anomalies. Not a person opening Splunk once a week and scrolling through events.

The requirement doesn't specify which tool, but it requires the mechanism exists, operates continuously, and produces evidence of its operation. A QSA will ask: show me your automated review configuration, show me evidence it's running, show me what it flagged in the last 30 days.

For organizations on Microsoft's stack, this maps to Sentinel's analytics rules and automated investigation playbooks. Detection rules fire automatically. Alerts route to response workflows. Evidence of operation is the Sentinel incident log itself.

The key point per Requirement 10.4.2.1: you also need to monitor the monitor. If Sentinel's data connector fails, you need an automated mechanism that detects and alerts on that failure.

Requirement 11.6.1: Continuous payment page integrity

For e-commerce organizations, Requirement 11.6.1 requires a change-and-tamper-detection mechanism on payment pages that alerts personnel to unauthorized modification of HTTP headers and script contents.

This exists because of Magecart-style attacks: injected JavaScript skimming card data, present for hours or days, invisible to monthly scanning. The mechanism must detect changes, evaluate authorization, and alert on unauthorized modifications at a frequency determined by targeted risk analysis (12.3.1 again). Given the threat model, the risk analysis will almost certainly require daily or more frequent monitoring.

Annual penetration testing doesn't satisfy this. Monthly vulnerability scanning doesn't satisfy this. It requires purpose-built page integrity monitoring running continuously.

How Kyudo addresses continuous PCI validation

Kyudo's approach to PCI DSS v4.0.1 continuous requirements maps to two core capabilities: CMCAE's continuous scoring engine and the integrations layer's connection to Microsoft security infrastructure.

Automated log review (10.4.1.1): Microsoft Sentinel integration feeds detection events into Evidence Hub. Sentinel's analytics rules constitute the "automated mechanism." Each rule firing generates a timestamped evidence artifact linked to the 10.4.1.1 control. CMCAE scores the control based on evidence freshness: no detection evidence in 7 days degrades the score. If the data connector fails (10.4.2.1), Sentinel's health monitoring alerts also feed into Evidence Hub.

Continuous control scoring: CMCAE evaluates PCI controls continuously as evidence flows in. Each requirement has a defined evidence cadence derived from targeted risk analysis. When evidence stops flowing at the expected cadence, the control score drops from green to yellow (aging) to red (stale). You see drift in real time, not at assessment time.

Targeted risk analysis management: Controls Hub stores each targeted risk analysis as a structured artifact linked to its requirement. When the review date passes without renewal, the control's frequency justification lapses, and CMCAE flags it. The risk analysis is a living control with its own freshness requirement.

Payment page integrity (11.6.1): Defender for Cloud's file integrity monitoring feeds change events into Evidence Hub. The control requires evidence of monitoring operation, evidence of change detection (including legitimate changes, proving the system works), and evidence of investigation when unauthorized changes are flagged.

Vulnerability scanning (11.3.1.1): Defender for Cloud's authenticated vulnerability assessment flows into Evidence Hub. CMCAE evaluates scan coverage and scan recency against the risk-analysis-determined frequency.

Cross-framework value: Every PCI control in Controls Hub has STRM relationships to equivalent controls in other frameworks. The automated log review control maps to SOC 2 CC7.2, ISO 27001 A.12.4.1, and NIST CSF DE.CM-1. Evidence collected for PCI 10.4.1.1 simultaneously attests to all mapped controls.

The counter-argument: "Our QSA hasn't flagged this yet"

Some organizations report that their QSA assessed them against v4.0.1 and didn't fail them on continuous requirements. This happens for two reasons, neither protective.

First, some QSAs applied future-dated requirements as recommendations rather than hard requirements during the transition period. That transition ended March 31, 2025. Any assessment after that date must validate the full v4.0.1 requirement set.

Second, assessment quality varies. A lenient assessment doesn't change the standard. If a breach occurs and a forensic investigator reviews your compliance against the actual standard, the gaps become liabilities.

The standard is the standard. It doesn't require your QSA to find the gap for the gap to exist.

The other objection: "Continuous monitoring is expensive." If you're already running Microsoft Sentinel and Defender for Cloud, the infrastructure for automated detection and evidence collection exists. The gap isn't infrastructure, it's the connection between your security tools and your compliance program. Your SIEM generates alerts. Your compliance tool stores controls. Nothing connects them. That's what continuous monitoring closes.

Your PCI v4.0.1 readiness checklist

Audit your targeted risk analyses (12.3.1). List every requirement where you've chosen a validation frequency. Confirm each has a documented risk analysis justifying that frequency. If the analysis is older than 12 months, it needs renewal.
Validate your automated log review (10.4.1.1). Confirm automated detection rules are running, firing, and producing evidence. Then confirm a failure of the automated system would itself be detected (10.4.2.1). Test this: disable a data connector and verify an alert fires.
Verify payment page monitoring (11.6.1) if applicable. Confirm change-detection is active on all payment pages. Make a controlled change to a script reference and verify the mechanism detects and alerts. Document the test.
Review your semi-annual access review cadence (7.2.4). If your access reviews are annual, they're non-compliant. Implement six-month reviews with documented evidence of completion and remediation actions.
Connect your security infrastructure to your compliance program. Sentinel, Defender, vulnerability scanners, and integrity monitoring must feed into the system that tracks PCI controls. If there's a manual step between detection and compliance evidence, that's where gaps appear.

Regulatory clocks don't recognize "we meant to automate that." PCI DSS v4.0.1's continuous requirements are in effect today. What your systems are producing right now is your compliance posture.

Kyudo's CMCAE continuously scores PCI DSS v4.0.1 controls against live evidence from Microsoft Sentinel and Defender for Cloud. No annual snapshots. No stale evidence.

Book a demo to see your PCI controls scored against current evidence, not last quarter's assessment.