For a small business, website security starts with knowing who owns the accounts and who can recover the service. A public scan can surface configuration questions, but many important controls live in hosting, application, and identity systems it cannot inspect.
Use this checklist to have a concrete conversation with the people maintaining your website.
Know who has access
List the business owner and administrator for the domain registrar, DNS, hosting, CMS, source repository, and critical integrations. Use individual accounts where supported and remove access that is no longer needed.
Ask the provider to explain the authentication and recovery controls for privileged access. The OWASP Authentication Cheat Sheet discusses multifactor authentication and other protections. A site health score cannot confirm those account settings.
Record where approved recovery instructions are kept without putting passwords or recovery codes into a client report.
Give updates a tested process
Identify who reviews updates, applies them, checks the result, and handles a failed release. Include the application and dependencies your team actually manages. A version visible in public HTML may be incomplete or misleading, so use the authoritative system inventory for maintenance decisions.
For WordPress sites, the project's hardening guidance covers maintenance and access considerations. Use documentation for your own platform rather than applying a generic CMS recipe.
Your evidence request can be simple: what changed, when was it applied, what visitor tasks were tested, and what remains outstanding?
Confirm that backups can be restored
Ask what is backed up, where the copy lives, who can retrieve it, and when a restore was last tested. “Backups enabled” does not establish that the required content, database, and configuration can be recovered together.
Choose a recovery target with your provider based on the business consequence. Record the test result and any dependencies that need separate recovery. Do not place live customer data in an unapproved test environment simply to demonstrate a restore.
Review public configuration separately
Inspect HTTPS, redirects, relevant headers, and unintended public exposure. A PageVital snapshot can help start the public-page review, while browser testing helps confirm the affected task still works.
Use the security-header guide before changing policies. A header grade does not measure account security, successful backups, or application authorization. A technology fingerprint also is not proof that an exploitable vulnerability exists.
Prepare a short response record
Before an incident, fill in:
Business decision-maker:
Technical responder and alternate:
Registrar and hosting support routes:
Where approved recovery instructions live:
Where logs and backups are held:
Who can authorize containment or restoration:
How business stakeholders receive verified updates:
If you suspect compromise, contact the responsible technical responder, preserve relevant evidence, and follow the agreed response process. Avoid speculative public explanations or destructive cleanup that removes information needed to understand what happened.
Ask for evidence of completion
A useful monthly summary identifies completed maintenance, tested recovery work, open issues, and limits. It should not say “everything is secure” because a scanner returned green checks.
The maintenance report template provides that structure. Keep sensitive account details and incident evidence in the appropriate private system; the client summary should communicate decisions without becoming a credential store.