WordPress Security Checklist for Agencies

Why agencies are a target

Agencies hold the keys to many sites. One weak password, one shared login or one infected laptop can expose every client at once, and clients hold the agency responsible, whatever the contract says.

Security that depends on remembering is fragile. The goal of this checklist is to turn good habits into defaults.

A WordPress security checklist for agencies: the baseline

Write down the standard configuration every client site gets, and apply it on every build. Treat exceptions as decisions you record, not accidents.

• Current WordPress core and a supported PHP version.
• A short approved plugin list, with a rule for adding to it.
• Two-factor sign-in for every administrator and editor.
• Lockouts, a generic login error and the login page hidden or restricted.
• XML-RPC, the code editors and user enumeration switched off unless needed.
• Security headers, HTTPS everywhere and a safe file permission setup.
• Backups, malware scanning, an activity log and alerts to a monitored inbox.

Keep an inventory

You cannot protect what you cannot list. Keep a record for every site: hosting account, domain registrar, WordPress version, PHP version, plugin and theme list, the people with access and the date of the last restore test.

Review it monthly. Sites nobody updates and nobody remembers are where attackers get in, so a client who left should have their site handed over or shut down properly.

Access control and offboarding

Most agency incidents start with a person, not a flaw in the code.

• One named account per person per site. No shared admin logins.
• Least privilege: designers and writers rarely need the Administrator role.
• A password manager for the whole team, with shared vaults per client.
• Two-factor on hosting, the registrar, the password manager and your email.
• An offboarding checklist: remove the person from every site, the host, the registrar and the vault on their last day, and change shared secrets.
• Review client user lists twice a year and remove accounts that are no longer needed, including old contractors.

Updates and staging

Decide who updates what and how often, and tell the client. A weekly update window with a backup before it, a quick visual check after it and a rollback plan beats ad hoc updates.

For sites that earn money, test updates on a staging copy first. Treat security releases for core and for any plugin with a known flaw as urgent, not as part of the weekly window.

Backups you have tested

Every site needs a recent backup stored away from the server, and every client contract should say how often it is taken. Restore a backup to staging for each site on a schedule and write down how long it took. A backup you have never restored is not a promise you can make to a client.

Monitoring and alerts

Make sure you hear about trouble before the client does. That means alerts that go to a shared agency inbox or ticket system, not a single person's mailbox, and a named person who reads them.

• Uptime monitoring on every site.
• Scheduled malware scans and file change alerts.
• An activity log so you can answer the question: who changed this, and when?
• Alerts for repeated failed sign-ins and new administrator accounts.
• Fewer, better alerts. If your team learns to ignore them, they stop working.

Have an incident plan

Write the runbook before you need it: who is in charge, how to put a site into maintenance mode, where backups live, who talks to the client and the host, and how to reset every secret.

Decide in advance when you will tell the client and what you will say. Calm, honest communication within hours does more for trust than a perfect fix delivered in silence.

Show clients the value

Security work is invisible when it succeeds, which makes it easy to cut. Send clients a short, regular summary of what was protected: updates applied, backups verified, attacks blocked. Branded emails that carry your name rather than a plugin vendor's keep the relationship with you.