A penetration test only reduces risk if its findings are fixed, retested and shared. The ICO found that Capita tested systems holding millions of records only when someone commissioned a test, never retested them, and kept findings inside individual business units, so network wide risks were not consistently addressed.
What the regulator wrote
In the Capita decision the ICO noted that systems holding millions of records, some with sensitive data, were penetration tested only when commissioned and were never retested. It also noted that findings stayed within business units. Its recommendation was to share penetration test findings across the organization.
None of this says Capita did no testing. The criticism is about what happened around the test.
Three ways a test report goes to waste
It is a one time event. A test describes a system on one day. Systems change weekly. Without a schedule tied to risk, results age quickly.
There is no retest. A finding marked fixed by the team that owns it is a claim. A retest turns the claim into evidence.
The findings stay local. If one business unit learns that a certain admin configuration lets an attacker move sideways, every other unit with the same configuration needs to hear it. A report filed in one folder helps one team.
A lightweight process that works
- Keep one register of all test findings across the organization, not one per team.
- Tag each finding with the weakness type, such as weak credential storage or missing segmentation.
- When a type appears twice, ask where else it could exist and check.
- Require a retest, by the testers or an independent person, before closing anything rated high.
- Review the register monthly with someone who can unblock work.
Step three is where cross unit learning happens. It takes an hour a month and finds the problems that matter most.
Decide testing frequency by data, not by habit
Systems that hold large volumes of personal or sensitive data deserve a recurring schedule, not a one off. Many teams also test after major changes such as a new integration or a platform migration. Write the trigger down so testing does not depend on whoever remembers.
Complement tests with continuous checks
A test shows what a skilled person found in a few days. Continuous scanning of dependencies and exposed assets covers the gaps between tests. Safeguard's SBOM and dependency scanning, reachability analysis and asset discovery can fill that role, and its free scan at https://gold.safeguard.sh/scan is a quick way to see what a repository contains. It does not replace a manual test.
Try it yourself
Click through it and watch how a new finding appears between scheduled tests.
Click through it at your own pace, or open it full screen.
Quick check
Who should retest a high severity finding?
Ideally the original testers or someone independent of the team that did the fix, so closure rests on evidence, not on the fixer's say so.
Do findings really need to be shared across business units?
The ICO's recommendation says yes. Weaknesses that repeat across units are the ones attackers use to move through a whole network.
Sources
Last reviewed: 19 October 2026.
