How to choose a PCI DSS 6.4.3 and 11.6.1 monitoring tool

The question that separates tools: what is behind your login?

Requirement 11.6.1 is about the HTTP headers and the contents of payment pages as received by the consumer browser. Many payment forms never appear on a public address: they show up after the customer signs in, or mid-checkout. A tool that only loads public addresses never evaluates those pages, and they matter most.

PCI Monitor was built for this case. You sign in and walk through the checkout once in a recording window; every scheduled test then replays that journey in a real browser and records the scripts at each step. It follows five sign-in methods (a username and password, an email address as the username, a one-time code by email, a one-time code by text message, and an authenticator app), a monitor can hold several logins, and the credentials are stored encrypted. See Authenticated Monitoring.

Ask this first, in writing: how does it reach a payment page that needs a login or appears mid-checkout, and how does it handle a second sign-in step?

Nine questions to ask any vendor

1. What does it evaluate? What a consumer's browser receives (the requirement's wording), or only source code or one request?
2. How does it see the page? An outside browser, a script tag in your page, a CDN or proxy, a service worker or policy violation reports each see and miss different things.
3. Does it reach pages behind a login and mid-flow steps? See above.
4. How often does it really run? At least every seven days, or the frequency in your targeted risk analysis (11.6.1 evidence).
5. What evidence does it keep? Dated results for every run, each script decision, who decided and when, exportable.
6. Who is alerted, and what happens next? Ask how a finding reaches a named person and is closed.
7. Does it detect or also block? The requirements ask for an inventory, authorization, integrity and alerts. Blocking is a separate capability, and it usually means something running in the live session of your pages.
8. What must you change? Adding a tag, changing headers or writing justifications takes your time.
9. What will your assessor accept? Ask early; a vendor's statement about approval is the vendor's claim.

What each vendor says on its own page

Checked on 23 October 2026 by reading each company's own page, not reviews or other comparisons. The first row is PCI Monitor, the publisher of this guide. The others are alphabetical and described only in the vendor's own words or a close paraphrase. The last column records whether the page we read mentions pages behind a login.

How to read the table

"Not mentioned on this page" is exactly that. A company may support logins elsewhere or on request, and products change. Treat the last column as the question to put to each vendor, in writing.

This guide is published by the makers of PCI Monitor, which is one of the tools described, so read the table with that in mind. Tools not listed have not been read yet, which says nothing about them. If a row is wrong or out of date, or you would like a tool added or a statement of yours reflected, contact us and we will check the page and correct it.

No tool makes a company compliant. PCI DSS compliance depends on your whole program and is confirmed by your assessor.