Glarion

Website security report template for client sites

A security report is read by someone who has to decide what to pay for and what to do first. This template gives you the sections in the order that person needs them, with the wording to fill in. Use it by hand, or let Glarion fill the findings from checks on sites you have verified. It describes an automated external audit, not a penetration test.

Decision firstThe client reads the summary and the priorities. The rest is for their developer.
Evidence for every claimWhat was requested, when, and what came back.
An owner for every fixA finding without an owner and a date is a note, not a plan.

The eight sections

  1. Cover and scope. Client, site address, scan date, who ran it and which checks. Say plainly that it covers what an outside visitor can observe.
  2. Summary in plain language. Three to five sentences: the overall picture, the one or two things to do first, and whether anything affects availability or customer data.
  3. Findings table. One row per finding: title, affected address, priority, status. Keep it to a single page so it can be read in a meeting.
  4. Detail per finding. What was observed, the evidence, the practical impact, the recommended fix and how confident the check is.
  5. Fix plan. Who does what, by when. Mark what the agency will change and what the client’s host or developer must change.
  6. Limits of the assessment. What was not tested: logged-in areas, business logic, source code, anything outside the verified domains.
  7. Retest notes. The date of the next scan and what will be compared with this one.
  8. Appendix. Raw evidence for the technical team: response headers, certificate details, DNS records.

One finding, written out

Finding: The site does not tell browsers to always use HTTPS.
Affected: www.example.com
Evidence: A request to https://www.example.com/ on 4 November 2026 returned no Strict-Transport-Security header.
Impact: A visitor who types the address without https:// can be sent over an unencrypted connection first, where a network attacker could interfere with the redirect.
Recommended fix: Send Strict-Transport-Security on every HTTPS response, starting with a short max-age and raising it once nothing breaks.
Priority: Schedule next.
Confidence: High, a direct observation of the response.

The example site and date are made up to show the shape. The complete sample report uses the same structure for a whole fictional client, and the security headers guide explains each header.

Use priorities the client can act on

A severity badge says how bad something could be. A priority says what to do. Four words are enough:

  • Fix now. Exposed and easy to abuse, or it threatens availability or customer data.
  • Schedule next. Real but not urgent; it goes into the next maintenance window.
  • Verify manually. The automated check cannot be sure; a person should look.
  • Accept with a reason. The client chooses to leave it, and the reason is written down.

Before you send it

  • Remove anything secret. A report should never contain passwords, tokens or personal data, even if a check happened to see them; say where they were seen instead.
  • Send it as a link or through a channel the client trusts, not as an open email attachment passed around.
  • Keep the date and scope on every page, because reports get forwarded without their cover.
  • Do not call it a penetration test or a certificate. It records what was observed on one day.

Where Glarion fits

The free public check reads the TLS certificate, security headers, SPF and DMARC records, cookie flags and public policy files with no account. See what it covers. For full scans, verify domain control with a DNS TXT record or a hosted file; Glarion then runs detection-only checks on a schedule and builds the report under your agency’s name. Glarion does not apply fixes, and a finding stays a finding until someone fixes it and the next scan shows it gone.

Run the free checkOpen the sample report

Read next