Reconciliation
How the script inventory is rebuilt from hash reports, when it runs automatically, and when a manual refresh is worth it.
Last update:
Reconciliation is the pass that turns hash reports into inventory rows. It matches reported page URLs against your payment-page patterns, works out which scripts are in scope, applies inventory rules, and writes any changes to the ledger.
You rarely need to trigger it.
Automatic schedule
A pass is enqueued in three situations:
- Hourly, for every website on a plan with compliance.
- Immediately, when you create, update, or delete a payment page.
- Immediately, when you create or update an inventory rule.
Rule deletion is the one gap: it does not enqueue a pass. Nothing about existing scripts changes on deletion anyway, so this only matters if you are waiting to see the effect.
Force a refresh
Go to PCI DSS > Script inventory and select Refresh inventory. Managers and above can do this.
Rate-limited to one request per 30 seconds per website. The work is queued rather than immediate, so expect a few minutes before the inventory settles.
Worth doing when you want newly observed scripts picked up before the next hourly pass, typically right after a deploy you want to verify. Not worth repeating.
Pass outcomes
For every script observed on a page matching an enabled payment-page pattern:
| Situation | Result |
|---|---|
| Not seen before, no rule matches | Status Unreviewed, ledger entry Script detected |
| Not seen before, an approve rule matches | Status Justified with the rule's text and tags, ledger Script detected plus Rule applied |
| Not seen before, an exclude rule matches | Status Out of scope with the rule's reason, ledger Script detected plus Excluded from scope by rule |
| Hash changed, no rule covers it | Status Needs review, ledger Script hash changed |
| Hash changed, a rule covers it and no person decided it | The rule decides it again, ledger Script hash changed plus the rule event |
| Hash changed on a script a person approved | Status Needs review, whether or not a rule covers it |
| No longer matching any enabled pattern | Retired, ledger Script left the payment-page scope |
| Matching again after being retired | Restored, ledger Script returned to the payment-page scope |
Retiring is not deleting. Status, justification, and history are all preserved, retired scripts stay in the evidence pack, and re-entering scope brings them back with their record intact.
Scripts injected by browser extensions are excluded throughout, so a visitor's password manager does not end up in your compliance scope.
Next steps
Payment pages
URL patterns that put pages in PCI DSS scope. Wildcard syntax, what Coverage counts, and why overlapping patterns inflate the numbers.
Justify scripts
Record why each script on a payment page is authorized, or reject it. Both decisions require written reasons and both land in an append-only ledger.