Faster penetration testing that turned ten days into two

A recent assessment of a digital-health platform was planned for ten working days. We completed the testing in two. The first findings reached the client the day after we received access, the full report followed a day later, and the retest and sign-off were done within four days, well ahead of the date in the proposal.

We share this not to boast about speed for its own sake, but because it shows what becomes possible when the work around a tester’s judgement is handled well. The client remains anonymous, and we will not add details about their systems or their findings. The lesson is in the shape of the engagement, not in its particulars.

Anyone who has run a traditional assessment knows that the hours spent on careful, creative testing are only part of the bill. A great deal of time goes on repetitive coverage, working through the same classes of check across every page and endpoint. More goes on capturing evidence, writing it up and formatting the report. And once the report lands, more time again is lost in back and forth as engineers try to reproduce what the tester saw.

Each of those steps is necessary, yet very few of them call for the rare skill a client is really paying for. That is the gap Pentriarch was built to close.

No, and we want to be very clear about that. The judgement on this engagement was human, and some of the most important findings came from hands-on work. Machines are not yet good at understanding what an application is meant to do for whom, and that understanding is where many serious weaknesses hide.

It is telling that OWASP places broken object level authorisation at the top of its API Security Top 10. A flaw of that kind is the application doing exactly what it was built to do, only for the wrong user, and spotting it usually takes a person who understands the business behind the code.

What changed was everything around that judgement. Our engine covered the repetitive ground, which freed the testers to spend their time where it counted. Every finding came with proof the client’s engineers could replay, so they could see the issue for themselves rather than wait for a meeting to have it explained.

That replayable proof is the quiet hero of the story. When a developer can reproduce a finding in minutes, the conversation moves straight from whether the issue is real to how best to fix it. Reports stop being documents to argue over and become work that can begin the same day.

The retest replayed the original proof against the fixed system and confirmed exactly which fixes held. That is a very different outcome from a ticket marked as done. A finding is only treated as verified fixed when the application answered and the same validator no longer matched, and anything that could not be judged is reported as inconclusive rather than quietly closed.

Because the evidence was already in a replayable form, the retest did not need a fresh round of discovery. That is a large part of why sign-off came within days rather than weeks.

If you are commissioning an assessment, this engagement suggests a few simple questions worth asking any provider. Ask how soon you will see the first findings, rather than waiting for a final report. Ask whether each finding will come with proof your own engineers can replay. Ask how the retest works, and whether it will tell you plainly, finding by finding, what is fixed and what is still open.

And ask where the human expertise goes. A good answer is that experts are free to focus on the hard problems while the evidence speaks for itself. That is the kind of testing we believe in.

Our interactive product tour at pentriarch.com/demo walks through the workflow from scope to signed report in a few minutes, and the 14-day pilot at pentriarch.com/pilot lets you run an assessment on a system you own with no card required.