A good maintenance plan states who keeps the plugin inventory, how fast security updates are applied, what happens to abandoned plugins, how premium plugins are handled, and what the agency does when a plugin is compromised. Write each as a plain duty with an owner and a time, and have your own counsel review the wording.
This is a scoping checklist, not legal advice.
The seven items
| Item | What to write | Evidence you can keep |
|---|---|---|
| Inventory | You maintain a list of core, plugins, themes and mu-plugins per site, refreshed weekly | The dated export |
| Update routine | Patch updates weekly, others on a schedule, with staging for sensitive plugins | Command output, change log |
| Security updates | A target window for applying a vendor security fix | Ticket times |
| Abandoned or closed plugins | You will flag them and propose a replacement with a date | Weekly diff |
| Premium plugins | The client holds the licenses, and you track the update path | License register |
| Removals | Unused plugins are deleted, not left inactive | Change record |
| Incident steps | What you do in the first hour, and who tells the client | Runbook |
Say what is out of scope
Be explicit about things you do not control: a plugin author's own account security, a vendor's release quality, or a host's server settings. WordPress.org itself documents account controls for authors, such as two factor authentication, release confirmations and a short list of committers, but a client plan cannot promise those on any vendor's behalf.
Make the update promise realistic
Avoid promising instant updates. WordPress.org now holds directory releases for a cooldown before distribution, currently 6 hours per the Plugins Team, and plugin updates can fail. State a target window and the conditions, such as staging tests for checkout flows. See our guide to the cooldown for the detail.
Premium and custom plugins
These sit outside directory checks. Put the license holder, the vendor contact, the update source and the renewal date in the register. For your own custom plugins, set the Update URI header so a same-named directory plugin cannot overwrite them, as in our post on that header.
Reporting to the client
Send a short monthly note: what was updated, what was removed, what is flagged, and what needs a decision. Plain words work best. Our post on how to tell a client their plugin is vulnerable has wording.
Review it yearly
Plans age. Revisit scope after a major WordPress release, a change of host, or any incident, and keep the previous version so you can show what was promised when.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings move from detection to an owner and a due date.
Quick check
Should the plan promise zero vulnerabilities?
No. Promise a process and response times, since no one can guarantee a plugin is flawless.
Who should own premium licenses?
Usually the client, with the agency recording them in the register.
Sources
Last reviewed: 19 October 2026.
