A WordPress maintenance SLA should define what support covers, how incidents are classified, when the provider is expected to respond, what is backed up, how updates are handled, and which situations sit outside the agreement.

Without those definitions, “24/7 support,” “fast response,” or “managed maintenance” can mean very different things to the agency, vendor, and client.

AxiomLift’s white label WordPress maintenance page covers the recurring service category. Use this checklist when building or reviewing an agency maintenance agreement.

1. Define the service boundary

List the work included in recurring maintenance.

Possible categories include:

  • WordPress core updates
  • plugin updates
  • theme updates
  • backups
  • uptime monitoring
  • security monitoring
  • minor content or configuration changes
  • incident investigation
  • restore support
  • compatibility checks
  • reporting

Then state what is not included, such as new features, redesigns, custom integrations, major migrations, or development projects.

A maintenance plan becomes difficult to operate when every new development request is treated as support.

2. Create severity levels that describe business impact

Do not classify incidents only by how technical they sound.

A practical model can be:

Critical: Production site unavailable, checkout or lead flow materially unusable, or a confirmed security incident with serious impact.

High: Major function unavailable but the site is still partly usable.

Normal: Non-critical defect, update issue, or routine support request.

Planned: Enhancement, content change, or maintenance task that can be scheduled.

Your actual definitions should match the client site. An ecommerce checkout failure and a typo should not enter the same queue.

3. Separate acknowledgement from resolution

An SLA should distinguish:

  • acknowledgement/response: provider confirms the issue and begins triage
  • workaround/restore: service is restored or impact reduced where possible
  • resolution: root cause is fixed or a final solution is delivered

A provider can usually control how quickly it acknowledges a request more directly than how quickly every third-party failure can be fully resolved.

Avoid promising a universal resolution time for problems that may depend on hosting, DNS, plugins, payment gateways, external APIs, or client approval.

4. Define support hours and escalation paths

Document:

  • normal support hours
  • time zone
  • emergency channel
  • who may open critical incidents
  • who receives escalations
  • after-hours rules if any
  • client/agency contacts

If emergency support is not included, say so clearly. If it is included, define what qualifies.

5. Write the backup policy in measurable terms

“Backups included” is incomplete.

Specify:

  • what is backed up: database, uploads, code, configuration
  • backup frequency
  • retention period
  • storage location or independence from production
  • encryption/security expectations
  • restore testing approach
  • who can request a restore
  • what happens to changes made after the restore point

The important question is not only whether backups exist. It is whether the team can restore the site responsibly when needed.

6. Define the update process

WordPress core, themes, and plugins change over time. WordPress documentation recommends keeping software updated, but an agency maintenance process still needs risk controls.

Decide:

  • whether updates are automatic or reviewed
  • whether staging is used for higher-risk updates
  • how compatibility is assessed
  • how custom code is handled
  • what happens if an update breaks functionality
  • whether backups occur before updates
  • how long an update may be deferred for a known conflict

The policy should balance security and stability instead of treating every update as identical.

7. Clarify vulnerability and security responsibilities

A maintenance provider can monitor and respond within scope, but no responsible agreement should imply that a WordPress site can be made impossible to compromise.

Define responsibilities for:

  • strong user access
  • MFA where available
  • least-privilege accounts
  • plugin/theme sourcing
  • security monitoring
  • malware investigation
  • credential rotation after incidents
  • hosting-level security
  • third-party services
  • incident communication

If remediation after a serious compromise is a separate project, state that before an incident occurs.

8. Define what counts as a “small change”

Many maintenance plans include a limited amount of content or minor development work. Define the unit.

For example, distinguish:

Routine maintenance: update existing text, swap an image, change a link, adjust a setting.

Development: new template, custom feature, integration, redesign, new workflow, complex layout.

The exact boundary can differ. The goal is to prevent a recurring care plan from becoming an unlimited development retainer.

9. Document third-party dependencies

List critical dependencies such as:

  • hosting
  • CDN
  • DNS
  • email delivery
  • payment gateway
  • form service
  • analytics
  • licensed plugins
  • external APIs

The SLA should explain how incidents are handled when the root cause belongs to a third party and what the maintenance provider can reasonably do: investigate, escalate, implement a workaround, or coordinate with the owner.

10. Include access and offboarding rules

Maintain an inventory of:

  • WordPress admin users
  • hosting access
  • SFTP/SSH
  • repository access
  • DNS/CDN
  • license accounts
  • monitoring tools
  • backup systems

When the contract ends, remove vendor access and transfer any agency/client-owned documentation or accounts.

The website handoff checklist provides a broader ownership inventory.

11. Require maintenance reporting that explains actions

A useful report can show:

  • updates completed
  • backups/restore tests where tracked
  • incidents and resolution status
  • security or compatibility issues requiring attention
  • work deferred and why
  • changes outside normal maintenance that need separate scope

Do not turn maintenance reporting into a page of green check marks with no explanation of exceptions.

SLA checklist

Before approving the agreement, confirm:

  • Included and excluded work is explicit.
  • Severity definitions reflect business impact.
  • Response and resolution are different terms.
  • Support hours and emergency channels are known.
  • Backup frequency, retention, and restore process are defined.
  • Update workflow and rollback expectations are clear.
  • Security responsibilities are shared explicitly.
  • “Small changes” have a boundary.
  • Third-party dependencies are addressed.
  • Access/offboarding is documented.
  • Reporting shows exceptions and unresolved risks.

For the boundary between project work and recurring care, read WordPress development vs maintenance.

Research sources

Related reading