Explore this guidance in context: Website security · Vulnerability management · Business resilience. Each topic includes an overview, related guides and a working template.

In this article

01Agree the boundary before an incident

A WordPress website depends on several layers: the application, themes and plugins; the runtime and database; the web server; and the accounts and DNS that control access. A managed hosting plan can cover some of these responsibilities, but the word managed is not a precise statement of who updates each component.

Use your contract and provider’s documentation to name the owner of each layer. WordPress’s own hardening guidance separates application administration from server responsibilities. Updating a plugin does not update the host operating system or every service on the server.

02Create a short responsibility record

  1. Business owner: approve risk decisions, maintain supplier contacts and control access when staff change.
  2. Website maintainer: manage WordPress core, supported themes and plugins, application configuration and customer-journey testing.
  3. Hosting provider or server administrator: confirm the supported runtime, system packages, server security, backups covered by the plan and restoration responsibilities.
  4. Domain and email administrators: maintain registrar access, DNS changes and mail authentication. One organisation may hold several roles; record the accountable person.

03Make the change recoverable

Before an update, confirm that a usable backup and restoration process exist. Where practical, test significant changes in a staging environment. Check forms, payments, login and other important journeys afterwards, rather than treating a successful administrator login as full verification.

Remove unsupported or unnecessary components using the maintainer’s process. Keep software sources trustworthy, review administrator access and protect the accounts that can deploy or restore the site.

04Close the right issue

An external observation should become a question for the appropriate owner. Ask for a package release, configuration evidence or retest result as relevant. Hiding a version string changes public visibility; it does not establish that the software received a security fix. Keep the evidence and the date of the decision together.

Sources & further reading

WordPress: Hardening WordPress (opens in a new tab)

Use the linked primary sources for current technical details. Guidance reflects the scope and dates described in this article.

TURN READING INTO ACTION

Put the guidance to work.

Choose a check with the right scope, inspect its observations and follow up with the person who can make the change.

Choose a security check More practical resources