PCI DSS script monitoring for insurance quote and payment pages
A quote-and-buy flow collects more third-party code than almost any other checkout, because comparison, chat, form analytics and attribution all earn their place on the page where the first premium is paid.
Start for free
Talk to an expert
TL;DR
Insurance and the client-side requirements
THE OBLIGATION
PCI DSS 6.4.3 and 11.6.1 have been mandatory since 31 March 2025 for any page where a cardholder enters, reviews or confirms card data.
THE SPECIFIC DIFFICULTY HERE
Quote-and-buy pages carry comparison widgets, form analytics and chat, and each one is both an attack path and a 6.4.3 line item that needs a written justification.
WHAT THE TAG PRODUCES
A script inventory with justifications, a weekly header change record, runtime blocking, and an evidence pack for your assessor.
Short on time? Session replay on a quote page is the finding that comes up first.
Block one capability, keep the tag
Does insurance need PCI DSS script monitoring?
Yes, if you operate any page where a cardholder enters, reviews or confirms card data, which includes pages that embed a payment iframe. A quote-and-buy flow collects more third-party code than almost any other checkout, because comparison, chat, form analytics and attribution all earn their place on the page where the first premium is paid. Requirements 6.4.3 and 11.6.1 apply to those pages regardless of platform, and have done since 31 March 2025.
Where the exposure is
Quote-and-buy pages carry comparison widgets, form analytics and chat, and each one is both an attack path and a 6.4.3 line item that needs a written justification
Session replay and form analytics exist to record what a visitor types, which is exactly the capability you do not want on the page where a card number is entered
Broker and agent portals are often built on a different stack from the main site and get reviewed later, or not at all
Renewal and instalment pages take a card but rarely get treated as checkout, so they sit outside whatever scope the ecommerce team defined
What the inventory shows you
Every script on quote-and-buy, renewal, instalment and broker portal pages, listed per domain
Session replay or form analytics reading payment fields, which is the single most common finding on an insurance payment page
A comparison or aggregator tag shipping changed code, caught by payload hash rather than URL
New outbound destinations from a tag that previously only talked to its own domain
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
The two requirements, in this context
Frequently asked questions
Read the FAQ
Yes, if a card is entered, reviewed or confirmed on it. The requirement follows the page, not the industry. A quote page that ends in a payment step is a payment page, and so are renewal and instalment pages, which are the ones most often missed.
This is worth separating, because searches for PCI compliance insurance usually come from one of two places. Either a broker portal that takes a card for a first premium, or a carrier renewal page. Both are in scope for 6.4.3 and 11.6.1. Cyber insurance policies are a different subject entirely and are not what this page covers.
Often yes. If the payment form is an iframe served by your provider, the iframe is theirs but the page around it is yours, and a script on that page can overlay it or capture keystrokes before the iframe ever sees them. See hosted payment pages and PCI.
Yes, if you can justify it and constrain it. Block the capability rather than the whole tag, so replay keeps working everywhere except reading the payment fields. That is usually the version that survives the conversation with the growth team.
No. Domains are unlimited on every plan and page views are the only metered unit, so a broker network costs what its traffic costs and nothing more.
Yes, for the code they run on your pages, which is the part in your scope. It does not tell you anything about what happens on the aggregator’s own site, which is their assessment, not yours.
It varies and that is part of the problem. Digital owns the tags, security owns the finding, and compliance owns the evidence. The evidence pack is built to be handed between all three without anyone having to use the console.
Days rather than weeks. The tag goes in, you mark quote, renewal and instalment pages with selector rules, and the inventory populates from live traffic immediately. Writing the justifications is the slower part and it is a writing exercise, not an engineering one.
See the scripts on your own payment pages.
Free forever on 1,000 page views a month, no credit card. Unlimited domains on every plan.
Free forever plan. No credit card.