A remediation plan turns a penetration test report into owned, time-bound, tracked tasks — and auditors judge the process, not just the fixes. Give every finding a reference, severity, action, owner, deadline, status and evidence. Prioritise by real risk, not raw CVSS. Anything you can't fix now goes on a risk register as formally accepted/deferred, with rationale, compensating controls and a review date. Prove closure with a retest, not self-attestation. What auditors penalise is unmanaged findings — open criticals with no owner, plan or record. Completeness and documentation matter as much as the technical work.
// 01 Why the plan matters as much as the fixes
Here's the uncomfortable truth that catches teams out: you can fix everything and still fail the audit conversation if you can't show that you did it in a managed way. Auditors and regulators aren't only checking whether vulnerabilities are gone; they're checking whether you have a risk-based process for handling them — ownership, prioritisation, decisions, evidence. A remediation plan is that process made visible. It converts a scary list of findings into a controlled, auditable programme, and it's frequently as decisive to a SOC 2, PCI or regulator outcome as the testing itself.
// 02 What each finding needs
Every finding from the report becomes a row in a tracker, with a consistent set of fields. This is the backbone of an acceptable plan:
| Field | What it records |
|---|---|
| Reference | The finding's unique ID from the report |
| Severity | Contextual risk rating (not just raw CVSS) |
| Remediation action | The specific fix to be applied |
| Owner | A named person accountable for it |
| Target date | Deadline set by severity (an SLA) |
| Status | Open / in progress / fixed / accepted |
| Evidence | Proof of closure (ideally a retest) |
The two fields teams most often skip — owner and evidence — are exactly the two auditors look for first. An unowned finding never gets fixed; an unevidenced fix can't be trusted.
// 03 Prioritise by real risk and SLA
Order the work by likelihood × impact in your environment, not raw CVSS — start with anything exploited in the test or reachable from the internet, as covered in triaging findings. Attach a severity-based SLA so remediation doesn't drift: a common baseline is critical within 7–15 days, high within 30, medium within 60–90, low best-effort. Auditors specifically look for timely remediation of high-severity issues, so demonstrable SLAs — and evidence you met them — carry real weight. Banking the quick wins early also shows momentum, which reads well in an audit.
// 04 Documenting accepted and deferred risk
You won't fix everything before every deadline, and that's fine — if you handle it correctly. Never let a finding sit silently open. Instead, formally accept or defer it on a risk register, recording: why it can't be fixed now, any compensating controls reducing the risk meanwhile, the accountable owner, and a date to review the decision. A documented, time-boxed acceptance signed off at the appropriate level is defensible and expected; an undocumented open critical is the classic red flag. The register is what transforms "we haven't fixed it yet" from a failure into a managed, auditable position — and it's the single most common thing weak remediation plans get wrong.
// 05 Closing the loop with a retest
Finally, prove closure the way auditors trust: a retest. Once you've applied the fixes, the testing provider re-attempts each finding, confirms it's actually closed, and issues updated evidence — a revised report or attestation letter — that you attach to the plan. This turns "marked as fixed" into independently verified closure, which is what an auditor accepts. Self-attested fixes without a retest are weaker and sometimes rejected outright, because remediations fail more often than teams expect. A remediation plan that ends in retested, evidenced closure — rather than a column of "done" checkboxes — is one an auditor will accept.
// 06 Frequently asked questions
What is a penetration test remediation plan?
A structured document that tracks how you'll fix the findings — turning the report's list into actionable, owned, time-bound tasks. Each finding records a reference, severity, action, owner, target date, status and evidence of closure. Auditors use it to confirm you're managing findings responsibly, so it's often as important as the test itself.
What does an auditor want to see?
Evidence of a managed, risk-based process: every finding owned with a deadline, risk-based prioritisation, timely remediation of high-severity issues, formal documented decisions for accepted/deferred risk on a register, and proof of closure via retesting. They penalise unmanaged findings — open criticals with no owner, plan or record.
How do you handle findings you can't fix immediately?
Formally accept or defer them on a risk register with the reason, compensating controls, accountable owner and a review date. A documented, time-boxed acceptance signed off at the right level is defensible and expected; an unremediated critical with no record is a red flag.
How do you prove remediation to an auditor?
Through retesting. The provider verifies each fix actually closed the vulnerability and issues updated evidence (a revised report or attestation letter) showing findings remediated and verified. Attaching that turns "marked as fixed" into confirmed closure. Self-attested fixes without a retest are weaker and sometimes rejected.
// 07 Related reading
- How to prioritise and triage findings — ordering the plan by real risk.
- Retesting after remediation and the attestation letter.
- What to do when you "fail" a pentest — the wider recovery.