Offboarding a Client Site Securely

Why offboarding deserves its own checklist

Almost everything written for agencies about client transitions covers taking a site on — what to audit before you sign anything. Almost nothing covers what happens when the relationship ends: a maintenance contract lapses, the client moves to a different agency, or the site gets handed back to the client's own team. That gap matters, because an offboarding that isn't done properly leaves a real security problem behind for both sides.

For the client, it means a site that's still reachable by a party with no ongoing relationship to it — no contract, no accountability, no reason to still be looking at it. For the agency, it's arguably worse: if anything goes wrong on that site later, a former agency with access still open is an obvious first place blame lands, whether it's fair or not. Neither side benefits from access that outlives the relationship it was granted for.

The access-revocation checklist

The mistake most offboardings make is stopping at the one obvious step — deleting the agency's named WordPress user — and treating that as done. In practice, a WordPress site accumulates access in far more places than the admin user list, and each one needs to be checked off individually:

• WordPress admin/user accounts. Remove every account tied to the agency — not just the primary one. Multi-person agencies often have two or three logins on a single client site by the time a contract ends.
• Hosting panel access. cPanel, Plesk, or the host's own dashboard — if the agency was ever given direct hosting-level access, it needs to be pulled separately from the WordPress login.
• DNS and CDN accounts. Cloudflare, the domain registrar, any CDN — these are commonly set up once during onboarding and then forgotten about entirely.
• Security-plugin and third-party API keys. Any API key the agency generated on the client's behalf — including the client's own SecurynAI or equivalent security-plugin connection — should be rotated or revoked, not left pointing at credentials the agency still effectively controls.
• Staging environment credentials. Staging sites are frequently forgotten in an offboarding because they're not the "real" site — but a staging environment with production-like data and a still-valid agency login is exactly the kind of loose end that gets missed.
• Alert and notification recipient lists. Remove agency email addresses from anywhere security alerts, uptime alerts, or backup notifications get sent — otherwise the agency keeps receiving signals about a site it's no longer responsible for, and worse, may start ignoring them since they're no longer relevant.

This is the same discipline security teams apply to employee offboarding generally: removing the one obvious account isn't enough on its own, because personal access tokens, API keys, and shared credentials set up along the way routinely outlive the account that created them unless someone deliberately goes looking for them.

Document what's being handed back

Once access is revoked, write it down — a short record of what was removed, from where, and on what date is enough. This isn't bureaucracy for its own sake; it's the thing that protects the agency if a dispute comes up later ("we thought you still had access" is a much easier conversation to have with a dated record in hand than without one). It's also worth getting the client's confirmation that they've taken ownership of what's been handed back, the same way a handover call ends with the client confirming they can log in before the agency actually walks away.

What the client should do next

Revoking the agency's account doesn't fully close the loop — a departing agency having once known a password is itself a residual risk, even after the account granting them that access is deleted. It's worth telling the client directly, as part of the handover, to rotate any shared passwords the agency had visibility into: the main WordPress admin password if it was ever shared directly (rather than via a separate account), hosting-panel credentials if those were shared rather than delegated, and anything else that wasn't strictly access-controlled per person. A clean offboarding is as much about what the client does in the days after as what the agency does on the way out.

Where this fits alongside onboarding

Treat this as the mirror image of the audit you'd run when taking a new client on — the same discipline, applied at the other end of the relationship. And if you're managing this across a real client roster rather than a one-off, the same tracking problem shows up at scale: see managing 30+ client sites without losing track for how to keep a growing list of access grants and revocations from becoming its own liability.