PCI DSS 4.0 Requirements: Scanning, Pentest and Scoping Guide

The Payment Card Industry Data Security Standard (PCI DSS) sets the minimum technical and operational requirements for protecting payment card data. The PCI DSS 4.0 requirements apply to every organization that stores, processes or transmits cardholder data, or can affect the security of that environment: merchants, payment gateways, processors, banks and service providers. The current version is PCI DSS 4.0.1.

What makes PCI DSS different from most frameworks is how specific it is: secure configurations, patch deadlines, quarterly vulnerability scans and annual penetration tests are spelled out. This guide covers the 12 requirements, what changed in version 4, the customized approach, the key technical requirements, scoping and segmentation, and what it means for payment providers in markets like Iran.

What is PCI DSS and who must comply?

PCI DSS is published by the PCI Security Standards Council (PCI SSC), founded by the major international card brands. Compliance is usually enforced through contracts with card brands and acquiring banks rather than by law. Two groups are in scope:

• Merchants: businesses that accept card payments.
• Service providers: companies that process, store or transmit card data on behalf of others, or can affect its security, such as processors, hosting providers and payment gateways.

Everything revolves around the cardholder data environment (CDE): systems that store, process or transmit card data, plus systems connected to them. The official standard and supporting documents are available from the PCI Security Standards Council.

The 12 PCI DSS 4.0 requirements

The 12 requirements are grouped under six goals:

Goal	Req.	Summary
Secure network 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	Strong cryptography over open, public networks
Vulnerability management	5	Protect 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 to cardholder data
Monitor and test networks	10	Log and monitor all access to systems and data
	11	Test security of systems and networks regularly
Security policy	12	Support security with organizational policies and programs

What changed in PCI DSS 4.0 and 4.0.1

Version 4.0 was published in March 2022, and version 3.2.1 was retired in March 2024. Version 4.0.1, published in June 2024, is a limited revision with clarifications and corrections and no new requirements. Many new version 4 requirements were future-dated and became mandatory on 31 March 2025. The most significant:

• MFA for all access into the CDE (8.4.2), not only remote access.
• Minimum 12-character passwords (8.3.6).
• Authenticated internal vulnerability scanning (11.3.1.2).
• Payment page script management (6.4.3) and change and tamper detection on payment pages (11.6.1).
• Targeted risk analysis to justify the frequency of certain controls (12.3.1).

The customized approach

Version 4 offers two ways to meet a requirement. Under the defined approach, you implement the requirement as written. Under the customized approach, you design a different control that meets the requirement's stated Customized Approach Objective. This requires a targeted risk analysis and thorough documentation, the assessor must design specific tests for it, and it suits organizations with mature security programs.

Key technical requirements: configuration, patching and PCI DSS vulnerability scanning

Requirement 2: secure configurations

Configuration standards must exist for all system components and be consistent with industry-accepted hardening standards or vendor recommendations. In practice:

• Remove or disable vendor default accounts, or change their passwords
• Enable only necessary services, protocols and functions
• Secure, or document a justification for, any insecure service
• Encrypt all non-console administrative access with strong cryptography
• Update standards as new vulnerabilities are identified

Requirement 6.3.3: critical patches within one month

All system components must be protected from known vulnerabilities by installing patches. Patches for critical vulnerabilities, identified through the risk ranking process in 6.3.1, must be installed within one month of release; other patches within a timeframe the organization defines. See our patch management guide for the process.

Requirements 11.3.1 and 11.3.2: internal and ASV scans

Req.	Topic	Frequency and condition
11.3.1	Internal vulnerability scans	At least every three months; high and critical resolved, rescanned
11.3.1.1	All other vulnerabilities	Managed based on a targeted risk analysis
11.3.1.2	Authenticated internal scans	Sufficient privileges on systems that accept credentials
11.3.1.3	Internal scans after change	After any significant change
11.3.2	External scans by an ASV	At least every three months with a passing result
11.3.2.1	External scans after change	After any significant change

