On 31 March 2025 the future-dated requirements in PCI DSS v4.x stopped being best practice and became requirements. If your last assessment was before that date, the scope of your next one is larger, and three of the changes have teeth.
A note on versions first, because it causes confusion: v4.0.1 was published on 11 June 2024 as a limited revision with “no new or deleted requirements”, and v4.0 was retired on 31 December 2024. If a proposal quotes v4.0, the firm writing it has not looked at the standard for two years.
Internal scanning now has to be authenticated
Requirement 11.3.1.2 says internal vulnerability scans must be performed via authenticated scanning: systems that cannot accept credentials have to be documented, sufficient privileges must be used on those that can, and if the scanning account can also be used for interactive login it has to be managed under requirement 8.2.2.
In practice this is the change that most often breaks an existing programme. Unauthenticated internal scanning no longer satisfies PCI. The scan now sees installed package versions, local privilege escalation paths and missing patches that a network-level scan never saw, so the first authenticated run produces an uncomfortable number of findings. Run it early, not the week before your assessment.
Payment page scripts have to be inventoried and watched
Two requirements took effect together and they are aimed squarely at e-skimming - the Magecart pattern, where a third-party script on your checkout page quietly copies card details as they are typed.
- 6.4.3 - a method to confirm each script is authorised, a method to assure the integrity of each script, and an inventory of all scripts with a written business or technical justification for each one.
- 11.6.1 - a change and tamper detection mechanism that alerts on unauthorised modification to the HTTP headers and the contents of payment pages as received by the consumer browser, running at least once every seven days, or on a frequency set by a targeted risk analysis.
Read that last phrase carefully. It is not asking what your server sends. It is asking what the browser receives, which is the only place a compromised tag manager or a swapped CDN file shows up.
The SAQ A trap
PCI removed 6.4.3 and 11.6.1 from SAQ A in early 2025 - and replaced them with a new eligibility criterion: the merchant must confirm that their site “is not susceptible to attacks from scripts” that could affect their e-commerce systems. A merchant who cannot confirm that loses SAQ A eligibility altogether and drops into SAQ A-EP or a full assessment. The criterion is vague - it is not even settled whether it applies site-wide or only to the payment page - and that vagueness is the risk.
There used to be an escape hatch: a merchant and their QSA could agree between themselves that SAQ A eligibility justified marking those two requirements not applicable in a Report on Compliance. A 2026 revision to the relevant FAQ is reported to have removed it, pushing the decision to acquirers and payment brands. We have seen this reported by a vendor with a commercial interest in the answer, so check the current FAQ text with your acquirer before you rely on either reading.
What requirement 11.4 asks of a penetration test
11.4.1 requires a documented methodology, and the list is specific enough to be used as a checklist when you compare proposals:
- An industry-accepted approach
- Coverage of the entire cardholder data environment perimeter and critical systems
- Testing from both inside and outside the network
- Testing that validates segmentation and scope-reduction controls
- Application-layer testing covering, at a minimum, the vulnerabilities in requirement 6.2.4
- Network-layer testing across all components supporting network functions and operating systems
- Review of threats and vulnerabilities experienced in the last 12 months
- A documented approach to assessing and addressing exploitable findings
- Retention of results and remediation evidence for at least 12 months
11.4.2 and 11.4.3 then require internal and external tests at least once every twelve months and after any significant infrastructure or application change, performed by a qualified resource with organisational independence.
PCI DSS says the tester must be qualified and organisationally independent, and states explicitly that they are not required to be a QSA or ASV. Firms that imply otherwise are selling a badge, not a requirement. Ask instead what the testers hold, what they actually did last year, and to see a redacted report.
Six months, not twelve, if you are a service provider
11.4.5 requires segmentation controls to be penetration tested at least once every twelve months and after any change, confirming they isolate the cardholder data environment from everything out of scope. 11.4.6 then applies to service providers only and makes the same test at least once every six months.
In Pakistan that catches payment system operators and providers, third-party processors and quite a few SaaS firms that sit in a card flow without thinking of themselves as payment companies. If card data or the systems that handle it touch your platform on behalf of someone else, read 11.4.6 before you budget for the year.
What we would do first
- Build the script inventory. It is tedious, it is required, and it almost always turns up a tag nobody can account for.
- Run one authenticated internal scan now, somewhere safe, and look at the delta against your last unauthenticated one.
- Work out whether you are a service provider under the card schemes’ definitions. The answer changes your testing frequency.
- Get your SAQ A eligibility confirmed in writing by your acquirer rather than assuming it.
We have quoted requirement text from reproductions rather than from the standard PDF, which sits behind the PCI SSC’s terms of use. Before you build a programme on any blog - this one included - download PCI DSS v4.0.1 and the Summary of Changes from the PCI SSC document library and read the clauses yourself.
Where these numbers come from
Every figure above is from one of these. If one of them has moved on since we wrote this, believe the source and not us.
- PCI Security Standards Council - Just published: PCI DSS v4.0.1 (11 June 2024)
- PCI Security Standards Council - guidance for e-commerce requirements effective after 31 March 2025
- PCI SSC document library (v4.0.1 and the Summary of Changes)
- TrustedSec - The hidden trap in the PCI DSS SAQ A changes (4 March 2025)
- usd AG - PCI DSS v4.0 authenticated vulnerability scans
- Microsoft Learn - PCI DSS requirement 11 reference text
Getting it right
Do we need a QSA to run our penetration test?
No. PCI DSS requires the tester to be qualified and organisationally independent, and says explicitly that they need not be a QSA or ASV. What your assessor will ask to see is the methodology, the scope, the findings and the evidence that the findings were fixed and retested.
How often do service providers have to test segmentation?
Every six months, and after any change to the segmentation controls - twice as often as the annual requirement that applies to merchants. It is the deadline most often missed, because it does not line up with the annual assessment cycle.
What does "authenticated scanning" mean in practice?
The scanner logs in rather than probing from outside. Systems that cannot accept credentials have to be documented as such, the account used has to have enough privilege to be meaningful, and if that account can also be used interactively it falls under the account-management requirements like any other.
We are on SAQ A. Does any of this apply?
More than it used to. The SAQ A eligibility and requirement text changed, and the safest course is to check the current version against your acquirer rather than relying on what was true at your last assessment. Get the answer in writing from the acquirer, not from a blog - including this one.
Want this done on your own systems?
We scope the work in writing first, so you know exactly what will be touched and when.
Book a free consultation Back to the blog