The Report Is Not the Assurance: A UK Board Guide to Commissioning and Challenging a Penetration Test

A penetration test is often treated as a compliance artefact: commissioned, received, filed and forgotten. That is a costly misunderstanding. For a UK board, the value of a test lies less in the final score than in the quality of the questions asked before the engagement begins and the rigour applied when the report lands.

BlueHat Group's roots are in ethical hacking, and that background shapes a simple view: a penetration test is evidence, not a certificate. It can show that a capable attacker, working within agreed rules and a defined window, found a route to something that matters. It cannot show that the organisation is secure. The board's task is to make sure the test is designed to inform decisions, and then to read it with the scepticism a serious assurance product deserves.

Begin with the decision, not the checklist

Many penetration tests are scoped by habit. An external test of the corporate website, a internal test of the data centre, a tick in the annual assurance plan. The result may be technically competent and commercially useless.

A better starting point is the decision the board needs to support. Is the concern customer funds, regulated data, clinical availability, manufacturing continuity or third-party access? Which systems and journeys would make a serious incident board-level? The scope should follow those answers. That may mean testing a payment journey end to end, including the application, APIs, identity controls and supporting cloud configuration. It may mean testing whether a supplier portal exposes more than intended. It may mean a scenario-led exercise rather than a broad scan of every internet-facing address.

Commissioning is also where expectations should be made explicit. Agree the rules of engagement, testing windows, escalation routes, evidence handling and data protection arrangements. Confirm whether testers will attempt to chain findings, test business logic or assess detection and response. Not every engagement needs every technique, but the board should know what has been bought and what has deliberately been left out.

What a good test proves, and what it conveniently ignores

A well-run penetration test provides a point-in-time view of specific targets, under specific conditions, with specific constraints. It can validate controls, expose attack paths and give engineers concrete evidence to fix. It can also provide useful comfort when a high-risk change is about to go live.

It does not prove the absence of weaknesses elsewhere. It does not cover unknown assets, shadow IT, staff behaviour, supplier risk or every configuration drift introduced after the test. A clean report from a narrow scope is not a clean bill of health for the organisation. Nor is a test a substitute for secure development, vulnerability management, monitoring or incident response. If the report says nothing about detection, that is not because detection is unimportant; it is because detection was outside the brief.

Boards should also resist the idea that a penetration test is a one-off. It is a sample. The quality of the sample depends on the scope, the tester's creativity and the time allowed. A tightly constrained test will usually produce tightly constrained findings.

Why the critical label can mislead

Severity ratings are useful shorthand, but they are not business risk ratings. A critical technical finding on an isolated development system may matter less than a medium finding on an internet-facing service that holds customer data. A high-score vulnerability may be difficult to exploit in the organisation's particular configuration. A lower-score issue may sit directly on the path to financial loss or regulatory exposure.

This is where boards should ask for narrative, not just counts. Which findings form an attack path to something material? What preconditions would an attacker need? Are compensating controls already in place? What data or service would be affected? A report that lists severity scores without business context leaves the board to guess, and guessing is not governance.

The same applies to the word critical itself. It can mean technically severe, easily exploitable or simply outside the agreed risk appetite. The board should ask the tester to explain the reasoning, not just the label.

Five questions before signing off the report

First, what exactly was tested and what was excluded? Ask for the asset list, environments, credentials used and any third-party systems that were out of bounds. A report is only meaningful in relation to its scope.

Second, which findings sit on a path to material business impact? Request an attack narrative for the most significant issues, not a list of isolated defects.

Third, what evidence supports the severity? Ask whether exploitation was safely attempted, whether false positives were ruled out and whether the finding can be reproduced.

Fourth, what would the testers fix first, and why? A credible remediation sequence weighs risk reduction, effort, dependencies and compensating controls. It is not simply a sort by severity score.

Fifth, what should the board track beyond ticket closure? Look for repeat findings, architectural weaknesses, detection gaps and unresolved risk acceptances. These often say more about the security programme than the number of closed items.

From trophy to remediation plan

Once the report is accepted, the work moves from assurance to delivery. Create a remediation register with a named owner, a due date and an explicit risk decision for anything that will not be fixed immediately. Group findings by root cause where possible. A cluster of access-control issues may point to a design problem, not fifteen separate tickets. A repeated finding across applications may indicate that the secure development lifecycle needs attention.

Report progress to the board in terms of risk reduction, not activity. Closing tickets is not the same as removing exposure. Retesting should be planned with clear criteria, and exceptions should be visible rather than buried in an appendix. The penetration test should also feed other governance threads: incident response planning, supplier management, insurance renewal discussions and the forward audit plan.

A penetration test is most valuable when it is treated as a decision-support tool. Commission it with intent, challenge the labels and turn the findings into a prioritised plan. The report is not the assurance. The assurance comes from what the board does with it.