Website Security Checklist Template

What the Website Security Checklist Covers

1. 1
   Phase 1

   Phase 1: Scope, Inventory & Last Quarter’s Actions

   4 tasks

   Record the site, the people and what the site is built from before checking anything. Answer the site type, payments and logins questions first: they add the matching checks. Every due date counts from the day the review starts.

   • Record the website, the review and who is involved — the website address, the quarter, the day the review starts, which every due date counts from, what the site is built on, whether it takes payments or has customer logins, and the review lead, technical maintainer and website owner
   • List what the site is made of and who manages each part — hosting, CMS or framework, plugins or extensions, CDN, DNS host, registrar, payment provider, forms and third-party scripts, each with the company or person who manages it and the account it sits under
   • Check last quarter’s actions are closed — every finding from the last review closed with evidence, or carried forward with a reason, an owner and a new date
   • Get the access the review needs — read access to the hosting or platform panel, CMS, DNS host, registrar, CDN and monitoring for the review lead, through their own accounts rather than a shared password
2. 2
   Phase 2

   Phase 2: HTTPS, Certificates & TLS

   5 tasks

   Check every hostname the site answers on, not only the home page. The NCSC’s TLS guidance asks for TLS 1.3, TLS 1.2 only where it is still needed, and every version of SSL and TLS 1.0 and 1.1 turned off. An expired or expiring certificate adds a task to fix it.

   • Check the certificate on every hostname — the bare domain, www and every subdomain that serves the site: trusted, covering the right names, sent with its full chain, and with its expiry date and who renews it recorded
   • Check certificate renewal is automatic or diarised — automatic renewal (ACME or the host’s own) working for every certificate, or a renewal date with an owner; CA/Browser Forum ballot SC-081 cuts the maximum lifetime of public certificates from 398 days to 47 days in steps between March 2026 and March 2029
   • Check the TLS versions and settings — TLS 1.3 turned on, TLS 1.2 only where still needed, SSL and TLS 1.0 and 1.1 turned off, and on a CDN or managed host the most restrictive policy it offers that meets this
   • Check HTTP redirects to HTTPS and nothing loads insecurely — every http:// address and the bare domain redirect permanently (301) to the HTTPS address, and no page loads scripts, images or forms over plain HTTP
   • Renew or fix the certificate — shown when a certificate is expiring, expired or broken: renew or reissue it now, install the full chain, check every hostname again and find out why renewal or monitoring did not catch it
3. 3
   Phase 3

   Phase 3: Security Headers, Cookies & Scripts

   7 tasks

   Check the home page, a form page and the login page, because headers often differ between them. MDN and the OWASP Secure Headers Project describe each header, and the table below lists them. Try a Content-Security-Policy change in report-only mode first.

   • Scan the site’s response headers — MDN’s HTTP Observatory or a similar scanner run against the home page, a form page and the admin or customer login page, with the results saved
   • Check Strict-Transport-Security (HSTS) — sent on HTTPS responses with a max-age of at least one year (31536000 seconds); add includeSubDomains only once every subdomain works over HTTPS, and treat preload as a separate decision, because removal from the preload list takes months
   • Check the Content-Security-Policy — a policy that limits where scripts, styles, frames and form submissions can load from, includes upgrade-insecure-requests and frame-ancestors, and was tried as Content-Security-Policy-Report-Only before it was enforced
   • Check X-Content-Type-Options, frame protection and Referrer-Policy — X-Content-Type-Options: nosniff, framing blocked with the CSP frame-ancestors directive (and X-Frame-Options DENY or SAMEORIGIN for older browsers), and a Referrer-Policy of strict-origin-when-cross-origin or stricter
   • Remove headers and tags that give away versions — Server, X-Powered-By, X-AspNet-Version and generator tags that name the software and version the site runs
   • Check cookie flags — every cookie the site sets over HTTPS marked Secure, and login and session cookies also HttpOnly and SameSite=Lax or Strict
   • Check the payment pages and their scripts — shown when the site takes payments: every script on the pages that lead to payment listed and approved, the payment provider’s page or form used as the provider documents it, and the owner and date of the next PCI DSS assessment recorded
4. 4
   Phase 4

   Phase 4: Software, Hosting & Exposed Files

   6 tasks

   Everything the site runs on should be on a version that still gets security updates. CISA’s Known Exploited Vulnerabilities catalogue lists flaws attackers are already using, so check it first. Which update task appears depends on what the site is built on.

   • Check the CMS core, plugins and themes are up to date — shown for WordPress and other CMS sites: every component on a supported version with updates applied, and plugins, extensions and themes that are not used deleted rather than only turned off
   • Check the site’s frameworks and dependencies are up to date — shown for static and custom-built sites: the frameworks, libraries and build tools in the site’s code on supported versions, with every known vulnerability the dependency scanner reports fixed or recorded
   • Check the platform’s apps, integrations and settings — shown for hosted builders and shop platforms: every installed app or integration still needed and from a known publisher, unused ones removed, and the platform’s own security settings reviewed
   • Check the server, runtime and database versions are supported — hidden for hosted builders: the operating system, web server, PHP, Node.js or other runtime and the database on versions that still get security updates, or the host’s documentation saying so
   • Check the software list against known exploited vulnerabilities — every component in the inventory compared with the CISA Known Exploited Vulnerabilities catalogue and the suppliers’ security advisories, with anything listed patched first
   • Remove old copies, test files and unused subdomains — old staging sites, backup archives, test pages, installer files and admin tools reachable from the web, and subdomains that point at services you no longer use
