What 890 security engagements actually find

We have recorded 6,643 findings across 890 engagements since our platform went live. This is what is actually in them.

Not a vendor threat report, not a survey of what people say they worry about. Our own findings, from our own engagements, counted.

What is being counted, before any of the numbers

The window is October 2021 to August 2026 — the engagements recorded in our own platform. Work from before that lived in a different system and is not counted here, so treat every number as a floor rather than a lifetime total.

890 engagements, 167 client organisations, 6,643 findings. Most of that work is penetration testing; a small remainder is design, code and architecture review. Findings run from 0 to 73 per project, with a median of 5 — and 234 projects produced none at all, which is a result too.

83% of findings map to a named finding type, and the rankings below describe that subset. Severities are the severity we assigned when we wrote the finding, so one a client has since fixed still counts as what it was.

Most of what we find is not critical, and anyone who tells you otherwise is selling

15.7% of everything we report is high or critical. 4.4% is critical.

I want to be blunt about what that means, because it cuts against how our industry sells. If a supplier promises a critical finding in every engagement, one of two things is true: they are testing systems that are genuinely broken, or they are inflating severity so the report looks like value for money. We would rather tell you the system held up.

But do not read that small slice as the unimportant part. It is the entire point. A median engagement of ours produces five findings. On these proportions, fewer than one of them is the finding that could actually hurt you — and the other four are housekeeping: real, worth fixing, and not what you hire a person for.

The whole craft is making sure that one finding is in the report. Everything below is about the difference between the four and the one.

How a finding gets to you

Before any of this reaches a client, it goes through a step most reports never mention, so here is ours with the numbers attached.

Every finding is written by one consultant and reviewed by a second. The reviewer’s job is to be the first person who did not find the bug — somebody who has to be convinced by the evidence written down, rather than by having been in the room when it worked. They can approve it, or send it back.

3,802 findings have been through that review. One in four was sent back.

956 findings were returned to their author before a client ever saw them. That is the number I would want from a supplier and the one nobody publishes, because on the surface it looks like an admission. It is the opposite: it is the only evidence that the second pair of eyes is doing anything. A firm with a 100% first-pass rate does not have a better process than us. It has a rubber stamp.

It is not a slow step — the median finding spends one day in review, and about 2.8 days from written to approved. Across the window that work has been spread over 22 consultants writing and 11 reviewing.

And the severity you read is not something that gets negotiated on the way out: 98% of severities are exactly what the consultant who found the issue first assigned.

The findings that actually endanger a business

Now the part that matters. Take the findings we rate high or critical, and ask a second question of each: when this appears, how often is it serious?

These are not the findings we report most often. Our highest-volume findings — Content Security Policy misconfiguration, missing HSTS, subresource integrity — do not appear on this list at all, and a scanner will hand you every one of them. The findings that fill a report and the findings that endanger a business are almost entirely different sets.

And one class dominates

Group that list by class. Authorization — IDOR, vertical and horizontal bypass, broken access control, anonymous bypass, forceful browsing — comes to 173. Every variety of cross-site scripting combined comes to 128.

Authorization is the single largest class of serious finding we report. When we find something that genuinely endangers a business, it is more often a broken authorization boundary than anything else.

Why authorization is the one a tool will not hand you

This is the part worth internalising, and it is not a marketing line — it follows directly from what these bugs are.

A cross-site scripting payload looks wrong. There is a string with angle brackets in a field that should hold a name. An SQL injection looks wrong. A traversal looks wrong. A tool can pattern-match all of them, because the request itself is malformed. That is why scanners find XSS, and why XSS is the one class that comes close to authorization above.

An authorization bypass is a perfectly well-formed request. A valid, authenticated session asks for object 1,041 instead of object 1,040. Every field is the right type. Every value is in range. The signature verifies. Nothing about it is anomalous in any way a scanner can express — and the server answers, because nobody wrote the check that says this user does not own that object.

To find it, you have to know what object 1,041 is, who is supposed to see it, and what the roles in this system actually mean. That is not pattern matching. That is reading a system the way its developers do, and then asking what they forgot.

It is the reason we exist as people rather than as a product, and the reason this number is the one we care about most.

What happens after we hand the report over

Retesting is part of how we work and it costs you nothing extra. When you have fixed something, you tell us, and we re-run the original attack to confirm it is actually closed. Our median turnaround on that is 0.2 days — about five hours.

The catch is the first step: it starts with you asking. And most of the time, nobody does.

Not asking turns out to be the norm rather than the exception. Roughly three in four of the findings we have handed over have never come back to us to be checked.

And they are not waiting in a queue. The typical unchecked finding was written nearly two years ago — well past the point where anybody circles back. They are not pending. They were settled by silence, and nobody on either side knows whether the fix held.

Before the obvious conclusion, here is the part to our clients’ credit: they triage sensibly. The rate at which fixes come back for checking tracks severity almost perfectly.

A critical finding is nearly four times more likely to be verified than an informational one. Nobody is being careless.

And yet. Six in ten critical findings are never sent back. Across high and critical together, 461 findings we rated as seriously dangerous have never come back to us. Somebody was told about a broken authorization boundary a year and a half ago, and to this day nobody has confirmed it closed.

When a fix does come back, it is right first time in 42% of cases — fewer than half. That is not incompetence: a fix for an authorization bug is often as subtle as the bug, and the only way to know is to look.

Put those together. Most fixes are never checked, and the ones that are checked fail more often than they pass. A finding you never confirmed as fixed is a finding you are probably still carrying.

What we would do with this if we were on your side of the table

Do not judge a report by its critical count. Ask what was tested and what was tried. A clean report from a test nobody pushed on is worse than no report, because it buys confidence nobody earned.

Ask how the report was reviewed. Not whether — how, and how often findings come back. A supplier who cannot tell you their internal rejection rate probably does not measure it.

Fix the hygiene layer with tooling, not with people. CSP, HSTS, TLS configuration and outdated components are over a quarter of our findings by volume, a scanner catches nearly all of them, and none of them appear among the findings that endanger a business. Buying expert hours to find a missing header is a waste of expert hours.

Spend the expert hours on authorization. Every object reference, tested against every role. That is where the serious findings actually are, and it is the work that does not automate.

Then ask for the retest. You are already triaging well — the gap is not that you ignore critical findings, it is that four in ten get checked and six do not. Put the retest in the plan at the start rather than leaving it as something to arrange later, and the number that should reach 100% is the high-and-critical one.

Figures are from our own engagement records, October 2021 to August 2026. Counts and distributions only — no client is identifiable from any number here. Severity is the severity assigned when the finding was written. Finding types are grouped by template; 83% of findings carry one, and the rankings describe that subset.

\n\n