Scoping Security Audits Into Web Design Projects

Most web design proposals talk about responsive layouts, CMS training, and SEO basics. Very few mention security — until a client's contact form starts sending spam, their cookie banner fails a compliance check, or a penetration tester hired by their enterprise customer flags 14 missing headers. By then, the project is closed, the budget is spent, and someone has to eat the cost of fixing it.

Bundling a security audit into your project scope from day one solves this. It protects the client, protects you from out-of-scope rework, and turns security into a billable deliverable rather than a free emergency favour. Here's how to actually do it.

Why Security Belongs in the Initial Scope

When security shows up as a change request after launch, three things happen: the client questions why it wasn't included originally, you absorb the time, and the fix is more expensive because it touches code that's already in production. Scoping it in upfront flips all three.

• Clients pay for it knowingly — it's a line item, not a surprise.
• You catch issues during build — fixing a missing CSP before launch takes 30 minutes; fixing it after a customer complaint takes a day.
• You differentiate from cheaper competitors — most freelancers and template shops don't offer this at all.

What a Security Audit Deliverable Should Cover

Be specific in your scope document. "We will check security" is meaningless. Break it into named checks the client can understand and verify.

SSL and Transport

• Valid certificate with at least 30 days before expiry
• TLS 1.2 minimum, TLS 1.3 preferred
• HSTS header with a sensible max-age
• HTTP traffic redirects to HTTPS

HTTP Security Headers

• Content-Security-Policy tuned to the actual scripts in use
• X-Frame-Options or frame-ancestors directive
• X-Content-Type-Options: nosniff
• Referrer-Policy and Permissions-Policy

Cookies and Compliance

• Secure and HttpOnly flags on session cookies
• SameSite attribute set appropriately
• Cookie banner matches actual cookies dropped (a surprisingly common failure)

DNS and Email

• SPF, DKIM, and DMARC records for any domain that sends mail
• CAA records to restrict who can issue certificates
• No dangling subdomains pointing at decommissioned services

CORS and Application Behaviour

• CORS policy doesn't return Access-Control-Allow-Origin: * with credentials
• No sensitive data leaking through error pages or source maps
• Admin paths aren't indexed by search engines

Writing the Scope Language

Vague scope language is what gets you into trouble. Here's a tighter version you can adapt:

"Pre-launch security audit covering SSL configuration, HTTP security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy), cookie security flags, DNS records (SPF, DKIM, DMARC, CAA), and CORS configuration. Deliverable: a written report with a letter grade, list of findings ranked by severity, and remediation for all High and Medium findings before launch. Low findings will be listed with recommendations but remediation is out of scope."

Notice what this does: it names the checks, defines the deliverable, and explicitly carves out what isn't included. That last part stops scope creep.

Pricing It Realistically

A security audit isn't an hour of work, but it isn't a week either if you have the right tooling. Rough benchmarks for a brochure-style site or small CMS build:

• Automated scan and triage: 1–2 hours
• Remediation of headers, cookies, DNS: 2–4 hours
• Re-scan and written report: 1 hour

That's typically $400–$900 added to a project, depending on your rate. For larger applications with authentication, payments, or user-generated content, double or triple that and add a manual review pass.

Where to Slot It Into the Project Timeline

Don't leave the audit until the last week. By then, changing headers or CSP risks breaking third-party widgets the client just signed off on. A better sequence:

1. Discovery phase: ask the client about compliance requirements (PCI, HIPAA, their enterprise customers' security questionnaires).
2. Development phase: configure headers, cookies, and DNS as you build, not after.
3. Staging: run a full scan against the staging environment. Tools like WebSentry give you a graded report you can paste straight into a client update.
4. Pre-launch: re-scan, fix anything that regressed, and archive the report as part of the handover documentation.
5. Post-launch (optional retainer): monthly scans to catch certificate expiries, new vulnerabilities, or changes the client makes themselves.

Turning the Audit Into a Client-Friendly Report

Developers care about headers. Clients care about whether they'll get sued or hacked. Translate findings into business language:

• Instead of "Missing Strict-Transport-Security header" write "Browsers may downgrade visitors to insecure HTTP — fixing prevents man-in-the-middle attacks on public Wi-Fi."
• Instead of "SPF record is soft-fail" write "Spammers can impersonate your domain in emails — tightening this protects your sender reputation."

A graded summary on the front page (A through F) makes the report instantly readable for non-technical stakeholders. This is one of the reasons we built WebSentry to lead with a letter grade — clients understand "we went from D to A" far more easily than a list of header names.

Selling It to Reluctant Clients

Some clients will push back on adding $600 to a $5,000 project. A few angles that work:

• Insurance framing: compare it to the cost of a single breach notification or GDPR fine.
• Procurement framing: if they ever sell to enterprise, they'll be asked to fill out a security questionnaire. Having a recent audit answers half of it.
• Reputation framing: Chrome marking their site as "Not Secure" or Gmail dropping their emails into spam costs real revenue.

If they still refuse, list it as a recommended optional add-on in writing. That way, when something breaks six months later, the paper trail is clear.

Make It Repeatable

The first time you scope a security audit, it feels like extra work. By the third project, you'll have a template paragraph for proposals, a checklist for staging review, and a report format clients recognise. Build the muscle once and it pays out on every project after.

If you want to see what a security audit actually surfaces before you write it into your next proposal, run a free scan on your own portfolio site or a recent client build at websentry.dev — the grade and findings list will give you a concrete starting point for your scope document.