A supplier breach checkout checklist should start with one question, and it is not the one most incident calls open with. The question is not whether your analytics vendor, chat provider or review widget was breached. The question is whether the file your payment page loads changed, and when. Those are different facts, and the vendor’s public statement almost never answers the second.
What follows is written for the hour after the email arrives. It assumes you have a checkout in production, a tag manager somebody else can publish to, and a supplier who has just used the words “security incident”.
First, work out which kind of supplier breach you are dealing with
Three situations get collapsed into one and they carry very different consequences for your card data.
- The supplier’s corporate systems were breached. Their CRM, support desk or internal network. Customer records they held may be gone. No code on your site changed. Your exposure is data the supplier already had, not your checkout.
- The supplier’s hosted script or CDN was altered. The file your page fetches from their domain is not the file they wrote. Every visitor to every page that loads the tag executed whatever was in it. If that includes the payment page, you have a skimmer problem until proven otherwise.
- Your own first-party code was injected using access the supplier held. An admin account, an API key, an SFTP credential, a plugin with write access. The malicious code sits on your domain, served by you, and will survive the supplier’s clean-up entirely.
Only the second and third put a skimmer in front of a cardholder. The vendor’s statement is usually drafted about the first, by a communications team, with lawyers reading over the shoulder. “No evidence of unauthorised access to customer code”is not the same sentence as “the asset at cdn.example.com/widget.js has not been modified since 4 February”.
Ticketmaster UK in 2018 remains the clearest reference case. A compromised third-party chat widget loaded on pages where customers typed card details, and the harvested data was used for fraud before the connection was understood. The ICO fined Ticketmaster UK £1.25 million in November 2020, citing a failure to assess the risks of running that third-party script on payment pages. The supplier was breached. The liability landed on the merchant.
Decide severity in the first hour on one fact: does this supplier’s code execute on the page where card details are entered, or in the same browsing context as it. If yes, treat it as a live card-data incident. If the tag is confined to your blog and category pages, you still have a data question, but not a payment one.
One more thing to get out of the way. If a vendor tells you their script was not named in any Magecart reporting, that tells you nothing. Magecart is a label for a method rather than a single group, used by many unconnected crews. Absence from a threat report is not absence of a skimmer.
The supplier breach checkout checklist: 12 steps in order
Assign a named owner and one evidence artefact to each step. A ticked box in a spreadsheet proves nothing to an acquirer six weeks later. A HAR file with a timestamp does.
Steps 1 to 4: containment, within the first hour
- Pull or pin the supplier tag on the payment page. Owner: whoever holds publish rights in the tag manager. Evidence: the tag manager version entry showing the time, the change and the publisher. Pull it if the business cost of 48 hours without it is nil, which it usually is for chat, reviews and A/B testing.
- Freeze deployments. Owner: engineering lead. Evidence: a locked release branch and a note of the freeze time. A routine deploy mid-incident overwrites the thing you are trying to examine.
- Snapshot the live checkout before anything else changes. Owner: a developer, working from an ordinary browser. Evidence: the rendered HTML, a saved HAR export of the full network request list, and a byte-for-byte copy of every script the page loaded, each with its SHA-384 hash. Do this on the payment step with a real basket, not the homepage.
- Preserve logs before any rotation or purge. Owner: platform or ops. Evidence: an exported archive of CSP reports, web server access logs, CDN logs and the tag manager audit trail, hashed and stored off the production host.
Steps 5 to 8: verification
- Diff the supplier file against your known-good hash. Owner: developer. Evidence: the two hashes, the approved version string, and the date the approved hash was recorded. If no approved hash exists, say so in the record. That gap is itself a finding.
- Read the file. Owner: a developer who can read minified JavaScript, or an external reviewer. You are looking for code appended after the original bundle’s final statement, domain names assembled from string fragments, base64 or hex blobs that decode to URLs, listeners bound to form submit or keydown on input elements, and calls to fetch, XMLHttpRequest or navigator.sendBeacon pointing at a host you cannot account for. Evidence: the annotated extract and the exfiltration endpoint if one exists.
- Audit what the supplier held on your systems. Owner: platform admin. Admin users, API keys, OAuth grants, webhook targets, SFTP accounts. Export the user list with last login times before you rotate anything, then rotate. Evidence: the pre-rotation export.
- Confirm where the card fields actually live. Owner: developer. Are the PAN, expiry and CVV inputs in your DOM, or inside the payment provider’s iframe on their origin. Evidence: a screenshot of the inspected DOM showing the iframe boundary and its document origin. The answer changes the severity of everything above it.
Steps 9 to 12: closing out
- Ask your acquirer or PSP for fraud signals over the exposure window. Owner: payments or finance lead. A common point of purchase report, where issuers have flagged your store as the shared origin of fraudulent cards, is the strongest external confirmation you will get. Evidence: the dated response, including a negative one.
- Decide on notification. Owner: compliance or DPO. Assess whether personal data was likely accessed and whether there is a risk to individuals, with the ICO’s 72-hour reporting window running from the point you became aware. Check your acquirer agreement separately; its notification terms are contractual and often tighter. Evidence: the written assessment, including the reasoning if you decide not to report.
- Document the timeline. Owner: incident lead. What loaded, from where, which versions, which hashes, when the tag was pulled, who approved each step. Evidence: a single dated document with the artefacts attached. Write it while the detail is fresh.
- Re-admit the script only against a version you have read. Owner: developer plus the business owner of the tag. Take a new hash from the reviewed version, pin it, update the inventory entry with the justification, the approver and the date. Evidence: the updated inventory row and the deploy record.
What gets destroyed if you move too fast
The single most valuable artefact in a supplier incident is the rendered checkout page plus its full network request list, captured before anybody redeploys. Suppliers clean up fast, and they clean up for their own reasons. A CDN purge and a rebuilt bundle can remove the compromised file within minutes of their own detection. After that, you cannot show your acquirer what executed on your payment page, only what executes now.
Rotating keys and purging caches feels like control. Done first, it leaves you with a clean site and no story. Snapshot, then rotate.
If you already run a Content Security Policy in report-only mode, you are in a different position entirely. The reports give you a dated record of destinations the browser was asked to reach, which answers “when did this start”without guesswork. Report-only mode pays for itself twice: it never breaks a checkout while you tune the policy, and it quietly builds the evidence log you will want exactly once. A working CSP setup for a checkout page takes an afternoon and no licence fee.
Using your script inventory to answer in minutes instead of days
PCI DSS 4.0 requirement 6.4.3 asks that every script on the payment page be authorised, justified and integrity-assured. Requirement 11.6.1 asks for detection of unauthorised change to the security-impacting elements of that page. Both stopped being future-dated and became mandatory on 31 March 2025, per the PCI Security Standards Council. What those two requirements actually ask for is narrower than most vendor pitches suggest.
You do not need a product. A weekly cron job that fetches each payment-page script, compares SHA-384 hashes against an approved list and emails on difference, combined with a Content-Security-Policy-Report-Only header and a report endpoint, satisfies the substance of 11.6.1 at the cost of a few hours of developer time. Buy the product later if the volume of tags justifies it.
The inventory column most merchants leave out, and then regret, is the operational one. A list of script URLs with a business justification passes an assessment. In an incident you want three more fields per row: the approved hash of the current version, the tag or template that injects it, and the supplier’s named security contact with the notification clause from the contract. Without those, step 5 of the checklist takes two days of email instead of ten minutes. If your scope depends on it, the same discipline underpins proving SAQ A eligibility for your scripts.
Hosted payment fields reduce the blast radius considerably. Card data typed into the provider’s iframe is not readable by a script on your page, so a compromised widget cannot copy the PAN directly. What remains in scope is still real: names, addresses, email addresses, order values, and the framing of the page itself, which a determined skimmer can replace with a convincing fake form. Moving the card fields out of your DOM changes the severity of the answer. It does not remove the work.
Kill the tag, pin it, or let it run
Apply the pull-it-now test. Does the tag execute on the payment page, and does the business lose anything measurable if it is off for 48 hours. A chat widget has no business on the page where card numbers are typed, so the answer is to pull it and argue later. A fraud-scoring script from your PSP is a different conversation.
Between killing and trusting sits Subresource Integrity. Pin the script to a hash and an altered version simply fails to load. Understand precisely what that buys you: SRI proves a file matches a hash you approved. It says nothing about whether the approved version was clean. Pin a file after the supplier shipped malicious code and the browser will faithfully enforce the skimmer. The hash has to come from a version somebody read.
The honest downside is suppliers who ship changes without notice. Their script breaks, your checkout logs a blocked resource, and the on-call developer gets a call about a vendor release nobody told them about. Handle it with versioned asset URLs in the contract, a staging environment that fetches the vendor’s unpinned URL so breakage surfaces there first, and a documented route for approving a new hash inside a working day.
Sometimes more tag hygiene is the wrong answer. If a supplier cannot offer a pinnable, versioned URL, or loads further scripts of its own at runtime, the correct move is to remove it from the payment page or migrate to hosted fields and a redirect. Tag hygiene on an unpinnable third-party loader is effort spent on nothing.
Supplier questions to settle before the next incident
Contract-level asks, in order of how much they help during an incident: a notification window measured in hours, a named security contact rather than a support inbox, versioned and pinnable asset URLs, and written notice before code changes to assets that load on checkout.
For any vendor whose script runs on the payment page, ask four things in due diligence. Does the script load further scripts at runtime, and from where. Can you pin it. Who at their end can modify the production bundle. How fast will they tell you if that bundle changes without authorisation.
Supplier hygiene is only one route in. Sansec reported in September 2020 that roughly 2,000 Magento 1 stores were skimmed over a single weekend, through the platform itself rather than any third-party widget. Patch state and supplier management are separate failure modes, and a clean supplier list will not save an unpatched platform. The pattern across high-profile incidents is consistent on this point.
Run the checklist as a dry-run twice a year against a real supplier tag, and record how long each step actually took. The useful output is not the tick, it is discovering that nobody present can publish a tag manager change on a Saturday.
The short version
Separate the three events: a supplier’s corporate breach, a supplier’s script compromise, and injected first-party code. Only the last two reach a cardholder. Snapshot the rendered checkout and its full network request list before anyone cleans up, because the supplier’s own remediation destroys your evidence. Pull the tag if the payment page can live without it for 48 hours, pin it to a hash from a version somebody has read if it cannot. Keep the approved hash, the injecting tag and the supplier’s security contact in your 6.4.3 inventory, and run a weekly hash diff with CSP report-only logging rather than waiting for a budget. Then rehearse the supplier breach checkout checklist before you need it, because the first hour is where the evidence either survives or does not.
Frequently Asked Questions
A supplier says they were breached but insists no code was changed. What should I check?
Check the file yourself. Fetch every script your payment page loads, hash each one, and compare against your approved hashes and the version the vendor says is current. Read the supplier’s asset for appended code and unfamiliar network destinations. A statement about their corporate systems is not a statement about the bundle on their CDN.
How do I prove a third-party script on my checkout was not altered?
With a hash recorded before the incident and a dated record of comparisons since. A weekly job that fetches each payment-page script and diffs SHA-384 hashes against an approved list gives you that record, and CSP report-only logs corroborate the destinations the page tried to reach. Without a prior approved hash you cannot prove absence of change, only that the current file matches the vendor’s current build.
Do I have to notify the ICO or my acquirer after a supplier breach?
Assess whether personal data was likely accessed and whether that poses a risk to individuals. Where it does, the UK GDPR requires a report to the ICO without undue delay and within 72 hours of becoming aware. Your acquirer’s notification terms are separate and contractual, often shorter, and apply whether or not personal data was involved. Document the assessment either way.
Does using hosted payment fields mean a supplier breach no longer affects my checkout?
No, it narrows the damage. Card data entered in the provider’s iframe is out of reach of scripts on your page, which removes the direct PAN theft route. Order details, names, addresses and email addresses remain exposed, and a compromised script can still overlay or replace the page around the iframe. The checklist still runs, with lower severity at step 8.
How often should I run the supplier breach checkout checklist as a drill?
Twice a year is enough for most merchants, with one run timed outside working hours. Pick a real supplier tag, walk the twelve steps, and record the elapsed time per step and who was reachable. The drill usually exposes process gaps, such as missing publish rights or an unmaintained inventory, long before it exposes technical ones. A one-hour detection pass makes a reasonable warm-up exercise.