PCI DSS script inventory: how do you run a year-end review?

Why review payment page scripts at year-end?

The scripts on a payment page change during the year, and your PCI DSS script inventory has to keep up. Requirement 6.4.3 requires every script that loads and runs in the customer's browser on a payment page to be authorized, checked for integrity and listed in an inventory with a written justification for why it is necessary. Marketing tags, chat widgets, analytics and plugin updates added over twelve months can all reach the page without anyone updating that list. For how e-skimming attacks work and the controls behind both requirements, see our guide to PCI 6.4.3 and 11.6.1.

Requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025, so 2026 is the first full calendar year in which both apply. A December review also lines up with Requirement 12.5.2, which requires PCI DSS scope to be documented and confirmed at least once every 12 months and after a significant change to the in-scope environment, according to the PCI SSC's summary of changes for version 4.0. A new donation platform, client payment portal or online invoice link added this year is the kind of change that belongs in that review.

What do Requirements 6.4.3 and 11.6.1 require?

Requirement 6.4.3 controls what is allowed to run on the payment page, and Requirement 11.6.1 detects when the page changes. Under 6.4.3, you need a method to confirm each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts with a written justification for each one.

Under 11.6.1, a change- and tamper-detection mechanism must alert staff to unauthorized changes to the payment page's scripts and its security-impacting HTTP headers, as the customer's browser receives them. The check runs at least once every seven days, or at a frequency the firm sets through a targeted risk analysis performed under Requirement 12.3.1. The PCI SSC published implementation guidance for both requirements in March 2025, titled Payment Page Security and Preventing E-Skimming.

Does this apply if a processor hosts the payment form?

It depends on how the form reaches your customer, and your acquirer decides how you validate. In January 2025 the PCI SSC removed Requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added an eligibility criterion: the merchant must confirm "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

PCI SSC FAQ 1588 explains two ways a merchant that embeds a provider's payment form, for example in an iframe, can make that confirmation. The merchant can protect its own page with techniques such as those in 6.4.3 and 11.6.1, or it can obtain confirmation from its PCI DSS compliant provider that the embedded solution includes script attack protections when implemented according to the provider's instructions. The criterion does not apply to pages that fully redirect the customer to the provider.

The Council has also noted that 6.4.3 and 11.6.1 are still in the standard, so merchants validating with other questionnaires or a full assessment should expect them to be in scope. Either way, a current inventory is the evidence behind whatever your firm attests to. If you are not sure which questionnaire applies, see which PCI SAQ you need.

What belongs in a PCI DSS script inventory?

Each entry should answer the questions an assessor or acquirer would ask about that script. A practical inventory records:

• The script name and where it loads from, including whether it is first-party or served from a third-party domain.
• Every payment page that loads it, such as checkout, donation, invoice payment or client portal pages.
• The business or technical reason the payment page needs it, written so someone outside IT can follow it (for example, "loads the processor's hosted card fields").
• Who authorized it, and when.
• How its integrity is assured, for example a subresource integrity hash or a Content Security Policy rule.
• The person responsible for changes to it.
• The date it was last reviewed.

Keep the inventory with the rest of your PCI evidence, and keep a short log of scripts you removed and why. The removals show the review actually happened.

How do you inventory scripts for PCI DSS 6.4.3?

Load each payment page, record every script that runs, and reconcile that list against your inventory. Plan for a few hours per payment page, with the person who owns the website and the person who signs your SAQ both involved. A workable sequence:

• Capture what actually runs. Load each payment page and record every script that executes, using browser developer tools or the report from your tamper-detection tool. Compare that list against the inventory.
• Remove what you cannot justify. Each script removed from a payment page is one less thing to authorize, monitor and defend. Analytics, heatmap, advertising and chat scripts are common candidates for removal from the payment step itself.
• Re-authorize what remains, with a dated sign-off from the page owner.
• Confirm integrity controls cover every remaining script.
• Test the 11.6.1 alerting. Make a harmless change in a test environment or trigger a test alert, and confirm it reaches a monitored mailbox or ticket queue.
• If you check less often than every seven days, re-read the targeted risk analysis that supports that frequency and confirm it still reflects how the page is built.
• If you rely on a provider's confirmation under FAQ 1588, get a current one in writing and file it.
• Confirm scope under Requirement 12.5.2 and update your data flow diagram if a new payment channel was added this year.

What should you do before the end of December?

Use the last weeks of the year to lock in ownership and change control:

• Name one owner for each payment page.
• Ask your web developer or agency to notify the owner before adding or changing any script on a payment page.
• Limit non-essential changes to payment pages during year-end giving and billing periods. Nonprofits can pair this with our donation page checklist for card testing fraud.
• Put the next review on the calendar, tied to the date you complete your annual SAQ.

Who enforces these requirements?

The payment brands and your acquirer set and enforce compliance requirements. The PCI SSC says it "does not define compliance requirements for any organization or set compliance validation responsibilities," and points to compliance enforcing entities such as payment brands, acquirers and payment facilitators in its January 2025 SAQ A announcement. For a small merchant, that usually means the acquiring bank or payment processor that asks for your annual self-assessment questionnaire.

How does s90 help?

s90 offers PCI DSS support as a solo add-on for nonprofits, law firms and professional practices that take card payments. We inventory payment page scripts, set up change and tamper alerts, collect provider confirmations and organize the evidence behind your SAQ, so your year-end review has documentation to show for it. If you would like help with your first full-year review, talk with our team.