PCI DSS 4.0.1: Application Requirements You’re Being Assessed On in 2026

Summary

PCI DSS 4.0.1 has fully integrated 51 former 'best practice' requirements into its scoring for all assessments starting March 31, 2025. A significant portion of these new requirements focus on application security, particularly in Requirements 6 and 11, emphasizing the need for comprehensive inventories of custom applications and APIs, continuous protection of public-facing applications, and robust payment page script management. Organizations must now actively manage and secure these elements, as they will be critical components of their 2026 PCI DSS assessments.

Full text

Table of ContentsMany Teams Still Get the Requirements WrongMost of the Application Scope Sits in Two of the Twelve RequirementsThe API Blind SpotHow This Gap Gets CostlyQualys TotalAppSec Operationalizes AppSec Beyond PCI ScopeBefore Your Next AssessmentFrequently Asked Questions (FAQs) Key Takeaways Since March 31, 2025, all 51 former “best practice” requirements in PCI DSS 4.0 have been fully scored. Every 2026 assessment covers them. A large share of the new weight sits in the PCI DSS 4.0.1 application requirements, concentrated in Requirements 6 and 11: inventory of custom applications and APIs, continuous protection of public-facing apps, payment page script management, authenticated scanning, and risk-based prioritization. 6.4.3 and 11.6.1 now require a complete inventory of every script on payment pages plus a mechanism that detects unauthorized changes. APIs fall inside the definition of bespoke and custom software, so inventory, pre-release review, and protection against business-logic abuse all apply. And yet, most organizations still underestimate this surface. Qualys TotalAppSec continuously discovers applications and APIs, supports authenticated scanning, inventories payment page scripts, and feeds findings into the Qualys ASV platform for attestation reporting. If you run security on infrastructure that takes card payments, you know the rhythm of assessment season. The gap analysis is done, the policy pack is refreshed, and multi-factor authentication (MFA) finally reaches the handful of people who kept finding reasons to postpone it. Someone signs the remediation plan, and for a few weeks, the dashboard sits at a comfortable green. If that’s where you are, here’s a test that takes about a minute. Open your checkout page and answer the two questions your Qualified Security Assessor (QSA) is now entitled to ask. Which scripts are executed on that page? And how would you know if one of them changed? Most teams can’t. Under the PCI DSS 4.0.1 application requirements, that’s a scored gap. The checkout page is only the start. Many Teams Still Get the Requirements Wrong Version 4.0 was released in 2022, with 51 requirements marked as best practices. Since March 31, 2025, they are now scored requirements like any other. The PCI Security Standards Council flagged this years in advance. Lauren Holloway, the Director of Data Security Standards, wrote in 2022 that after March 31, 2025, the requirements “are effective and must be fully considered as part of a PCI DSS assessment.” Most of them land squarely on application security teams: Inventory every custom application and API you own Authenticate your internal vulnerability scans Test public-facing applications continuously, not once a year Rank vulnerabilities on real-world context, not severity alone Every 2026 assessment covers all 51. Most teams don’t realize how far that reaches into their applications. Most of the Application Scope Sits in Two of the Twelve Requirements A large share of what a 2026 assessment scores sits at the application and application programming interface (API) layer, which, for many organizations, is exactly the part of the estate their compliance program was never designed to reach. It concentrates on two of the standard’s twelve requirements. These PCI DSS application requirements extend well beyond traditional vulnerability scanning, covering application inventory, APIs, payment-page scripts, authenticated scanning, and continuous protection. Requirement 6: Develop and Maintain Secure Systems and Software 6.3.1, identifying and managing vulnerabilities. Vulnerabilities have to be identified from industry sources and assigned a risk ranking that reflects context and real-world impact, not a severity score copied out of a scanner. 6.3.2, inventory of bespoke and custom software. New. A complete, current inventory covering your web applications, your APIs, and the third-party components inside them. 6.4.2, protect public-facing web applications. New, and it replaced 6.4.1. The old requirement allowed you to manually review public-facing applications once every 12 months. That option is gone. An automated technical solution that continually detects and prevents web-based attacks is now the expectation. 6.4.3, manage payment page script inventory. New. Knowing how to inventory payment page scripts starts with identifying every script loaded or executed in the customer’s browser on a payment page. It must be inventoried, authorized with written justification, and checked for integrity. Analytics tags, chat widgets, and tag manager containers all count. Requirement 11: Test Security of Systems and Networks Regularly 11.3.1, internal vulnerability scans. Two new sub-requirements sit underneath this one. 11.3.1.1 ends the practice of closing only criticals and highs: everything below that threshold now needs a documented, risk-based decision behind it. 11.3.1.2 makes authenticated scanning mandatory. This is important because unauthenticated scanning sees the front door while missing most of the building. 11.3.2, external vulnerability scans. Performed by an Approved Scanning Vendor (ASV). The requirement most organizations already have covered, and for many of them, the only application-adjacent testing happening anywhere. 11.6, tamper detection for payment pages. New at 11.6.1. A mechanism that detects and alerts on unauthorized modification to payment page content and HTTP headers. It’s the companion to 6.4.3: one governs what should be there, the other catches what changes. Read them together and the pattern is obvious. The standard moved from annual validation toward continuous evidence for PCI DSS assessment, and from network scope toward application scope. The API Blind Spot PCI DSS rarely uses the word “API” in a heading, which is precisely why APIs get missed. They fall squarely inside the definition of bespoke and custom software, so 6.2.3 pre-release review, 6.2.4 protection against business logic abuse and injection, and 6.3.2 inventory all apply to them. Most organizations underestimate this surface. Undocumented endpoints, forgotten versions, and partner integrations that quietly touch cardholder data rarely appear on anyone’s inventory until an assessor asks for one. How This Gap Gets Costly The threat these requirements target isn’t hypothetical. Recorded Future’s 2024 payment fraud research found e-skimmer infections on close to 11,000 unique e-commerce domains, roughly triple the prior year, alongside 269 million card records posted to dark and clear web sources. Magecart campaigns were still actively targeting major payment networks well into 2026. E-skimming is quiet by design. The malicious script runs in the shopper’s browser, captures the card number and security code as they’re typed, and sends them to an attacker-controlled server. Your backend logs stay clean. Your fraud tooling sees nothing unusual. The average dwell time is measured in months. Then there’s the attestation risk, which is more immediate for most teams. A QSA who asks for your payment page script inventory and your change-detection alerts expects to see both. Missing evidence means a failed Report on Compliance, a delayed Attestation of Compliance, uncomfortable conversations with your acquiring bank, and in some cases contractual exposure with partners who require your attestation to stay current. The Council removed 6.4.3 and 11.6.1 from Self-Assessment Questionnaire (SAQ) A, and replaced them with an eligibility criterion that you confirm your site isn’t susceptible to script attacks. Those requirements are still in the standard. If your checkout uses an embedded iframe, you still ship the page that loads the scripts, so the risk never left. Only the paperwork changed. Qualys One PagerLearn how Qualys TotalAppSec closes critical application level PCI-DSS 4.0.1 scoring gaps.Learn More Qualys TotalAppSec Operationalizes AppSec Beyond PCI Scope Most of the vendor conversation ar

Entities