How to Create a Website Vulnerability Report for Clients

If you run a web agency or work as a freelance developer, sooner or later a client will ask: "Is our website secure?" A vague "yes" won't cut it. What they actually want is a website vulnerability report — a document that explains what's wrong, what's at risk, and what you'll do about it.

Done well, a vulnerability report becomes a sales tool, a retention tool, and a justification for ongoing maintenance retainers. Done poorly, it confuses clients and erodes trust. Here's how to build reports that actually move the needle.

What a Client Vulnerability Report Should Contain

Most developers make the mistake of dumping raw scanner output into a PDF and calling it a report. Clients don't read CVE numbers. They read risk, cost, and next steps.

A strong report has six core sections:

1. Executive summary — One page, plain English, with an overall grade.
2. Scope and methodology — What was tested, what wasn't, and how.
3. Findings by severity — Critical, High, Medium, Low, Informational.
4. Technical detail per finding — Evidence, impact, and reproduction steps.
5. Remediation plan — Prioritised, with effort estimates.
6. Appendix — Raw scan data, headers, certificate details.

Step 1: Run a Baseline Scan

Before you can report on anything, you need data. A solid baseline covers the externally visible attack surface:

• SSL/TLS configuration — protocol versions, cipher suites, certificate validity and chain.
• HTTP security headers — HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• Content Security Policy — presence, strictness, unsafe-inline/unsafe-eval usage.
• Cookie flags — Secure, HttpOnly, SameSite.
• DNS hygiene — SPF, DKIM, DMARC, CAA records.
• CORS policy — wildcard origins, credential exposure.
• Information disclosure — server banners, exposed .git directories, verbose error pages.

Tools like WebSentry automate this entire baseline and return a single A–F grade plus per-category breakdowns, which maps neatly onto an executive summary.

Step 2: Translate Findings Into Client Language

This is where most reports fail. A line like Strict-Transport-Security header missing means nothing to a marketing director. Rewrite it.

Bad finding

HSTS header not present. max-age not set. includeSubDomains missing.

Good finding

Issue: Browsers can be tricked into loading your site over insecure HTTP, even after a user has visited the secure version.
Risk: An attacker on a public Wi-Fi network could intercept login credentials or payment details.
Fix: Add the Strict-Transport-Security header with a one-year max-age. Estimated effort: 15 minutes.
Severity: High

Same finding. Completely different impact on the reader.

Step 3: Use a Severity Model the Client Understands

Don't invent your own scoring. Use a simplified version of CVSS or stick to a five-tier model:

• Critical — Active exploitation possible, data loss likely. Fix this week.
• High — Realistic attack path with significant impact. Fix this month.
• Medium — Contributes to a larger attack chain. Fix this quarter.
• Low — Hardening opportunity. Fix when convenient.
• Informational — Best-practice notes, no immediate risk.

Pair every severity rating with a recommended timeline. Clients respond to deadlines far more than abstract risk levels.

Step 4: Show Evidence, Not Just Claims

For every High and Critical finding, include reproduction evidence. This protects you legally and stops clients from disputing the result.

Examples of solid evidence:

• Screenshot of the HTTP response headers showing the missing or misconfigured directive.
• The exact curl command and its output.
• The certificate chain output from openssl s_client.
• A redacted screenshot of an exposed admin panel or directory listing.

Format technical evidence in monospaced blocks so it stands out from the narrative text.

Step 5: Build a Remediation Roadmap

Findings without fixes are just complaints. Every report should end with a prioritised action list that the client can either approve as a quote or hand to their internal team.

Structure it as a table-style list:

1. Enable HSTS — 15 min — $50 — High priority
2. Implement Content Security Policy — 4 hours — $600 — High priority
3. Add SameSite=Lax to session cookies — 30 min — $75 — Medium priority
4. Configure DMARC with p=quarantine — 2 hours — $300 — Medium priority
5. Remove server version banner — 15 min — $50 — Low priority

This format converts directly into a statement of work. Clients can tick boxes and approve. You've just sold security work without writing a separate proposal.

Step 6: Schedule Recurring Reports

A one-off vulnerability report is useful. A monthly or quarterly report is a retainer. Security drifts: dependencies update, certificates expire, new headers become best practice, marketing teams add third-party scripts that break your CSP.

Set up recurring scans and deliver a short delta report each month showing:

• Current grade vs last month's grade
• New findings introduced
• Findings resolved
• Items still outstanding from previous reports

WebSentry's scheduled scans make this almost automatic — you re-run the scan, export the results, and wrap them in a one-page commentary. Agencies typically charge $150–$500 per month per site for this service.

Common Mistakes to Avoid

• Padding the report with informational findings to look thorough. Clients see through this and stop trusting your severity ratings.
• Reporting on things you didn't actually test — never claim a clean bill of health for areas outside scope.
• Using fear-based language — "hackers will destroy your business" reads as a sales pitch, not a technical assessment.
• Forgetting to date-stamp the report — security findings are time-sensitive. Include the scan date, the report date, and the tool versions used.
• Skipping the executive summary — decision-makers rarely read past page one.

A Quick Template You Can Steal

Here's a skeleton you can adapt for any client:

• Page 1: Client name, scan date, overall grade, top three risks, recommended next steps.
• Page 2: Methodology and scope.
• Pages 3–N: One finding per page or section, using the Issue / Risk / Fix / Severity format.
• Final page: Remediation roadmap with effort and cost.
• Appendix: Raw scan output for technical readers.

Want a head start? Run a free scan at websentry.dev — you'll get an A–F grade and categorised findings you can paste straight into the template above and have a client-ready vulnerability report on your desk in under an hour.