PCI DSS: the scan is only the beginning

Who does PCI DSS apply to, and who assesses?

The Payment Card Industry Data Security Standard applies to every entity that stores, processes or transmits payment card account data, and to everyone who can affect the security of that environment. That covers merchants and payment service providers as well as data centres and software vendors, insofar as they process account data or have access to their customers’ environment. PCI DSS is not a law but becomes binding through contracts with the acquiring bank and the card brands. Violations can lead to contractual penalties, higher fees or the loss of card acceptance.

How compliance is demonstrated depends on transaction volume and role. The largest merchants and service providers are assessed annually, usually by a Qualified Security Assessor (QSA), and with some card brands also by internal auditors. The result is a Report on Compliance (ROC). Smaller merchants usually complete a Self-Assessment Questionnaire (SAQ). The thresholds are set by the card brands, and what the acquirer requires is decisive. In both cases, the result is confirmed with an Attestation of Compliance (AOC).

PCI DSS 4.0.1: the current version

Version 4.0 was published in March 2022 and replaced version 3.2.1 on 31 March 2024. A limited revision with clarifications followed as 4.0.1 in June 2024, and since the turn of 2024/25 it has been the only valid version. The requirements marked as future-dated in 4.0 have been mandatory since 31 March 2025.

New in version 4, alongside the defined approach, is a customised approach: an organisation may meet an objective with its own controls if it justifies this with a targeted risk analysis under 12.3.2 and an assessor (QSA or ISA) confirms it in the ROC. The customised approach is not available with an SAQ. Targeted risk analyses under requirement 12.3.1 are also needed wherever the standard leaves the frequency of an activity to the organisation.

The 12 requirements across six goals

The standard is organised into six goals containing twelve principal requirements with several hundred sub-requirements:

• Secure networks and systems: 1 install and maintain network security controls, 2 apply secure configurations to all system components.
• Protect account data: 3 protect stored account data, 4 protect cardholder data with strong cryptography during transmission over open, public networks.
• Vulnerability management: 5 protect all systems and networks from malicious software, 6 develop and maintain secure systems and software.
• Strong access control: 7 restrict access by business need to know, 8 identify users and authenticate access, 9 restrict physical access.
• Monitor and test: 10 log and monitor all access, 11 test the security of systems and networks regularly.
• Information security policy: 12 support information security with organisational policies and programmes.

The cardholder data environment (CDE) and scope

The cardholder data environment comprises all system components that store, process or transmit cardholder data or sensitive authentication data. The scope also includes systems connected to the CDE or able to affect its security, such as directory services, log servers or jump hosts. Sensitive authentication data such as the card verification code must not be stored after authorisation.

The scope must be documented and confirmed at least annually and after significant changes, every six months for service providers. This includes network and data flow diagrams and an inventory of system components. Keeping it small saves effort: through network segmentation, tokenisation, point-to-point encryption or a payment page hosted entirely by the payment provider. Segmentation only counts if it is tested, annually and every six months for service providers.

The PCI DSS module keeps the CDE with its components. Segmentation stands and falls with the firewall rules, which firewall management documents across multiple vendors.

The ASV scan under requirement 11.3.2

Requirement 11.3.2 mandates an external vulnerability scan at least quarterly by an Approved Scanning Vendor (ASV), a provider approved by the PCI Security Standards Council. Whether a scan passes is governed by the ASV Program Guide: a scan fails if a component has a vulnerability with a CVSS base score of 4.0 or higher or shows one of the automatic failures. Vulnerabilities that only enable denial of service are exempt. A failed scan requires remediation and rescans until the result holds.

No more than about 90 days may pass between two quarterly scans, including remediation and rescans. Over the year, four passing quarterly scans must be evidenced, and a gap in summer breaks the chain. After significant changes, 11.3.2.1 requires additional scans, which need not be performed by an ASV. Suspected false positives are resolved with the ASV and documented. Alongside are the internal scans under 11.3.1, also quarterly and since March 2025 authenticated, and penetration tests under 11.4 at least annually, internal and external. Why a passing scan proves little if the scope is wrong is covered in The passing scan that proves nothing.

ASV readiness check: what to verify before the quarterly scan

Most surprises in an ASV scan could have been found beforehand. A short check before every quarter:

1. Is the scan scope complete, with all external IP addresses and domains, including cloud, behind CDNs and load balancers?
2. Is every excluded component justified?
3. Are only the required ports open, with no management interfaces reachable from the internet?
4. Are outdated protocols such as SSL and early TLS disabled and all certificates valid?
5. Is the software on reachable services up to date, without default pages and default credentials?
6. Do WAF and intrusion prevention let the ASV through so the scan neither aborts nor stays blind?
7. Is it clear who resolves findings and triggers rescans before the 90 days run out?

The readiness comparison in the PCI DSS module places your own view from attack surface management next to the scan scope. What is reachable there but missing from the scope surfaces before the scan, not in the assessment interview.

What has applied additionally since March 2025

With the end of the transition period, the future-dated requirements of version 4 became mandatory. The most important of them:

• Multi-factor authentication (8.4.2): for all non-console access into the CDE, not only for administrators and remote access. Exceptions include accounts that authenticate only with phishing-resistant factors, see identity governance.
• Longer passwords (8.3.6): at least twelve characters where the system supports it.
• Scripts on payment pages (6.4.3 and 11.6.1): an inventory and authorisation of all scripts running in the browser, and detection of tampering with the payment page. For merchants using SAQ A, the PCI SSC replaced these two requirements with an eligibility criterion in early 2025.
• Phishing protection (5.4.1): technical mechanisms against phishing, such as an effective DMARC policy for your own domains, see Who sends mail in your name.
• Automated log review (10.4.1.1): logs are reviewed with automated mechanisms rather than by hand.
• Authenticated internal scans (11.3.1.2): internal vulnerability scans with authentication on the systems.

PCI DSS alongside ISO 27001, NIS2 and DORA

PCI DSS is narrower and more prescriptive than an ISMS: it says not only that access must be protected but how long a password is and how often scans run. In substance it overlaps heavily with ISO 27001, especially on access control, logging, vulnerabilities and suppliers. Anyone running an ISMS under ISO 27001 can keep much of the evidence once and relate it to both frameworks. Payment institutions are additionally subject to DORA, other companies possibly to NIS2. A PCI DSS attestation replaces none of them.

Checklist: PCI DSS in eight steps

The order starts with the scope, because every later measure depends on how large the CDE is.

1. Clarify with the acquirer which evidence is required: SAQ and which type, or ROC.
2. Map data flows: where card data arrive, where they go, where they are stored.
3. Reduce the scope through tokenisation, outsourced payment pages or segmentation.
4. Document the CDE, components and exclusions, and maintain network and data flow diagrams.
5. Assess gaps against the 12 requirements, including those in force since March 2025.
6. Schedule quarterly scans, internal and by the ASV, with a readiness check before and rescans until passing.
7. Run penetration tests and segmentation tests at the required frequency.
8. Confirm the scope annually and submit the SAQ or ROC with the Attestation of Compliance.