The pentest is the easy part. The remediation is where most organisations lose the value of the investment. A confidential 60-page report shows up. It contains 47 findings ranging from critical to informational. Nobody owns it. Six months later it is still on the same shared drive, untouched, while the same vulnerabilities sit live in production.
A pentest delivers value only if you act on it. Here is the 90-day playbook to do so.
Week 1: triage the findings, not the report
Within five working days of the report landing, hold a triage session with engineering leadership, security, and the executive sponsor. The goal is not to read all 60 pages. The goal is to classify every finding into one of four buckets: fix this sprint (critical, exploitable now), fix this quarter (high severity, not actively exploitable), fix this year (medium, fix as part of normal hygiene), and accept (low or no real-world risk in your context).
Document the rationale for everything in the "accept" bucket. If a finding later becomes an incident, "we accepted the risk" with no written reasoning is the wrong answer.
Week 2: assign owners and timelines
Every finding that is not accepted gets a named owner and a target fix date. Owners go into your normal ticketing system. Targets must be realistic but firm. Vague "ASAP" deadlines guarantee no progress.
For the critical bucket, identify whether any of the issues are still being actively exploited. If so, contain before fixing.
Weeks 3 to 8: actually do the work
Most teams underestimate this phase by half. Fixes look small in a report and turn out to involve dependency upgrades, configuration changes across multiple environments, regression testing, and downtime windows. Build slack into the schedule.
- Hold a weekly 30-minute remediation review. Track open and closed counts.
- Group related findings to fix in single deployments.
- Where the same fix closes multiple findings, mark all of them. The aggregate count matters for the eventual retest.
- Update the ticket with evidence of fix (commit, change ticket, screenshot) before closing.
Weeks 9 to 10: validate before requesting a retest
Before paying for an external retest, do your own internal validation. Re-run the relevant scans. Manually verify the critical fixes. Have a different engineer check at least 20% of the closed tickets. Anything that fails internal validation goes back into the queue.
Weeks 11 to 12: external retest
Commission the retest with the original pentest provider. A good retest validates the findings that were marked closed and produces a clean letter you can share with customers, insurers, and auditors. Anything still open returns to the queue for the next cycle.
What good looks like
Within 90 days of receiving the report, you should have closed every critical and high-severity finding, addressed most mediums, written rationale for accepted risks, and obtained a clean retest letter. Six months later, the next pentest should produce a substantially shorter report. That is the loop. Run it twice and your risk posture is meaningfully different.