The questionnaire is coming
Clients in regulated sectors, and increasingly any client with a procurement department, now send their suppliers a security questionnaire. For an agency that builds and hosts WordPress sites, the questions are always the same five: what software runs on our site, how do you know when it has a vulnerability, how fast do you patch, can you prove it, and what happens if there is an incident. The CRA checklist explains the obligations; this guide is the agency operating model for answering across many sites without drowning in it.
Step 1: monitoring without a token per site
The free Dragon Compliance checks a site's inventory against the Wordfence Intelligence vulnerability feed using a token from a free Wordfence account. Across thirty client sites that is thirty tokens to create, store and rotate. Dragon Compliance Pro removes the step: a licensed site downloads the same feed from Dragon Core, authenticated by its licence key and hostname, refreshed every few hours. The feed is served unmodified, copyright notices included, and nothing about the site's inventory is sent anywhere. If a licence lapses, the free plugin's own token takes over if there is one.
Install both plugins on each site, enter the licence, and the daily scan is running with no further configuration. Confirm it once from the Findings tab.
Step 2: route alerts to where you work
A finding that lands in a client site's admin email is a finding nobody at the agency sees. Under the Pro Alerts tab, send new findings to your own address, a Slack channel, or an HMAC-signed webhook into your ticketing system. Do this on every site, to the same place, so a critical vulnerability across the portfolio shows up as thirty messages in one channel rather than thirty unread admin emails.
Step 3: build the evidence you will be asked for
Four artefacts answer the questionnaire, and Pro keeps all of them current:
- SBOM snapshots. Every export is kept as a point-in-time inventory, and any two can be diffed to show exactly what changed between dates. Export CycloneDX for security teams and SPDX for the ones who ask for it.
- Tamper-evident evidence log. The free plugin's log of scans, detections, resolutions and attestations becomes a hash chain in Pro, each entry sealed against its predecessor, so a client's auditor can be told the history has not been edited.
- Time-to-patch. Computed from the findings history: how long a vulnerability stayed open on this site, as a median and as a list. This is the number that ends most conversations about patching policy.
- The NIS2 view. The checklist regrouped against NIS2 supply-chain expectations, for clients whose questionnaire is written in that vocabulary.
Step 4: the white-label report
The Reports tab produces a compliance report under your agency's branding: readiness score, inventory summary, open and resolved findings, time-to-patch, checklist status with attestations, and the evidence trail. Schedule it monthly to the client contact, and export it on demand when a questionnaire arrives.
The report is what the client forwards to their auditor. It should carry your name because you are the supplier being assessed, and it should carry a date and a period, because a report with neither is decoration.
Step 5: write the three policies once
The tooling produces evidence of what you do. The questionnaire also asks what you promise. Write, once, for all clients:
- A patch policy with severities and deadlines (critical within 24 hours, high within 7 days is a common shape). Attest it on each site's checklist so the attestation is logged.
- A vulnerability disclosure policy and security contact address.
- An incident response outline with the CRA's 24-hour, 72-hour and 14-day reporting steps and named owners.
Keep them as short documents in your own systems and paste the URLs into the checklist attestations.
Answering the questionnaire in an afternoon
With the above in place, the answers are: attached SBOM (snapshot from this week), monitoring enabled continuously with alerts to our team (screenshot of the Alerts tab), patch policy attached with measured time-to-patch (from the report), evidence log hash-verified (Integrity from the report), disclosure and incident policies attached. That is a complete, honest response, and most competing agencies cannot produce it.
Checklist
- Compliance and Pro installed and licensed on every client site
- Alerts from every site routed to one agency channel
- First SBOM snapshot exported on each site
- Monthly white-label report scheduled to each client
- Patch, disclosure and incident policies written and attested