We Found the Vulnerability in 20 Minutes. The Report Took 3 Days.

On one memorable engagement, I found the critical vulnerability — the one that would have let an attacker take the whole thing over — about twenty minutes after I started. It was a good find, the kind that makes the job feel like magic. Then I spent the next three days writing it up. That ratio shocks every newcomer, and it should, because it is the exact opposite of what the movies and the tutorials led them to expect.

The exciting part — the breaking in — is fast and invisible. The unglamorous part — the report — is slow, difficult, and the only part the client ever actually experiences. Understanding why the ratio runs that way is understanding what penetration testing actually is.

The ratio nobody warns you about

Newcomers imagine an engagement is mostly hacking with a bit of writing at the end. In reality, across a full engagement, the writing and analysis often take as long as or longer than the active testing. The finding is a moment; the report is the deliverable, and deliverables take time to do well.

That chart surprises people, but it reflects the truth of the job. Finding the flaw is the payoff of the enumeration that came before it, and communicating it well is a separate, substantial piece of work. The client is paying for the whole arc, and the largest part of that arc is turning what you found into something they can act on.

Why the report is so much slower

Breaking in is fast because it is a technical act with immediate feedback: it either works or it does not. Reporting is slow because it is an act of translation, and translation is hard. You have to take something you understand intuitively — why this flaw matters, how an attacker would chain it, what the real business impact is — and render it into language a non-specialist can act on, with evidence, severity, and a fix.

Every finding has to be reproduced and evidenced so the client can verify it and confirm the fix later. Its severity has to be justified, not just asserted, because a client will — rightly — push back on a "critical" that is really a "medium". And the remediation has to be specific and achievable, which means understanding the client's environment well enough to recommend something they can actually do. Multiply that by every finding and three days is not padding. It is the job.

What three days actually buys

Those three days produce the thing the engagement exists to deliver: a document that turns your afternoon of testing into lasting security improvement. An executive summary that lets leadership understand the risk without reading the technical detail. A prioritised findings list so the client fixes the most dangerous things first instead of drowning in a flat list. Reproducible evidence for each issue. And clear, achievable remediation guidance for each one.

Writing is a testing skill

Here is the reframing that changes how you approach the whole profession: writing is not a chore you do after the testing. It is part of the testing, and it is a skill you develop as deliberately as you develop your technical ability. A tester who finds ten vulnerabilities and writes them up poorly delivers less value than a tester who finds five and communicates them so clearly that all five get fixed. The client's security improves by exactly the amount your report causes them to change — and a report nobody understands causes no change at all.

This is why PenTest+ weights reporting and communication so heavily, and why so many technically strong candidates are blindsided by the exam. They trained to break in. They never practised the slow, difficult, essential craft of explaining what they broke. If you are preparing, give your writing the respect it deserves: read good reports, practise translating a technical finding for a non-technical reader, and learn to justify a severity rating. The twenty-minute break-in makes the story. The three-day report makes the difference.

The ratio is not a flaw in the profession. It is the profession. The breaking in is what earns you the engagement; the report is what earns you the next one — and, more importantly, what actually makes the client safer. Learn to love the slow part, because the slow part is the part that matters.

How to make the slow part faster

None of this means the report has to be needlessly painful. The testers who write good reports quickly do it by writing throughout the engagement, not at the end. The moment you confirm a finding, you capture the evidence, note the reproduction steps, and draft a first line of the writeup while the detail is fresh — not three days later when you are reconstructing it from memory and screenshots you half-labelled. A finding documented at the moment of discovery is a paragraph; the same finding reconstructed afterward is an afternoon. Good testers also keep a library of clear, reusable explanations for common vulnerability classes, so they are not rewriting the description of SQL injection from scratch every time. The three days are real, but disciplined note-taking during the test turns what could be a week of archaeology into a focused, efficient write-up. The lesson is the same one that runs through the whole profession: the report is not an afterthought bolted on at the end, it is something you build continuously as you go.