A script list is where the evidence starts
If you have followed PCI DSS 6.4.3 and 11.6.1 for WooCommerce, you have an inventory of the scripts on your payment pages, a justification for each, and a weekly check. That answers "what runs on the page today".
An assessment asks about a period, not a day. The questions that follow the inventory are about operation over time, and they are the ones a spreadsheet or a one-off scan cannot answer:
- Who is alerted when something changes, and can you show an alert was ever delivered?
- When a script changed in March, who looked at it, what did they decide, and why?
- Did the check run every week of the period, or only the week before the assessment?
- If you check more or less often than weekly, where is the risk analysis that supports it?
- Could anyone have edited this record after the fact?
Dragon Checkout Guard Pro is built around those five questions. This guide walks through each one. Everything stays on your own server, and the free plugin keeps doing everything it did before.
Make the record tamper-evident
Pro writes every event to an append-only ledger: each check, each new or changed script, each authorisation, approval and acknowledgement, each alert sent, each saved risk analysis and each settings change. Every row is hashed onto the row before it, so an edited or deleted row breaks the chain from that point on.
The Evidence tab shows the verification result, and wp dragon-checkout-guard-pro verify does the same from the command line. The CSV export carries the stored payload of every row, so a reader who does not trust the site can recompute the chain without WordPress:
$prev = '';
foreach ( $rows as $row ) { // the exported CSV, in id order
$expected = hash( 'sha256', $prev . $row['id'] . $row['kind'] . $row['payload'] . $row['created_at'] );
if ( $expected !== $row['hash'] ) {
echo 'Row ' . $row['id'] . ' does not match' . PHP_EOL;
break;
}
$prev = $row['hash'];
}Export the ledger on a schedule and keep the files somewhere other than the site. The chain shows that the record was not altered. An off-site copy shows that it was not replaced.
Name an owner and show that alerts work
11.6.1 asks for a mechanism that alerts personnel. "An email goes somewhere" is a weak answer. A named person with a role is a strong one.
On the Alerts tab, set the alert owner once. That name and role are printed on every alert and in the evidence pack. Then choose channels: email, a signed webhook, or Slack. Choose which triggers matter: a new script, a changed script, changed headers, a failed check, a missed check, or an authorised script past its review date.
Press Send test alert after setting up each channel. The test and its outcome are written to the ledger, so the record shows a channel worked on a given date. Every later send is logged the same way, including the ones that failed and why.
If a busy day would flood the inbox, switch to the daily digest. In immediate mode, a burst is throttled to one message per trigger every 15 minutes, and anything held back is rolled into the next message and never dropped.
Review every change with a note
The Review tab collects new scripts, changed scripts and changed headers in one queue. Approving a changed script requires a reviewer note, and the approval records who made it and when. Acknowledge records that someone saw an item without changing its status, for the cases where the right answer is "known, being handled".
Most changes on a healthy store have a dull explanation: a plugin updated and shipped a new version of its script. Pro records plugin, theme and core updates. When a script changes within 24 hours of an update to the component that owns it, the queue says so and offers Approve as vendor update with the note prefilled. The reviewer still decides. They just start with the likely explanation in front of them.
A change with no matching update is the one that deserves a slow, careful look.
Choose a cadence and write down why
Weekly checks need no further justification. Anything else does: 11.6.1 allows a different frequency only when a targeted risk analysis under requirement 12.3.1 supports it.
The Monitoring tab offers weekly, daily, twice-daily and six-hourly checks, with a guided form for the analysis: the pages in scope, the threat, the factors you weighed, the frequency you chose, a written rationale, a reviewer and a review date. The factors are the ones that change the answer in practice: how many third-party scripts the page loads, how often they change, how many people can add tags, traffic volume and past incidents.
The 52-week coverage calendar on the same tab answers "did it run every week" at a glance. A check that does not run on time is recorded as a missed check and can raise its own alert, so a broken cron job shows up in days and not at the assessment.
Track provider confirmations
PCI SSC FAQ 1588 accepts written confirmation from your payment provider as one route to the SAQ A criterion. Requests like that get lost in support tickets. The Evidence tab keeps one row per provider: when you asked, when the answer arrived, its reference, the contact and when to review it. Providers found in your inventory are prefilled, and every update is written to the ledger.
Holding the confirmation and keeping your own page record are not alternatives you have to choose between. Many merchants keep both.
Hand over an evidence pack
From the Evidence tab, open a pack for the last 30, 90 or 365 days and print it to PDF. It covers the scope and SAQ route, the risk analysis, provider confirmations, the coverage calendar, the script inventory, the check record, every review decision with its reviewer and note, alert deliveries and tests, header baselines, and the ledger's integrity result. Generating a pack is itself written to the ledger.
Set a monthly or quarterly reminder and the alert owner gets a short summary with a link, which keeps the evidence habit alive between assessments. Add your SAQ due date for a reminder 30 days ahead.
The pack is evidence supporting your assessment. It does not certify anything, and it does not decide which SAQ applies to you.
For agencies
Add your own name and logo to the pack and it becomes a deliverable: a quarterly payment page report for each store you look after. The five-site and unlimited licences exist for this. WP-CLI covers verification, ledger export and on-demand checks, so the routine fits into whatever already runs your maintenance.
Common questions
Does anything leave the site? Only the alerts you configure, and licence and update checks to dragoncore.ltd. The ledger, the inventory and the pack stay in your database.
What happens if the licence lapses? Every feature keeps working on the sites where it is activated. New versions and support stop until you renew.
Can an administrator still tamper with the ledger? Anyone with database access can change a row. They cannot do it without breaking the chain, which is the point of hashing each row onto the last. Off-site exports close the remaining gap.
We already use Dragon Activity Log. Is this the same thing? No. Dragon Activity Log records who did what across the whole site. This ledger records the payment page evidence specifically, in the shape an assessor asks for. The free Checkout Guard plugin feeds the Activity Log as well, so the two agree.