# Can you keep a tag manager on a payment page under PCI DSS 6.4.3?

> A tag manager is one authorized script that loads scripts you never approved, which is the exact thing 6.4.3 asks you to control. What an assessor expects, why a crawl cannot produce the inventory, and how to handle container hash rotation without drowning the change log.

- Canonical: https://info.centralcsp.com/articles/pci-dss-payment-page-tag-manager/
- Published: 2026-09-21
- Language: en
- Publisher: CentralCSP (https://centralcsp.com)

Requirement 6.4.3 asks for three things about every script on a payment page: that it is authorized, that its integrity is assured, and that an inventory exists with a written justification for why it is there. Both 6.4.3 and 11.6.1 have been mandatory in assessments since 31 March 2025.

A tag manager is a single authorized script whose entire job is loading scripts you did not individually approve, changed by a team that does not deploy code, without passing through review. It is not that a tag manager is insecure. It is that the mechanism it provides is the exact mechanism 6.4.3 is written to constrain.

So the short answer: you can keep it, but the container is not the unit of authorization, and listing `gtm.js` in your inventory does not satisfy anything. You have to inventory the tags it loads, in the environment where it loads them, and justify each one. Most teams who cost that out end up moving the tag manager off the checkout page instead, and we think they are right.

## Why "the container is one approved script" does not survive an assessment

Put the requirement next to what a container does.

| 6.4.3 asks for | What a tag manager gives you |
| --- | --- |
| Each script is authorized | One authorization covering an unbounded, changing set |
| Integrity of each script is assured | A loader whose payload changes without notice |
| Written justification per script | A justification for the loading mechanism |
| Inventory kept current | An inventory that is current until marketing publishes |

The killer is the second column, third row. The justification you wrote says "we use a tag manager to manage marketing tags". It does not say why a session recording vendor has DOM access on the page where the card number is typed, which is the question an assessor is actually asking, and which is the question that matters regardless of the assessment.

There is a second problem that has nothing to do with compliance. A container publish is a production change to your payment page made by someone whose job is conversion rate, usually with no code review, no staging and no rollback conversation. Magecart operators know this, and the tag manager is a known path onto checkout pages precisely because it is the one place where a change is normal.

## A crawl cannot produce this inventory

The instinct is to open the checkout page, look at the network tab, write down what loaded, and call that the inventory.

That misses most of it, because tags fire conditionally. Triggers depend on page path, on cart value, on whether consent was granted and for which category, on geography, on A/B test assignment, on whether the user is logged in. A synthetic visit from a data centre in one country with no consent state and an empty cart exercises a fraction of the container. The tags that fire only for real customers in the checkout flow are the ones nearest the card form.

Skimmers exploit exactly this. Cloaked payloads check for a real session, a populated cart or a non-headless browser before doing anything, precisely so that scanning does not see them.

Which means the inventory has to come from real sessions. The mechanism is CSP hash reporting: adding `'report-sha256'` to the policy makes the browser report every script that actually executed, with its SHA-256, from whichever visitors triggered it. No agent on the page, no crawler, no vendor JavaScript added to a page whose script count you are trying to defend. First-, third- and fourth-party scripts all appear, including the ones a tag loaded that were loaded by another tag. We covered the general mechanism in [building a script inventory without an agent](/articles/script-inventory-without-an-agent/).

## The hash rotation problem, which is the reason people give up

Here is what sinks a homegrown attempt. Container scripts change constantly. Every publish regenerates the container, and the vendor updates the hosted loader on its own schedule. If your inventory treats a new hash as a change requiring review, your change log fills with a dozen entries a week that all mean "marketing published again", and within a month nobody reads it.

Then a real change arrives and lands in the same pile.

The way out is validation rules that know the difference between a known script rotating and a genuinely new script appearing. In CentralCSP's PCI DSS module, a script carries a justification and a set of auto-validation rules for its known patterns, so a routine container rotation is recorded in the timeline without re-entering the pending queue, while anything that has no matching justification does go to pending and raises an alert. The distinction is between "this file changed as it always does" and "something that was never authorized is now running on the page".

That module also produces the artefacts an assessor asks for: a dated change timeline per payment page (script added, changed, removed, new origin), the justification text per script with who recorded it and when, and an evidence export as CSV and PDF plus an SBOM of the page's technologies. The compliance records are kept until the account is deleted, which matters because raw browser reports are retained for 90 days and an assessment window is longer than that.

The PCI DSS module is on the Scale plan (€349.99/month) and Enterprise. The script inventory that feeds it is on every plan including Start.

## 11.6.1 and the seven-day floor

11.6.1 is the detection half: you have to detect unauthorized modification of the HTTP headers and page content of payment pages, evaluated at least once every seven days.

Seven days is a floor, not a target. A skimmer that harvests for six days before you notice has harvested for six days. Report-driven detection is continuous rather than scheduled, because the evaluation happens when a browser sends a report, and CentralCSP's alert rules are evaluated on ingest rather than on a cron. The relevant rules here are an unjustified script appearing on a payment page and a new script origin, which go to any of six channels (Slack, Teams, Google Chat, Telegram, email, signed webhooks) with a cooldown so that one bad deploy does not produce four hundred messages. Alerting starts at Business (€129.99/month).

Headers count too. 11.6.1 names them explicitly, and a CSP quietly removed by a proxy change is an unauthorized modification of the page's security posture that no script inventory will show you.

## What we would actually do

In order of how much we would argue for it:

1. **Take the tag manager off the payment page.** Keep it everywhere else. The checkout page gets a short, hand-maintained list of scripts, each with a name attached to it. Conversion tracking generally survives this, because the purchase event can fire server-side or on the confirmation page, which is not where the card is entered. This is the option that makes 6.4.3 straightforward instead of ongoing.
2. **If it stays, treat the tags as the inventory.** Enumerate what actually fires in the checkout flow from real traffic, justify each one, and get the container into a change process that at minimum notifies you. A publish on the checkout container should page someone, not just appear in a version history nobody reads.
3. **Cut the container's own ability to add arbitrary code.** Tag managers can inject custom HTML and inline JavaScript. Restricting who can publish, and disabling custom HTML tags on the container used for checkout, removes the worst case, which is an attacker with tag manager credentials rather than server access.
4. **Watch what runs, continuously.** Whichever of the above you choose, the page needs to be reporting what executed and alerting on anything unjustified. That is the control both 6.4.3 and 11.6.1 are circling.

One note on CSP itself. A tag manager and a strict policy fight each other: custom HTML tags want inline execution, so teams reach for `'unsafe-inline'` and undo the policy to keep the container working. If the container stays, it needs nonce propagation rather than a blanket exception, and that is usually the point at which someone recalculates the cost of option one.

The requirement-by-requirement detail is in [PCI DSS 6.4.3 and 11.6.1 for payment pages](/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/), and the evidence side is in [proving your payment scripts have not changed](/articles/prove-payment-scripts-unchanged/). CentralCSP produces the evidence for an assessment. It does not certify compliance, and anyone telling you their tool does is selling something.

## Frequently asked questions

### Does PCI DSS forbid a tag manager on a payment page?

It does not name tag managers at all. Requirement 6.4.3 says each script must be authorized, its integrity assured, and an inventory kept with a written business or technical justification. A container script satisfies none of that for the tags it loads, so the container itself is not the unit of control. You can keep it if you inventory and justify what it actually loads, which is more work than moving it off the page.

### Can I just list the tag manager as one authorized script?

Assessors we have dealt with do not accept it, and the reasoning is hard to argue with: the thing you authorized can load something different tomorrow without a deploy, a code review or a ticket. Authorizing the container authorizes a mechanism, not a script. The inventory has to reach the tags.

### Why does the container hash change every day?

Tag manager containers are regenerated whenever the container is published, and the hosted loader is updated by the vendor on its own schedule. A naive inventory treats every regeneration as a change to review and buries the real ones. You need validation rules that recognise the routine rotation of a known script and only queue a change when the loaded tags differ.

### Does 11.6.1 apply if my payment page is a hosted iframe?

The parent page still matters. If your page frames a payment provider, the framing page can still be modified to overlay or replace that iframe, which is why SAQ A eligibility since the 2025 revision turns on script-attack exposure rather than on whether you touch card data directly. Monitor the page that carries the iframe.