Reporting
Vulnerability remediation plan template, with a worked example
A free vulnerability remediation plan template: the sections to include, the fields to track per action, a worked example and how to keep the plan current between scans.
By Brandon Sooknanan, Founder, Varaxon Technologies · · 5 min read
A vulnerability report says what is wrong. A remediation plan says what will be done about it: which fixes, in which order, by whom and by when. It is the document the people doing the work actually use, and the one an auditor, insurer or client will ask for when they want to know whether findings are being handled.
Below is a template you can copy into a document, spreadsheet or ticketing system, followed by a short worked example.
What a remediation plan contains
- Scope and source. Which systems, which scan or assessment the plan is based on, and the scan date.
- Summary. The number of findings by priority, the number of actions, and the headline risks in two or three sentences.
- Priority method. How findings were ranked, for example CISA KEV first, then EPSS, then CVSS, adjusted for internet-facing and critical systems.
- Deadlines. The target time to fix for each priority, taken from your remediation SLA.
- Action list. The core of the plan: one row per action, using the fields below.
- Exceptions. Findings that will not be fixed on time, with the reason, compensating control, approver and expiry date.
- Verification. When the rescan will happen and who checks the results.
- Sign-off. Who agreed the plan, and the date.
Fields to track for each action
| Field | What to record |
|---|---|
| Action ID | A short reference, for example R-01, or the ticket number |
| Action | What will be done, in plain words: 'Install the October Windows cumulative update' |
| Findings covered | The CVEs or scanner check IDs this action closes, and how many scan rows |
| Affected systems | Hostnames or IP addresses, or a group such as 'all Windows 11 laptops' |
| Priority | The band, with the reason: 'Fix now: on CISA KEV, internet-facing' |
| Owner | The named person or team who controls the system |
| Target date | From the SLA for that priority |
| Status | Not started, in progress, done (awaiting rescan), verified, exception |
| Verification | The scan date that confirmed the fix, or the reason it is still open |
| Notes | Change ticket, maintenance window, dependencies, risks of the change |
Worked example
A small professional services firm, monthly authenticated scan on 3 November: 212 findings across 38 hosts. After merging duplicates and setting aside informational items, they group into seven actions.
| ID | Action | Covers | Priority | Owner | Target | Status |
|---|---|---|---|---|---|---|
| R-01 | Update the VPN appliance firmware | 1 CVE on CISA KEV, 1 host | Fix now (KEV, internet-facing) | Network admin | 6 Nov | Verified 7 Nov |
| R-02 | Install the latest Windows cumulative update on all servers | 41 findings, 6 hosts | Fix next (Critical, high EPSS) | Server team | 17 Nov | In progress |
| R-03 | Update the PDF reader on all workstations | 64 findings, 29 hosts | Fix next (high EPSS) | Desktop support | 17 Nov | Not started |
| R-04 | Replace the end-of-life database server | 18 findings, 1 host | Scheduled (end of life) | IT manager | 31 Jan | Exception until 31 Jan, host isolated |
| R-05 | Disable TLS 1.0 and 1.1 on the intranet server | 3 findings, 1 host | Scheduled (Medium, internal) | Server team | 3 Dec | Not started |
| R-06 | Update printer firmware | 9 findings, 4 hosts | Routine | Desktop support | Next cycle | Not started |
| R-07 | Check reported SMB signing finding on the NAS | 1 finding, 1 host | Possible false positive | Network admin | 10 Nov | Under review |
Seven rows are something a team can work through in a weekly meeting. The original 212-row export is not. The end-of-life server sits in the plan as an exception with an isolation control and a date, so it cannot be forgotten. Our guide to vulnerability risk acceptance covers what to record.
Keeping the plan current
A plan written once and never updated is a snapshot, not a plan. After each rescan:
- Mark actions verified when their findings are gone, with the scan date.
- Add new actions for new findings, ranked the same way.
- Flag actions past their target date and bring them to the next review with a reason.
- Review every exception and its expiry date.
- Look for findings that came back after being fixed, and find the cause.
Over time this record becomes your evidence: when each issue was found, what was done and when it was confirmed fixed. It is also the raw data for metrics such as mean time to remediate.
How it fits with other documents
The remediation plan sits between the vulnerability assessment report, which explains the findings, and the tickets in your service desk, which track the individual changes. For penetration tests, the same structure works for the findings in a penetration test report.
We built Varaxon Scan Hub to produce this plan for you. Upload a scan export and it ranks the findings with CISA KEV, EPSS and CVSS, groups them into remediation actions with the affected hosts, and on the next scan marks what was fixed, what is new and what is still open. Approved actions can become HaloPSA or ConnectWise PSA tickets. See the sample reports, or start a 14-day free trial with no card needed.
Common questions
What is a vulnerability remediation plan?
A document that lists the actions needed to fix the vulnerabilities found in a scan or assessment, with an owner, a priority, a target date and a verification step for each.
What is the difference between a vulnerability report and a remediation plan?
The report describes what was found and why it matters. The plan describes what will be done about it, by whom and by when, and is updated as work is completed and verified.
How often should a remediation plan be updated?
After every scan at minimum, and at each regular review. Mark verified fixes, add new findings, chase overdue actions and review exceptions.
Turn your next scan export into a client-ready report.
Run a free pre-flight check