WordPress security inventory: the components you need to know

A security advisory only becomes manageable once you know which software your website uses. A WordPress inventory answers that question systematically: it connects core, plugins, themes and the technical environment with versions and responsible people. For small teams, a manageable list that is actually maintained is enough to get started.

Record four layers separately

Start with WordPress itself. Record the version shown in the administration area and the date you checked it. Then add regular plugins. Record not just the displayed name, but also the directory name, vendor and installed version. A similar product name does not establish that a security advisory refers to the same extension.

For the design layer, include the active theme and, where applicable, its parent theme. A custom theme may also contain functionality that someone needs to maintain. Finally, add the hosting layer: who looks after PHP, the web server, database and certificates? As the operator, you do not need to read out every system package yourself. However, you should know who receives a relevant warning and what information that contact needs.

The WordPress documentation explicitly treats hardening as several measures working together. These include trusted software sources, restricted access, updates, backups and monitoring. An inventory does not replace these measures; it provides a shared basis for assigning them. Source: WordPress hardening.

Distinguish observations from confirmed inventory

An external check sees your website from a visitor’s perspective. It can find clues in HTML, resource paths and metadata. These observations are useful, but their scope differs from a list obtained through your own administration. Therefore, mark how each entry was established: publicly observed, checked internally or confirmed by the responsible service provider.

Imagine a small association with a contact form. A JavaScript file from the form plugin appears publicly. This can identify a product. The file does not tell you whether a server-side export also runs or whether an old plugin remains in the file system. A missing observation must therefore never be entered in the inventory as confirmed absence.

The date matters just as much as the version. An entry checked three months ago may now be outdated. Give each record a check date and a useful trigger for the next review: after an update, a change of agency or a new extension, for example. This makes it clear which inventory statements remain reliable.

A useful inventory entry

A good entry remains understandable to someone who did not set up the website. For example, write: contact form, product and directory name, internally confirmed version, responsible agency, last check date and available update permissions. For paid extensions, add who manages license access. A security update is of little help if nobody can obtain the appropriate package.

Do not store passwords, license keys or private download links in this list. Refer instead to the designated password manager or responsible person. Support credentials should not casually end up in a freely shared document either. The inventory needs to be accessible for maintenance without becoming a collection of credentials itself.

For custom extensions, an additional note is worthwhile: source repository, responsible contact and most recently deployed release. An internal version number is only useful if it can be linked to a specific deployment. If that link is missing, document the gap openly and plan to resolve it.

Turn the list into a maintenance workflow

Decide when inventory changes must be recorded. A short step in the existing change process is practical: whoever installs, replaces or removes a plugin updates the corresponding entry. Whoever deploys an update records the version actually checked afterwards. This avoids creating a second, parallel record that quickly becomes outdated.

Connect security advisories to the matching inventory entries. Only then check the affected version range and actual usage. An advisory for a product you do not use requires different handling from a matching finding. An unknown version remains an open task; it is neither marked green as a precaution nor automatically presented as a successful attack.

For small teams, appoint a primary owner and a backup. This person does not need to carry out every technical change themselves. They make sure questions reach the right people and decisions are documented. This prevents several people from reading the same warning and each waiting for someone else to act.

Keep the scope deliberately manageable

Start with the components that keep your website running. You do not need to map a perfect supply chain on day one. A reliable basic inventory with clearly identified gaps is better. Add deeper dependencies where the maintenance provider or a specific advisory makes them relevant.

Keep separate mappings for multiple websites. Two installations can use the same product in different versions. A shared product list without website references does not reveal where an update is still missing. A central product catalog with individual installation entries can provide clarity, as long as the actual version for each website remains visible.

Also check which components you still need. A forgotten add-on is more than an inventory issue: it creates review and maintenance work. However, only remove software after a technical review and backup, so important data or hidden workflows are preserved. Plan this transition around data, dependencies and a controlled follow-up check.

When a website changes hands

The inventory should be included in a handover. Ask the previous agency for more than a collection of ZIP files: request a clear mapping of functions, products and maintenance arrangements. Check which updates are tied to someone else’s customer account and which custom developments would be left without support.

Do not accept unsupported claims without checking them. An entry saying “updates automatically” is a reason to ask for a demonstration of the actual process and its failure notifications. Document who can intervene in future if an automatic operation fails to happen. This turns a one-off handover list into a useful operations document for the next person responsible.

A practical start for this week

Set aside a short appointment with the person who has administrative access and maintenance knowledge. Review core, extensions, themes and hosting together. Explicitly mark anything unknown. Then choose the three most important open questions and assign each an owner and a deadline. In everyday work, this is more valuable than an extensive spreadsheet with no next steps.

Keep a traceable change history. If a later scan shows a different version, you can check whether an update is missing, a cache is serving old files or detection was inaccurate. The guidance on cache and CDN behavior and unambiguous product identification helps distinguish these situations.

A maintained inventory does not promise complete security. It ensures that a new advisory does not get stuck on the basic question of which software could be affected at all. It is precisely this mapping that turns a general warning into a verifiable task.