We have been running engagements since 2019. In that time, the most consistent pattern we have observed is not what happens during the test — it is what happens after the report arrives.
The findings do not fix themselves. That is obvious. But the specific ways that remediation stalls or fails to happen are worth documenting, because most of them are predictable and a few of them are avoidable.
The report goes to the wrong person
Pentest reports are often commissioned by a CISO or an IT manager and then circulated to a developer team that had no involvement in scoping the engagement. When those developers open a 60-page document written in security language and see a list of findings they need to fix, the most common response is to add it to the backlog. Not because they are negligent — because they need context that is not in the document.
The walkthrough call we run after every engagement exists specifically for this reason. Getting the people who will do the remediation work into a room, even a virtual one, to ask questions about specific findings changes how they prioritise the work.
Critical findings get fixed. Medium findings drift.
There is a reliable pattern in post-report remediation timelines. Critical findings — SQL injection, broken authentication, remote code execution — get addressed relatively quickly. The risk is obvious, the fix is usually specific, and there is pressure to close them before the next audit or client review.
Medium-severity findings are where things stall. "Clickjacking protection missing" or "verbose error messages in API responses" are real risks that take an afternoon to fix, but they sit in the backlog for months because they do not trigger the same urgency. Then a second test comes around and the same findings reappear.
One approach that works: a separate, short findings list ordered by implementation effort, not severity. A developer can close five medium findings in a day if they can see which ones are fast to fix. That list does not replace the full report; it sits alongside it.
Remediation guidance that is too generic
We try to write specific remediation guidance. "Add the Content-Security-Policy header with the following values" is more actionable than "implement appropriate CSP headers." The difference in effort to follow the instructions is small; the difference in time-to-fix is measurable.
If you receive a pentest report with generic remediation guidance, it is worth pushing back on that before the engagement closes. A good consultant should be able to turn generic guidance into something specific to your stack without significant additional effort.