# How to prove to an auditor that your payment-page scripts haven't changed

> What QSAs actually request under PCI DSS 6.4.3 and 11.6.1: a current script inventory with justifications, integrity hashes per script, and a change log covering the assessment period. Why screenshots fail, and how to build the evidence pack before the auditor asks.

- Canonical: https://info.centralcsp.com/articles/prove-payment-scripts-unchanged/
- Published: 2026-08-09
- Language: en
- Publisher: CentralCSP (https://centralcsp.com)

The uncomfortable moment in a PCI DSS v4 assessment is rarely the policy discussion. It is the follow-up question. You explain your payment-page controls, the QSA nods, and then asks: "Show me what changed on your checkout between January and March, and who approved it." If your answer starts with "well, normally...", the interview just became a finding.

Here is the short version of what works. To prove your payment-page scripts haven't changed (or that every change was caught and authorized), assessors expect four artifacts: a script inventory per payment page with a written business justification for each script, proof that the inventory reflects current production, integrity evidence per script, and a change log covering the assessment period with at least one alert that shows detection actually fired. Screenshots and verbal walkthroughs fail because they prove a moment. The assessment covers a period.

## What QSAs actually ask for under 6.4.3 and 11.6.1

We have sat on the merchant side of enough of these interviews to know the requests are predictable. For [6.4.3](/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/), the assessor wants the inventory itself, and then immediately tests whether it is alive: pick a script, when did it appear, who justified it, is it still loading today. For 11.6.1, the questions are about the mechanism and its output: what watches the page as the consumer browser receives it, how often it evaluates, and, the one that kills most first-time assessments, "show me a detection." A tamper-detection control with an empty log is indistinguishable from a control that does not work. New marketing pixels and CDN version bumps happen on every real checkout. If your log shows none, the assessor concludes the log is blind, not that your page is frozen.

One more request that surprises teams: the justification text. Assessors read it. "Required for analytics" written by the security team for forty scripts reads as what it is, a bulk fill. A justification written by the team that owns the script ("A/B testing on the shipping step, owned by growth, contract renewed 2026-01") reads as governance.

## Why screenshots and verbal explanations fail

A screenshot of your dashboard proves the state of the page on the day you took it. The assessment period is typically the full year since the last one. Between those two facts sits every Magecart incident ever written up: the skimmer that lived on a checkout for three weeks and was gone before anyone looked. That is [precisely the attack](/articles/catch-magecart-attack-csp/) 11.6.1 exists to catch, and a point-in-time artifact says nothing about it.

Verbal explanations fail for a related reason. Describing how CSP reporting or SRI works tells the assessor the mechanism could detect tampering. Evidence shows that it did detect changes, repeatedly, with timestamps, throughout the period. The gap between "could" and "did" is where findings live.

## What auditor-ready evidence looks like

This is what the PCI DSS module in [CentralCSP](https://centralcsp.com/en/platform/pci-dss/) produces, on Scale (€349.99/mo) and Enterprise. The evidence maps one-to-one onto the requests above.

For the inventory: you declare which pages are payment pages, and the module builds a per-page script list from what real consumer browsers loaded, each entry carrying its origin, URL and SHA-256/384/512 integrity hash. No agent on the page, no crawler guessing: the browsers your customers actually use are the data source, which is exactly the "as received by the consumer browser" wording of 11.6.1. Each script carries its authorization status and the business or technical justification recorded against it, so the "who approved this and why" question is a click, not an email hunt. Auto-validation rules keep routine hash rotations from re-queuing, which means the pending queue only ever holds things a person needs to look at.

For the period: a dated change timeline listing every script added, changed or removed and every new origin, exportable as CSV and PDF, with an SBOM of the site's technologies alongside. That export is your change log for the assessment, and the alert delivery history next to it (the "unjustified script on a payment page" rule, on Slack, Teams, email or a signed webhook, with a per-channel delivery log) is your proof that detection fires. Rules evaluate on ingest, which sits comfortably past the seven-day minimum in 11.6.1. Raw browser reports live 90 days, but the justifications and the change ledger are kept until the account is deleted, so "show me March" in November is an export, not an archaeology exercise.

Honesty requires one caveat, and it is the same one we put in every PCI article: QSA acceptance of CSP-based approaches for 11.6.1 varies, we have seen both. Which is exactly why the evidence package matters more than the mechanism. An assessor skeptical of the header stops being skeptical when handed a dated inventory, per-script justifications, hashes and a quarter of change history. Nobody argues with a good log.

## Prepare the pack before the auditor asks

The difference between a smooth interview and a painful one is usually a half-day of preparation:

1. Export the evidence before the assessment starts: inventory per payment page, change timeline, alert history. Walking in with the pack beats generating it live in the meeting.
2. Map each export to the requirement line it answers (inventory and justifications to 6.4.3, timeline and alerts to 11.6.1) in a one-page cover note. Assessors remember merchants who do their filing for them.
3. Have justifications written by the script's owner, not the security team. Chase the owners weeks ahead. It is the slowest step.
4. Pull one real detection from the period and be ready to narrate it: what changed, who was alerted, what the disposition was.

If your organisation also cares where this evidence lives, the reports are stored and processed on OVH in France, never leaving the EU, a point that matters to some assessors and most European DPOs (we wrote up the [data-residency angle](/articles/csp-monitoring-for-banks-eu-data-residency/) separately).

The teams that pass these interviews easily are not the ones with the cleverest mechanism. They are the ones who can answer "show me March" in under a minute.

## Frequently asked questions

### What evidence do QSAs ask for under requirement 6.4.3?

Typically four things: the inventory of every script on each payment page, a written business justification per script, proof of an authorization step (who approved the script and when), and evidence that the inventory reflects current production rather than a point-in-time document. An inventory export dated the week of the assessment, generated from live browser data, answers all four at once.

### How do I prove script integrity to a QSA?

Show a per-script integrity value and a mechanism that notices when it changes. SHA-256, SHA-384 or SHA-512 hashes collected from real consumer browsers, plus a change log showing each hash change with a timestamp and a disposition, is direct evidence. A verbal description of Subresource Integrity with no record of drift is much weaker.

### Is a quarterly spreadsheet an acceptable script inventory for PCI DSS?

It rarely survives questioning. The assessor picks a script, asks when it last changed, and the spreadsheet has no answer because it captures a moment, not a period. 6.4.3 asks you to manage scripts continuously, so the inventory needs a data source that updates when production does, which a manually edited document does not.

### How long a change log does a PCI assessment need for payment pages?

The assessor samples across the period since your last assessment, so aim to cover all of it. CentralCSP keeps raw browser reports for 90 rolling days on every plan, but the PCI module's change ledger, script justifications and audit log are kept until the account is deleted, so the timeline for the whole period exports as CSV or PDF the week of the interview. Exporting quarterly and archiving the file on your side remains a sensible habit.