From penetration test report to fix plan
What to do in the two weeks after the report arrives, so the findings end up fixed and retested rather than filed.
Read the scope section first, re-rate each finding against your business, make sure the system owner understands how it was reached, and group findings by cause. Then give each cause an owner and a date, write down any risk you accept, and book the retest before the plan is signed off.
Updated · 6 minute read
Read the scope section first
Start with what was tested, not with the findings. What was not tested, and why, matters as much as what was. A system outside the scope has no findings because nobody looked, not because it is sound.
Compare the scope as tested with the scope you signed. Note every target that was dropped, every role that was not used, and any nights lost to access problems. Those gaps go into the fix plan as items of their own, usually as scope for the next test.
Severity, re-rated for your business
The severity in the report is the tester's rating of each finding in isolation. Re-rate it against your business: what the system holds, who can reach it, and what stops if it fails.
A critical on a lab server with no data may matter less than a medium on the page that takes payments. Keep both ratings in your register, the tester's and yours, with a line on why they differ. Anyone who reads the register later, an auditor or a customer, will want that line.
| Question | How it moves the rating |
|---|---|
| What does the system hold? | Customer and personal data raise it. Test data with no copy of anything real lowers it. |
| Who can reach it? | Anyone on the internet raises it. A network segment only a few staff can reach lowers it. |
| What depends on it? | Payments, orders or production raise it. |
| Is there a control the tester could not see? | It may lower the rating. Write down what the control is, so the reason survives the next review. |
Understand each finding before anyone fixes it
For each finding, the system owner should be able to explain how the tester reached it and what an attacker would gain. You are reproducing your understanding, not the exploit.
Do not re-run exploit steps on production to check the tester's work. If the evidence is unclear, ask the provider to walk your team through it.
A finding nobody on your side can explain is usually fixed in the wrong place. The symptom gets patched on one page and the cause stays in shared code.
Group findings by cause
Reports list findings one by one; fixes work by cause. Fourteen missing patches are one finding about the patching process. Six access control issues across one API are often one missing check in shared code.
Grouping shrinks the plan to something a team can own. It also changes the fix. Patching fourteen servers closes fourteen findings. Fixing the patching process stops the fifteenth from appearing in next year's report.
Keep the link from each cause back to its findings. The retest works finding by finding, and the register has to show which findings each cause closes.
Owners, dates and written risk decisions
Each cause gets one named owner and a date. Anything you decide not to fix gets a written risk decision: what the risk is, why it is accepted, who accepted it, and when it will be looked at again.
One owner per cause, not a team. A date agreed with that person, not set for them.
For a risk you accept, the person signing must have the authority to accept it for the business. That is rarely the IT manager alone.
Book the retest before sign-off
Book the retest with the provider before the fix plan is signed off, dated after the last fix is due. A retest left until the fixes are done tends not to happen.
Check the retest terms agreed before the test: what is included, and how long after the report it can be booked. The provider that found each issue retests it, which keeps the confirmation independent of the people who planned the fix.
What to send a customer who asked for the report
Often a summary letter from the provider, not the full report. A full report is a map of your weaknesses. Ask the customer what it needs to see; a letter stating what was tested, when, by whom and the position after retest often answers it.
If the customer insists on the full report, send it under a confidentiality agreement, after the retest, with the closure register beside it. A report sent before the fixes shows open findings with no evidence they were ever closed.
The fix plan template
One row per cause, not per finding. The columns below are enough for most plans, and each one holds something an auditor or a customer may ask to see later.
| Column | What goes in it |
|---|---|
| Cause | One sentence naming the underlying problem, such as no authorisation check in the orders module. |
| Findings | The report's finding numbers this cause explains. |
| Your severity | Re-rated for your business, with the tester's rating beside it. |
| Owner | One named person. |
| Fix | The change to be made, specific enough for someone else to check. |
| Due date | Agreed with the owner. |
| Risk decision | For anything not fixed: accepted by whom, why, and when it is reviewed. |
| Retest | The date booked with the provider, then the result for each finding. |
| Status | Open, fixed and awaiting retest, or closed on retest. |
Questions after the PDF lands
There is a critical finding we cannot fix quickly. What now?
Reduce the exposure while the fix is built: restrict access to the system, switch off the affected feature, or put a control in front of it. Record that in the plan as an interim measure with its own owner, and keep the finding open until the provider retests the real fix.
Do we have to fix every finding?
Every finding needs a decision, not necessarily a fix. Fix it, or accept the risk in writing with a named person and a review date. Informational findings usually need only a note.
How long should fixing take?
That depends on the cause, not the severity label. Your own policy, a customer contract or a regulator's control may set time limits by severity. Where none does, set dates with each owner and write them into the plan.
Can the provider write the fix plan?
Its remediation advice is the starting point. The plan itself has to be yours, because only your team knows which causes share code, which systems matter most and who can own each fix.
Where to go next
Commissioning a penetration test
The report read with you, findings grouped by cause, and the closure register kept up to the retest.
Read moreGuideWhat a good report contains
Before you start re-rating, check the report gives you enough to work with.
Read moreGuideHow to scope a penetration test
The gaps you found in the scope section become next year's scope. How to write it.
Read moreITF DigitalWhen the causes are in code
ITF Digital builds applications, and can work on causes a report traces back to application code.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Read the report with someone on your side
We walk through the report with you and your IT team, recheck severity against your business, group findings by cause and turn them into a fix plan with the retest booked.