Website Security Compliance Checklist: 40 Controls for Ongoing Protection

Overview

Website compliance is the combined result of technical controls, documented decisions, and reliable operating routines. The exact requirements depend on your application, users, data, contracts, and applicable laws, so this checklist is a practical baseline rather than legal advice or a substitute for a formal risk assessment.

Use a tracker with these fields for each item:

• Control: what should be in place.
• Owner: the person accountable for maintaining it.
• Status: complete, partial, not started, or not applicable.
• Evidence: a configuration record, report, ticket, policy, screenshot, or test result.
• Last reviewed and next due date: when the control was checked and when it must be checked again.
• Exception or action: the remaining risk, deadline, and planned remediation.

Keep evidence in a controlled location. Avoid storing passwords, private keys, or unnecessary personal data in the tracker. Where a control does not apply, record why; an explicit rationale is more useful than an unexplained blank.

What to track: 40 website security controls

Infrastructure, hosting, and deployment

1. Asset inventory: maintain a current list of domains, subdomains, applications, APIs, cloud services, hosting accounts, and repositories.
2. Environment separation: keep development, testing, and production environments separated, with production data restricted from lower environments unless specifically approved and protected.
3. Hosting account security: enable strong authentication, review account recovery options, and restrict administrative access to named individuals.
4. Resource baseline: document approved operating systems, runtimes, frameworks, containers, databases, and critical configuration settings.
5. Change control: require review, testing, and an accountable approval before material production changes.
6. Dependency inventory: track direct and significant transitive software dependencies, including their versions and sources.
7. Patch management: define how operating system, framework, library, container, and hosting updates are assessed, prioritized, tested, and deployed.
8. Secure deployment: use a controlled deployment process and prevent secrets, debug settings, and test accounts from reaching production.

SSL/TLS, application, and browser protections

9. HTTPS coverage: serve every intended page and endpoint over HTTPS and redirect insecure requests where appropriate.
10. Certificate management: record certificate owners, expiration dates, renewal methods, and monitoring for failed renewals.
11. TLS configuration: review supported protocols, ciphers, and certificate chains against your risk and compatibility requirements.
12. Security headers: configure headers appropriate to the application, such as content security, transport security, framing, and MIME-sniffing protections.
13. Cookie settings: review Secure, HttpOnly, and SameSite attributes, along with retention and scope, for every sensitive cookie.
14. Input validation: validate input on the server, apply context-appropriate output encoding, and handle file uploads with strict type, size, and storage controls.
15. Authentication controls: enforce appropriate password, session, recovery, lockout, and MFA controls for users and administrators.
16. Authorization tests: verify that users cannot access another account's records or administrative functions by changing requests or identifiers.
17. Secrets management: keep API keys, credentials, signing keys, and tokens out of source code, public files, logs, and client-side bundles.
18. Vulnerability testing: perform risk-based scanning, code review, penetration testing, or other testing suited to the application's exposure and sensitivity.
19. Web application firewall: document enabled rules, exclusions, alert handling, and the process for reviewing rule changes. See the Web Application Firewall Rules Checklist.

Domain, DNS, and hosting security

20. Registrar access: limit registrar administration to approved personnel and protect it with MFA and monitored recovery channels.
21. Domain renewal: record renewal dates, payment ownership, and escalation contacts so a missed renewal does not interrupt the website.
22. Transfer protection: use registrar transfer locks or equivalent safeguards and document approval requirements for domain moves. Review the domain transfer checklist.
23. DNS provider security: protect the DNS account, review API tokens, and remove inactive users and integrations.
24. DNS record review: compare live records with an approved inventory and remove stale subdomains, verification records, and unused services.
25. DNS integrity: assess DNSSEC, authoritative name-server configuration, and change alerts where supported and appropriate.
26. Email authentication: maintain SPF, DKIM, and DMARC records according to your sending services and monitoring capability.
27. Hosting isolation: confirm that unrelated sites, tenants, storage buckets, databases, and management interfaces are not unnecessarily exposed to one another.
28. Origin protection: restrict direct access to application origins when a proxy or CDN is used, and ensure administrative interfaces are not publicly exposed without need.

Access, data protection, and resilience

