ISO 27001:2022 evidence you can collect from outside the network
Which Annex A controls leave a trace on the internet, and how to evidence them in ten minutes.
Why look from outside at all
Most ISO 27001 evidence comes from inside: policies, tickets, screenshots of admin consoles. All of it is supplied by the organisation being audited. A handful of controls also leave a trace on the public internet, and that trace can be checked independently in minutes.
Outside-in evidence doesn’t replace the inside view. It corroborates it. When the policy says “all email is authenticated” and DMARC is at p=none, you have a finding before you open a single screenshot.
The controls that show up on the internet
- A.5.14 Information transfer: SPF, DKIM and DMARC protect email sent in the organisation’s name; MTA-STS and STARTTLS protect it in transit.
- A.8.24 Use of cryptography: TLS versions, certificate validity and expiry, HSTS, DNSSEC.
- A.8.20 Networks security: which services answer from the internet. Remote desktop (3389), SMB (445) and databases (1433, 3306, 5432) should not.
- A.8.9 Configuration management: security headers and redirects form a public configuration baseline you can compare across audits.
- A.5.9 Inventory of information and other associated assets: subdomains in certificate transparency logs should appear on the asset register.
- A.8.14 Redundancy and A.5.30 ICT readiness: at least two nameservers on separate networks, and more than one mail exchanger where email is critical.
- A.5.19 Supplier relationships: the registrar and DNS host are suppliers; domain expiry and transfer lock show whether that relationship is managed.
What good looks like
- DMARC at p=quarantine or p=reject, with reports going to a mailbox someone reads.
- SPF that ends in -all or ~all and stays under 10 DNS lookups.
- TLS 1.2 and 1.3 only, certificate valid for more than 14 days, auto-renewal in place, HSTS set.
- No remote-access or database ports open to the internet.
- Domain registered for at least a year ahead, with transfer lock on.
- Every subdomain in certificate logs is known, and none points at a deleted cloud resource.
Collecting evidence that holds up
Run a health check on each in-scope domain and keep the result. Each run records the time, the probe location it ran from and the raw data behind every finding, so it can be re-examined later.
For surveillance audits, run it again and compare. A score that drops between audits is a prompt to ask what changed and whether change management (A.8.32) caught it.
Turning findings into nonconformities
A technical gap is only a nonconformity when it contradicts a requirement the organisation set itself, through its risk treatment plan, its Statement of Applicability or its policies. DMARC at p=none is a minor nonconformity if the policy requires email authentication; it’s an observation if email spoofing was assessed and accepted as a risk.
Record the finding, the control, the evidence (the dated result) and the requirement it contradicts. The plain-English summary in each result is written to be quoted.
Limits to state in your report
- Results show the state at the time of the test, from the probe locations listed.
- Only public-facing configuration is assessed. Internal networks, endpoints and processes are not.
- A port that is closed to our probes may still be open to other networks if access is filtered by source.
This maps what we can see from the internet to common controls, to help you gather evidence. It isn’t a certification, an audit opinion or legal advice. Your auditor, your scope and your Statement of Applicability decide what applies.