A merchant keeps card entry inside a provider-hosted iframe and believes its scope is minimal. Customer support uses a screen-sharing tool that can see and record the customer's browser during checkout, calls are recorded, and a session-replay script runs on every page for analytics. Review the arrangement.

What is actually required

The scope-reduction logic the merchant relied on is correct as far as it goes: if card data is entered directly into a provider-hosted iframe and never touches the merchant's systems, the merchant's environment is largely out of scope for storage and processing. That is a real and valuable architectural decision.

Scope, however, follows the data and not the page. Anything that can capture, transmit or store the card number brings itself and its surrounding systems into scope, regardless of which domain served the form.

What I would remove, and why it is safe to

• The session-replay script on the checkout pages. Replay tools record DOM interaction, and a misconfigured or updated tool can capture input values. Running one on a payment page puts a third-party analytics vendor and its storage into the cardholder data environment for no proportionate benefit. Remove it from the payment flow entirely rather than relying on field masking, because the masking is a configuration that can silently change — and a script on the payment page is also the classic path for a card-skimming attack, which is what the script-integrity requirements in PCI DSS v4.0 exist to address.
• Screen sharing during card entry. Support can share the customer's screen at any other point in the journey. During entry it must be blocked by the application, not by a procedure telling agents to look away.

The one change that matters

Make the payment step a state the rest of the estate can see and react to. The application signals entry into card capture; the replay script stops, screen sharing is suspended, call recording pauses, and all three resume afterwards. One mechanism, enforced in code, covering every channel that could observe the field — rather than three separate policies each depending on someone remembering.

What I would leave, even though it looks odd

Call recording itself. Telephone orders are a recognised scenario with a recognised control set: pause-and-resume around card capture, or a dual-tone keypad entry service that keeps the digits out of the recording and out of the agent's hearing. Removing call recording would damage dispute handling and quality assurance for no gain, because the problem is the interval, not the practice. What must change is that the pause is automatic and evidenced, since an agent-operated pause fails at exactly the rate you would expect.

How I would argue this in the review

Not as a compliance finding. As a question with one answer: name every system that could observe the characters the customer types into the card field. That list is the scope, and it usually contains three or four things the architecture diagram does not show — an analytics script, a support tool, a recording system, a browser extension the enterprise deploys.

Then the proportionality point, so the review does not over-correct: this is an argument for segmenting the payment step, not for abandoning session replay or screen sharing elsewhere in the product. Both are useful, and the correct scope of the restriction is the interval in which card data is present.

When this is over-engineering

If the merchant redirects to a fully hosted payment page on the provider's domain, rather than embedding an iframe, most of this dissolves — the customer is not on the merchant's page at all during entry, so the merchant's scripts and tools cannot observe it. That is the cheaper architecture and it should be the default unless the conversion cost of leaving the site is demonstrably material, which is a measurable question rather than a matter of opinion.