The March 31, 2025 deadline passed quietly for most organizations. All 51 requirements that were once labeled "best practice" are now scored. Your 2026 assessment will test every one of them, and most of the new weight sits at the application layer, where traditional compliance programs have the least visibility.
This checklist covers the application and API requirements your QSA will score in Requirements 6 and 11. It's designed for GRC professionals who need to shift from annual validation cycles to continuous evidence collection before your next Report on Compliance is due.
Prerequisites
Before you start this checklist, confirm you have:
- Write access to your application inventory system, You'll need to document findings and gaps as you discover them.
- Collaboration from application security and development teams, Many of these requirements cross organizational boundaries.
- Access to current scan results and tooling, Both internal vulnerability scanning and ASV reports.
- A sample payment page to test against, If you process card payments through a web interface.
Application Security Requirements Checklist
Requirement 6.3.1: Vulnerability Identification and Risk Ranking
☐ You maintain subscriptions to industry vulnerability sources (NVD, third-party risk management bulletins, CISA advisories)
Good looks like: A documented feed that updates daily, with evidence of regular review.
☐ Every identified vulnerability receives a risk ranking based on context, not severity score alone
Good looks like: A documented methodology that weighs asset criticality, threat intelligence, and exploitability alongside CVSS scores.
☐ Your risk ranking methodology is documented and approved
Good looks like: A written policy that your QSA can validate against actual prioritization decisions in your tracking system.
Requirement 6.3.2: Inventory of Bespoke and Custom Software
☐ You maintain a complete, current inventory of all custom web applications
Good looks like: An inventory that updates automatically or weekly, not a spreadsheet someone refreshes before audits.
☐ Your inventory includes all APIs, internal, partner-facing, and public
Good looks like: Documented endpoints, versions, authentication methods, and data classification for each API.
☐ Third-party components and libraries within custom applications are inventoried
Good looks like: Software composition analysis results tied to each application record.
☐ The inventory distinguishes between applications in scope for PCI DSS and those outside it
Good looks like: Clear tagging or segmentation that your QSA can validate against network diagrams.
Requirement 6.4.2: Protection of Public-Facing Web Applications
☐ You deploy an automated technical solution that continuously detects and prevents web-based attacks
Good looks like: A web application firewall or runtime application self-protection tool with evidence of active blocking.
☐ Manual code review as your only protection method has been replaced
Good looks like: Annual code reviews may still happen, but they don't satisfy 6.4.2 anymore.
☐ Your solution generates logs that demonstrate continuous operation
Good looks like: Attack detection logs, block events, and rule updates visible to your assessor.
Requirement 6.4.3: Payment Page Script Inventory
☐ Every script loaded or executed on payment pages is inventoried
Good looks like: A documented list covering analytics tags, chat widgets, tag managers, fraud detection scripts, and payment processor code.
☐ Each script has written justification for why it's authorized
Good looks like: Business purpose documented for each script, approved by someone with authority.
☐ You have a mechanism that verifies script integrity
Good looks like: Subresource Integrity hashes implemented and monitored, or a commercial script monitoring tool.
Requirement 11.3.1: Internal Vulnerability Scans
☐ Internal scans use authenticated credentials
Good looks like: Scan reports showing successful authentication and deeper enumeration than unauthenticated scans provide (sub-requirement 11.3.1.2).
☐ Every vulnerability, including those below high severity, has a documented, risk-based remediation decision
Good looks like: A tracking system where medium and low findings show either remediation dates or written acceptance rationale (sub-requirement 11.3.1.1).
☐ Scans cover applications and APIs, not just infrastructure
Good looks like: Authenticated application scanning results in your evidence package.
Requirement 11.6.1: Tamper Detection for Payment Pages
☐ You deploy a mechanism that detects unauthorized modification to payment page content
Good looks like: Alerts when scripts change, HTTP headers are modified, or new resources load.
☐ The mechanism monitors HTTP headers in addition to page content
Good looks like: Detection coverage for Content Security Policy changes, missing security headers, or unexpected redirects.
☐ Alert recipients are documented and alerts are tested
Good looks like: Evidence that someone receives and acts on alerts, not just that the tool is configured.
Common Mistakes
Treating APIs as out of scope. APIs are bespoke software. If they touch cardholder data or sit in your cardholder data environment, Requirements 6.2.3 (pre-release review), 6.2.4 (protection against business logic abuse), and 6.3.2 (inventory) all apply. Undocumented partner endpoints and forgotten API versions fail assessments.
Relying on unauthenticated scanning. Requirement 11.3.1.2 made authenticated scanning mandatory. Unauthenticated scans miss most application-layer vulnerabilities. Your QSA will ask for evidence that credentials were used and that authentication succeeded.
Closing only criticals and highs. Requirement 11.3.1.1 ended that practice. Medium and low findings need documented decisions. "We'll get to it eventually" isn't a decision your assessor can score as compliant.
Confusing SAQ A eligibility with actual requirements. The Council removed script requirements from SAQ A and replaced them with an eligibility statement about susceptibility to script attacks. If you use an embedded iframe, you still ship the page that loads the scripts. The requirements didn't disappear, they moved to a different form.
Waiting until assessment season to build your inventory. Continuous evidence means your inventory needs to reflect reality today, not a snapshot from three months ago. If your application team ships weekly and your inventory updates quarterly, you have a gap.
Next Steps
Start with your application and API inventory. If you can't produce it on demand tomorrow, that's your first priority. Most compliance failures in 2026 assessments will trace back to incomplete inventories.
Then verify your scanning is authenticated and that you're actually testing applications, not just the servers underneath them. Unauthenticated scans and infrastructure-only coverage won't satisfy Requirements 11.3.1.2 or 6.4.2.
Finally, if you process payments through a web interface, audit one payment page against Requirements 6.4.3 and 11.6.1. Open your checkout flow, view source, and list every script that executes. If you can't justify each one or detect when they change, your QSA will document that gap in your next Report on Compliance.
The transition period is over. The requirements are scored. The evidence your assessor expects is continuous, application-focused, and more detailed than most programs were built to produce. Start building that evidence now, before your assessment window opens.
