What Belongs in a Security Posture Report for Managed Hosting Clients

Managed hosting providers sit in an awkward spot. Clients assume you're handling security because you're handling the server, but most hosting agreements stop at the OS and runtime. The application, headers, TLS configuration, DNS records, and third-party scripts are usually outside scope — yet they're exactly where breaches happen.

A monthly security posture report fixes that mismatch. It tells clients what you're protecting, what they own, and what's drifting. Done well, it justifies your retainer. Done badly, it's a PDF nobody reads.

Here's what actually belongs in a security posture report for managed hosting providers, with specific checks, thresholds, and reporting structures that hold up to client scrutiny.

Why generic uptime reports aren't enough

Most managed hosts send clients an uptime percentage and a backup confirmation. That's operational reporting, not security reporting. It says nothing about:

• Whether the site's TLS certificate is using a deprecated cipher suite
• Whether Content-Security-Policy is missing or set to unsafe-inline
• Whether cookies are flagged HttpOnly and Secure
• Whether DNS records like CAA, DMARC, or SPF are configured
• Whether a recently added marketing tag introduced a cross-origin risk

Clients who get breached rarely get breached through the server you patched. They get breached through a misconfigured header on a page their marketing team launched last Tuesday. A posture report makes that visible.

The seven categories every report should cover

1. TLS and certificate health

Don't just confirm the cert is valid. Report on:

• Days until expiry (flag anything under 30)
• TLS versions enabled (TLS 1.0/1.1 should be off)
• Cipher suite strength and forward secrecy
• HSTS presence, max-age value, and includeSubDomains
• Certificate chain completeness

2. HTTP security headers

List each header with current value and recommended value. The non-negotiables:

• Strict-Transport-Security
• Content-Security-Policy
• X-Content-Type-Options: nosniff
• X-Frame-Options or CSP frame-ancestors
• Referrer-Policy
• Permissions-Policy

3. Content Security Policy breakdown

CSP deserves its own section because it's where most reports either lie or skip. A real CSP review checks:

• Presence of unsafe-inline or unsafe-eval
• Wildcard sources like *.googleapis.com vs pinned origins
• Whether nonce or hash is used for inline scripts
• Report-only vs enforcing mode
• Whether frame-ancestors and base-uri are set

4. Cookie configuration

Pull every cookie set on the homepage and a logged-in page. Flag any missing Secure, HttpOnly, or SameSite attributes. Session cookies missing HttpOnly are a finding, not a footnote.

5. DNS and email security

Often skipped by hosts who only manage the web layer, but clients expect coverage:

• SPF record present, no more than 10 DNS lookups
• DKIM selectors active
• DMARC policy at p=quarantine or p=reject
• CAA records restricting which CAs can issue certs
• DNSSEC status

6. CORS and exposed endpoints

Check the Access-Control-Allow-Origin on API endpoints. A response of * alongside Access-Control-Allow-Credentials: true is a critical finding. Also check for exposed .env, .git, wp-config.php.bak, and admin panels indexed by search engines.

7. Software and dependency drift

For WordPress, Laravel, or Node-based stacks: CMS version, plugin versions with known CVEs, PHP version, and Node version against EOL dates.

Structuring the report so clients actually read it

A report nobody opens is worse than no report at all. Use this structure:

1. Grade or score at the top. A single letter (A–F) or score out of 100. Executives skim; give them something to react to.
2. Change since last report. Did the grade move? Which checks regressed?
3. Critical findings. Maximum five items. If everything is critical, nothing is.
4. Remediation owner. Mark each finding as "Host action", "Client action", or "Joint". This single column prevents 80% of the "why didn't you fix this" conversations.
5. Detailed findings. Full list with evidence (response headers, screenshots, curl output).
6. Trend chart. Score over the last six months. Clients love a line going up.

Automating the data collection

Manually checking 30 sites a month doesn't scale. The reports that survive past month three are the ones built on automated scans. A practical workflow:

1. Run an automated scanner against each client domain on a schedule (weekly is plenty).
2. Store the raw JSON results in object storage so you can diff between runs.
3. Generate a templated PDF or HTML report from the latest scan.
4. Auto-flag regressions and send an internal alert before the client report goes out — you want to fix or explain issues, not be surprised by them.

Tools like WebSentry give you the A–F grading and category breakdowns out of the box, which means you can skip building a scanner from scratch and focus on the client-facing layer. The API output slots into whatever reporting template you already use for uptime and backups.

Pricing the service

Security posture reporting is usually sold one of three ways:

• Bundled into the managed plan — adds perceived value but no margin. Works if you're trying to reduce churn.
• Tiered add-on — $25–$75 per site per month for monthly reports, remediation guidance, and a quarterly review call.
• Project-based audits — $500–$2,500 for a one-time deep audit, often a gateway to the recurring tier.

The recurring add-on is where the margin lives. Once the automation is in place, each additional client costs you minutes, not hours.

Common mistakes to avoid

• Reporting on findings you can't fix. If the client owns the CMS and you only own the server, say so. Don't report a CSP issue without flagging it as a client action.
• Grading too harshly. A site with an F grade and no path to A in 30 days demoralises clients. Show the realistic ceiling for their stack.
• Ignoring false positives. A scanner flagging X-Frame-Options missing on a site that uses frame-ancestors in CSP looks unprofessional. Tune your rules.
• Sending the same template to every client. An e-commerce site cares about PCI-adjacent findings; a brochure site cares about defacement risk. Frame the same data differently.

If you want to see what a posture grade looks like before building this into your service, run a free scan against any client domain at websentry.dev and use the output as the skeleton for your first report.