The Agency Website Security Audit Process: A Practical Guide

If you run a web agency or manage client sites, security audits aren't optional anymore. Clients expect them, regulators increasingly require them, and a single missed misconfiguration can mean a defaced homepage, a leaked database, or a Google Safe Browsing warning that tanks traffic overnight.

The problem is that most agencies don't have a repeatable agency website security audit process. Audits happen ad-hoc, findings get lost in Slack, and nothing actually changes between projects. This guide walks through a practical, repeatable process you can use on every client site — from discovery to remediation to reporting.

Why Agencies Need a Repeatable Audit Process

One-off security checks don't scale. When you're managing 20, 50, or 200 client sites, you need a process that:

• Produces consistent results across every site you audit
• Can be delegated to junior team members without losing quality
• Generates client-ready reports without hours of manual formatting
• Catches regressions when sites are updated or migrated

A good audit process is essentially a checklist plus a toolchain plus a reporting template. Let's build all three.

The 7-Stage Agency Security Audit Process

Stage 1: Scope and Discovery

Before you scan anything, agree on scope in writing. Audits without scope turn into endless rabbit holes.

1. List every domain and subdomain in scope. Use crt.sh or subfinder to enumerate subdomains the client may have forgotten about.
2. Identify the tech stack: CMS, hosting, CDN, third-party scripts, payment processors.
3. Confirm authentication: are you testing the public site only, or authenticated areas too?
4. Get written permission for any active testing. Passive scans are usually fine; intrusive testing needs sign-off.

Stage 2: Transport Security (SSL/TLS)

Start with the basics. A surprising number of production sites still have weak TLS configurations.

• Check certificate validity, expiry date, and chain completeness
• Verify TLS 1.2 minimum (TLS 1.3 preferred); disable SSLv3, TLS 1.0, and TLS 1.1
• Check for weak ciphers (RC4, 3DES, CBC-mode issues)
• Confirm HSTS is set with a sensible max-age (at least 6 months) and includeSubDomains where appropriate
• Look for mixed content — HTTPS pages loading HTTP assets

Tools like SSL Labs, testssl.sh, and WebSentry all surface these issues quickly. WebSentry rolls TLS into a graded report alongside everything else, which saves cross-referencing multiple tools.

Stage 3: HTTP Security Headers

Headers are the cheapest security wins on the web. They take minutes to configure and block entire classes of attack.

Check for and validate:

• Strict-Transport-Security — forces HTTPS
• Content-Security-Policy — controls which scripts and resources can load
• X-Content-Type-Options: nosniff — prevents MIME-type confusion
• X-Frame-Options or CSP frame-ancestors — prevents clickjacking
• Referrer-Policy — controls referrer leakage
• Permissions-Policy — restricts browser feature access

Stage 4: Content Security Policy Deep-Dive

CSP deserves its own stage because it's the header agencies get wrong most often.

Common CSP issues to flag:

• 'unsafe-inline' or 'unsafe-eval' in script-src — these defeat most of CSP's value
• Wildcard sources like * or https: in script-src
• Missing frame-ancestors — leaves clickjacking protection incomplete
• No report-uri or report-to — you can't fix what you can't see

For agencies, the practical advice is: deploy CSP in Content-Security-Policy-Report-Only mode first, collect violations for two weeks, then move to enforcement.

Stage 5: Cookies and Session Security

Audit every cookie the site sets. For each one, confirm:

• Secure flag is set (HTTPS-only)
• HttpOnly is set on session cookies
• SameSite is Lax or Strict (never None without Secure)
• Expiry is reasonable — long-lived session cookies are a red flag
• No sensitive data is stored in cookie values directly

Stage 6: DNS and Email Authentication

DNS is often overlooked in website audits but it's where domain takeovers and email spoofing start.

• SPF — published, no +all, ideally -all
• DKIM — keys 2048-bit, rotated periodically
• DMARC — at minimum p=quarantine, with rua reporting
• CAA records — restrict which CAs can issue certificates
• Dangling DNS — CNAMEs pointing to deprovisioned services (classic subdomain takeover vector)

Stage 7: CORS and Application-Level Checks

Finally, check application-level configurations:

• CORS: no Access-Control-Allow-Origin: * with Allow-Credentials: true; no reflective origins
• Exposed admin paths: /wp-admin, /.git, /.env, /phpinfo.php
• Outdated software fingerprints: CMS version disclosure, old jQuery, vulnerable plugins
• Open redirects in login or auth flows

Building Your Audit Toolchain

You don't need expensive enterprise tools. A solid agency stack looks like:

• Automated scanning: WebSentry for graded reports across SSL, headers, CSP, cookies, DNS, and CORS in one pass
• Manual deep-dive: Burp Suite Community or OWASP ZAP for application testing
• DNS: dig, dnsrecon, MXToolbox
• Vulnerability scanning: Nuclei with public templates
• Reporting: a templated Notion or Google Doc with severity ratings

Turning Findings Into a Client Report

This is where most agencies lose value. A 40-page raw scan output isn't a report — it's homework. Structure findings like this:

1. Executive summary with an overall grade (A–F) and top three risks in plain English
2. Findings table with severity (Critical/High/Medium/Low), affected URL, and a one-line description
3. Detailed remediation for each finding — exact header values, config snippets, or code changes
4. Re-test plan — when you'll verify the fixes

Tools like WebSentry produce a letter grade out of the box, which makes executive summaries trivial: clients immediately understand whether their site is a B or a D, even if they don't know what HSTS is.

Making Audits Recurring, Not One-Off

The biggest leverage point is making audits recurring. Sell quarterly or monthly retests as a retainer. Sites change — new plugins, marketing scripts, redirects — and so does their security posture. A site that scored an A in January can easily slip to a C by June.

Set up monitoring so you're alerted when grades drop, certificates near expiry, or new headers go missing. That turns a one-time audit into ongoing managed security — and a recurring revenue line for your agency.

Conclusion

A repeatable agency security audit process — scope, TLS, headers, CSP, cookies, DNS, CORS, reporting — is the difference between selling one-off audits and offering ongoing security as a service. Start with the seven stages above, codify them into a checklist, and run every client site through the same flow.

If you want a fast starting point, run a free scan at websentry.dev. You'll get an A–F grade across SSL, headers, CSP, cookies, DNS, and CORS in under a minute — a solid foundation for any client audit.