Everything an attacker sees before they even try the front door lives in your domain's public posture: certificates, headers, DNS, exposed services, leaked data and more. This checklist covers 25 controls that measure that posture from the outside, the way an attacker would — and that our external scanner automates.
In essence
- The idea: measure what your domain exposes to the internet, before someone else does.
- The scope: transport, headers, DNS and email, exposure, reputation and AI readiness.
- The point: repeatable evidence, mapped to NIS2, DORA, ENS and ISO 27001.
Why you need a web security checklist
Public posture drifts. A certificate expires, a subdomain is forgotten, a header is dropped during a release, an old API stops being monitored. None of it shows up internally, but all of it is visible — and useful — to an attacker. A checklist turns that scattered exposure into something you can measure and track over time, and pairs naturally with an attack-surface programme.
Transport and encryption
Controls 1–3 cover TLS/SSL configuration, DNS health and exposed ports. Weak protocols, misissued or expiring certificates, unhealthy DNS and unnecessary open ports are the basics attackers check first — and the basics that most often slip.
HTTP headers, technologies and cookies
Controls 4–8 review security headers (HSTS, CSP and friends), the technologies your stack reveals, cookie flags, known public CVEs in detected components, and mixed content. Fingerprintable, outdated components are a direct route to a known exploit — see how to prioritise exploitable vulnerabilities.
DNS, email and domain state
Controls 9–11 cover email security (SPF, DKIM and DMARC), domain state, and Certificate Transparency. DMARC left at p=none is one of the most common — and most exploitable — gaps, leaving your domain easy to spoof in phishing.
Exposure: cloud, leaks and subdomains
Controls 12–19 look outward: AI security posture, cloud storage exposure, leaks in pastes and repositories, subdomain takeover, AI training exposure and bot blocking, subdomains via Certificate Transparency, and third-party breach exposure. This is where forgotten assets and supplier incidents surface — and where third-party risk becomes concrete.
Reputation, compliance and evidence
Controls 20–25 cover threat intelligence and reputation, security.txt and robots.txt, compliance signals, historical evolution, and exportable evidence. The last one matters more than it sounds: posture you cannot evidence is posture you cannot prove to an auditor.
How this maps to NIS2, DORA, ENS and ISO 27001
Public posture is not just hygiene; it is evidence. NIS2 and DORA expect you to manage exposure and third-party risk; Spain's ENS and ISO 27001 expect documented, repeatable control. A scan that exports evidence turns a checklist into audit-ready proof.
Common mistakes
The recurring ones: assuming HTTPS is enough, dropping checks after retiring an API, setting DMARC to p=none and forgetting it, ignoring old subdomains, not controlling third parties, never repeating the analysis, keeping no evidence, and treating SEO, security and compliance as separate. Each leaves exposure that a periodic check would catch.
How to use this checklist
Use it as an initial self-assessment, as a guide to prepare a formal review, or as the basis for a conversation with a specialist. Run your domain through the scanner for a baseline, compare it with our take on scanning versus managing vulnerabilities, and when you want the exposure turned into a remediation plan, get in touch.