Pentest Remediation and Retesting: Closing the Loop
A penetration test only reduces risk when its findings get fixed. Yet many reports end up in a shared drive with half the issues still open a year later. Here is a process that turns findings into fixes and fixes into evidence.
Step 1: Triage within 48 hours
As soon as the report arrives, hold a short triage session with engineering leads:
- Confirm each finding is understood and reproducible.
- Assign an owner.
- Set a target date based on severity.
- Flag anything that needs an immediate hotfix.
Step 2: Set remediation timelines by severity
Many teams adopt timelines like these. Adjust them to your risk appetite and contractual commitments.
| Severity | Target time to fix |
|---|---|
| Critical | 24 to 72 hours |
| High | 7 to 14 days |
| Medium | 30 to 60 days |
| Low | 90 days or next planned work |
| Informational | Review and decide |
Write the timelines into your security policy. Auditors check that you follow your own policy.
Step 3: Fix the root cause, not the symptom
If a tester found an IDOR on /api/invoices/{id}, the real question is why the endpoint did not check ownership, and whether other endpoints have the same gap. Good fixes:
- Centralise authorisation checks in middleware or a policy layer.
- Use parameterised queries everywhere, not just on the reported endpoint.
- Add a regression test that would fail if the bug returned.
Step 4: Track everything
Create a ticket for each finding in your normal issue tracker, linking to the report. Record the fix, the pull request and the deploy date. This trail is what turns "we fixed it" into evidence.
Step 5: Retest
A retest confirms the fix works and was not bypassed by a variation. It also catches partial fixes, such as validating input on one parameter but not another. Retesting should produce a dated result showing each finding's new status.
Step 6: Handle what you will not fix
Sometimes a finding is not worth fixing, or cannot be fixed yet. Document a risk acceptance: the reason, compensating controls, who approved it, and a review date. This is acceptable to auditors when done deliberately.
Step 7: Learn from patterns
After the cycle, review the findings as a group:
- Do most issues come from one area or one type of bug?
- Would a linter rule, framework change or code review checklist have prevented them?
- Should developers get targeted training?
What auditors and customers want to see
- The original report.
- Tickets showing ownership and fixes.
- A retest result.
- Risk acceptances for anything left open.
Retest without the wait
With traditional providers, a retest is often a separate booking. SecurityInfinity lets you rerun tests on demand, so you can verify each fix as soon as it ships and export an updated report. Start free.
Frequently asked questions
Is a retest required for SOC 2?
Not explicitly, but auditors look for evidence that findings were addressed, and a retest is the clearest proof.
What if a retest finds the issue is still there?
Reopen the ticket, investigate why the fix was incomplete, and retest again. It is common for the first fix to miss a variant.
How long should we keep pentest records?
Keep them for at least the length of your audit cycles and customer contracts. Many companies keep them for several years.