Vulnerability reporting and remediation tracking
In short: Finding vulnerabilities is only useful if they get fixed. Good programmes assign each finding to an owner, set due dates by priority, manage exceptions with expiry dates, verify fixes, and report a few clear metrics to technical teams and management.
From findings to fixes
Scanners and testers can produce thousands of findings. Without a tracking process, those findings sit in reports nobody reads. Remediation tracking makes sure every important finding has an owner, a due date and a status, and that it is only closed when the fix is proven.
Owners and SLAs
Findings should go to the team that can fix them, usually by mapping assets to owners in the inventory or configuration management database (CMDB). Group findings sensibly: one ticket for "upgrade the web server package on 40 hosts" is far more useful than 40 separate tickets.
A remediation SLA (service level agreement) sets how long each priority may stay open. The numbers below are an example only; each organisation agrees its own in policy.
| Priority | Example target | Typical trigger |
|---|---|---|
| Emergency | 48 to 72 hours | Actively exploited and internet facing |
| High | 14 days | Severe, exploitable, important asset |
| Medium | 30 to 60 days | Moderate risk or internal only |
| Low | 90 days or next refresh | Minor impact, well mitigated |
Exceptions and risk acceptance
Sometimes a fix is not possible in time: the vendor has no patch, or an upgrade would break a critical application. That is acceptable if it is handled openly through an exception (risk acceptance) process:
- The owner explains why the fix cannot be done and what compensating controls are in place.
- Security reviews the remaining risk.
- Someone with the authority to accept that level of risk signs it off, usually a business manager, not the IT technician.
- The exception gets an expiry date and a review reminder.
- Expired exceptions are escalated automatically.
Reporting for different audiences
- System teams need actionable lists: what to fix, where, how, and by when.
- IT managers need trends by team: overdue items, ageing and SLA compliance.
- Executives need a short view of risk: are the most dangerous exposures being closed quickly, and where is help needed?
Avoid vanity metrics such as "total vulnerabilities found", which rises whenever you scan more and says little about risk. Trends in time to remediate and overdue critical items tell a truer story. Also track recurrence: findings that come back often point to a broken build image or process.
Tip: if a fix is closed without rescanning, you are reporting intentions, not results. Make verification evidence part of closing every ticket.
Real-world example: monthly reporting at a housing association
A fictional housing association scans its network every week but fixes little, because results go to one shared mailbox. The new security lead assigns every server and application to a named owner, sets due dates of 7 days for known-exploited flaws and 30 days for other critical ones, and sends each owner only their own list. A monthly one-page report for the leadership team shows three numbers: scanning coverage, percentage of critical findings fixed on time and the number of active exceptions. Within three months on-time fixes rise sharply, and two long-running exceptions are closed when the board asks why they were still open.
Practice
Who should approve a risk acceptance for an unpatched business system?
Why is "total vulnerabilities found" a weak metric?
What does a high recurrence rate suggest?
Key takeaways
- Every finding needs an owner, a due date and a status.
- Remediation SLAs set fix times by priority and are agreed in policy.
- Exceptions need compensating controls, proper sign-off and an expiry date.
- Tailor reports to the audience: tasks, trends or risk.
- Close findings only with verification evidence.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.