Website Hosting Security Checklist: SSL, Backups, Access Controls, and Server Hardening

Overview

Website security has two dimensions: reducing the chance of compromise and limiting the damage when something goes wrong. Your hosting plan, application, domain, DNS configuration, server software, administrator accounts, and backup system all form part of the same security boundary.

A useful checklist should record more than whether a feature is enabled. It should identify who owns each task, when it was last completed, what evidence confirms it worked, and what action is required if the result changes. For example, “backups enabled” is less useful than “the latest backup completed yesterday, is stored separately, and was restored successfully during the last test.”

Use this guide as a recurring tracker. Apply the setup checks when launching or migrating a site, perform operational checks monthly or more often for critical systems, and review the broader plan after material changes such as a new domain, plugin, server, administrator, or payment workflow.

What to track

HTTPS, SSL, and domain controls

Confirm that every public page uses HTTPS and that HTTP requests redirect to the intended secure URL. Check the certificate’s hostname coverage, expiration status, renewal process, and installation on all relevant domains and subdomains. Also test important paths such as the login page, checkout, contact forms, and API endpoints.

Review domain and DNS access separately from hosting access. Keep registrar credentials protected with multi-factor authentication where available, and document who can change nameservers or high-impact records. Unexpected changes to A, AAAA, CNAME, MX, or TXT records can affect both availability and email security. For a record-by-record reference, see DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and AAAA Records.

Updates and exposed software

Track the versions and update status of the operating system, control panel, web server, runtime, CMS, themes, plugins, extensions, and deployment dependencies. Remove software that is no longer required rather than leaving inactive components installed. Before applying significant changes, confirm that a recent backup exists and that the update can be tested on a staging site.

For WordPress and other CMS platforms, record who reviews update notices and how compatibility is checked. A staging workflow can reduce the risk of applying an update directly to production; the guide How to Use Staging Sites Safely Before Pushing Changes Live covers the operational safeguards to consider.

Accounts, permissions, and authentication

Maintain an inventory of hosting, SSH, SFTP, CMS, database, registrar, DNS, analytics, and deployment accounts. Every account should have a named owner, a business reason, and only the permissions required for its task. Avoid shared administrator logins. Use separate accounts for administration, deployment, monitoring, and routine content work where the platform supports it.

Review dormant users, old API keys, temporary access, SSH keys, and application passwords. Remove access promptly when a person or integration no longer needs it. Use strong unique credentials, multi-factor authentication where available, and key-based SSH access instead of password-only administration when appropriate for the server environment.

Backups and recovery

Document what is backed up, how often it runs, where copies are stored, how long they are retained, and who can restore them. Include databases, uploaded files, configuration, deployment code, DNS information, and any secrets or certificates needed to rebuild the service. A backup stored on the same server is useful for some failures but should not be the only recovery copy.

Test restoration rather than relying on successful backup notifications. Restore to an isolated location, confirm that the database and files work together, and record the time required to return the site to a usable state. Define a practical recovery point objective—the acceptable amount of data that could be lost—and recovery time objective—the acceptable time to restore service.

Monitoring, malware checks, and logs

Monitor availability, certificate status, disk capacity, resource usage, failed logins, unusual administrator activity, and application errors. For a server-level review of CPU, RAM, disk, load, and network indicators, use the Server Monitoring Checklist. Keep enough logs to investigate incidents, while limiting access to those logs and managing their retention deliberately.

Malware scanning can provide another signal, but it should not replace updates, least-privilege access, secure deployment, or tested backups. Record alerts, investigate their cause, and distinguish false positives from confirmed changes to files, accounts, redirects, or scheduled tasks.

Server and application hardening

For VPS or cloud hosting, disable unnecessary services and ports, restrict administrative access by network or VPN where practical, apply host-level firewall rules, and avoid running applications as a highly privileged user. Store secrets outside publicly served directories, protect configuration files, and verify that directory listings and debugging output are disabled in production.

For managed hosting, confirm which controls the provider operates and which remain your responsibility. A managed service may handle parts of the operating system or platform maintenance, but you still need to protect application accounts, plugins, content, DNS, and backups. Keep a written responsibility boundary so that an incident does not begin with uncertainty about ownership.

Cadence and checkpoints

At setup or migration

• Enable HTTPS and verify redirects, certificate coverage, and renewal.
• Remove default accounts, sample files, unused services, and unnecessary plugins.
• Create individual administrator accounts and enable multi-factor authentication where available.
• Configure backups, off-server storage, alerts, and a documented restore procedure.
• Record DNS, hosting, registrar, deployment, and monitoring ownership.
• Test the site, forms, authentication, email delivery, and recovery path before launch.

When moving a site, include security validation in the migration plan rather than treating it as a post-launch task. The low-downtime cloud hosting migration checklist can help organize DNS, testing, and cutover work.

Monthly review

• Review updates, vulnerable or unused components, administrator accounts, API keys, and SSH keys.
• Check certificate renewal, domain registration details, DNS changes, and email-related records.
• Verify that scheduled backups completed and inspect at least one recent restore or restore rehearsal.
• Review monitoring alerts, failed logins, suspicious file changes, error logs, and disk capacity.
• Confirm that incident contacts and escalation instructions are still accurate.

Quarterly or after major change

Perform a deeper access review, test the recovery plan with the people responsible for it, and reassess the hosting architecture. Revisit this after a domain change, server migration, major application release, new payment or customer-data workflow, ownership change, or security incident. Compare current resource and availability patterns with previous months using the website uptime and performance monitoring guide.

How to interpret changes

Not every alert indicates an attack, and not every quiet monitoring period indicates safety. Interpret changes in context and preserve evidence before making destructive changes. A sudden administrator login, DNS edit, new scheduled task, unexpected redirect, or unfamiliar deployment should be verified with the responsible owner and compared with change records.

Prioritize issues by impact and exposure. An expired certificate on a public login or checkout path is urgent. A full disk can become a security and availability problem if logs stop recording or databases fail. An unused administrator account may be less urgent than an active compromised account, but it increases future risk and should still be removed.

If compromise is suspected, avoid repeatedly logging in through the affected account. Isolate the site or server when practical, preserve relevant logs, rotate credentials and keys from a known-clean device, identify unauthorized changes, and determine whether a trusted backup is available. Restore only after addressing the likely entry point, then monitor closely. If the system handles sensitive information or has contractual reporting duties, follow the applicable internal response process and seek qualified incident-response advice.

When to revisit

Schedule a monthly security review and a more detailed quarterly checkpoint. Do not wait for the calendar when the environment changes. Revisit this checklist immediately after a hosting migration, DNS or registrar transfer, CMS or plugin change, new administrator, new integration, major traffic increase, certificate problem, malware alert, unexplained outage, or backup failure.

Make the checklist maintainable by assigning an owner to every control and recording the date, result, evidence, and follow-up action. Keep a short change log beside it. At the end of each review, choose the three most important actions, set a due date, and verify completion at the next checkpoint. This turns secure web hosting from a collection of settings into an operating routine that can be tested, improved, and trusted over time.