Retest fixes and close findings
Agree what a retest must prove, distinguish fixed from mitigated or untested findings, and keep an evidence-based closure record.
Close a security finding when the agreed evidence supports the closure decision. A developer's change, a successful deployment and an effective security fix are related events, but they answer different questions.
A retest is usually narrower than a new assessment. Define that boundary explicitly so a successful result is not mistaken for a fresh review of the entire service.
Agree the retest question before changing the service
Use the original finding to describe the security property that should hold. In the fictional HWP-04 finding, the property is: an ordinary customer can retrieve only attachments they are entitled to access.
An effective retest plan identifies:
- The original finding and restricted evidence record.
- The fixed release, configuration and environment.
- Test accounts and synthetic data needed to reproduce the relevant conditions.
- The original check and a justified set of adjacent checks.
- Expected denied and permitted outcomes.
- Changes outside the retest and known limitations.
- Who will record the result and who can approve closure.
OWASP's reporting guidance recommends making retest findings traceable to the earlier report. A stable reference is useful even when the implementation changes substantially.
Worked before-and-after example
This is an original fictional example using authorised synthetic customer records. It continues the annotated finding in reading a report.
| Stage | Recorded observation | Interpretation |
|---|---|---|
| Original assessment | A test customer retrieved another test tenant's attachment | The tested access boundary failed |
| Proposed change | The team adds a server-side entitlement check to the download handler | A plausible remedy; effectiveness is still to be tested |
| Retest of original path | The first customer receives the agreed denial response for the other tenant's record | The original observation is no longer reproducible in this condition |
| Adjacent check | A second supported attachment route also denies the same cross-tenant request | The verified coverage extends beyond the original handler |
| Authorised access check | Each customer still retrieves their own synthetic attachment | The change has not simply disabled all retrieval for these cases |
| Coverage limit | The bulk-export function was excluded from this retest | Its security is not established by this result |
The result supports closure for the verified routes and release. If the original finding encompassed bulk export too, leaving it untested would require further work or a qualified status rather than complete closure.
Use statuses that describe the evidence
| Status | Meaning in the working record |
|---|---|
| Fixed and verified | The agreed checks support the remedy in the recorded scope |
| Partially fixed | Some affected conditions are corrected; identified conditions remain |
| Mitigated | A compensating control reduces exposure; the underlying weakness may remain |
| Still present | The relevant failing behaviour is reproducible |
| Not retested | Access, environment or time prevented the necessary verification |
| Risk accepted | An authorised owner made a documented treatment decision; this is not evidence that the flaw is fixed |
Define these terms with the provider and your tracking system. Avoid a single “closed” label that hides very different outcomes.
Keep this closure record
Fictional record: HWP-04, revision 2
| Field | Completed example |
|---|---|
| Change | Server-side entitlement checks added to the agreed attachment routes |
| Tested build | Portal 2.4.1 in the representative pre-release environment |
| Test basis | Original HWP-04 evidence plus the adjacent route agreed in the retest scope |
| Results | Cross-tenant access denied; own-tenant access permitted for both synthetic customer accounts |
| Evidence | Restricted retest record R-04, containing timestamped requests, account references and build identifier |
| Limitation | Bulk export not covered; tracked separately under the service's assessment plan |
| Proposed status | Fixed and verified within the stated attachment-route scope |
| Closure responsibility | Service owner confirms the scope matches the finding and accepts the recorded limitation |
| Deployment check | Release owner confirms the verified build and configuration reached production |
In a real record, add the actual verification date, responsible people and evidence location. Never backdate a retest or mark a test complete because the fix is scheduled.
Recognise when a broader test is needed
A narrow retest may be insufficient when the remedy changes authentication, introduces a new dependency or substantially alters the architecture. Agree whether the new behaviour needs a fresh assessment. The GOV.UK Service Manual treats testing as ongoing work through service development, particularly around significant changes.
Also check deployment coverage. A corrected component on one server does not establish that every instance or customer environment received it. Ask the platform owner to provide appropriate deployment evidence, then decide whether representative or wider verification is needed.
Finish the engagement cleanly
Remove temporary access according to the agreed plan, confirm any retained evidence arrangements and record unresolved issues in the remediation backlog. Keep the original report, corrections and retest outcome linked.
The useful final statement is precise: what was verified, in which version and scope, when, and by whom. It gives the next service owner something stronger than an unexplained green status.
Sources and further reading
- OWASP Web Security Testing Guide v4.2: Reporting — checked 2 November 2026
- GOV.UK Service Manual: Vulnerability and penetration testing — checked 2 November 2026