PCI DSS 4.0: Continuous Monitoring for Merchants

March 2025, when v3.2.1 was formally retired, made PCI DSS v4.0 fully mandatory. Its biggest operational change is moving from periodic, point-in-time compliance toward shorter testing intervals for certain controls and documented risk decisions throughout the year. For most merchants, that means rebuilding how compliance work gets done.

Why Annual Snapshots No Longer Satisfy

Under v3.2.1, the usual pattern was a QSA connecting remotely once a year, reviewing evidence from the prior 12 months, and issuing a Report on Compliance. Controls were judged at one point in time. If the firewall rules looked right on audit day, they passed, even if they changed in February or August.

PCI DSS 4.0 keeps annual assessments but adds requirements expected to operate continuously or on shorter schedules. In specific sub-clauses, the DSS uses wording such as "at least once every three months" and "continuously," where v3.2.1 said "at least annually" or "periodically." This changes the evidence QSAs must review; it is not merely a wording update.

Requirement 6.3.3: The Patch Documentation Shift

Requirement 6.3.3 most clearly shows the difference between an annual snapshot and what 4.0 requires. All system components must be protected from known vulnerabilities by applying applicable security patches within defined timeframes. Critical patches, generally those with CVSS base scores at or above 9.0, must be installed within one month of release. Other applicable patches need a timeframe set through a documented targeted risk analysis.

The targeted risk analysis requirement surprises many teams. Before 4.0, a patch policy stating "critical patches within 30 days" was generally enough. Now, each patch category needs evidence of a formal risk evaluation, a selected and documented timeline, and proof that the timeline was met. If installation takes 47 days while the analysis allows 45, that is a finding.

For a merchant operating Linux-based payment processing servers, this means keeping a patch log for each component. It should record the release date, vulnerability classification, risk analysis completion date, approved installation window, and actual installation date. A hand-maintained spreadsheet quickly becomes difficult to manage when infrastructure changes keep the component inventory moving.

Targeted Risk Analysis: More Than a Policy

Several 4.0 requirements let organizations set their own testing frequencies when a documented targeted risk analysis supports them. That analysis must address the threat environment, the type and volume of data at risk, and mitigating factors that lower risk in the specific configuration.

This offers flexibility compared with the old fixed periods. If documented analysis shows that semi-annual firewall rule reviews fit your environment, they may satisfy the requirement. The documentation work is significant, though. Each targeted risk analysis must be reviewed and updated after environmental changes. An April analysis based on one network topology may no longer apply after a July cloud migration.

Teams already conducting quarterly reviews informally may see little operational change. They need to add documentation and treat each review as an evidence-producing event, not only an internal task. Teams relying on annual reviews must use shorter cycles or formally explain, for every affected requirement, why a longer cycle is suitable.

What Continuous Testing Means for Evidence

Requirement 11.3 addresses internal vulnerability scanning. Quarterly internal scans were already required under v3.2.1. Under 4.0, the evidence chain is tighter: scans must cover all CDE components, results must be reviewed, and new vulnerabilities must enter the 6.3.3 patch process. The trail runs from scan result to risk classification, targeted risk analysis, patch installation, and re-scan confirmation, with a timestamp and responsible party at each step.

Evidence should be captured when the work occurs, rather than rebuilt for an audit. Many merchants used to pull logs and create reports in the two or three weeks before a QSA visit. That does not provide the longitudinal evidence 4.0 assessors seek. A March 10 scan paired with a March 28 patch entry tells a consistent story. A log filled from memory in April does not.

Not Every Control Needs Real-Time Visibility

We are not saying every PCI requirement now calls for continuous automated monitoring. Requirements 7 and 8 retain annual review cycles as a baseline, though 4.0 examines their completeness and traceability more closely. Requirements 9 and 12 remain largely policy-driven controls and do not change their assessment frequency.

Continuous monitoring is most useful for controls whose state can drift between audits: firewall rules, patch levels across CDE components, software composition, log pipeline health, and access provisioning. A firewall rule that was correct on January 1 can become non-compliant by September through routine changes that were reviewed individually but not against the segmentation model. Without ongoing visibility, the drift may remain hidden until a QSA finds it.

Maintaining Compliance Between Annual Audits

Merchants that transition most cleanly to 4.0 already treat compliance as an operational state, not an audit event. Making the change requires either considerably more headcount or tooling that automates monitoring and evidence collection.

In practice, structured evidence collected throughout the year changes the QSA engagement from evidence excavation to verification. Targeted risk analysis written when a risk decision was made is more credible than an analysis rebuilt two weeks before an assessment. Patch logs with ongoing timestamps are also easier to defend than logs reconstructed afterward from system audit trails.

The 4.0 requirements reflect how payment security failures occur: through gradual drift in configuration, patch posture, and access control between annual checkpoints, rather than one dramatic event. Merchants are being asked to catch that drift before a breach exposes it. That means knowing the environment every day between audits, not only on audit day.