Run an external security assessment against a well-configured site and some checks will simply not complete. A web application firewall sees automated traffic, decides it does not like it, and returns a block.
How a report handles that moment says a lot about whether it is honest.
Two true things
A blocked probe means two things simultaneously, and reports usually record only one.
It is a positive finding. Something is watching, it recognised automated behaviour, and it acted. That is the control working exactly as intended. A site that answers every automated request cheerfully is in a worse position than one that does not.
It is a coverage gap. The assessment could not see what sits behind the block. Whatever the check was going to examine remains unexamined. That is not a criticism of the site — it is a limit of the assessment, and it means the report has less to say about that area than about others.
Both are true. Reporting only the first produces a falsely reassuring report; reporting only the second produces a falsely alarming one.
Why reports get this wrong
Two failure modes, from opposite directions.
The first is credit-only. The report notes “WAF detected — good security posture” and moves on, leaving the reader with the impression that the area was assessed and passed. It was not assessed at all.
The second is gap-only. The report records “unable to verify” alongside genuine findings, so a working control appears in a list of problems. Read quickly — which is how these are read — it looks like a failure.
The second is more common in automated tooling, because a scanner that could not complete a check has no vocabulary for “and that was the right outcome.”
What a correct entry looks like
Something close to:
Automated request filtering active. Requests from our assessment were blocked at the edge before reaching the application. This is a positive control and is credited as such. It also means the checks in this section could not be completed, so this report makes no assessment of the underlying behaviour. If assurance is needed here, it requires an authenticated or coordinated test rather than a passive external read.
Three parts: the credit, the limit, and what would be needed to close it. The third part is what makes it actionable instead of merely honest.
The general principle
This generalises well beyond firewalls, and it is worth stating as a rule: a passive external assessment must distinguish between “we checked and it is fine” and “we could not check.”
Collapsing those two into a single “no findings” is the most misleading thing an audit can do, because the reader takes absence of findings as evidence of safety. Sometimes it is evidence that the door was closed.
The same distinction matters for pages behind authentication, endpoints not publicly linked, and anything requiring a valid account. All are legitimately out of scope for an external read; none should be silently reported as clean.
What this means for choosing an assessment
Useful when deciding what to buy.
A passive external audit reads what a cautious buyer or a curious stranger could see: public trust signals, policy surface, published commitments, configuration visible from outside. It is fast, needs no coordination, and involves no intrusive testing. Its limits are structural — it cannot see behind authentication or past active defences.
A penetration test is a different exercise: authorised, coordinated, often authenticated, actively attempting to get past controls. It sees far more and costs far more.
These are not competing products, and an external audit that quietly implies penetration-test coverage is misrepresenting itself. The right sequence for most companies is the external read first — it finds the cheap, embarrassing, deal-blocking gaps like questionnaire unreadiness and missing policy surface — then a penetration test when the surface is worth testing.
Reading a report with blocked checks
Three questions worth asking of any external assessment you receive:
- Does it distinguish verified-clean from not-verified? If every non-finding reads the same, you cannot tell what was actually examined.
- Does it credit working controls? A report with no positive findings is either describing a badly configured site or was written to sell remediation.
- Does it say what would close each gap? “Unable to verify” with no follow-on is a shrug.
Our Trust & Security Audit handles blocked probes this way deliberately — credited as a working control and recorded as a coverage limit, in the same entry. It is a passive external read with no intrusive testing, and it says where it could not see. Related: ranking security gaps by whether they actually block a deal.