The Quarterly Security Check: Find Weaknesses Before They Become Incidents
A regular security check makes it possible to identify old users, vulnerable components, failing backups and unresolved alerts before they cause problems.
Category: Website Security
A WordPress website can be up to date today and still develop security vulnerabilities over time. Employees change roles, suppliers finish assignments, extensions remain unused, and alerts are sent to an inbox no one monitors. Security is often weakened through many small changes, not one dramatic error.
A quarterly security check gives the business a regular opportunity to address this gradual deterioration. The goal is not to conduct a comprehensive audit every three months, but to verify the most important conditions for secure operations: who has access, what is running on the website, whether the backup can be used, and whether anyone actually responds when something happens.
Start with responsibility, not tools
Before the check begins, one person must be responsible for ensuring that it is carried out. This person does not need to perform all the technical tasks, but must ensure that findings are assigned an owner and a deadline.
Also clarify which parts the check covers. A business website usually consists of more than the WordPress installation itself. Hosting, domain management, forms, email distribution, analytics tools and external integrations can all provide access to data or affect the website’s functionality.
Therefore, create a simple overview of:
- the WordPress installation with themes and extensions
- hosting, server environment and any publishing platform
- domain management and technical settings
- forms, online store and other data-collecting functions
- integrations with CRM, payment, newsletter or other services
- people and suppliers with administrative access
This overview does not need to be elaborate. It only needs to be up to date enough for you to know what must be checked and who can make changes.
1. Check users and authentication
Start with all accounts that can affect the website. Do not look only at WordPress users. Hosting, domain management, databases, integrations and security tools may have their own user accounts.
Check whether each account still has a legitimate need. Former employees, old agencies and consultants who have completed their assignments should not retain access as a precaution. Access can be created again when the need arises.
The quarterly review should clarify the following:
- Does every person have their own account?
- Have shared administrator accounts been removed?
- Do users have the lowest access level that covers their responsibilities?
- Is multi-factor authentication enabled for critical accounts?
- Is recovery information up to date and verified?
- Are there service accounts or integration keys whose purpose no one knows anymore?
Shared users should be replaced with personal accounts. When several people use the same login, it becomes difficult to see who made a change. It also becomes more difficult to terminate one person’s access without affecting others.
Also test recovery for at least one critical account. Secure login provides little benefit if the recovery code is held by a former employee or sent to an email account no one can access.
2. Identify Components That Have Become Security Debt
Create an up-to-date list of the WordPress core, active and inactive extensions, themes and any custom-developed components. Then check whether each part is still necessary and maintained.
An inactive extension is still code stored on the server. If you do not plan to use it again, it should normally be removed. The same applies to old themes, testing tools and temporary solutions installed during a project.
Assess each component by asking three questions:
- Does the business still need the functionality?
- Is the component maintained, and can it be updated?
- Is there someone responsible for testing the functionality after an update?
If the answer is no, you have a specific risk point. This does not necessarily mean the component must be removed the same day, but it must be given a plan. The options may be to replace it, discontinue the functionality or carry out a controlled technical upgrade.
3. Carry Out Updates as a Controlled Change
Updates should not be reduced to pressing a button in the production environment. Before major changes, you need a recent backup, an overview of the affected functions and a plan for checking the result.
Prioritize security-related updates and known vulnerabilities. In particular, test functions that are important to the business, such as contact forms, login, search, payment and integrations. A page that still loads is not necessarily a page that still works.
A simple post-update check may include:
- opening key pages on mobile and desktop
- submitting and receiving forms
- login for relevant user roles
- completing a purchase or order if the website supports this
- checking error messages and technical logs
Document what was updated, who tested it, and whether anything needs follow-up. This prevents uncertainty from causing important updates to be postponed indefinitely.
4. Confirm that the backup covers what you think it does
The quarterly check should not simply confirm that a backup job has a completed status. Investigate what is actually being backed up, how long the copies are retained, and whether they are stored separately from the website.
A WordPress website usually needs both files and a database. In addition, the business may have uploads, product data, or integration information that requires special handling. A copy of only part of the solution may result in an incomplete restoration.
Check when the last restoration test was performed, how long it took, and who can initiate it. If no one knows the process, a new test should be scheduled. The result should be a functioning solution, not merely a collection of backup files.
5. Look for unnecessary exposure
Websites often accumulate features and test setups that should no longer be available. These may include old test environments, temporary users, open forms, outdated subpages, or technical features that were enabled during development.
Check whether test environments are clearly separated from production, whether they contain real personal data, and whether access is restricted. Also look for debugging that is still enabled. Detailed error messages can reveal information about the system that should not be publicly visible.
At the same time, assess what data the forms collect. Fields that no longer have a clear purpose should be removed. Collecting less data reduces both security risks and the effort required to manage the information.
6. Check monitoring and alerting
Monitoring has little value if alerts do not reach the right person. Send a test alert and confirm that it is received, understood, and followed up.
Alerts should distinguish between issues requiring prompt action and information that can be reviewed later. Critical events may include an unavailable website, suspicious login attempts, unexpected administrator accounts, changes to key files, or backup failures.
For each important alert, you must know:
- who receives it
- who assesses its severity
- who can take technical action
- who informs the business in the event of an outage or data risk
Also check that the logging is useful. Logs should make it possible to investigate incidents without collecting more personal information than necessary. Access to the logs must be restricted, and the retention period should be deliberately chosen.
7. Finish with a prioritized action plan
A security check is only complete when the findings have been turned into action. Avoid a long list without prioritization. Instead, group the findings by impact and how quickly they should be addressed.
A practical outcome could be a short table in the business’s task management system, listing the finding, risk, owner, and deadline. Critical issues should be addressed immediately. Other improvements should be incorporated into planned operations.
Typical findings may include an old administrator account, an extension without a clear owner, missing multifactor authentication, or an alert sent to the wrong recipient. Each item is manageable when assigned to a specific person.
A regular cadence makes the checks manageable
Do not wait three months to address all security tasks. Critical updates, alerts, and suspicious incidents must be handled continuously. The quarterly check should identify changes and gaps that daily operations do not detect.
Add the check to the calendar for the entire year. Set aside time for both the review and follow-up work, and use the same checklist each time. Adjust the list when the website gains new features, integrations, or vendors.
The value lies not in a green checkmark, but in someone regularly checking whether the security procedures still work. When responsibilities, access, updates, backups, and alerting are reviewed together, it becomes much harder for small oversights to develop into serious incidents.