An Approved Scanning Vendor (ASV) is a company qualified by PCI SSC. Under the ASV Program Guide, vulnerabilities with a CVSS score of 4.0 or higher generally cause a scan to fail unless remediated or disputed with sufficient evidence. To pass the official scan cleanly, clean up your attack surface with your own internal and external scanning first.

Requirement 11.4: penetration testing

Internal and external penetration tests must follow a documented methodology and run at least every 12 months and after significant upgrades or changes. Exploitable vulnerabilities must be corrected and retested. If you use segmentation to reduce scope, its effectiveness must be confirmed by segmentation testing, more often for service providers. Our article on vulnerability assessment vs penetration testing explains how the two differ.

Scoping and segmentation

Scope size is the biggest driver of PCI DSS cost. Any system that touches card data, or can reach the CDE without restriction, inherits the relevant requirements. A practical scoping process:

1. Map every card data flow from entry point to storage and deletion.
2. Identify and inventory all systems inside and connected to the CDE.
3. Use network segmentation and access controls to move unnecessary systems out of scope.
4. Avoid storing card data where possible, or use tokenization.
5. Review and document scope at least annually and after significant changes.

PCI DSS for payment providers and banks in Iran

Iran's domestic card payment network operates under Central Bank of Iran regulations and the Shaparak network, and banks and payment service providers (PSPs) must first meet those requirements. Because international card brands are not active in the domestic network, PCI DSS is usually not a direct contractual obligation there. Still, as one of the most complete references for payment security, it defines CDE scoping, segmentation, quarterly scanning, patch deadlines and log management in an actionable way, making it a useful basis for designing controls and preparing for audits. Companies working with foreign merchants or partners may be directly required to comply. Always check regulators' latest official documents, and see our security compliance guide for mapping frameworks together.

How NetGuard helps with PCI DSS

NetGuard is not an ASV, and the official external scans under 11.3.2 must be performed by an approved ASV. It does cover much of the technical work around them: authenticated and agentless internal vulnerability scanning for 11.3.1 and 11.3.1.2; configuration audits against CIS Benchmarks and custom baselines for Requirement 2; external attack surface discovery (domains, subdomains, open ports, TLS certificates) to prepare for ASV scans; web application scanning; prioritization using known-exploited vulnerabilities; and rescans to verify fixes. Findings are mapped to PCI DSS requirements, with reports in English and Persian. See our vulnerability scanner.

Frequently asked questions

What is PCI DSS?

PCI DSS is the Payment Card Industry Data Security Standard, published by the PCI Security Standards Council, which sets minimum requirements for protecting payment card data. It contains 12 requirements grouped into six goals, from network security controls and secure configurations to vulnerability management, access control, monitoring and regular testing. Any organization that stores, processes or transmits cardholder data is in scope.

What is the difference between PCI DSS 4.0 and 4.0.1?

PCI DSS 4.0, released in March 2022, introduced major changes such as the customized approach, MFA for all access into the CDE and authenticated internal scanning. Version 4.0.1, released in June 2024, was a limited revision that clarified wording and corrected errors without adding new requirements. The future-dated version 4 requirements became mandatory on 31 March 2025.

How often are PCI DSS vulnerability scans required?

Internal vulnerability scans are required at least once every three months under 11.3.1, and external scans by an Approved Scanning Vendor at least once every three months under 11.3.2, with a passing result. Both internal and external scans are also required after any significant change. High-risk and critical vulnerabilities must be resolved and rescanned to confirm the fix.

What is an ASV scan?

An ASV scan is an external vulnerability scan of internet-facing systems in PCI scope, performed by an Approved Scanning Vendor qualified by the PCI Security Standards Council. It must be run at least quarterly and achieve a passing result. Under the ASV Program Guide, vulnerabilities scored CVSS 4.0 or higher generally cause a failure until they are remediated or successfully disputed.

Is penetration testing required by PCI DSS 4.0?

Yes. Requirement 11.4 calls for internal and external penetration testing at least once every 12 months and after significant infrastructure or application changes, following a documented methodology. Exploitable vulnerabilities found must be corrected and retested. Organizations that rely on segmentation to reduce scope must also test that segmentation controls are effective, with more frequent testing for service providers.