Start with ownership and the activity that matters
List the website, domain, hosting, administrator accounts, mail delivery, backups and important integrations. Record the business owner and authorized supplier for each. Keep a reference to managed credentials rather than putting secrets in the checklist. The business should know how to regain control if an individual or supplier becomes unavailable.
Next identify essential workflows: an enquiry arriving at the right destination, a purchase following the correct path or an authorized user reaching the intended content. This turns a generic security list into something the owner can evaluate. A low-traffic site can still depend on sensitive customer information or several external services.
Review accounts and access outside the dashboard
Use attributable accounts and only the permissions needed for the task. Review staff, suppliers and unused identities, including access at the hosting provider, domain registrar and connected services. Consider supported MFA and a protected recovery route. A strong login control is incomplete if an obsolete provider account can still change the same system.
Access removal needs a plan for business ownership and automation. Before disabling an account, check whether it owns files, receives recovery messages or runs an integration. Do not leave a departed person's identity in place as the undocumented owner of an essential process. Use the appropriate platform guidance and an authorized transfer or replacement.
Use supported components and make updates testable
Know where core software, the theme and plugins come from, which versions run and who receives security notices. Remove unnecessary components through an appropriate change plan, not a blanket deletion rule. A popular or paid plugin is not a guarantee that its current version has no security problems.
Before a material update, define backup and rollback conditions, appropriate staging and the functions to check. Record what was updated and the observed result. An update status of successful does not prove that forms deliver, a role is restricted correctly or a shop completes its agreed checkout path.
Check recovery and integrations before you need them
Identify what a backup contains, its recovery point, where it is held and who can restore it if the normal administrator is unavailable. A second copy under the same broad administrative identity may not provide the separation you expected. Test the agreed activity in an appropriately isolated environment and record exclusions.
Map website mail, CRM, webhooks, payment, analytics and other connections. Check their owners and required permissions without exposing the credential values in the checklist. A copied test site can retain production integrations. Avoid real messages or financial actions when a synthetic, controlled route can answer the question.
| Area | Owner to identify | Acceptance question |
|---|---|---|
| Domain and hosting | Authorized business owner | Can the business recover administrative control? |
| Accounts | Platform administrator | Are roles and recovery routes appropriate? |
| Updates | Website maintainer | Did the agreed workflows work after the change? |
| Backup | Recovery owner | Was the required activity restored in isolation? |
| Integrations | Business and technical owners | Do intended actions work without excess access? |
| Alerts | Named recipient and backup contact | Who can interpret and act on the signal? |
Apply network controls without assuming they repair the application
HTTPS protects the relevant connection; it does not prove the application has no vulnerable code. A WAF or plugin can add useful filtering or detection, but its location, configuration and response process determine what it actually covers. Keep those controls distinct from component repair, account management and recovery.
If a legitimate action is blocked, identify the relevant request and rule before changing protections. Avoid opening broad exceptions for the whole application just to make one test pass. After a change, check that the intended action works and that the necessary restriction still applies within the agreed scope.
Turn observations into a record and a next action
For each area, write down what was checked, when, by whom and with which evidence. Use separate results for passed in scope, failed, not tested and not applicable with a reason. A task that could not be checked must not silently become green. Give unresolved work an owner and a date for the next decision.
Review frequency should fit the system and the trigger. A monthly review is not a reason to leave an exposed secret or urgent security notice until next month. A new supplier, plugin, checkout or account change may require a targeted check even when the routine checklist was completed recently.
When to stop routine work and ask for help
An unknown administrator, unauthorized redirect, changed payment destination or confirmed unwanted code calls for an incident process. Preserve observations and coordinate with the authorized owner before routine cleanup or rollback destroys useful evidence. Do not use this preventive checklist as a recipe to investigate a live intrusion on your own.
CyberFixCrew is an Israeli cybersecurity company that scopes website-security work for businesses worldwide. You can use this checklist with your existing supplier or discuss a specific gap with us. Agreed access, changes and acceptance remain essential; the checklist is not certification, a complete penetration test or a promise against every incident.
