We are occasionally asked to retest a system another firm assessed six months earlier. It is common to find that almost nothing was remediated. The findings were valid. The report was thorough. It still sat in a shared drive.
The report is the deliverable, not the test
Technical accuracy is the baseline. What determines whether anything changes is whether three different audiences can each find what they need in the report.
- Leadership needs business impact and cost of inaction, in one page.
- Engineering needs reproduction steps and a specific fix, without wading through context they already have.
- Operations needs to know what changes, when, and who approves it.
Rate by exploitability, not by category
Severity scores are useful and they are also frequently misread. A high-scoring finding on an internal-only system behind strong authentication may matter far less than a moderate finding on a public login page. We rate by what an attacker could realistically achieve against your specific environment, and we say so explicitly.
Include the retest in the engagement
Fixes are often incomplete or introduce new issues. Bundling a retest into the original engagement removes the commercial friction of asking for a second piece of work, and it gives the report a verifiable conclusion.
A finding without a remediation path is an observation. It is not a result.
Written by
Samuel Kiyingi
Director of Security, Oasis Hive Limited
