A website can remain available while its supporting infrastructure becomes misconfigured, over-permissioned, or difficult to recover. This DNS and hosting security checklist provides a recurring review process for domains, DNS records, certificates, hosting access, backups, email authentication, monitoring, and recovery evidence. Use it monthly or quarterly, and repeat it after ownership changes, migrations, major releases, or security incidents.
Overview
Website infrastructure security is broader than checking whether a page loads over HTTPS. A secure review follows the path from the domain registrar to DNS, the hosting account, the application, administrative identities, backups, and the systems that send or receive email. Each layer can affect availability, confidentiality, or the integrity of the website.
Start by creating an inventory for every production domain and important subdomain. Record the registrar, account owner, nameservers, DNS provider, hosting provider, origin environment, certificate source, email provider, backup location, and responsible internal owner. Include staging or administrative subdomains where they can expose sensitive systems or create confusion during an incident.
The inventory is not only documentation. It gives reviewers a defined scope and makes changes visible. A domain transferred to a new registrar, a nameserver changed without approval, or a forgotten subdomain left pointing at an old service should all produce a review item.
For broader control evidence, connect this review to your website security compliance checklist. If the website processes personal data, review infrastructure findings alongside your GDPR website compliance checklist so technical changes are considered alongside privacy and data protection obligations.
What to track
1. Registrar and domain account security
- Confirm that the registrar account uses multi-factor authentication, preferably with a strong second factor that is controlled by the organization rather than one individual.
- Review the account’s recovery email, recovery phone, authorized users, and notification settings. Remove former staff and unapproved delegates.
- Enable registrar lock or transfer protection where appropriate, and document who can approve a transfer or change ownership information.
- Check the domain expiration and renewal method. Ensure renewal notices reach more than one responsible person and that payment or renewal details are current.
- Review recent account activity and changes to registrant, administrative, or technical contacts.
2. Nameservers and DNS records
Compare the authoritative nameservers with the approved inventory. An unexpected nameserver change can redirect traffic or prevent the organization from controlling its records. Confirm that only approved administrators can modify the DNS zone and that changes are logged or otherwise reviewable.
Review records for stale, duplicated, or unexplained entries. Pay particular attention to A, AAAA, CNAME, MX, TXT, and delegation records. Remove records for retired services after confirming that they are no longer needed. Check wildcard records and subdomains used for testing, support, status pages, APIs, or administrative tools.
Use DNSSEC where it is supported by your domain and DNS configuration, and verify that its signing status is intentional and operational. A DNSSEC review should include the delegation, signing configuration, key-management responsibility, and a documented recovery procedure for rollover or misconfiguration. Do not mark DNSSEC as complete solely because a dashboard displays an enabled setting.
3. TLS certificates and transport settings
- List production domains, subdomains, and certificate expiry dates.
- Confirm that certificates cover the names users actually reach and that renewal is automated where practical.
- Test redirects from HTTP to HTTPS and check for mixed content or inconsistent certificate deployment across load balancers, CDNs, and origin servers.
- Record who receives renewal alerts and what happens if automated renewal fails.
Certificate monitoring is useful, but it does not replace a test of the complete request path. A certificate may be valid at a CDN while the origin, alternate hostname, or administrative endpoint remains misconfigured.
4. Hosting, cloud, and privileged access
Review hosting dashboards, cloud consoles, deployment systems, server panels, database consoles, and content management systems as one access-control surface. Require individual accounts, multi-factor authentication, least privilege, and a documented offboarding process. Avoid shared administrator credentials; where a shared emergency account is unavoidable, protect it with controlled storage, logging, and periodic access review.
Check firewall rules, exposed ports, remote administration paths, public storage, security groups, origin IP addresses, and default accounts. Confirm that staging environments do not contain production data or publicly exposed administrative interfaces without a clear business need. Review software, operating system, plugins, themes, containers, and dependencies according to the ownership model for the environment.
Use the access control policy checklist to document account reviews, and record infrastructure providers as part of your vendor risk assessment process.
5. Backups, monitoring, and email authentication
Verify that backups cover the website, database, configuration, DNS information, certificates or deployment settings, and other components required for recovery. Record retention, storage location, encryption expectations, access restrictions, and the last successful backup. A backup that has never been restored remains an assumption, not recovery evidence.
Check uptime, certificate, DNS, domain-expiration, log, and security alerts. Make sure alerts have an owner and an escalation path. For email sent from the domain, review SPF, DKIM, and DMARC records against the organization’s approved sending services. Investigate unauthorized senders, overly broad records, and changes that could affect mail delivery or domain reputation.
Cadence and checkpoints
A practical schedule separates frequent automated checks from periodic human review.
- Continuously or daily: monitor availability, certificate failures, critical security alerts, backup failures, and high-risk changes where tooling supports it.
- Monthly: review domain and hosting notifications, privileged-account changes, DNS modifications, exposed services, backup status, and unresolved alerts.
- Quarterly: reconcile the full asset inventory, inspect all DNS records, review registrar and provider access, test a representative restore, and confirm that owners and escalation contacts are still correct.
- After a change: repeat relevant checks after a migration, registrar transfer, DNS provider change, new third-party integration, certificate change, major deployment, or hosting redesign.
- After an incident: preserve logs and evidence, review changes made during response, rotate affected credentials, and update the recovery procedure based on what was learned.
For every finding, record the affected asset, observed condition, risk, owner, target date, remediation status, and evidence of closure. Distinguish between a verified control and an untested assumption. This makes the checklist useful for operational governance and for security reviews such as the evidence preparation described in the SOC 2 readiness roadmap.
How to interpret changes
Not every infrastructure change is a security incident, but every unexplained high-impact change deserves prompt investigation. Treat a new nameserver, registrar contact, privileged user, public storage location, origin server, or mail sender as a change requiring validation. Confirm whether it was approved, identify the requester, and compare it with deployment or vendor records.
Prioritize changes using impact and recoverability. A change that could redirect all web traffic, prevent domain control, expose personal data, disable backups, or block incident response should be escalated ahead of a low-risk documentation gap. A stale DNS record may be less urgent than an active unauthorized administrator, but it can still increase future attack surface and should receive an owner and due date.
When a control fails, avoid recording only “fixed.” Note what was changed, when it was changed, who approved it, and how it was tested. For example, a restored backup should include the restore date, environment, data scope, result, and any limitations. If a provider cannot supply the required evidence, record that as a dependency or risk rather than assuming the control exists.
If a change suggests compromise, use the organization’s incident process instead of silently reverting it. The incident response plan template and website and SaaS incident response checklist can help structure roles, evidence preservation, escalation, communications, and recovery.
When to revisit
Schedule the full DNS and hosting security review at least quarterly, with monthly checks for high-risk access and change activity. Revisit the scope immediately when ownership changes, a domain is transferred, a provider is replaced, a new subdomain is launched, a certificate or DNS configuration is altered, or a website begins processing a different category of data.
Set a calendar reminder with the inventory attached, but do not rely on a calendar alone. Assign a named owner, maintain a current list of backup reviewers, and retain the previous review so trends are visible. Repeated findings—such as expired certificates, unknown DNS records, or failed restore tests—indicate a process weakness rather than isolated housekeeping issues.
To complete the next review, export or inspect the current domain and DNS configuration, compare it with the approved inventory, review privileged access, verify certificates and email authentication, check backups and monitoring, and test one recovery path. Close the cycle by documenting exceptions, assigning remediation dates, and recording evidence. A short, repeatable review performed consistently is more useful than a detailed checklist that no one can maintain.
