Website Security for Agencies: What You're Liable For When a Client Site Gets Hacked

Picture the call. A client's website — the one your agency designed and built two years ago — is showing a defacement, or pushing malware, or their customer list has turned up for sale. They're panicking, and the first person they call is you. Website security for agencies stops being abstract the moment that call comes in, and the question that follows is the one most agencies have never actually answered: when a client's site gets hacked, who is liable?

The honest answer is "it depends" — and what it depends on is almost entirely decided before anything goes wrong, in your contract and your architecture. Here's how to think about it. (This is practical guidance, not legal advice — your contracts and your jurisdiction ultimately govern, so talk to a lawyer about your specific agreements.)

Where agency liability actually comes from

You'd think "we just designed it" is a clean defense. Often it isn't. Liability tends to come from four places:

• What your contract promised. If your agreement mentions "security," "maintenance," "updates," or "support" without carefully scoping them, a client can reasonably argue you owned keeping the site safe. Vague scope cuts against whoever wrote it.
• What you didn't say. Silence isn't protection. If you built the site, handed it over, and never made clear in writing that ongoing security was the client's responsibility, the client's assumption — "the experts are handling it" — can become the default expectation a dispute is judged against.
• Negligence. Even without a specific promise, shipping something a competent professional wouldn't have (no HTTPS, a known‑vulnerable plugin, default admin credentials) can expose you. The standard is "reasonable professional care," and you're the professional.
• Data‑breach law. If real personal data was exposed — the client's customers' data — privacy regulations and breach‑notification rules enter the picture, and everyone who touched the system can be pulled into the question of who was responsible for protecting it.

None of this means you're automatically at fault. It means the fault is decided by documents and decisions you control — if you make them deliberately.

How client sites actually get hacked

To manage the risk you have to know the risk surface. The overwhelming majority of small‑ and mid‑business site compromises come from a short, boring list:

• Unpatched CMS, plugins, and themes. This is the number‑one vector by a wide margin. A WordPress site with a stack of plugins is a stack of independently‑maintained code, any one of which can ship a critical vulnerability — and an unattended site never gets the patch.
• Weak, reused, or shared credentials, and no MFA. One phished or reused admin password and it's over. Most breached sites had no multi‑factor authentication.
• An outdated server or runtime. An unsupported PHP or .NET version stops getting security patches while staying happily online — inheriting every new vulnerability, indefinitely.
• Missing HTTPS or misconfiguration. No TLS, permissive settings, exposed admin panels, secrets in the wrong place.
• Vulnerable third‑party scripts. Every embedded widget and tag is code you don't control running on your client's domain.
• No backups. Not a breach vector, but the difference between "restored in an hour" and "the site and its content are gone."

The gap that creates the dispute

Here's the trap most agencies fall into: you build a great site, hand it over, and move on — while the client quietly assumes that "the people who built it" are keeping it secure. Neither side is maintaining it. Months later a known plugin vulnerability gets exploited, and now you're arguing about who was supposed to have applied an update that shipped last spring. That gap — between what you delivered and what the client assumed — is where the liability and the ruined relationship live. Closing it is mostly a matter of being explicit, in two places: the contract and the architecture.

Protecting your agency — contractually

• Scope security and maintenance explicitly. State plainly who owns updates, patching, hosting, backups, and monitoring after launch. If it's not you, say so in writing. If it is you, price it.
• Offer a maintenance/security plan — and turn the liability into revenue. The cleanest way to remove the ambiguity is to own ongoing security as a paid retainer. It protects the client, protects you, and converts a scary open‑ended risk into predictable recurring margin.
• Set out incident responsibilities. If something does happen, a pre‑agreed plan — who investigates, who notifies, who pays for what — beats improvising at 2am.
• Carry the right insurance. Professional liability / errors‑and‑omissions and cyber coverage exist precisely for this. Check that yours actually covers client‑site incidents.

Protecting your clients — technically

Every client site, regardless of who ends up owning maintenance, should have a baseline:

• Managed updates. A real cadence for patching core, plugins, themes, and the runtime — not "whenever someone remembers."
• MFA and least privilege. Multi‑factor on every admin account, and no more access than each person needs.
• HTTPS, security headers, and a WAF. Encrypt everything, set the headers that close off whole classes of attack, and put a web application firewall in front.
• Monitoring and backups you've actually tested. Know when something changes, and be able to restore — a backup you've never restored from is a guess.

There's also an architectural lever, and it's a big one: reduce the attack surface in the first place. A dynamic, plugin‑heavy CMS is a large, always‑changing target — a server, a database, and dozens of third‑party extensions, all needing patches. A static or headless architecture serves pre‑built files from a CDN with almost no server‑side surface to exploit: no live database to breach, no plugin soup to keep patched. For the right client sites, choosing the architecture is the single most effective security decision you can make — and it's a core reason we build the way we do.

Turn security from a liability into an offering

Most agencies treat security as a risk to be disclaimed. The agencies that do best treat it as a service to be sold. You don't need to hire a security team or a maintenance department to do that — a white‑label development partner can handle the patching, monitoring, hardening, and incident response behind your brand, so you can offer "ongoing security & maintenance" as a confident line item instead of a nervous footnote. Your clients stay protected, your exposure drops, and a recurring revenue stream replaces an open‑ended liability.

The worst time to work out who's responsible for a client's website is while it's on fire. Sort it out now — in the contract and in the architecture — and the 2am call becomes a controlled process instead of a crisis (and an argument about the bill).