> report_status: no critical findings —— risk_status: unknown —— confidence_level: dangerously high —— reality: the most reassuring result is often the most misleading<span class="cursor-blink">_</span>_
A mid-sized financial services firm commissions an annual penetration test. The report comes back: no critical findings. A handful of medium-severity issues — some missing HTTP security headers, an outdated TLS configuration, a few accounts with weak password policy enforcement. Nothing alarming. Nothing that would keep anyone awake at night.
The CISO presents the results to the board. Slides are prepared. Green traffic lights. The narrative is clear: we tested our security, and we passed. The board is satisfied. The proposed investment in network segmentation — £120,000 and six months of architectural work — is deferred to next year. After all, the penetration test showed no critical issues. Why spend that money now?
Seven months later, the firm suffers a ransomware incident. The attacker enters through a phishing email that harvests Microsoft 365 credentials via an adversary-in-the-middle proxy. The MFA — push notifications — is bypassed because the user approves the prompt, believing it to be legitimate. The attacker uses the compromised email account to identify internal systems, finds the VPN portal, logs in with the same credentials, and lands on the corporate network. From there, they move laterally through an unsegmented environment, escalate privileges through a misconfigured service account that was outside the pen test scope, and deploy ransomware across 400 endpoints in a single weekend.
No individual finding in the original pen test was rated critical. The phishing vector was not tested. The MFA bypass was not in scope. The service account misconfiguration was on a system that was excluded from the engagement. The flat network architecture was noted as a medium-severity recommendation. But the chain they formed — credential theft, MFA bypass, unrestricted lateral movement, privilege escalation, mass deployment — was catastrophic. And the clean report had given everyone involved the confidence to defer the one control that would have limited the blast radius.
This is not a hypothetical. It is a composite of real incidents we have seen in the aftermath of engagements — not our engagements specifically, but situations where organisations shared their previous test results during our onboarding. The pattern repeats with striking consistency: a clean report creates confidence, confidence defers investment, and deferred investment creates the conditions for a breach that the next test — or a real attacker — exploits.
'No critical findings' is a precise technical statement with a precise technical meaning. But the way it is communicated, received, and acted upon transforms it into something far broader — and far more dangerous — than the tester ever intended.
| What the Tester Means | What the CISO Often Communicates | What the Board Hears | What the Organisation Does |
|---|---|---|---|
| Within the defined scope and timeframe, I did not identify any individual vulnerabilities that meet my 'critical' severity threshold. | Our annual penetration test found no critical issues. | We passed our security test. Our systems are secure. | Defer security investment. Reduce urgency on remediation. Use the clean report as evidence for compliance and regulatory purposes. |
| I tested for a defined period (typically 5–10 days) with specific access and constraints. My findings reflect what I found, not what exists. | The test was thorough and covered our key systems. | Everything was tested and everything was fine. | Reduce the scope and budget of next year's test — we do not seem to need as much coverage. |
| Medium and low findings exist. Some may combine into significant attack paths that require contextual risk assessment. | There are some minor issues the technical team will address. | Minor housekeeping items. Nothing to worry about. | Deprioritise remediation of medium and low findings. Focus technical resources elsewhere. |
| Significant areas were out of scope, including social engineering, cloud infrastructure, specific business-critical systems, wireless, and internal user endpoints. | The test covered our external and internal infrastructure. | The test covered everything important. | Do not commission additional testing for out-of-scope areas — the existing test provides sufficient assurance. |
At every stage — from tester to CISO to board to organisational action — the message loses precision and gains false confidence. The gap between the left column and the right column is where security failures are born. Every statement on the left is accurate. Every action on the right is rational given the information received. The problem is not dishonesty — it is the systematic loss of nuance and caveats as technical findings pass through layers of interpretation.
Severity ratings exist to help organisations prioritise remediation. Critical findings get fixed first. Medium findings enter the backlog. Low findings are often accepted as residual risk. This is rational — resources are finite, and prioritisation is necessary. But it creates a systematic blind spot: the assumption that medium findings represent medium risk.
In practice, we find that the most realistic attack paths in mature environments are composed entirely of medium and low findings chained together. The environment has been hardened enough to eliminate the obvious critical vulnerabilities — the unpatched externally-facing services, the default credentials, the SQL injection in the login page. What remains is a collection of individually moderate issues that, when combined by an attacker with patience and skill, provide a viable path to full compromise.
Every finding in that chain was rated medium or low. The report summary would legitimately state: zero critical findings, zero high findings. The board would see green. And an attacker — or a red team tester with a slightly broader scope — would achieve full domain compromise using nothing that individually qualified as critical.
This is why our reports always include an attack path narrative alongside individual findings. Severity ratings tell you about the parts. Attack paths tell you about the whole. The whole is nearly always worse than the sum of the parts, because attackers do not operate in isolation — they chain, combine, and compound every weakness they encounter.
Every penetration test leaves residual risk — risk that persists after testing is complete and findings are remediated. This is not a failure of the test. It is a structural reality of point-in-time assessment. The question is not whether residual risk exists — it always does — but whether the organisation understands, accepts, and manages it consciously, rather than ignoring it because a report provided reassurance.
| Source of Residual Risk | Why It Exists | How to Manage It |
|---|---|---|
| Scope exclusions | Budget constraints, system availability concerns, or regulatory restrictions prevent testing of certain systems, networks, or attack vectors. | Document all exclusions explicitly. Ensure risk owners formally accept the residual risk of untested systems. Commission separate, targeted assessments for high-value excluded systems. |
| Time constraints | A 5–10 day engagement cannot achieve the same coverage as a motivated attacker with unlimited time. Testers make prioritisation decisions that leave some attack surface unexplored. | Extend engagement duration for complex environments. Commission continuous testing programmes rather than annual point-in-time assessments. Supplement with automated vulnerability scanning. |
| Tester skill and methodology | Different testers have different specialisms, experience levels, and approaches. Findings are a function of the tester's capability as much as the environment's vulnerability. | Rotate providers periodically. Specify methodology requirements in the statement of work. Request evidence of tester qualifications and certifications (CREST, OSCP, CHECK). |
| Finding chains not assessed | Standard vulnerability-focused testing may not assess how individual findings combine into viable attack paths. Each finding is rated in isolation. | Commission attack path analysis alongside vulnerability assessment. Request narrative-based reporting that describes realistic attack scenarios. Include red team objectives in the engagement scope. |
| Environment changes post-test | New deployments, configuration changes, staff turnover, and infrastructure modifications can introduce vulnerabilities that did not exist during testing. | Implement change management processes that include security review. Deploy continuous vulnerability scanning. Conduct re-tests after significant infrastructure changes. |
| Threat landscape evolution | New vulnerabilities, new attack techniques, and new threat actor capabilities emerge continuously. A test conducted against the 2025 threat landscape may miss techniques that become prevalent in 2026. | Subscribe to threat intelligence feeds. Monitor emerging vulnerability disclosures. Ensure testing providers update their methodology against current threat intelligence. |
| Human factors untested | Unless social engineering is in scope, user susceptibility to phishing, vishing, pretexting, and helpdesk social engineering is entirely unassessed. | Include social engineering in the engagement scope. Conduct regular phishing simulations. Train helpdesk staff on identity verification for sensitive requests. Test MFA bypass resilience specifically. |
| Detection and response untested | Penetration testing assesses whether vulnerabilities exist. It does not assess whether the SOC would detect exploitation of those vulnerabilities in a real attack. | Commission red team engagements that specifically test detection and response. Measure dwell time. Conduct purple team exercises. Validate that alerts generated by automated platforms are actually investigated. |
A penetration test report that communicates only what was found — without explicitly acknowledging what was not tested, what was excluded, and what residual risk remains — is a report that enables the false confidence this article describes. Responsible reporting requires transparency about limitations, not just findings.
Every report we deliver includes the following sections alongside the technical findings, because we believe the context around findings is as important as the findings themselves.
| Report Section | Purpose | Example Content |
|---|---|---|
| Scope Statement | Define precisely what was tested and what was excluded — so the reader understands the boundaries of the assurance provided. | "This assessment covered the external perimeter (X.X.X.0/24) and internal network (10.0.0.0/16) infrastructure. Social engineering, wireless networks, cloud infrastructure (AWS), and physical security were excluded from scope." |
| Limitations Statement | Acknowledge the structural constraints of the engagement — time, access, environmental factors — that may have affected coverage. | "Testing was conducted over a 5-day period. The tester did not have time to fully enumerate the 10.20.0.0/16 subnet. Production database servers were excluded from active exploitation to avoid service disruption." |
| Attack Path Narrative | Describe how individual findings combine into realistic attack scenarios — showing collective risk even when individual severity ratings are moderate. | "While no individual finding was rated critical, the combination of phishable MFA (M-01), flat network architecture (M-02), and the over-privileged svc_backup account (M-03) creates a viable path to domain compromise." |
| Residual Risk Statement | Explicitly state the risk that remains even after all findings are remediated — giving the reader an honest assessment of what the clean report does and does not guarantee. | "Remediation of all identified findings will improve the organisation's security posture. However, residual risk remains in areas not covered by this assessment, including social engineering susceptibility, cloud configuration, and detection and response capability." |
| Strategic Recommendations | Provide forward-looking guidance that extends beyond the specific findings — helping the organisation understand what to test next, what to invest in, and where blind spots remain. | "We recommend commissioning a separate social engineering assessment to evaluate phishing and helpdesk resilience. Additionally, a red team engagement measuring dwell time would provide assurance about the SOC's detection capability." |
These sections are not disclaimers designed to protect the testing provider. They are risk communication designed to protect the client. A report that omits them — that presents findings in isolation without context about what was not tested, how findings combine, and what risk remains — is a report that enables exactly the false confidence trap this article describes.
The CISO presenting penetration test results to the board occupies the most critical position in the interpretation chain. They translate technical findings into business risk language. If nuance is lost at this stage — if caveats are softened, scope limitations are omitted, and the narrative becomes 'we passed' — the board will make investment decisions based on incomplete information.
| Instead of Saying... | Say This Instead | Why It Matters |
|---|---|---|
| "Our penetration test found no critical vulnerabilities." | "Our penetration test, which covered [specific scope], found no individual critical-severity vulnerabilities. However, the tester identified three medium-severity findings that, when combined, create a viable attack path to [specific impact]. [Specific areas] were not included in the test scope." | Preserves accuracy while communicating scope limitations and attack chain risk. Gives the board the information they need to make informed investment decisions. |
| "We passed our security test." | "The test provides assurance over the specific systems and attack vectors that were in scope. It does not provide assurance over social engineering, cloud, detection capability, or third-party risk — these would require separate assessments." | Prevents the board from interpreting a scoped assessment as a comprehensive security validation. |
| "Our security is in good shape." | "Our perimeter and internal infrastructure show improving maturity. The areas I recommend we invest in next are detection capability, social engineering resilience, and MFA upgrade to phishing-resistant methods — these represent our highest residual risk based on current threat intelligence." | Frames the conversation as continuous improvement rather than binary pass/fail. Uses the pen test as a foundation for forward-looking investment, not backward-looking assurance. |
| "We can defer the segmentation project — the test showed no issues." | "The test did not identify exploitation of our flat network architecture as a critical finding. However, network segmentation remains our most significant architectural risk — as confirmed by both the tester's recommendations and the attack chain analysis in the report. I recommend we proceed with the project." | Prevents the most dangerous misinterpretation: using a clean report to justify deferring strategic security investment. |
'No critical findings' is a statement about what one tester found, within one scope, during one engagement, at one point in time, using one methodology. It is a precise technical statement with specific limitations. It is not a statement about your organisation's security posture. It is not a guarantee that you will not be breached. And it is certainly not a rational basis for deferring security investment.
Residual risk always exists. It lives in the systems that were not tested, the techniques that were not attempted, the finding chains that were not assessed, the people who were not phished, the detection capability that was not measured, and the threat landscape that has evolved since the report was written. Organisations that understand and manage this residual risk — that treat pen test results as one input to a continuous security programme rather than a binary pass/fail verdict — are the ones whose 'no critical findings' report actually means something.
The most honest penetration test report is not the one that delivers reassurance. It is the one that tells you exactly what was tested, what was not, how the findings combine, what risk remains, and what you should do next. If your report does not do all of those things, the reassurance it provides is not honest — it is incomplete. And incomplete reassurance, acted upon with confidence, is how organisations with clean pen test reports end up in incident response.
Our reports include attack path analysis, scope limitation transparency, residual risk statements, and strategic recommendations — because we believe a pen test should inform your security programme, not just validate it. We also offer red team engagements that measure dwell time and test your detection capability — the assurance that a standard pen test cannot provide.