Prove PCI 6.4.3 & 11.6.1 with what
actually ran in the browser

Yes, for the technical controls both requirements describe. The product produces the script inventory with a per-script business justification and integrity assurance that 6.4.3 asks for, and the change- and tamper-detection mechanism with alerting that 11.6.1 asks for, plus the evidence to show an assessor. Compliance itself is a judgement your QSA or your SAQ makes across the whole standard, and this covers two requirements out of twelve requirement families. We are deliberately not a full-scope PCI platform.

Yes. The controls have been validated by a Qualified Security Assessor and the evidence pack is built around what assessors actually ask for: the scope, the inventory with justifications, the header change record, and the alerts. If your assessor wants something in a particular format, that is a reasonable request and worth raising with us early.

Yes, in the sense that any tag has a cost, and no in the sense that it is designed not to be felt. The tag is small, runs first in the head so it sees every script after it, and is fail-open: if our service is unavailable your page still renders and your checkout still works. Deep analysis of each script happens off the page rather than in the visitor's browser.

Yes, this is the right question to ask of any client-side security product. Our own tag is integrity-checked when it loads: if what arrives in the browser is not the script we published, it does not run. A monitor an attacker can silently modify is worse than no monitor at all, because it keeps reporting all-clear while the page is being skimmed. Not every agent in this category verifies itself, so it is worth asking each vendor you evaluate.

No, and this is worth being precise about. There is no DNS change and no CDN change, and your site traffic is never routed through our infrastructure. The tag runs on your page and reports what it sees. Separately, we fetch the third-party scripts themselves from our side so they can be hashed, archived and analysed without doing that work in your visitor's browser.

Any page where a cardholder enters, reviews or confirms card data. That includes checkout forms, payment confirmation screens and stored-card management pages. It also includes a page that embeds a payment iframe: the iframe belongs to your provider, but the page around it is yours, and that page is where a script can reach the form. You define the scope with selector rules, and only those page views count towards your plan.

Yes. Monitor-only mode produces exactly the same evidence, including a record of what would have been blocked and on which pages, with nothing actually stopped. Most teams run this way for the first few weeks, then enable enforcement once the inventory has settled.

Yes, you find out, and that is the point of integrity assurance. Approval is pinned to the payload hash you approved, so when a vendor ships new code it arrives as a change that needs review rather than as silently inherited code. You will also see it if the vendor's own vendors change, which is where most surprises come from.