Start with what the website depends on
Before looking for weaknesses, make a simple inventory. Note where the website is hosted, who manages its domain name, which content management system and plugins it uses, and which services connect to it. Include forms, payment providers, email tools, analytics and any agency accounts. For each item, record an owner and where renewal or support information can be found. This map makes risks easier to spot: an old plugin matters, but so does a domain account that nobody knows how to access.
Next, identify what the site needs to protect. A brochure site may mainly need to stay available and show trustworthy information. A site with enquiry forms may also handle names, contact details and private messages. A shop may depend on an external checkout. Trace where submitted information goes and who can see it. If a volunteer group’s contact form sends messages to a shared inbox, for example, that inbox belongs in the review even though it sits outside the website.
Review accounts and ways in
Access is often the most useful place to begin. List people and suppliers who can sign in to the website, hosting account, domain registrar and connected services. Check whether each person still needs access and whether their permissions match their work. Someone who only edits event descriptions, for instance, may not need permission to install plugins or change site settings. Remove unused accounts, especially those belonging to former staff or contractors, through the normal account-management process.
Look for shared logins, reused passwords and accounts without multi-factor authentication where it is available. These conditions make it harder to control access or understand who changed something. Check how password resets work, too: if a single poorly protected email account can reset every important login, it deserves attention. Record the issue and the account owner rather than putting passwords into the inventory.
Look for neglected software and exposed information
Check whether the website platform, themes, plugins and server software have a clear update owner and a workable update routine. An out-of-date component is a stronger concern when it is publicly reachable, no longer maintained or essential to a form or checkout. Do not assume every available update is equally urgent; first note what the component does, whether it is still needed and whether the site can be backed up before a change. Removing an unused plugin may be simpler than maintaining it.
Review the site as an ordinary visitor. Can you find pages, files or old forms that should no longer be public? Are staff contact details or documents exposed unintentionally? Test forms using harmless sample information and confirm where submissions arrive and who can open them. Avoid probing for technical vulnerabilities on systems you do not own or have permission to assess. The goal at this stage is to find visible gaps and unclear ownership, not to conduct a penetration test.
Check how the organization would recover
A risk is bigger when there is no reliable way to respond. Find out whether backups cover the site’s files and database, where they are stored, who can restore them and whether a restore has been tested. A backup that has never been checked may not provide the reassurance people expect. Also identify who can contact the host, pause a compromised form, reset an administrator account and tell colleagues which website information can be trusted during an incident.
Consider common disruptions alongside security incidents. If the domain expires or the only administrator leaves, could someone else regain control? If a form stops working, how would the team notice? A short recovery checklist with account owners, support contacts and first steps can reveal gaps while there is still time to fix them. Keep that checklist somewhere the appropriate people can reach even if the website itself is unavailable.
Rank findings and make the review routine
Put findings in a small risk register with four fields: what could go wrong, what would be affected, who owns the fix and the next action. To prioritize, consider the likely impact, how exposed the issue is and how quickly it can be addressed. For example, an unused administrator account with access to the whole site may come before a minor issue on an archived page. Be honest about uncertainty: if you cannot tell whether a plugin is supported, mark that as something to investigate rather than guessing.
Turn the highest-priority findings into specific tasks, such as removing a former contractor’s access, enabling multi-factor authentication or testing a backup restore. Assign an owner and check that each task is complete. Repeat the review after major site changes and at a regular interval that fits the organization. The aim is not to produce a perfect risk score; it is to keep the most consequential weaknesses visible and steadily reduce them.