29. Least privilege: grant only the access needed for each role and review elevated permissions regularly.
30. Joiner and leaver process: remove access promptly when staff, contractors, or vendors change roles or leave.
31. Service accounts: assign owners, limit permissions, rotate credentials, and monitor non-human accounts.
32. Personal data map: document what the website collects, why it is collected, where it goes, and how long it is retained.
33. Privacy notice: keep the notice accurate, accessible, and consistent with actual collection and processing practices.
34. Cookie and tracking review: inventory analytics, advertising, session, and embedded third-party technologies; align consent and disclosure practices with applicable requirements.
35. Third-party data flows: document processors, subprocessors, integrations, and contractual safeguards. The subprocessor list guide can help with maintenance.
36. Backups: back up databases, configuration, content, and critical files according to documented recovery needs.
37. Restore testing: periodically restore backups in a controlled environment and record the result, duration, and any missing dependencies.
38. Retention and disposal: remove data, accounts, logs, and backups when the approved retention period ends, subject to documented legal or operational holds.

Logging, monitoring, and incident readiness

39. Security logging: collect useful records for authentication, privilege changes, deployments, DNS changes, sensitive actions, and relevant system events without unnecessarily logging sensitive values.
40. Alerting and response: define alert owners, severity levels, escalation contacts, evidence preservation steps, and a tested incident response process. Use the incident response plan checklist to structure the review.

Cadence and checkpoints

A useful cadence is risk-based: review controls more often when they protect an internet-facing system, privileged access, or sensitive data.

Monthly checks

• Review failed logins, privileged-user activity, security alerts, vulnerability findings, and unresolved exceptions.
• Check certificate, domain, backup, and critical subscription renewal dates.
• Review newly added DNS records, administrator accounts, service accounts, integrations, and production changes.
• Confirm that high-priority patches and incident actions have owners and deadlines.

Quarterly checks

• Reconcile the asset inventory with hosting, DNS, cloud, code, and monitoring systems.
• Review access for administrators, vendors, developers, and service accounts; remove unnecessary permissions.
• Test a backup restoration and review recovery assumptions, dependencies, and recovery documentation.
• Review cookie technologies, privacy disclosures, third-party data flows, and retention practices after product changes.
• Run a tabletop incident exercise and update contact details and escalation paths.

Event-driven checks

Repeat relevant controls after a redesign, migration, domain transfer, hosting change, major dependency update, acquisition, new tracking tool, material change in data collection, or suspected security event. Do not wait for the monthly meeting when the risk has changed today.

How to interpret changes

A checklist is valuable only when changes lead to decisions. Treat a new public asset, privileged account, third-party integration, or data flow as a change in exposure, not merely an administrative update.

• New asset: assign an owner, add it to monitoring and backups where relevant, and confirm its authentication and patching model.
• New vulnerability: determine whether the affected component is present, exposed, and exploitable in your configuration; then set a documented remediation or compensating control.
• Failed backup or test: treat recovery as unverified until the cause is fixed and a successful restoration is recorded.
• Access increase: confirm business need, approval, expiration, MFA, and logging before treating the change as complete.
• New data collection: update the data map, privacy notice, cookie review, retention decision, and relevant contracts before launch where practical.
• Repeated alerts: investigate the underlying control or threshold rather than closing each alert without reducing the cause.

Prioritize issues using business impact, internet exposure, data sensitivity, exploitability, and ease of remediation. A small organization does not need a complex scoring system; a clear high, medium, and low approach with written rationale is often enough to support consistent decisions.

When to revisit

Revisit this checklist at least monthly for operational checks and quarterly for broader governance reviews. Review it immediately after a significant website, domain, hosting, identity, vendor, or data-processing change. Also update the checklist when your internal policies, customer commitments, security framework, or applicable compliance obligations change.

At each review, archive the completed evidence, record open actions, and set the next due date. Compare the current result with the previous review: are assets increasing, exceptions aging, backup tests passing, access becoming broader, or third-party data flows changing? These trends often reveal risk before an incident occurs.

For the next working session, create a simple table with the 40 controls above, assign owners, and complete the highest-risk gaps first. Pair this tracker with an access control review, a documented security policy set, and an incident response exercise. Consistent evidence and follow-through will make the checklist useful for everyday protection as well as broader cybersecurity compliance and website compliance reviews.