What is the difference between merchant responsibility and vendor responsibility under PCI DSS 4.0.1 script controls?

Merchant responsibility covers scripts running on the merchant’s own pages, while vendor responsibility applies to scripts running inside PSP or TPSP iframes. That distinction matters because it prevents both sides from assuming the other is handling security. Clear ownership reduces oversight, supports cleaner compliance evidence, and helps teams focus remediation on the correct control boundary.

How PCI DSS 4.0.1 splits ownership between merchant pages and embedded vendor frames

The control boundary is the key difference. Merchant responsibility is tied to scripts on the merchant’s own checkout or account pages, where the merchant controls the page, the content, and the security expectations. Vendor responsibility applies when a payment service provider or third-party service provider hosts the script inside its own iframe boundary, which changes who can directly manage the page logic and evidence.

That distinction matters because script control is not just about where a line of code executes, it is about which organisation owns the surface that can be altered, observed, or abused. Under PCI DSS 4.0.1, teams should treat page ownership and iframe ownership as separate control domains, not interchangeable hosting details.

Why the ownership line changes the security and compliance burden

On a merchant-owned page, the merchant is the party expected to govern the scripts that can influence payment collection, form handling, and user interaction. That usually means the merchant must know what is loaded, why it is loaded, and how changes are approved and reviewed. On a vendor-controlled iframe, the vendor controls the embedded context, so the merchant should not assume the same visibility or control as it would have on its own page.

For compliance, the important point is that the evidence trail follows the control boundary. If the merchant owns the page, it needs to show that scripts are approved, monitored, and reviewed on that page. If the vendor owns the iframe, the merchant still needs assurance that the vendor’s embedded content is governed appropriately, but the operational evidence will look different because the vendor is responsible for that embedded execution environment.

One practical way to frame the split is that the merchant owns what it publishes, while the vendor owns what it embeds. That simple rule prevents the common failure where both sides assume the other party is checking script integrity, reviewing changes, or maintaining the right records.

What teams should verify at the control boundary

For merchants, the first check is whether the script runs on a merchant page or within a PSP or TPSP iframe, because that determines who must demonstrate control. If the script can affect a merchant-hosted page, the merchant should be able to explain the approval path, inventory, and monitoring approach for that page. If the functionality lives in a vendor iframe, the merchant should be able to identify the vendor owner and the evidence that supports trust in that boundary.

This is where governance often breaks down. Scripts can be added during feature launches, A/B tests, tag management updates, or payment-flow changes without the owner of the page understanding that a new control obligation has appeared. The same is true on the vendor side if the iframe content changes faster than the merchant’s review cycle. A clean boundary only helps if both parties keep an accurate view of what lives on their side of it.

Merchant pages should have an inventory of active scripts and approved change paths.
Vendor iframes should have documented ownership, change control, and assurance evidence.
Both parties should verify that the control boundary matches the actual rendering path, not just the intended architecture.

Risk and Threat Considerations

Script ownership gaps create a trust problem that attackers and careless change management can both exploit. If neither side is clearly responsible, a malicious or compromised script can persist longer, remain unreviewed, or be incorrectly scoped during incident response. That is especially dangerous in payment flows, where a small boundary mistake can expose high-value customer interaction points.

Failure mechanism: Ownership ambiguity weakens review, monitoring, and escalation, which makes it easier for an unsafe script to be introduced, modified, or left in place without timely challenge.

Impact: The result can be compliance failure, delayed remediation, loss of evidence quality, and a larger blast radius if payment-page scripting is abused or altered.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
PCI DSS v4.0	6.4.3 — Script authorization and integrity	PCI DSS 4.0.1 script ownership hinges on who controls scripts on payment pages.
	12.5.2 — Roles and responsibilities	The question is about assigning merchant versus vendor responsibility clearly.
Recommendation — Define script ownership by execution boundary and maintain evidence for approved, monitored scripts. Assign explicit control ownership for merchant pages and vendor iframes, and retain accountability evidence.
NIST SP 800-53 Rev 5	AU-2 — Event Logging	Script control depends on monitoring and traceable evidence for page changes and review.
Recommendation — Log script changes and reviews so ownership and remediation decisions remain auditable.
ISO/IEC 27001:2022	A.5.15 — Access control	Ownership of script execution surfaces is a control-boundary and access-governance issue.
Recommendation — Restrict who can change page scripts and verify the boundary for embedded vendor content.
CIS Controls v8	CIS-6 — Access Control Management	The page/iframe split requires clear access ownership and control over script changes.
Recommendation — Maintain role-based approval for changes to merchant scripts and vendor-controlled embeds.

Practitioner Guidance

What to verify: Confirm whether each script is executed on a merchant-controlled page or inside a PSP or TPSP iframe before assigning the control owner. The hosting model, not the business relationship, should decide who carries the primary evidence burden.

What good looks like: The merchant can show a current script inventory for its own pages, while the vendor can show governed ownership for its iframe content. Both sides can point to the same boundary without overlap, gaps, or contradictory assumptions.

Common mistake: Treating “the payment vendor handles it” as a complete control answer when the script still runs on a merchant page. That shortcut usually leaves the merchant unable to prove who reviewed the content that actually touches the customer journey.

Practitioner takeaway: In PCI DSS script controls, the deciding question is not who is involved in the payment flow, it is who owns the execution surface where the script actually runs.