Why the Report Takes Longer than the Test, and What Actually Fixes It

The report takes longer than the test because most of the time after testing goes on describing weaknesses your firm has written up before, formatting, and reconciling the edited Word document with the record, not on writing new findings. Ask a room of testers where their week goes and you get the same shape: four days of testing, then two to five days of writing, formatting, reviewing, re-formatting and chasing.

The testing is what the client is buying. The rest is what determines whether the engagement was profitable. Most attempts to fix this go after the writing, which is the one part that is genuinely irreducible. The recoverable time is almost all somewhere else.

Where the days actually go

Roughly, and in our experience of watching a lot of firms do this:

Two thirds of the time after testing goes on work that produces nothing a client can tell apart from the alternative. That is the target.

The first leak: writing the same finding again

Across a year, a firm of six will write up SQL injection, missing security headers, weak transport configuration and verbose error messages dozens of times. Each instance feels like ten minutes of work. Multiplied out it is weeks, and the output is worse than it should be, because the twentieth description is written in a hurry by whoever drew the short straw rather than being the best version your firm has produced.

The fix is a house library of findings: the wording your firm has agreed on, with the remediation you actually recommend, the references you actually cite, and the scoring you have already argued about once. Instances are then edits rather than compositions.

The reason most libraries fail is worth naming. They get built as a separate document, they drift, and after a few months nobody opens them. A library only survives if saving to it happens in the same place as the writing, and pulling from it is faster than typing, which is the whole argument of building a findings library your team actually uses.

The second leak: the document and the record disagree

Here is the pattern that costs the most and gets discussed the least. The platform generates a report. Somebody opens it in Word, because that is where the last ten per cent of polish happens: a sentence rewritten for a nervous client, a screenshot moved, a finding dropped after a conversation. The edited document goes to the client.

At that moment the record and the deliverable diverge permanently. The retest six months later starts from a record that does not match what the client is holding. The client asks a question about a paragraph nobody can find. And the next engagement for the same client starts from a slightly wrong baseline.

Most firms handle this by trying to stop people editing in Word. It never works, because the editing is where the judgement lands.

The fix is not to prevent the edit. It is to let the edit come back.

The third leak: formatting

Every hour spent on layout is an hour spent producing something the client will not notice unless it is wrong. Worse, inconsistent formatting between quarters becomes a talking point: a client comparing this report with last quarter’s sees the document change shape and asks about the document instead of the vulnerabilities.

Generation from a single agreed template removes the entire category. The same engagement should produce the same document every time, so the only differences between two reports are the findings. Setting up report templates shows what mapping a template once involves.

What to change first

1. Measure one engagement honestly. Ask the tester to note the hours after the last test day, split into writing, reusing, formatting and chasing. One data point beats a year of assumptions.
2. Start the library with your top ten. Not a taxonomy project. The ten weaknesses you actually write up most, in the wording you want, saved as you write the next instance.
3. Freeze the template. One agreed document, mapped once. Every change after that is a change to the template, not to a report.
4. Close the loop on edits. Whatever tooling you use, get the Word edits back into the record. If that is manual today, make it deliberate rather than accidental.
5. Review inside the workflow. Comments on the finding, not in an email thread that has to be reconciled later, as in a QA process that survives a busy month.

What good looks like

• A common finding takes minutes to write because the house version already exists.
• Nobody touches layout during an engagement.
• The record matches the delivered document, including the last-minute edits.
• The executive summary is assembled from the findings, then edited by a human for the part that requires judgement, as described in writing an executive summary that gets read.
• Reports go out the same week the testing ends, and margin stops being a mystery.

None of this makes the writing itself faster, and it should not. The sentence explaining what a weakness means for that particular business is the thing your client is paying for. Everything around it is overhead, and overhead is negotiable.