PCI DSS 4 expands authentication, payment-page protection, vulnerability scanning, and risk-management requirements. For merchants, the first step is to identify which changes apply to their payment environment and Self-Assessment Questionnaire (SAQ).
This guide follows the practical format of our PCI version 3.0 article, with guidance for PCI DSS v4.0.1.
Which version should I use? PCI DSS v4.0.1 is the current version as of November 12, 2026. It clarified version 4.0 without adding or removing requirements. The requirements originally deferred until March 31, 2025 are now in effect; they are no longer optional best practices. See the PCI SSC announcement.
Your payment setup determines which SAQ you may use. Start with the current documents in the PCI SSC Document Library and our guide to choosing an SAQ. Confirm the required validation with your acquiring bank or payment processor.
For online merchants using SAQ A, the revised questionnaire no longer lists Requirements 6.4.3 and 11.6.1 as individual questions. Instead, merchants embedding a provider’s payment form, such as an iframe, must meet an eligibility condition addressing script attacks. PCI SSC describes ways to meet this through protective techniques or confirmation from the compliant payment provider. That specific script-related condition does not apply to redirects or fully outsourced payment links. See PCI SSC FAQ 1588.
Requirement 8.4.2 expands multi-factor authentication (MFA) to non-console access into the cardholder data environment, including ordinary users. Review its applicability notes: exceptions include certain automated accounts, limited POS accounts, and accounts using only phishing-resistant authentication. Other MFA requirements still apply.
Where Requirement 8.3.6 applies, passwords must contain letters and numbers and be at least 12 characters long. Eight is allowed only when the system cannot support 12. Review the affected accounts and system settings rather than assuming an existing password policy meets the requirement.
Where applicable, Requirement 6.4.3 calls for authorization, integrity checks, and an inventory with justification for payment-page scripts. Requirement 11.6.1 adds detection of unauthorized changes to security-impacting headers and payment-page scripts as received by the customer’s browser. These controls address attacks that can steal payment details through the checkout page. The PCI SSC browser-script overview explains the two controls.
Requirement 6.4.2 also requires an automated solution that detects and prevents attacks against in-scope public-facing web applications. A periodic application assessment alone no longer satisfies this requirement. See PCI SSC’s explanation of the replacement requirement. Check your applicable SAQ before deciding which controls your business must validate.
External ASV scanning remains required at least once every three months where Requirement 11.3.2 applies, with passing results. SAQ A e-commerce websites that redirect customers to a provider or embed a provider’s payment form are included in the scanning requirement. See PCI SSC FAQ 1604.
For recurring internal scans, Requirement 11.3.1.2 adds authenticated scanning with sufficient privileges. Systems unable to accept scan credentials must be documented. This does not turn an external ASV scan into an internal scan.
Penetration testing now appears under Requirement 11.4. It remains a separate activity; purchasing an ASV scan does not fulfill penetration-testing requirements. Learn more about PCI scanning and our penetration-testing services.
Requirement 12.5.2 makes documenting and confirming PCI DSS scope an explicit requirement at least every 12 months and after significant changes. Keep your payment flows, systems, and service-provider responsibilities clear.
Where the standard allows a risk-based frequency and requires a targeted risk analysis, document why your chosen schedule is appropriate. This flexibility does not override fixed deadlines such as the three-month ASV scanning interval. PCI SSC’s targeted risk analysis guidance explains the approach.
Use these references to locate the relevant controls. Applicability depends on your environment and assessment.
| Requirement | What to review |
|---|---|
| 6.4.2 | Automated protection for public-facing web applications. |
| 6.4.3 and 11.6.1 | Payment-page script management and tamper detection. |
| 8.3.6 and 8.4.2 | Password length and expanded MFA coverage. |
| 11.3.1.2 and 11.3.2 | Authenticated internal scanning and recurring external ASV scans. |
| 11.4 | Penetration-testing requirements, previously in section 11.3. |
| 12.3.1 and 12.5.2 | Targeted risk analyses and documented scope confirmation. |
Confirm your SAQ, compare your existing controls with its current requirements, assign responsibility for gaps, and keep evidence of the work completed. If scanning is required, schedule it early enough to correct findings and obtain a passing rescan within the required period.
A passing scan is one part of compliance. Read what a passing PCI scan does and does not establish, or get started with PCI scanning.
