iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Most penetration-test findings that stay open are not hard to fix. They stay open because nobody owns the steps after the report arrives: assigning the fix, agreeing what proves it works, and checking it later. A retest programme closes that gap by treating each finding as an owned remediation action with a risk-based priority, a documented verification plan, and a retest record that links back to the original evidence.
The guidance behind this approach comes mainly from CREST’s Guide to Penetration Testing (2022) and the OWASP Web Security Testing Guide’s reporting pages, with NIST SP 800-115 (2008) as general background on technical testing.
Why findings stay open after the report is delivered
Delivering a report is not the same as closing a test. CREST describes follow-up work as a sequence of remediation, root-cause analysis, improvement, effectiveness review, lessons learned and monitored action plans. A programme that stops at delivery leaves most of that sequence undefined, and the findings drift.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The failure points are usually predictable:
- No single person is accountable for a finding from report to verified fix.
- Work is sorted by the order in which findings appear in the report rather than by risk.
- A ticket marked “fixed” is accepted as proof that the weakness is gone.
- No retest date is agreed, so verification happens only when someone remembers it.
- The root cause is never recorded, so the same weakness reappears in the next test.
What a retest programme has to cover
CREST is direct about the follow-up obligation. It states:
#1 Best Overall
“Your penetration testing programme should specify that follow-up activities include remediating weaknesses found during the testing process, in line with a comprehensive and approved remediation process solution, to reduce the risk of them being exploited again.” (CREST, Guide to Penetration Testing 2022, remediation section)
From that guidance, a workable programme needs four things:
- Remediation that covers all reported issues, not only the critical ones.
- Prioritisation by risk. CREST gives risk ratings for critical assets as its example.
- Qualified and experienced security professionals involved in remediation and verification.
- Short-term retesting or verification agreed in advance. CREST asks for this agreement but does not set an interval.
The operating model, step by step
The steps below are a practical implementation of those requirements. The sources set the outcomes; the sequence and labels are editorial choices.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallStep 1: Give every finding a durable record
Each finding needs an identifier that survives the ticketing tool, the report version and the retest. Keep the affected asset, reproduction steps, impact, supporting evidence and a reference to the original report. OWASP asks for enough detail that a reader can understand, reproduce and resolve the issue, and it recommends reproducible artefacts such as requests, screenshots or scripts where they help. If a finding cannot be reproduced by someone who did not write it, its record is not yet complete.
Step 2: Assign two owners
Name a remediation owner, usually the team that runs the affected system, who is responsible for the fix. Name a programme owner, usually in security or governance, who follows status and escalates overdue items. The sources call for action plans and monitoring but do not prescribe a role chart, so this split is a practical choice rather than a requirement.
Step 3: Prioritise by risk and business context
Sort findings by the documented risk rating, adjusted for asset criticality, how easily the weakness could be exploited, and the business impact the report describes. OWASP calls for risk ratings and business impact in each finding, which gives you the inputs. Report order is not a priority signal.
Step 4: Agree what proves the fix before work starts
Before a team starts remediation, record four things:
- The evidence that would demonstrate a successful fix, for example a failed exploitation attempt from the original reproduction steps.
- Who will perform the retest, and whether that person must be independent of the fix.
- Any access, test accounts or environment needed to retest, including whether production or staging is appropriate.
- A target date based on risk and the complexity of the change.
Agreeing the verification method early prevents the common situation where a fix is deployed, nobody knows what to test, and the finding is closed by default.
Step 5: Retest and record an honest status
Link the retest directly to the original finding and report its current status with a cross-reference to the new test. The status should reflect what was verified, not what was done. The table below uses labels that are editorial suggestions for this purpose; the sources require the status and cross-reference but do not prescribe these exact terms.
| Status label | Use when | Record to keep |
|---|---|---|
| Verified fixed | The retest reproduces the original steps and the attack no longer works. | Retest date, tester, evidence and cross-reference to the new test. |
| Partially fixed | The original attack path is blocked but a variant or related path still works. | What remains, the variant tested, and a new target date. |
| Not fixed | The original reproduction still succeeds. | Reason for failure and the next action owner. |
| Risk accepted | The organisation decides not to remediate the finding. | Approver, rationale, residual risk and review date. |
| Not yet verified | The fix is reported as deployed but no retest has occurred. | Planned retest date and who will perform it. |
Only “Verified fixed” should close a finding. A deployment ticket alone is not verification.
Step 6: Analyse root cause and feed lessons back
For each finding, record the root cause as well as the fix. A missing input validation routine in one service often means the same pattern exists elsewhere. CREST links root-cause analysis to broader improvement, patching, testing and lessons-learned work, so the outcome of a retest should inform the next test scope and the teams that build similar systems.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Setting a retest date without an invented deadline
No source reviewed sets a universal retest interval or a mandatory remediation deadline, and no industry-wide service-level figure should be presented as one. Set dates from local inputs instead:
- The risk rating and asset criticality of the finding.
- Whether the fix is a configuration change, a code change or an architectural change.
- Whether the retest needs access that takes time to arrange.
- Any regulatory or contractual obligations that already apply to the system.
Agree the date with the remediation owner before the test is closed, and record it against the finding. A date that is written down and monitored is more useful than a stricter target that nobody tracks.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Writing the retest report so it stays linked
The retest needs to stand on its own and also connect to the original test. OWASP’s Reporting Structure guidance on re-tests states:
“If this is a re-test, you might create a subsection that summarizes findings of the previous test, the updated status of previously identified vulnerabilities, and any cross-references with the current test.” (OWASP, Web Security Testing Guide, Reporting Structure)
In practice that subsection should list every prior finding, its updated status using the labels from Step 5, and a reference to where the new evidence sits. Reading the retest report alone should tell a reader what changed since the original test.
Best Value
Measuring whether the programme works
A retest programme should be judged on whether findings get fixed and stay fixed. CREST’s guidance points toward four measures that can be tracked without external benchmarks:
- How many findings have reached “Verified fixed”, and how long they sat in each status.
- Which findings are overdue against their agreed date, and who owns them.
- Which root causes recur across tests or across systems.
- Whether lessons from the testing have been applied to other environments and to the testing programme itself.
Each organisation must set its own baseline. No published figure in the sources gives a typical share of findings left open or an average remediation time, so comparisons with outside numbers would not be valid.
What the guidance does and does not establish
CREST’s guide dates from 2022. OWASP’s Reporting Structure page is living guidance and may change. NIST SP 800-115, by Murugiah P. Souppaya and Karen A. Scarfone and published on 30 September 2008, describes how to plan and conduct technical tests, analyse findings and develop mitigation strategies. It is useful background but is not a current standard for running a retest programme.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsNone of these sources sets a universal retest deadline, requires the verifier to be independent, or defines an industry-wide retest metric. The programme described here therefore depends on decisions your organisation must make and record: who owns each finding, what evidence counts as a fix, and when verification happens.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
