A monthly hosting security audit helps you find unnecessary access, unexpected configuration changes, outdated software, and early signs of compromise before they become an outage. This reusable checklist covers hosting accounts, files, DNS, SSL, firewall controls, backups, and logs, with a practical workflow for recording findings and verifying fixes safely.
Overview
A website hosting security audit is a repeatable review of the systems that keep a site online. It is broader than scanning a homepage for malware and more useful than checking whether the site loads in a browser. The review should include the hosting control panel, domain and DNS management, administrator accounts, remote access, application files, server software, certificates, backups, and security logs.
Use this checklist monthly for active websites and at least quarterly for low-change projects. Run an additional review after a staff or vendor change, a hosting migration, a suspected compromise, a major software update, or before a high-traffic campaign. The objective is not to change every setting during every review. It is to identify what changed, decide whether the change is expected, and assign a clear remediation or follow-up action.
Before starting, create a simple audit record with the date, reviewer, website or hosting account, production environment, and previous audit reference. Record evidence such as screenshots, configuration exports, version numbers, log entries, or ticket links. Avoid placing passwords, private keys, or complete access tokens in the record.
What to track
1. Administrator and hosting accounts
Export or review the list of users with access to the hosting panel, domain registrar, DNS provider, cloud console, deployment system, database, and backup storage. For each account, confirm the owner, purpose, last known use, and appropriate permission level. Remove former staff, inactive vendors, shared logins, and accounts created for temporary work. Where the platform supports it, require multifactor authentication and use separate accounts rather than one shared administrator identity.
Review recovery email addresses, billing contacts, API keys, application passwords, and personal access tokens as well. These secondary access paths are easy to overlook during a normal hosting control panel review. Revoke credentials that are unused or cannot be tied to a current owner, then document any service account that must remain active.
2. SSH, FTP, and remote access
Check whether SSH, SFTP, FTP, control-panel file access, database administration, and other remote services are enabled. Disable services that the site does not need. If FTP must be retained for a specific workflow, verify that encrypted transport is used and that access is restricted as far as the hosting platform allows.
For SSH access, review authorized keys, key owners, login history, allowed users, and administrative escalation rules. Remove old keys and investigate logins from unfamiliar accounts, locations, or times. Do not treat an unfamiliar location as proof of compromise by itself; confirm it against known staff, automation, VPN use, and deployment activity.
3. Files, applications, and software versions
Review the website directory for unexpected scripts, recently modified files, unfamiliar administrator accounts, writable upload folders, and old installation archives. Compare changes with deployment records where available. Look for backup archives, configuration files, or private keys stored in publicly accessible directories. File permissions should allow the application to function without granting broader write access than necessary.
Inventory the operating system, web server, runtime, content management system, plugins, themes, libraries, control-panel components, and other exposed software. Confirm that supported security updates have been applied according to the provider or project maintenance process. Remove abandoned extensions and unused applications instead of leaving them disabled but present. If a version cannot be updated immediately, record the exception, its owner, and a compensating control or planned replacement.
4. DNS, domain, and SSL configuration
Compare current DNS records with the approved inventory. Pay particular attention to A and AAAA records, CNAME records, nameservers, MX records, and TXT records used for verification or email security. Investigate records that point to retired infrastructure, unknown services, staging systems, or third-party tools no longer in use. A practical explanation of these record types is available in the DNS records guide.
Review domain registrar access, transfer locks or equivalent protections where available, renewal contacts, and nameserver changes. For SSL certificates, confirm that the certificate covers the required hostnames, renews through a known process, and is presented correctly on the main site and important subdomains. Check for mixed content, redirect inconsistencies, and expired certificates without making production changes until the impact is understood.
5. Firewall rules, headers, backups, and logs
Review hosting firewall rules, network access lists, web application firewall settings, rate limits, and exposed ports. Remove temporary allow rules that are no longer needed. Confirm that administrative interfaces are not publicly exposed without a business reason and additional protection.
Check security headers and application settings appropriate to the site, including HTTPS redirects, content security controls, clickjacking protection, and browser policy settings. Apply them carefully: an overly strict policy can interrupt scripts, payment flows, or integrations.
Verify that website files and databases are included in the backup schedule, that backups are stored separately from production, and that retention matches the recovery objective. A backup that has never been restored is an assumption, not a verified recovery option. Use the offsite website backup strategy as a companion checklist.
Finally, inspect authentication, web server, firewall, DNS, deployment, and backup logs. Record failed login spikes, privilege changes, new scheduled jobs, unexpected outbound requests, repeated application errors, and configuration changes. Retain enough context to correlate an event across systems.
Cadence and checkpoints
Use a consistent order so that a rushed review still covers the highest-risk areas:
- Prepare: confirm the site, environment, reviewer, maintenance window, and last audit record.
- Check access: review users, multifactor authentication, SSH keys, API credentials, and recovery contacts.
- Check exposure: review DNS, nameservers, open services, firewall rules, SSL certificates, and public administration paths.
- Check the application: inspect software versions, plugins, themes, file changes, permissions, scheduled jobs, and database access.
- Check resilience: confirm backup completion, offsite storage, monitoring, and the last successful restore test.
- Check evidence: review logs and compare important changes with deployment or maintenance records.
- Close the loop: assign findings, set due dates, verify fixes, and preserve the audit record.
Use a priority system that reflects business impact rather than technical complexity. A critical finding may involve active unauthorized access, an exposed secret, a compromised administrative account, or a missing recovery path for a vital site. A high-priority finding may be an unapproved DNS change, an expired certificate, or a known vulnerable component exposed to the internet. Medium findings can include stale accounts, overly broad permissions, or incomplete logging. Low findings are useful hardening improvements that do not create immediate exposure.
Do not make several unrelated production changes at once. For each remediation, note the intended result, backup or rollback plan, implementation time, and verification method. This reduces the chance that a security improvement creates an avoidable outage.
How to interpret changes
Change is not automatically evidence of an attack. A new DNS record may support a legitimate service, a login from a new location may belong to a traveling administrator, and a file modification may come from a scheduled deployment. The important question is whether the change has an owner, a reason, and supporting evidence.
Classify each finding as expected, unexplained, or confirmed harmful. Expected changes can be recorded and closed. Unexplained changes should be preserved, investigated, and compared with deployment records, support tickets, provider notifications, and other logs. Confirmed harmful activity requires containment: limit affected access, preserve evidence, protect backups, and follow the organization’s incident response process. Avoid deleting suspicious files or resetting logs before evidence is captured.
Look for patterns across months. Repeated failed logins, growing storage use, increasing server errors, certificate renewal failures, recurring permission drift, or repeated backup failures may indicate a process problem even when no single event appears severe. If availability changes at the same time as security configuration changes, consult the website uptime monitoring guide and investigate the timeline rather than guessing from one symptom.
When to revisit
Schedule the next routine audit immediately after closing the current one. Monthly reviews are appropriate for sites with frequent deployments, multiple administrators, or important customer transactions. A quarterly review may be sufficient for a low-change site, provided that access, backups, certificates, and monitoring are still checked after significant events.
Run an unscheduled review after a domain transfer, hosting migration, ownership change, vendor departure, major CMS or plugin update, DNS incident, suspected malware, unexpected outage, or failed backup restore. Recheck the audit procedure whenever the hosting control panel, authentication model, supported software, browser behavior, certificate process, or security requirements change. The checklist should describe the controls your current platform actually provides, not features from an older hosting environment.
To make the process actionable, reserve a recurring calendar slot, keep one owner responsible for the audit record, and maintain a small change inventory for domains, DNS, hosting accounts, software, certificates, backups, and monitoring. At the end of each review, answer three questions: what changed, what remains exposed, and who will verify the fix? That discipline turns a one-time website security audit into an ongoing part of website hosting operations.
