When to Fire a Client Over Security Risk

Where this actually comes up

Most maintenance relationships never reach this point. But a specific, recognizable pattern shows up often enough across agencies that it's worth naming directly: a client whose own decisions keep widening the gap between what the agency can control and what it's implicitly still on the hook for.

It rarely arrives as one dramatic incident. More often it's a client who reuses the same weak password across every service you've flagged, repeatedly, despite the warning. Or a client who demands you disable a WAF rule, turn off two-factor authentication, or skip an update because it's "getting in the way" of something they're doing — and expects you to comply without pushback, since you're "just the developer." Or a client who stops paying for the basic maintenance plan that was keeping the site patched, while still expecting the agency to answer the phone if something goes wrong.

None of these are catastrophic on their own. What makes them worth taking seriously is the direction they point: less and less actual control for the agency, while the client's — and often the public's — assumption of who's responsible stays exactly the same.

Why this is the agency's risk too, not just the client's

It's tempting to think of a client's bad security decisions as their problem — it's their site, their call. In practice, it doesn't stay that way cleanly. If a site the agency's name is attached to gets compromised because a client insisted on disabling a control the agency recommended keeping, the agency can still absorb real reputational damage, and depending on how the contract is written, real liability exposure too. "The client told us to turn it off" is a defensible position, but only if there's actually a record of that conversation — and only if the agency hasn't quietly kept charging for services it can no longer meaningfully deliver.

This is the same underlying idea behind pricing incident response as its own distinct product rather than absorbing it silently into routine maintenance — see should your agency offer an incident-response retainer — and behind being honest with clients about what a hack cleanup actually costs. Risk that isn't priced or scoped explicitly doesn't disappear. It just sits quietly on the agency's side of the ledger until something forces it into view.

Before it gets to firing: document the decision

Firing a client is the last step, not the first response to a disagreement. Long before that point, the useful habit is making sure every meaningful security recommendation — and every time a client explicitly declines one — exists somewhere in writing, not just in a phone call or a Slack message that scrolls away.

• Put the recommendation in writing first. An email, a note in the same kind of report described in the client security report they'll actually read, or a dedicated risk memo — the format matters less than the fact that it exists and has a date on it.
• Get the decline in writing too. If a client says no to a recommendation, a short confirming reply — "Understood, we'll leave X disabled per your instruction" — turns a verbal disagreement into a documented decision with a clear owner.
• Revisit it periodically, not just once. A client's circumstances change. A recommendation declined a year ago is worth raising again, especially after any relevant incident elsewhere becomes public knowledge.

This isn't about building a paper trail to use against a client. It's about making sure that if something does go wrong, the record reflects who actually made which call — protecting the agency and giving the client an honest account of their own decisions, rather than a dispute over memory.

When documentation isn't enough

Sometimes the pattern doesn't resolve itself. A client keeps declining the same basic recommendations, keeps demanding controls stay off, or keeps falling behind on payment for work the agency is still nominally responsible for — and the gap between stated responsibility and actual control keeps widening rather than closing. At that point, the honest conversation isn't about convincing the client to change their mind again. It's about deciding whether the agency can keep its name attached to that site at all.

This isn't a decision to make in the heat of a single bad interaction. It's a decision that becomes obvious in hindsight, looking at a documented pattern rather than one incident — which is exactly why the paper trail from the section above matters before you're standing in this position.

Ending it safely

When it does come to this, the mechanics are the same discipline already worth having for any offboarding, just with a harder conversation attached. See offboarding a client site securely for the actual access-revocation checklist — removing admin accounts, revoking API keys and third-party connections, pulling the agency off any alert or notification lists — none of that changes just because the relationship ended over a disagreement rather than a natural conclusion.

The framing of the conversation itself matters too. State the reason plainly and professionally — a specific, ongoing security risk that the agency is no longer willing to be responsible for — without turning it into a personal or adversarial exchange. A termination handled badly can create its own dispute, on top of whatever prompted it in the first place. Giving reasonable notice, a clear final invoice, and a straightforward handoff of what the client needs to continue elsewhere keeps the door closed cleanly, rather than leaving a mess that outlasts the relationship itself.