For a DevOps lead, PCI DSS v4.0.1 shows up as a patch clock for critical vulnerabilities, multi-factor authentication into the card data environment, control of scripts on payment pages, and evidence that all of it happens. Build the evidence into the pipeline rather than collecting it before the audit.
What is the current standard?
The PCI Security Standards Council released v4.0.1 in June 2024. It is a limited revision with no new or deleted requirements. v4.0 was retired on 31 December 2024, and the requirements labelled future dated in v4.0 took effect on 31 March 2025. So if your last audit predates April 2025, expect more to be tested now.
What is the patch rule?
In Requirement 6, v4.0.1 reverted to the v3.2.1 language so that the 30 day installation window applies to critical vulnerabilities only, per the council's summary of changes. That does not mean other patches can wait forever. The standard still expects you to rank and fix them on a schedule you define from risk.
Constructed example: a library in a payment microservice gets a critical advisory on a Monday. A 30 day clock starts. On day 3 you find the service never calls the vulnerable function. Reachability analysis supports a risk ranking, but the standard speaks about critical vulnerabilities, so document your reasoning and agree it with your assessor rather than assuming the clock stops. Safeguard offers reachability analysis and dependency scanning that can give you that evidence.
How should MFA be handled?
The v4.0.1 revision added an applicability note: MFA for all non administrative access into the card data environment does not apply to accounts authenticated only with phishing resistant factors. Administrative access is a separate matter and continues to need MFA. For your platform, audit every path in: bastion hosts, cloud consoles, CI systems that can deploy into the environment, and break glass accounts.
Each path should show an enforcement setting and a log entry that proves it. A screenshot of a policy page is weaker than an export of the identity provider configuration with a date.
What about payment page scripts?
The revision added applicability notes on managing payment page scripts. For DevOps, that suggests a script inventory built in the release process: every script on a payment page is listed, has an owner, and changes only through a reviewed deploy. Alerting on unexpected changes to those pages is a good safeguard, though you should confirm with your assessor what exactly satisfies the requirement text.
Which evidence can the pipeline create?
- Deployment records tying each release to an approved change.
- Dependency inventories per build, stored with the release.
- Scan results, with dates and the versions scanned.
- Access reviews exported from identity systems every quarter.
- Logs of administrative actions in the environment, retained and protected.
Keep them in one place with predictable names. Assessors respond well to the same artifact appearing for each release.
What does Safeguard add?
Safeguard generates SBOMs and scans dependencies, and its free browser scan at gold.safeguard.sh/scan covers up to 100 dependencies. This supports the inventory and vulnerability evidence above. It does not replace a qualified assessor or make your environment compliant.
What to do
- Identify every system in the card data environment and every path into it.
- Enforce MFA on all administrative paths and document the phishing resistant exception where you rely on it.
- Track critical vulnerabilities with a 30 day deadline and an owner.
- Generate a dependency inventory and scan on every release and archive it.
- Maintain an approved script list for payment pages inside the deploy process.
- Export access reviews and logs on a schedule.
Quick check
Does the 30 day patch window apply to every vulnerability?
In v4.0.1 the 30 day installation requirement applies to critical vulnerabilities. Others should be handled on a risk based schedule you define.
When did the future dated v4.0 requirements take effect?
31 March 2025, and v4.0.1 did not change that date.
Sources
Last reviewed: 18 October 2026.
