Penetration testing is not a compliance checkbox

Many organisations commission a penetration test because a standard, a regulator or a client asks for one. That is a reasonable trigger. The risk is that the test is then designed to produce a report rather than to find out how an attacker would actually get in.

A vulnerability assessment looks broadly for known weaknesses, often with automated tools, and lists them. A penetration test goes further. It tries to exploit weaknesses, chain them together and show what an attacker could reach. Both are useful. They answer different questions, and a scan relabelled as a penetration test answers neither well.

A test can only find what it is allowed to look at. Excluding the systems that matter most, or testing a staging environment that differs from production, produces a clean report and false confidence.

• Scope by what an attacker would target: internet-facing services, identity systems, and the paths to sensitive data.
• Agree rules of engagement in writing: what is in scope, testing windows, contacts and what to do if a critical issue is found mid-test.
• Choose the level of knowledge deliberately. Black-box testing shows an outsider's view; grey- and white-box testing find more in the same time.

A useful report confirms each finding, removes false positives, explains the realistic impact in the context of the organisation, and gives remediation steps a developer or administrator can act on. Executives need a short account of risk; engineers need reproduction steps. One document can serve both if it is structured for it.

1. What are we trying to learn: whether outsiders can get in, what an insider could reach, or whether a specific system is safe to launch?
2. Which systems and data would hurt most if compromised, and are they in scope?
3. Will testing happen against production, and if not, how close is the test environment?
4. Who on our side will be available during testing to respond to critical findings?
5. Who will fix the findings, and is there time and budget for a retest?

• A short executive summary: the overall exposure, the most serious issues and what they would allow an attacker to do.
• The scope, approach and limitations, so readers know what was not tested.
• Each finding with evidence, affected systems, a severity rating that reflects the organisation's context, and clear remediation steps.
• Attack paths that show how individual weaknesses combine, which is often where the real risk lies.
• Positive observations, so teams know which controls held up.

1. Fix critical and high findings first, and track each one to closure.
2. Retest to confirm fixes, rather than assuming them.
3. Look for the root cause. The same weakness will recur if the build or deployment process produced it.
4. Test again after significant changes, not only on the anniversary of the last test.

Some standards set a minimum frequency. PCI DSS, for example, requires internal and external penetration testing at least once every twelve months and after significant changes. Treat the minimum as a floor. The point of the exercise is a system that is harder to break, and the report is only evidence of that.