The same finding, written five ways
Look at a year of your reports and pick a common finding, such as missing security headers or an outdated TLS configuration. You will probably find it written up five different ways. One tester's version has a thorough description and a clear remediation. Another's is two lines. Severity ratings differ. One version references a guidance document that has since been updated. Some still carry a phrase copied from a report years ago.
Each tester keeps their own snippets in a text file or an old report, and copies from them. When they write a finding they have not written before, they start from scratch, even if a colleague wrote the same one last month.
Clients who get tested by different people in different years notice the inconsistency. So does your QA reviewer, who spends time correcting the same write-ups repeatedly.
Your reporting platform may already have a findings library feature. The problem is rarely the feature. It is that nobody owns the content, so it goes out of date and testers stop trusting it.
Why findings libraries decay
- Nobody is responsible for each entry, so none are updated.
- Testers improve write-ups in their own reports but the improvement never reaches the library.
- References and guidance change, and old entries keep citing outdated sources.
- Severity rating approaches differ between testers and are not written down.
- It is quicker to copy from your own last report than to search a library you do not trust.
What inconsistency costs
| Problem | Effect |
|---|---|
| Rewriting common findings | Report time spent on repetition |
| Different write-ups for the same issue | Clients question your consistency |
| Different severity for the same issue | Harder conversations about ratings |
| Outdated references | Report looks less current than your testing |
| QA correcting the same text | Reviewer time wasted |
The findings library we build and keep alive
- We start by gathering findings from your recent reports, grouping duplicates and presenting each group to a senior tester to choose or merge the best version.
- Each approved entry has an owner, a severity guideline, a description, a remediation section, references, and a review date.
- The library plugs into your reporting platform, such as Dradis or PlexTrac, through its API or import format, so testers search and insert approved entries where they already write reports.
- When a tester improves an entry in a report, they can propose the change back to the library in one click. The owner reviews and accepts or rejects it.
- Entries past their review date appear on the owner's list, and references are checked periodically for broken links.
- Usage is tracked, so you can see which entries are used most and focus care there.
An AI model can help with the first merge, suggesting which write-ups describe the same issue and drafting a combined version, but a senior tester approves every entry. The library carries your firm's judgement, not a model's.
What report writing is like afterwards
Testers insert the approved write-up for common findings and spend their writing time on what is specific to this client: the evidence, the context, the business impact. QA reviews focus on the new material. Clients see consistent write-ups and ratings year to year, whoever tested. And the library improves over time because improvements have a route back into it.
New testers get up to speed faster too, because the library shows how your firm describes and rates common issues.
Here is what that looks like on a normal report day. A tester finishes a web application test with a dozen findings. Eight are common issues: they search the library inside the reporting platform, insert the approved entries, and add the client's evidence and context. The four unusual ones they write from scratch, and flag one of them as a candidate for a new library entry. The report reaches QA a day earlier than it would have, and the reviewer spends their time on the four new write-ups.
Recognise this in your reports?
- Testers copy findings from their own old reports.
- The same issue is rated differently by different testers.
- Your findings library exists but nobody trusts it.
- QA corrects the same write-ups repeatedly.
- References in reports are sometimes out of date.