What an external, non-intrusive security check can and cannot tell you
3 June 2026 · 5 min read
When people hear "security audit", they often picture something intrusive: an attacker-style test that pokes at every corner of a system to see what breaks. That is one kind of security work, and it is not what we do. Our security audits are external and non-intrusive, and we think it is worth being precise about what that means, because the distinction changes what the results can and cannot tell you.
What a passive external check actually looks at
We look at what is publicly visible from outside your systems: the security.txt file, robots.txt, certificate transparency logs, and pages the site itself links to. We fingerprint publicly exposed software and services from the outside, in the way any visitor to your site could.
We do not run authenticated testing, we do not attempt exploitation, we do not run denial-of-service style checks, and we do not run intrusive scanning. We also never brute-force paths: guessing at addresses like a hidden configuration file or a backup archive is unauthorised-access-shaped conduct, however passive it might feel, and we will not do it regardless of intent.
Why fingerprinted versions are indicators, not proof
A common output of this kind of check is a software version, picked up from a banner or a response header. It is tempting to treat that version number as a finding: "this software is out of date, therefore it is vulnerable." That reasoning does not hold up.
Software vendors regularly backport security fixes into an older-looking version number without changing what the banner reports. A version that looks outdated from the outside may already be patched. That is why we report fingerprinted versions as indicators worth investigating, not as confirmed vulnerabilities. Treating a banner as proof overstates what we actually know and can lead to wasted effort chasing a problem that does not exist, or worse, false confidence in a check that never looked deep enough to find a real one.
Why the scope letter comes first, always
No check touches a client asset before a scope letter is signed and filed. This is not a formality. Running any kind of scan against a system without clear authorisation is unauthorised-access-shaped conduct under the Computer Misuse Act 1990, and motive is not a defence. A signed scope letter defines exactly what is in scope, so there is no ambiguity about what we checked, what we did not, and what you agreed to.
The result is a check with real, honest value: a clear view of what an outsider can see about your systems, without the risk, cost, or legal exposure of an intrusive test. It will not tell you everything a full penetration test would. It will tell you, accurately, what is visible from outside, and it will tell you that without ever touching anything it was not authorised to touch.