Remediation: Turning Penetration Test Findings into Action

A report without remediation is just expensive reading.

The penetration test report tells you what is wrong. Remediation is the process of making it right. This is where the real value of a penetration test is realised — or lost. We have seen organisations commission thorough, well-conducted penetration tests, receive detailed reports with clear findings, and then fail to act on them. Twelve months later, the next test finds the same vulnerabilities in the same systems.

Remediation does not happen by itself. It requires ownership, prioritisation, tracking, and verification. This article provides a practical framework for turning your penetration test findings into measurable security improvements.

The debrief — start with a conversation.

Before diving into remediation, hold a debrief meeting with your penetration testing provider. This should include both the business owner (or a senior stakeholder) and the technical team responsible for fixing the findings. The debrief serves three purposes: it ensures everyone understands the findings, it clarifies any ambiguity in the report, and it allows the tester to explain the practical context behind each finding.

A good debrief is interactive — your team should ask questions. 'How did you exploit this?', 'What would an attacker need to reproduce this?', 'Is this finding related to that one?', 'What is the most effective fix?' The tester has context that may not be fully captured in the written report. Use the debrief to extract it.

Prioritisation — fix the right things first.

Not all findings are equal, and you probably cannot fix everything simultaneously. Effective prioritisation ensures your limited resources are applied where they will have the greatest impact on reducing risk.

Assign ownership — every finding needs a name.

Findings without owners do not get fixed. Every finding in the report should be assigned to a specific individual — not a team, not a department, but a named person who is accountable for resolving it within the agreed timeframe.

Track progress — do not let findings drift.

Create a remediation tracker — a simple spreadsheet or project board that records each finding, its severity, its owner, the target resolution date, and its current status. Review this tracker regularly — weekly for the first month after the test, then monthly until all findings are resolved.

The tracker does not need to be complex. What matters is that someone is reviewing it regularly and holding finding owners to account. If a critical finding has not been resolved within the agreed timeframe, it should be escalated — not quietly rolled into the next quarter.

Verify fixes — retesting is not optional.

Once findings are remediated, they must be verified. A fix that you believe works but have not tested may not actually resolve the vulnerability — or may introduce a new one. Retesting involves the penetration testing provider re-examining the specific findings that were remediated to confirm they are properly resolved.

Most providers include retesting of critical and high findings within the engagement price, or offer it as an add-on at a reduced rate. At a minimum, have all critical and high findings retested. For medium findings, retesting can be deferred to the next annual assessment unless they are part of an attack chain.

Do not accept your own team's confirmation that a fix works as a substitute for independent verification. The team that missed the vulnerability in the first place may also miss an incomplete fix. Independent retesting by the original tester provides genuine assurance.

When you decide not to fix something.

Not every finding will be remediated. Some may require disproportionate effort relative to the risk. Some may be in systems scheduled for decommissioning. Some may be inherent to a third-party product that you cannot change. This is acceptable — provided the decision is deliberate, documented, and made by someone with the authority to accept the risk.

For each finding you choose not to remediate, record the reason, who approved the risk acceptance, and any compensating controls that mitigate the risk (for example, network segmentation that limits the impact of the vulnerability). This risk acceptance register is valuable evidence for compliance audits and demonstrates that unresolved findings are conscious business decisions, not oversights.

Part 10 preview.

In the final article of this series, we bring everything together: building a long-term penetration testing programme that matures over time, integrates with your broader security strategy, and delivers continuous improvement rather than periodic snapshots.

Related Articles