PCI DSS v4.0.1 Compliance Guide (2026): Requirements, SAQs and Validation

Who it applies to

PCI DSS covers "all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers" (PCI SSC).

• Size doesn't matter. It applies to small merchants "regardless of their size or transaction volume." Whether a small merchant must validate compliance is determined by the individual payment brands (PCI SSC merchants).
• Brand programs. Each founding brand runs its own compliance program: American Express, Discover, JCB, Mastercard and Visa (PCI SSC merchants).
• Encryption doesn't take you out of scope. Encryption alone generally does not remove an environment from scope. Systems that encrypt or decrypt, or that manage keys, remain in scope. A PCI-listed P2PE solution can significantly reduce scope (PCI SSC merchants).

Key requirements

The standard (PCI DSS v4.0.1, Document Library) is built around 12 principal requirements:

1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
3. Protect stored account data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect all systems and networks from malicious software.
6. Develop and maintain secure systems and software.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access to system components.
9. Restrict physical access to cardholder data.
10. Log and monitor all access to system components and cardholder data.
11. Test security of systems and networks regularly.
12. Support information security with organizational policies and programs.

Requirements that most often catch teams out

• 3.3.1: sensitive authentication data is not stored after authorization, "even if encrypted."
• 6.4.3: every payment page script loaded in the consumer's browser must be authorized, integrity-assured and inventoried with a justification.
• 11.6.1: a change- and tamper-detection mechanism alerts on unauthorized changes to payment page HTTP headers and scripts.
• 8.4.2: MFA for all non-console access into the CDE. v4.0.1 added an exception for accounts that use only phishing-resistant authentication (PCI SSC blog).
• 8.3.6: passwords must be at least 12 characters (or 8 if the system can't support 12) and contain both letters and numbers.
• 11.3.2: external vulnerability scans at least once every three months by an Approved Scanning Vendor (ASV).
• 11.4.2 and 11.4.3: internal and external penetration testing at least once every 12 months, and after significant changes.
• 12.5.2: PCI DSS scope is documented and confirmed at least every 12 months, and on significant change.

Defined vs customized approach

Under the defined approach, you meet each requirement as written. Compensating controls are allowed where there's a legitimate constraint.

Under the customized approach, you meet the stated Customized Approach Objective in a different way. This needs a targeted risk analysis and a controls matrix, and it isn't available for every requirement (PCI DSS v4.0.1).

What changed in v4.0.1

v4.0.1 is a limited revision with "no additional or deleted requirements" (PCI SSC blog). Among its changes:

• It reverted the 30-day patching rule so that it applies only to critical vulnerabilities.
• It clarified how the payment page script requirement applies.
• It clarified the responsibilities between customers and third-party service providers.

Certification process and timeline

PCI DSS has no "certificate". Entities validate compliance and receive an AOC:

1. Scope. Map your data flows and the systems in your CDE, as required by 12.5.2.
2. Pick a validation tool. Ask your acquirer or brand which one applies. SAQs are "validation tools for use by SAQ-eligible merchants and service providers," with several types defined by eligibility criteria (PCI SSC merchants). Larger entities generally complete a ROC with a Qualified Security Assessor (QSA). A QSA is an independent firm "qualified and trained by PCI SSC" (PCI SSC).
3. Remediate and test. Close any gaps, then run ASV scans and penetration tests.
4. Submit. Send the SAQ or ROC, and the AOC, to whoever requested them.
5. Repeat. Validation is annual, and some controls run every quarter or continuously.

SAQ A changes (January 2025)

For merchants that have fully outsourced their payments, the January 2025 SAQ A:

• removed requirements 6.4.3, 11.6.1 and 12.3.1
• added an eligibility criterion: merchants must confirm their site "is not susceptible to attacks from scripts"

PCI SSC stressed that this does not diminish the underlying requirements (PCI SSC blog).

Costs

PCI SSC doesn't publish what an assessment costs. QSA, ASV and tooling fees are set by the market.

Penalties

PCI DSS is not a law. PCI SSC "does not define compliance requirements for any organization or set compliance validation responsibilities." Compliance is enforced by "brands, acquirers, payment facilitators, etc." (PCI SSC blog).

Consequences come from your merchant agreement and the brand rules. Check your acquirer contract for fees, fines or termination clauses.

Mapping to related frameworks

• ISO/IEC 27001: its management system and risk process can host PCI controls. Note that ISO certification does not replace an AOC.
• SOC 2: overlaps on access, change and logging. Service providers often maintain both.
• NIST CSF 2.0: useful for governing the wider program, with PCI DSS as a sector-specific profile.

Readiness checklist

1. Document every payment channel and data flow, then confirm scope (12.5.2).
2. Reduce scope with tokenization, P2PE or outsourced payment pages.
3. Confirm your validation type (SAQ or ROC) with your acquirer.
4. Inventory and authorize your payment page scripts (6.4.3), and deploy tamper detection (11.6.1).
5. Enforce MFA into the CDE and the v4.x password rules.
6. Schedule quarterly ASV scans and annual penetration tests.
7. Get AOCs from your third-party service providers and keep a responsibility matrix.
8. Complete the targeted risk analyses where requirements call for them.
9. Train your staff and test your incident response plan.

Common pitfalls

• Assuming encryption removes scope. It usually doesn't.
• Assuming outsourcing removes all obligations. SAQ A still has eligibility criteria, including the one on script attacks.
• Storing SAD "temporarily" in logs or call recordings.
• Treating validation as annual-only. Scans, log review and script monitoring are ongoing.
• Missing the future-dated requirements. Assessors have expected them since 31 March 2025.

How AssureCore helps

• The Controls Register tracks all 12 requirements and their sub-requirements.
• Evidence Management, with expiry alerts, flags scans and pen tests that are due.
• Cross-framework Mapping reuses ISO 27001 and SOC 2 evidence.
• Audit Reports (PDF or CSV) support SAQ or ROC preparation.

Frequently asked questions

Official references

• PCI SSC – PCI DSS standard page
• PCI SSC – Merchant resources and FAQs
• PCI SSC – Document Library (PCI DSS v4.0.1)
• PCI SSC blog – Just Published: PCI DSS v4.0.1 (June 2024)
• PCI SSC blog – Future-dated requirements of PCI DSS v4.x (Aug 2024)
• PCI SSC blog – SAQ A updates (Jan 2025)
• PCI SSC blog – RFC on PCI DSS v4.0.1 (June 2026)

Related frameworks

• SOX IT guide
• ICIF guide
• DORA guide
• MAS TRM guide