PCI DSS 4.0 script requirements
Two requirements do most of the work here, and a fair amount of what is written about them oversells the drama.
The plain version — and a longer one in this post — is that the standard now expects you to know which scripts run on a payment page, to have authorized each of them for a stated reason, and to be told when the set changes or when one of them is modified.
What an assessor tends to ask for
| Asked for | What satisfies it |
|---|---|
| An inventory of scripts on the payment page | A current list, not a list from the last review |
| Written justification for each | A reason per script, attributable to a person |
| Assurance that each is authorized | An approval record, and evidence of what happens when an unapproved one appears |
| A method to detect change or tampering | Evidence the method runs, and evidence of what it produced |
What a tool can and cannot do for you
Can: produce the inventory, keep it current without anyone remembering to refresh it, record the baseline and every deviation from it, and generate the change evidence with timestamps.
Cannot: write your justifications. Someone at your company has to say why the chat widget is on the checkout page, and that is a judgment, not an output. Any vendor implying otherwise is selling you a document that will not survive an interview with the person whose name is on it.
What applies here
Checkout Monitor. This is the product for it. Account Defense is not in scope for these two requirements and we would rather not pretend it is.
A caution about deadlines
Requirement dates get quoted with more certainty than they deserve, and they have moved before. Confirm the current dates with your QSA or acquirer rather than with a vendor's marketing page, including this one.
Related
What PCI DSS 4.0 actually asks about scripts · Your CSP is more permissive than you think