Use this checklist to identify unowned tasks and missing safeguards. It is not a certification or a guarantee of complete security. Adapt it to the sensitivity of your data and the complexity of your application.
1. Protect the control accounts
- The domain, DNS and hosting accounts have clear ownership.
- Passwords are unique and stored securely.
- Available multi-factor authentication is enabled for critical accounts.
- Recovery email and recovery codes remain accessible outside the website.
- Contractors use individual, appropriately restricted access.
- Former collaborators and unused API credentials have been removed.
2. Keep software and configuration current
Record the operating system or managed platform, application, themes, plugins and external services involved. Assign an owner for updates in each layer. Remove components that are no longer necessary and check dependencies before making large changes.
For WordPress, use the official hardening guidance as a starting reference. For a custom application, add checks specific to its framework and data flows. Hosting security and application security overlap, but they are not identical responsibilities.
3. Check the live connection and exposed files
- HTTPS works for all intended public hostnames.
- Certificate renewal and failure notifications are understood.
- Sensitive configuration, backups and logs are not publicly downloadable.
- Administrative services are limited to the access actually required.
- Production debug information does not reveal secrets to visitors.
- Public forms validate input and have proportionate anti-abuse controls.
4. Verify backups and restoration
Identify the files, database and external data needed to rebuild the site. Choose backup frequency and retention around acceptable loss. Test restoration on an isolated copy rather than relying on a green status indicator.
Check who can read or delete backups. A backup may contain the same sensitive information as production, so restrict access and use suitable storage protections. Record how to recover if the main hosting account cannot be reached.
5. Assign incident ownership
| Event | Owner to identify | Evidence to preserve |
|---|---|---|
| Site unavailable | Hosting contact and application maintainer | Timing, affected URLs and relevant error logs |
| Unexpected redirect | Security or technical maintainer | Observed behavior and change history |
| Backup failure | Backup process owner | Failed job details and last usable copy |
| Account access problem | Authorized account owner | Recovery information and provider case details |
| Data exposure concern | Responsible business contact | Relevant logs and scope information without unnecessary redistribution |
Decide how to reach the owner outside the affected site. Serious incidents involving personal or sensitive data may require specialist technical and legal advice.
6. Repeat the review when the site changes
Run the checklist again after a migration, a new integration, a change of developer or a substantial application upgrade. The objective is to keep responsibilities accurate, not to check the same boxes forever.
Maintain a short record of unresolved issues, their owner and the intended action. A known gap with a clear plan is easier to manage than an assumption that a hosting security badge covers everything.
Common questions
Does this checklist prove compliance with a security standard?
No. It is an educational operating checklist. Formal compliance depends on the applicable standard, scope, evidence and assessment process.
Can my hosting provider do all of this?
Some tasks may be included in a managed service, but business account ownership and application-specific decisions often remain yours. Confirm responsibilities in writing.
Sources & reference notes
Official sources consulted on 9 October 2026. Product details may change. Sources describe provider claims or technical documentation, not independent test results.
Independent educational hosting resources. Prepared with AI-assisted research and drafting; no individual expert credentials or firsthand testing are implied.
About the publication · Editorial standards · Suggest a correction