A security audit report is a deliverable that clients keep on file, share with their board, and use to justify remediation budgets. A poorly structured report — all technical findings, no context — fails to do its job. This guide covers what a client-ready security audit report should contain and how to produce one at scale.
Anay Pandya
1,850 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
A security audit without a good report is a tree falling in an empty forest. You found the issues. You know what needs to be fixed. But the client''s CTO needs to understand why it matters, their board needs to authorize the remediation budget, and their engineering team needs specific, actionable instructions. One report, three audiences, three different ways of processing the same information.
Getting the report right is not just a quality-of-service issue — it determines whether your findings get acted on or filed and forgotten.
Is your site actually secure?
Run a free check — 60 seconds
Keep reading
A complete security audit report has five sections. Each serves a different purpose and a different reader.
This section is written for the CEO, CTO, board member, or investor who will not read the rest of the report. It answers four questions:
Write this in non-technical language. Use percentages and comparisons ("your security score of 62 puts you in the bottom 25% of SaaS applications we''ve audited this quarter") rather than technical specifications.
Example executive summary opening:
We conducted a comprehensive security assessment of [client].com on May 2, 2026.
The assessment covered 80+ security checks across server configuration, transport
security, HTTP security headers, exposed sensitive content, and authentication patterns.
Overall Security Score: 64/100
Your application has 2 critical findings, 4 high-severity findings, and 9 medium-severity
findings. The critical findings represent immediate risks that could allow attackers to
intercept user data or expose sensitive backend information. We recommend addressing
these within 48 hours.Define what was tested and how. This section protects you legally and sets appropriate expectations:
Assessment Scope:
- Primary domain: client.com
- API subdomain: api.client.com
- Admin portal: admin.client.com (excluded per client request)
Testing methodology:
- Automated scanning using ZeriFlow security platform
- 80+ checks including: HTTP security headers, TLS configuration,
certificate validity, CORS policy, exposed sensitive files,
known CVE patterns in server software
- External scan only — no code access, no network-level access
- Scan date: May 2, 2026 at 09:14 UTC
Limitations:
- This assessment covers the application''s external attack surface as observed
by a standard internet client. It does not cover internal network security,
database configuration, authentication logic, or business logic vulnerabilities.This is the largest section and the most important for the engineering team. Structure findings in four tiers.
Critical findings — require immediate remediation (within 24-48 hours):
CRITICAL-001: TLS 1.0 and TLS 1.1 Enabled
─────────────────────────────────────────────
Severity: Critical
CVSS Score: 7.4
Affected: client.com, api.client.com
Description:
Your server accepts connections using TLS 1.0 and TLS 1.1, both of which were
deprecated in 2020 (RFC 8996). These versions are vulnerable to POODLE, BEAST,
and CRIME attacks, which allow an attacker in a network-adjacent position to
decrypt HTTPS traffic.
Business impact:
User session tokens, form submissions, and API credentials could be intercepted
on insecure networks (public Wi-Fi, corporate proxies).
Remediation:
Disable TLS 1.0 and TLS 1.1 in your server configuration. Enable TLS 1.3.
Nginx:
ssl_protocols TLSv1.2 TLSv1.3;
Apache:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Verification:
After applying the fix, run: nmap --script ssl-enum-ciphers -p 443 client.com
Confirm TLS 1.0 and 1.1 no longer appear in the output.
Estimated remediation time: 30 minutesHigh findings — resolve within 1-2 weeks:
HIGH-001: Missing HTTP Strict Transport Security (HSTS) Header
────────────────────────────────────────────────────────────────
Severity: High
Affected: client.com
Description:
Your application does not send the Strict-Transport-Security header, which means
browsers will continue to accept HTTP connections even when HTTPS is available.
This allows SSL stripping attacks where an attacker downgrades a connection
from HTTPS to HTTP.
Remediation:
Add the following header to all HTTPS responses:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Begin with a lower max-age (86400) to test, then increase to 31536000.
Submit to the HSTS preload list at https://hstspreload.org once stable.
Estimated remediation time: 1 hourUse this structure consistently for every finding. The engineering team should be able to implement every fix directly from the report without needing to ask you for clarification.
A single-page reference that the engineering team can use as a checklist:
| ID | Finding | Severity | Status | Assigned To | Due Date |
|---|---|---|---|---|---|
| CRIT-001 | TLS 1.0/1.1 enabled | Critical | Open | DevOps | 2026-05-04 |
| CRIT-002 | Exposed .env file | Critical | Open | DevOps | 2026-05-04 |
| HIGH-001 | Missing HSTS header | High | Open | DevOps | 2026-05-16 |
| HIGH-002 | CSP missing | High | Open | Frontend | 2026-05-16 |
| HIGH-003 | X-Frame-Options absent | High | Open | DevOps | 2026-05-16 |
| MED-001 | CORS overly permissive | Medium | Open | Backend | 2026-05-30 |
Leave the "Status" and "Assigned To" columns blank in the delivered report — the client fills these in during their remediation planning session.
End with clear next steps that include both immediate actions and longer-term guidance:
Immediate actions (this week):
1. Disable TLS 1.0 and 1.1 (30 minutes, DevOps)
2. Remove or restrict access to the exposed configuration file (15 minutes, DevOps)
3. Enable HSTS with max-age=86400 as a starting value (1 hour, DevOps)
Short term (next 30 days):
4. Implement Content Security Policy (4-8 hours, Frontend)
5. Audit CORS configuration on API endpoints (2-4 hours, Backend)
6. Enable security header defaults in your reverse proxy configuration
Long term (next quarter):
7. Set up continuous security monitoring to detect configuration drift
8. Integrate security scanning into your CI/CD pipeline
9. Schedule a follow-up assessment after major infrastructure changes
We recommend scheduling a follow-up scan in 30 days to verify remediation
and track your progress toward a target score of 85+.ZeriFlow''s Business plan includes white-label PDF report generation. Instead of delivering a report that says "Powered by ZeriFlow," you deliver a report on your agency''s letterhead with your logo, your color scheme, and your contact information.
Configuration in the ZeriFlow dashboard: 1. Navigate to Settings > White Label 2. Upload your agency logo (SVG or PNG, min 400px wide) 3. Set your primary brand color (used for severity indicators and accent elements) 4. Enter your company name, website, and contact details 5. Add a custom report footer (typically your disclaimer and certification language)
Once configured, every PDF you generate from ZeriFlow will carry your branding. The client never knows what tool produced the underlying scan — they see your agency''s professional report.
For agencies managing multiple clients, you can generate reports programmatically:
# Scan and immediately generate a white-label report
RESPONSE=$(curl -s \\
-X POST https://api.zeriflow.com/scan-quick \\
-H "X-API-Key: $ZERIFLOW_API_KEY" \\
-H "Content-Type: application/json" \\
-d ''{
"url": "https://client-site.com",
"generate_pdf": true,
"white_label": true,
"report_options": {
"include_executive_summary": true,
"include_remediation_steps": true,
"client_name": "Acme Corporation",
"assessor_name": "Your Agency Name"
}
}'')
PDF_URL=$(echo "$RESPONSE" | jq -r ''.report.pdf_url'')
# Download the report
curl -s "$PDF_URL" \\
-H "X-API-Key: $ZERIFLOW_API_KEY" \\
-o "acme-security-report-$(date +%Y%m%d).pdf"
echo "Report saved: acme-security-report-$(date +%Y%m%d).pdf"The PDF is not the end of the engagement — it is the beginning of the client conversation. Here is a delivery process that maximizes the chance your findings get acted on:
Step 1: Pre-delivery briefing (15 minutes)
Before sending the PDF, schedule a short call to preview the findings. The goal is to prevent the client from opening a report with "2 Critical Findings" without context and immediately panicking or dismissing it. Frame the findings: "We found two issues that need quick attention, both are fixable in under an hour. The rest are medium-priority improvements. Overall, you''re in a normal range for an application at your stage."
Step 2: Report delivery
Send the PDF with a covering email that summarizes the top three findings and explicitly states the recommended first action. Make it easy for the client to forward to their engineering team with all the context they need.
Subject: Security Assessment Report — Acme Corporation — Action Required
Hi [name],
Please find your security assessment report attached. Here is a summary:
Overall score: 64/100
Critical findings: 2 (require action within 48 hours)
High findings: 4 (resolve within 2 weeks)
Medium findings: 9 (address this quarter)
The two critical findings are:
1. TLS 1.0/1.1 enabled — ~30 minute fix for your DevOps team (instructions on page 7)
2. Exposed configuration file — ~15 minute fix (instructions on page 9)
I recommend sharing pages 6-12 with your engineering team directly.
Would you like to schedule a 30-minute walkthrough call this week?
[Your name]Step 3: Remediation walkthrough (optional, billable)
For clients who want help prioritizing, offer a 60-90 minute remediation planning call where you walk through each finding, help them assign owners, and set realistic deadlines. This is a natural upsell for agencies who do not want to limit their engagement to a single scan.
Step 4: Follow-up scan (30 days later)
Run a second scan 30 days after delivery. Compare the before and after scores. Present a one-page "progress report" showing which findings were resolved and the new score. This is both a client success demonstration and a natural entry point for selling ongoing monitoring.
If you are delivering security audits to multiple clients monthly, systematize the process:
#!/bin/bash
# batch-scan-clients.sh
# Scans all clients in clients.json and generates PDF reports
CLIENTS_FILE="clients.json"
while IFS= read -r client; do
NAME=$(echo "$client" | jq -r ''.name'')
URL=$(echo "$client" | jq -r ''.url'')
EMAIL=$(echo "$client" | jq -r ''.contact_email'')
echo "Scanning $NAME ($URL)..."
RESULT=$(curl -s \\
-X POST https://api.zeriflow.com/scan-quick \\
-H "X-API-Key: $ZERIFLOW_API_KEY" \\
-H "Content-Type: application/json" \\
-d "{\\"url\\": \\"$URL\\", \\"generate_pdf\\": true, \\"white_label\\": true, \\"report_options\\": {\\"client_name\\": \\"$NAME\\"}}")
SCORE=$(echo "$RESULT" | jq -r ''.score'')
PDF_URL=$(echo "$RESULT" | jq -r ''.report.pdf_url'')
echo "$NAME: $SCORE/100 — Report: $PDF_URL"
# Log to CSV for tracking
echo "$(date +%Y-%m-%d),$NAME,$URL,$SCORE,$PDF_URL" >> scan-log.csv
done < <(jq -c ''.[]'' "$CLIENTS_FILE")Where clients.json follows the format:
[
{"name": "Acme Corp", "url": "https://acmecorp.com", "contact_email": "cto@acmecorp.com"},
{"name": "Beta Inc", "url": "https://betainc.com", "contact_email": "engineering@betainc.com"}
]A great security audit report is structured, actionable, and written for multiple audiences simultaneously. The executive summary justifies the remediation investment. The technical detail enables engineers to fix issues without additional research. The summary table becomes a project management artifact.
White-label PDF generation makes this scalable for agencies — one scan, one generated report, your branding on the cover.
ZeriFlow Business plan includes white-label reports, 100 API calls per month, and the monitoring features needed to sell ongoing security-as-a-service to your clients.
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
April 9, 2026
How to Automate Website Security Scans with a REST API
Monitor your security score
Schedule recurring scans and catch regressions after deployments.