PCI DSS Readiness

The Compliance section of the dashboard has one page today, PCI DSS 4.0. For the two requirements HeaderHawk speaks to, it says Met, Partially met or Not met, shows the facts the status rests on, lists what is missing, and exports the evidence. It is available on every plan: on a plan that cannot meet a requirement, the page says so and names the plan each missing step needs.

Nothing is decided on the page. Every row links to the Scripts, Headers or Alerts page where the work is done.

One site at a time

An assessment covers one site, so the page shows one site’s readiness. With All sites selected in the header, it asks you to choose one.

Requirement 6.4.3: payment page scripts are managed

PCI DSS 4.0 asks that every script loaded and executed on a payment page is authorized, that its integrity is assured, and that it is inventoried with a written justification.

The status is decided from the scripts on the site’s payment pages over the period your plan keeps reports: the ones browsers reported running there, and the ones the daily scan of each payment page found in its HTML (Header Monitoring).

Status	When
Not met	The site has no payment page marked, or the plan does not include the script inventory.
Partially met	Any script on a payment page is not yet reviewed, a rejected script was still found there after it was rejected, any script was reported running without integrity metadata, integrity is not measured yet, the inventory is longer than can be listed, or no script has been found on the payment pages at all.
Met	Every script found on the payment pages has been authorized or rejected, no rejected script has been found since, the site is reporting integrity violations, and none was reported running without integrity metadata.

Two details decide how the integrity half reads:

Unmeasured integrity is a gap, never a pass. A script is only counted as protected when the site is reporting integrity violations (see Script Integrity Monitoring). Until then nothing shows that any script on the page is integrity-checked, so a site that has reviewed every script is still Partially met, and the page says integrity is not measured yet. Deploying the report-only Integrity Policy header is what closes it.
A script the inventory never saw still counts. If a browser reported a script running without integrity metadata that the script hash reports never named, it is counted as unprotected.

A rejected script that keeps running is a gap. HeaderHawk records a rejection; it does not enforce it. A script still reported on a payment page, or found there by a scan, after it was rejected is an unauthorized script running, and the page lists it as rejected and still running until it stops.

No script found is a gap, not a pass. A payment page whose site sends no script hash reports, and whose scans found no script either, has an empty inventory, and an empty inventory is not evidence that every script was reviewed. Check that script hash reporting is switched on for the site.

Requirement 11.6.1: changes to payment pages are detected

PCI DSS 4.0 asks for a mechanism that alerts personnel to unauthorized changes to the security-impacting HTTP headers and the script contents of payment pages, at least weekly.

Status	When
Not met	The site has no payment page marked, or any payment page has had no complete scan in the last 7 days.
Partially met	Every payment page is being scanned, but at least one kind of change has no enabled alert rule that would deliver it.
Met	Every payment page is scanned daily, and every kind of change below has an enabled alert rule with a destination.

The kinds of change, as they are named on the Alerts page:

Security header changed and Scan grade dropped, from the daily scan of each payment page (Header Monitoring).
New script on a payment page and Pinned script changed, from the script reports (Script Integrity Monitoring).
Script gone from a payment page and Script moved to another origin, the deletions the requirement names, from the daily scan of each payment page (Scripts that leave a page).

A rule counts when it is enabled, has at least one destination, covers the site, and names a kind of change the plan can route: the same test the alerts themselves go through. A rule limited to payment pages counts here, because payment pages are what the requirement is about.

A failed scan does not count. A scan that could not reach its page detected nothing, so the page’s last scan is its last complete one. A page whose scans have failed for a week reads as not scanned.

Every payment page counts. One page scanned this morning does not vouch for another whose scans have failed all week: the requirement is not met until each payment page has a complete scan in the last 7 days, and the page marks which ones have not.

Scans run daily on the Professional plan and above. The requirement asks for at least weekly; the page states both.

The changes in the last 30 days

Below the two statuses, the page lists every header change and grade drop the scans found on a payment page in the last 30 days, and whether an alert about it was delivered immediately. A change that reached someone only in a daily or weekly digest shows as No immediate alert: a digest’s delivery record covers everything it held, so it cannot show which change was in it.

The Not met state

With no payment page marked, both requirements are Not met and the page shows a Start here list instead of the evidence tables: mark the payment pages, let them be scanned, review each script, and add the alert rules. Each step says Available now or names the plan it needs. The first step names the busiest pages the site has reported from in the last 30 days, as candidates for payment pages.

The export

Each requirement exports as its own CSV file, dated, from the same data the page shows. The export is available once the site has a payment page.

6.4.3: one row per script reported from the payment pages, with the pages it ran on, its status, who decided and when, the justification, the integrity mode and its integrity state.
11.6.1: the watched payment pages with their last complete scan, the changes found in the last 30 days with whether each was alerted immediately, and the rules covering each kind of change.

The lines starting # above the header give the status, each gap and what the file cannot show. For the script inventory export on the Scripts page, see PCI Evidence From the Script Inventory.

To keep a copy of the page itself, print it from your browser.