5. 5
   Phase 5

   Phase 5: Admin Access, Accounts & MFA

   6 tasks

   Check every route into the site, not only the CMS login: the hosting panel, the registrar and DNS host, the CDN and the code repository can all change what visitors see. A customer login adds its own check.

   • Review every admin and editor account on the site — each one a named person who still needs it, leavers removed, and anyone who does not need admin rights moved to a lower role
   • Confirm multi-factor authentication on every admin route — CMS administrators, the hosting or platform panel, the registrar, the DNS host, the CDN, the payment provider’s dashboard and the code repository
   • Replace shared logins and passwords — no shared admin accounts; where one cannot be avoided, it sits in a password manager with a named owner and its password is changed when someone with access leaves
   • Review hosting, SFTP, SSH and database access — every account and key belongs to a current person or service, FTP is replaced by SFTP, and the database is not reachable from the internet
   • Check the admin login is protected — repeated failed logins are slowed or locked out, default usernames such as admin are gone, and admin logins are recorded
   • Check the customer login — shown when the site has customer or member logins: failed logins slowed or locked out, password reset links that expire and work once, multi-factor authentication offered, and session cookies set as in Phase 3; deeper testing belongs in a web application security test round
6. 6
   Phase 6

   Phase 6: Backups, Restore Test, Domain & Email

   7 tasks

   A backup is only proven by a restore. The NCSC recommends at least three copies, on two devices, with one offsite, and at least one backup kept offline. A failed or partial restore adds a task to fix the backup and test it again.

   • Check the backups ran and one copy is out of reach — files and database backed up on schedule, the last good backup recorded, and at least one copy kept offsite where the site’s own credentials cannot change or delete it
   • Restore a backup to a test location — the latest backup restored to staging or a test host, the site checked page by page with its forms and logins, and the time it took recorded
   • Fix the backup and repeat the restore test — shown when the restore failed or was partial: find what was missing or broken, fix the backup job or its storage, and restore again until the site comes back complete
   • Check the domain registration and registrar account — auto-renew on with a company payment method, the expiry date recorded, the registrar lock on, two-step verification for every registrar admin, and more than one trusted person able to manage the domain
   • Check DNS records for entries left pointing elsewhere — records match the services in use, and CNAME records and delegations that point at services you no longer use are removed
   • Check SPF, DKIM and DMARC for the domain — all three published for the site’s domain and every domain it sends email from, with DMARC reports going to someone who reads them
   • Check certificate transparency logs for unexpected certificates — certificates issued for your domains this quarter compared with the ones you requested; the NCSC notes that an unexpected certificate may mean an attacker controls DNS for the domain
7. 7
   Phase 7

   Phase 7: Monitoring, Logs & Security Contact

   4 tasks

   Monitoring turns a quiet problem into an alert that someone acts on. Each check confirms an alert was tested this quarter and reached a named person.

   • Check uptime and certificate expiry monitoring — the site, its key pages and certificate expiry monitored, with a test alert this quarter that reached a named person
   • Check change and malware detection — file-change or malware scanning on the site, alerts on changes to critical DNS records, and a look at key pages for anything unexpected such as injected links or scripts
   • Check logs are kept and reviewed — web server, CMS and hosting panel logs kept long enough to investigate an incident, stored where an attacker on the site cannot delete them, and admin logins and failures reviewed
   • Check the security contact and incident plan — a security.txt file at /.well-known/security.txt with a Contact and an Expires date still in the future, and a short plan for who acts if the site is defaced, hacked or down
8. 8
   Phase 8

   Phase 8: Findings, Sign-off & Next Review

   6 tasks

   Log each finding with a severity, an owner and a fix date. When a critical or high finding is still open, a task appears to fix or contain it before sign-off. The website owner signs off the review, and nothing after that step can be completed until they do.

   • Log each finding with a severity, owner and fix date — every issue from Phases 2 to 7 in one table with its reference, severity (Critical, High, Medium or Low), owner, fix date and status
   • Fix or contain each critical or high finding — shown when a critical or high finding is open: fix it and check again, or contain it (take the page or feature offline, or block the route) and record who accepted the remaining risk until the fix
   • Write the review summary — what was checked, what passed, findings by severity and status, anything not checked and why, and the restore test result
   • Website owner signs off the review — Accepted, Accepted with open actions or Not accepted, based on the summary and the open findings
   • Book the next quarterly review — the next review’s start date agreed, and the review set to start on a schedule so nobody has to remember it
   • Carry open actions into the next review — every finding still open with its owner and date, and any change to this checklist or the site’s inventory