The Monthly Security Check: How to Keep WordPress Under Control
A regular monthly check makes it easier to detect weak access controls, vulnerable components and inadequate backups before an incident occurs.
Category: Cybersecurity
Good WordPress security rarely depends on one specific security tool. It depends on carrying out the same important checks regularly, documenting deviations and making sure someone is actually responsible for following them up.
A monthly security check gives the business a manageable routine for authentication, updates, vulnerabilities, backups, access management and monitoring. The goal is not to guarantee that nothing can happen. The goal is to reduce the likelihood of incidents, detect problems earlier and make recovery more predictable.
Start with responsibility, not settings
Before the check is carried out, it must be clear who is responsible for the website. Many business websites involve several parties: internal editors, a web agency, an operations provider and suppliers of forms, analytics or integrations. If responsibility is unclear, critical alerts and updates can fall between the gaps.
Clarify at least three roles:
- System owner: Has overall responsibility and decides which measures should be prioritised.
- Technical owner: Carries out updates, troubleshooting, monitoring and recovery.
- Content owner: Manages editorial access and reports unexpected changes.
In a small business, the same person can fill all these roles. What matters is that the tasks have a named owner and are not simply “something the provider is probably keeping an eye on”.
1. Check who can log in
Begin the monthly check with the user list in WordPress and any separate access to hosting, domain administration, backups and other operational services. Look for former employees, terminated suppliers, test users and accounts whose purpose no one can explain anymore.
Each person should have their own account. Shared administrator accounts make it difficult to know who made a change, and the password must be changed every time someone leaves. Personal accounts can be disabled without affecting others.
At the same time, check that two-factor authentication is enabled for users with extensive privileges. A strong password is still necessary, but two-factor authentication reduces the risk if the password becomes known to others. Passwords should be unique and stored in a suitable password manager.
Questions to answer
- Do all active users still have a genuine need for access?
- Does anyone have more extensive privileges than their responsibilities require?
- Are shared accounts being used that should be replaced with personal users?
- Is two-factor authentication in place for administrators and operations users?
- Is there a documented procedure for disabling access when someone leaves?
2. Distinguish between updates and vulnerabilities
The fact that WordPress displays available updates does not automatically mean that the website has a known vulnerability. At the same time, a vulnerable component may require faster action than the regular update schedule. Therefore, update status and vulnerability status should be checked separately.
Create an overview of the WordPress core, themes and plugins. Unused components should be removed rather than merely deactivated. They create unnecessary complexity and can be overlooked when the rest of the solution is maintained.
When a known vulnerability affects the website, prioritisation should be based on more than severity alone. Consider whether the component is active, whether the function is available to visitors, what privileges are required to exploit the weakness and whether the provider has published a fix.
An active vulnerability in a publicly accessible form may require swift action. A vulnerability in a deactivated function that is only available to administrators may allow more time for controlled testing. Both should be handled, but not necessarily in the same way.
3. Update in a controlled and verifiable manner
Updates close security holes, but they can also affect design, forms, integrations and editing functions. A safe routine therefore combines speed with control.
- Confirm that a recent and completed backup exists.
- Record which components are to be updated.
- Test major or high-risk changes in a separate test environment.
- Carry out the update during an agreed time window.
- Check key functions afterwards.
- Document the result and any errors.
The post-update check should be adapted to the website. For a typical business website, it may include logging in, navigation, the contact form, search and important landing pages. If the website has payments, logins or integrations, these functions must also be tested.
Automatic updates can be useful, particularly for minor, low-risk fixes. However, they do not relieve the business of monitoring the outcome. If no one notices that a form stopped sending enquiries after an automatic update, the process is not adequately controlled.
4. Treat backup as a recovery plan
A message saying that “backup is enabled” is not enough. The business must know what is being backed up, how often it happens, where the copies are stored, how long they are retained, and who can initiate a recovery.
WordPress consists of both files and a database. An incomplete backup may therefore be missing uploaded documents, images, content, users or settings. For websites with frequent changes, the intervals must be adjusted to reflect how much data the business can afford to lose.
Backups should be stored separately from the environment they are intended to protect. If both the website and all backups depend on the same account or operating environment, a single incident can affect both.
Carry out an actual recovery at regular intervals. The test should show that the copy can be retrieved, that the necessary access is available, and that the website works after recovery. Record how long the test took and which manual steps were required. This gives management a more realistic picture of the expected downtime.
5. Look for changes that should not happen
Monitoring should not only measure whether the front page responds. A compromised website can remain accessible while sending spam, showing unwanted content to certain visitors, or having a new administrator account created.
The monthly review should examine relevant events since the last review. Look, among other things, for:
- new administrator accounts and changed roles
- numerous failed login attempts
- logins from unexpected locations or at unusual times
- changes to plugins, themes and key settings
- unexpected files or changes to existing files
- errors in scheduled backups and updates
- unusual traffic, resource usage or email sending
Alerts must be sent to a channel that is actually monitored. Too many alerts often lead to everything being ignored. Prioritize events that require action, and distinguish between information, warnings and critical deviations.
6. Finish with a simple risk list
The review has little value if the findings simply remain in a security tool. Create a short risk list with the deviation, its consequence, the person responsible and a deadline. Distinguish between measures that must be carried out immediately, measures that can be planned, and issues the business chooses to accept temporarily.
A specific deviation could, for example, be: “A former consultant still has administrator privileges.” The measure is to disable the account, check recent activity and confirm that the consultant has no other operational access. The responsibility and deadline should be clearly stated.
Over time, the risk list will also reveal recurring problems. If updates are repeatedly postponed because of one outdated plugin, the long-term solution is not to create more exceptions. The functionality should instead be replaced or rebuilt.
A practical agenda for the monthly review
For a straightforward business website, the review can be organized as a regular meeting between the system administrator and the technical lead. Use the same agenda every time:
- Review users, roles and two-factor authentication.
- Check available updates and known vulnerabilities.
- Remove components and access rights that are no longer used.
- Confirm that backups have been completed and are available.
- Review security alerts, operational issues and unexpected changes.
- Prioritize measures, set deadlines and assign responsibility.
- Archive a brief log of what was checked.
Complex websites need more frequent technical monitoring and faster handling of critical findings. The monthly review does not replace ongoing operations, but serves as a regular checkpoint where the business can confirm that security work is actually being carried out.
Secure operations require evidence, not assumptions
The most important result of a monthly security review is not a lengthy report. It is that the business can give concrete answers about who has access, what has been updated, which vulnerabilities have been assessed, whether backups can be restored, and who responds when something unexpected happens.
When these answers exist and are checked regularly, WordPress security becomes part of normal business governance. The business then becomes less dependent on individuals, random alerts and emergency measures when the problem has already occurred.
