Your Pen Test Report Is Not a Risk Management Plan

There is a very expensive ritual we see far too often. A customer asks whether the business does penetration testing. Someone on the leadership team panics slightly. A provider is engaged. A scope is agreed quickly, usually based on what is easiest to test rather than what the business most needs to understand. A few weeks later, a report lands.

Everyone skims the executive summary. A handful of findings are assigned to IT. The PDF is saved in a folder called something like “Security Evidence”. Then everyone moves on. And somehow, this is treated as risk management. It is not. It is buying a security artefact.

Penetration testing can be incredibly valuable. Done properly, it helps validate assumptions, test controls, expose weaknesses and improve the organisation’s understanding of risk. But a poorly scoped pen test, disconnected from the risk management plan, adds very little value beyond giving someone a document to show an auditor or customer.

It might get you through a shallow assurance request. It will not make the business meaningfully safer.

The Problem Starts with the Scope

Most poor penetration testing starts before anyone tests anything. The scope is vague. The objective is unclear. The environment selected is convenient rather than critical. The business has not defined what it wants to learn. No one has connected the test to the risk register, control set, incident history, supplier exposure, customer commitments or crown-jewel assets.

So the test answers a question nobody properly asked. That is how you end up with reports that say useful-sounding things, but do not actually help the organisation make better decisions.

A good pen test should start by asking: “What risk are we trying to understand?”

It might ask: Are we worried about external attack paths into a customer-facing platform? Privilege escalation inside the network? Weak authentication? API exposure? Cloud misconfiguration? Sensitive data leakage? Ransomware pathways? Supplier access? AI-enabled product features? Identity compromise?

Different questions then require different scopes. If you don’t define the question, the report is unlikely to give you a useful answer.

The Annual Pen Test Habit

A lot of organisations treat penetration testing as an annual compliance activity.

Once a year, someone arranges a test. The report goes into the evidence pack. A few findings get remediated. The rest are accepted, deferred or forgotten. The next year, the process repeats.

Annual testing is not inherently wrong. But if the test is not driven by risk, change or business context, it becomes security theatre.

A business that has launched a new customer portal, migrated cloud environments, added AI features, changed identity providers or onboarded a critical supplier may need a very different test from the one it ran twelve months ago. As your risk changes, your pen test cope should change with it.

A Finding is Not the Finish Line

Another common problem is that some organisations treat the report as the outcome. When, in reality, the report should be treated as the beginning of the risk conversation.

A penetration test finding should be connected to the wider management system. What risk does it relate to? Which control failed or needs strengthening? Who owns the treatment? What is the due date? What evidence will show remediation? Does the risk rating need to change? Does the control need retesting? Should policy, training, supplier management or architecture be updated?

Without that linkage, findings become tickets. Some get closed. Some drift. Some reappear next year wearing a slightly different hat.

The real value comes when testing feeds the risk management process, updates the control environment and creates evidence that the business has acted.

“High Severity” Does Not Always Mean “Highest Business Risk”

Pen test reports often use technical severity ratings. That is useful, but it is not the whole story.

A technically severe issue on a low-value, isolated system may not be the organisation’s biggest risk. A moderate issue on a customer-facing platform handling sensitive data might matter far more. A low-rated weakness that enables a known attack chain may deserve urgent attention.

This is where human judgement matters. The business needs to interpret findings in context: asset criticality, data sensitivity, exposure, exploitability, compensating controls, customer commitments, regulatory obligations and operational impact. That judgement should not happen in someone’s head during a meeting with no record.

It should be part of the risk management system.

What Good Looks Like

A useful penetration testing program is not necessarily more complicated. It is more intentional. Good testing usually has a clear purpose. It is tied to business risk. It focuses on systems, processes and attack paths that matter. It is informed by previous incidents, threat intelligence, customer obligations, architectural change and known control weaknesses.

Before the test, the organisation should be able to explain why the scope was chosen.

After the test, it should be able to show what changed. That means:

test objectives are linked to risks
scope reflects critical assets and business context
findings are mapped to controls and owners
remediation actions are tracked
accepted risks are documented properly
evidence is captured as work is completed
retesting happens where needed
the risk register is updated when findings matter

How de.iterate Helps

At de.iterate, we believe security testing should feed governance, not sit beside it.

Our platform helps organisations connect penetration testing outputs to the wider risk and compliance programme: risks, controls, assets, suppliers, policies, assurance tasks, evidence and reporting.

So when a pen test identifies a weakness, it does not disappear into a ticket queue with no business context. It can be linked to the relevant risk, assigned to an owner, tracked through treatment, supported with evidence and reviewed as part of ongoing assurance.

Penetration testing should help the business understand whether its controls are working, where risk is increasing, and what needs to happen next. If your pen test does not tie back to your risk management plan, you may have bought a report. But you probably have not bought much assurance.