A test finds what is wrong with one system on one date, which makes the date and the scope as important as the findings.
Why it matters when the plan changes
Security assurances are otherwise self-reported. A penetration test is the one common piece of evidence produced by someone with an incentive to find problems rather than to describe controls. For a system holding assessment data about identifiable people, it is the minimum a security reviewer will expect to see, and the report matters more than the fact of the test. Article 32 of the GDPR requires security measures appropriate to the risk, and a test is one way that adequacy is checked rather than asserted.
The tension is that a clean report is a statement about the past, a point-in-time result rather than a permanent security claim, and not the same thing as a formal certification. Code changes, dependencies update and a system tested in spring is a different system by autumn. Suppliers present tests as permanent facts; reviewers should read them as dated. The honest form states the date, the scope and what has changed since.
In practice
A supplier's security page says the platform is penetration tested. The report, when asked for, is fourteen months old and covers a version before a major rewrite. Nothing on the page was false. The reviewer now has to treat the current system as untested, and the supplier's other assurances are read more carefully than they would otherwise have been.
Evidence
Penetration testing targets components or the whole application to determine whether vulnerabilities can be exploited.
National Institute of Standards and Technology, Computer Security Resource Center glossary (2026)Security measures must be appropriate to the risk, and a test is how their adequacy is checked in practice.
Article 32, General Data Protection Regulation (2016)
What it cannot tell you
A penetration test tells you what testers could exploit within an agreed scope on specific dates. It says nothing about what was excluded from scope, weaknesses outside the testers' skill set, or the system as it exists after the next code change. It is evidence of a moment, not a continuous guarantee of security.
Questions
The scope tested, the dates, the methodology, the testers' independence, each finding with its severity and evidence, the fix applied and whether it was retested. A summary letter saying the test happened is not a report, and a reviewer will ask for the full document.
At least annually and after any material change to the code, the infrastructure or the way data flows. A test before a rewrite says nothing about the system after it. The interval should be stated in the security documentation rather than left to be inferred from the date on the last report.
No. A code review reads the source for weaknesses; a penetration test attacks the running system from outside. Each finds things the other misses, which is why an assurance that covers both source code and the live platform is stronger than either alone.
It means the testers did not find exploitable weaknesses within the scope on those dates. It says nothing about what was out of scope, what has changed since, or what a differently skilled attacker might find. A clean result is useful evidence and a limited one, and it should be described as both.
Testers independent of the team that built the system, with the scope and rules agreed in writing beforehand. Internal testing is valuable and is not independent. A reviewer will look at who did the test and whether they had any stake in the result before reading the findings.