A website maintenance retainer should cover five recurring jobs: applying updates, taking and testing backups, reviewing who has access, watching for problems, and responding when something breaks. If a retainer only says "we keep it up to date", the client and the agency will disagree about what that means.
Scope it in writing, with a cadence for each job and a named owner. The table below is a starting point.
The five jobs
| Job | Typical cadence | What "done" looks like |
|---|---|---|
| Updates | Weekly check, urgent same week | Core, plugins, themes and packages updated on staging, then production, with a note of what changed |
| Backups | Daily or weekly by site activity | Files and database captured, copies kept off the server, restore tested on a schedule |
| Access review | Quarterly | List of accounts and roles checked, leavers removed, MFA confirmed |
| Monitoring | Continuous | Uptime and change alerts reach a named person |
| Response | On demand | Agreed contact route and first steps, written down before it is needed |
Updates: define the window
The WordPress core team notes that core minor updates apply automatically by default but plugin and theme auto-updates are off until someone enables them. So the retainer must say who enables them, for which plugins, and what is held back for manual review. Put exceptions in a list: for example, a checkout plugin that is always tested on staging first.
Also state what you do when a plugin has no fixed version. Options include removing it, replacing it, or accepting the risk in writing with a review date. Do not leave this open.
Backups: include the restore test
The WordPress handbook suggests weekly backups for smaller sites and daily for busy ones, always before an upgrade, with copies kept in different locations. It also says to check automated backups manually from time to time. Turn that into a retainer line: "One restore test per quarter, results logged."
Access: the cheapest control
Review accounts every quarter. Remove people who have left, reduce administrators to the people who need that role, and confirm two-step login is on. CISA describes multifactor authentication as asking for two or more authenticators, so a stolen password alone is not enough.
Monitoring and response
WordPress's own hardening guidance says prevention is sometimes not enough and that monitoring lets you react faster and recover. Decide what is watched (uptime, changed files, new admin users) and who receives the alert. Write down the first three steps of a response: isolate, preserve logs, restore from a known good backup. Details will vary by host.
What to leave out of the promise
Do not promise that a site will never be hacked. The WordPress handbook frames security as risk reduction, not risk elimination. Promise the process, not the outcome.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new advisory is matched against an existing inventory without a manual re-scan; that is the monitoring job in the table.
For client projects that keep dependency manifests in a repository, Safeguard offers dependency scanning and continuous monitoring, and a free scan shows what a first report looks like.
Quick check
Should a retainer include incident response?
Include the first steps and the contact route. Full clean up of a compromised site is usually a separate, scoped job.
How often should access be reviewed?
Quarterly is a reasonable default, plus an immediate review whenever someone leaves the project.
Sources
- Controlling plugin and theme auto-updates UI in WordPress 5.5
- Backing up your WordPress site
- Hardening WordPress
- CISA, More than a password
Last reviewed: 19 October 2026.
