Remediation tracking
from open finding to verified close
Track every vulnerability through the full remediation cycle. Assign owners, set SLAs by severity, collaborate with clients in a branded portal, log retest evidence, and produce a closure record stakeholders can audit.
No credit card required. Free plan available forever.
Remediation tracking software for security teams and consultancies
Most security findings die in the gap between "reported" and "fixed". The pentest report lands as a PDF, the criticals get triaged in a meeting, and then the long tail of medium and low items quietly drifts. Three months later the next engagement finds the same issues, the client is unhappy, and nobody can show whether last quarter's remediation programme actually worked. The cause is almost always the same: there is no single record that follows a finding from open to verified close. SecPortal closes that gap with a remediation tracking workflow that handles owner assignment, SLA timers, client collaboration, retest pairing, and closure evidence in one place.
This page is the workflow view. For the retest deliverable as a tracked use case, read the pentest retesting workflow. For the deeper retest playbook, read the guide to retesting vulnerabilities. For the wider vulnerability programme model with CVSS, EPSS, and KEV, read the vulnerability prioritisation framework. For how the import side feeds remediation, see the vulnerability assessment use case. And for remediation that originates from external researchers rather than internal scans, see the VDP management workflow. For the analytical view of how findings age past SLA and turn into risk debt across PCI DSS, ISO 27001, SOC 2, and CISA KEV programmes, see the research on aging pentest findings. For the evidence record that backs every status transition, sign-off, and retest pair, see the pentest evidence management workflow. And for the upstream handover that lands findings in the client SOC, SIEM, ticketing system, and risk register before remediation begins, see the pentest finding handover to SOC and SIEM workflow.
What a remediation tracking workflow needs to do
Status workflow per finding
Every finding moves through open, in progress, awaiting retest, resolved, or accepted risk. Status changes are timestamped and tied to the user who made the change so the audit trail is complete without manual logging.
Owner assignment and accountability
Assign a remediation owner per finding from your team or the client side. The owner sees their queue, gets notified on status changes, and is named on every report so accountability is visible.
SLA timers by severity
Set target close dates per severity tier. Critical findings get the shortest window, informational findings can be deferred. The platform shows due dates and overdue counts at a glance.
Branded client collaboration
Clients update status and post questions inside the branded portal. No emails to triage, no PDFs to version, no shared spreadsheets to keep in sync. The conversation stays attached to the finding it relates to.
Retest pairing
Pair retest results to the original finding so the close-out record captures the original scope, the fix, the retest evidence, and the final outcome in a single timeline.
Regression handling
When a previously closed finding reappears in a later scan, the platform reopens it with the regression noted. The history of close, regression, and re-close stays on a single record.
The end-to-end remediation pipeline
Each finding moves through a defined sequence so the work cannot quietly stall in someone's inbox. The platform records who did what and when, which removes the manual logging that usually breaks down in week three of a remediation programme.
- A vulnerability is logged with severity, CVSS vector, affected asset, evidence, and remediation guidance from a finding template or scanner import.
- A remediation owner is assigned, an SLA is set based on severity, and the finding is published to the branded client portal so the right people see it without waiting for a report cycle.
- The owner works the fix, asks clarifying questions inside the finding record, and updates status from open to in progress to awaiting retest.
- A retest is scheduled, executed, and the outcome is paired to the original finding with proof of the fix or notes on what is still outstanding.
- If the fix is verified, the finding is closed with a closure timestamp and the SLA performance is recorded. If not, it is moved back to open with regression notes and the SLA clock resumes.
- When stakeholders need a snapshot, an AI report summarises open findings, overdue items, and the remediation trend across the engagement or across the workspace.
Sensible default SLAs by severity
SLAs are the lever that turns a finding list into a programme. Without target close dates, severity becomes a label rather than a deadline. A reasonable default ladder is below; tune the numbers to your risk tolerance and release cadence and document the choice on the engagement record. To produce defensible windows tied to PCI DSS, ISO 27001, SOC 2, or CISA KEV expectations, use the free vulnerability remediation SLA calculator. For the deeper workflow that runs the SLA policy on the engagement record (timer per finding, breach escalation by severity, clock pause and resume, audit-ready reporting), see the vulnerability SLA management workflow.
| Severity | Target close | When to use it |
|---|---|---|
| Critical | 7 days | Active exploitation risk, public-facing, no compensating control. Engineering pulls the work into the current sprint or treats it as an out-of-band fix. |
| High | 30 days | Significant impact but mitigated by a control, internal-only, or requires authentication. Slotted into the next planned release window. |
| Medium | 90 days | Material risk that can be addressed with normal release cadence. Tracked but does not interrupt the roadmap. |
| Low | 180 days | Hardening or hygiene items. Bundled into a remediation sprint or addressed as a side effect of other work. |
| Informational | Best effort | No direct exploitable risk. Tracked for context, often closed with an accepted-risk decision and a written rationale. |
Reporting views remediation owners actually use
The reports that drive remediation are not the static PDF that lands at the end of an engagement. They are the live views that owners and stakeholders look at every week. The five below are the ones every meaningful remediation programme settles on.
- Open findings by severity, sliced by client, engagement, owner, or asset class so the right person sees the right queue.
- Overdue findings against the configured SLA so escalation happens before the next steering meeting, not after it.
- Closure rate over time so you can show that remediation velocity is improving rather than asserting it from memory.
- Mean time to remediate per severity so the next pricing conversation, board update, or auditor walkthrough has real numbers behind it.
- Aging buckets (under 30 days, 30 to 90 days, 90+ days) so the long tail of unfixed findings becomes visible instead of hiding inside a spreadsheet.
For pentest firms and security consultancies
If you sell engagements, remediation tracking is part of the deliverable. Clients buying a pentest expect a clear picture of where they stand a month later, not an artefact that aged out the day after delivery. Most consultancies still rely on email and reissued PDFs to keep that picture current, and the friction shows up as renewal risk, retest pricing pressure, and the "we already fixed that" conversation that nobody wants. A finding-level remediation workflow inside a branded client portal replaces all of that with a live record both sides can rely on.
Fix evidence scattered across email and Slack
When the client emails a screenshot to one consultant and pastes a config diff in a Slack channel a week later, neither lives next to the finding it relates to. The retest then has to reconstruct the story from scratch. Keeping evidence inside the finding record fixes this on the first delivery.
Reports go stale within days
A static PDF report is accurate at the moment of delivery and out of date the next morning when the client has already fixed three of the criticals. A live status view inside the portal keeps the picture current without re-issuing PDFs.
Retests get billed but not tracked
Retest cycles are usually a separate line item, but most teams have no clean record of which findings the retest covered or which it left open. Pairing retests to original findings inside the platform makes the deliverable self-documenting.
No baseline for remediation pricing
Without remediation timing data, every retest quote is a guess. After a few engagements with closure timestamps, you can quote retest packages from real numbers and defend the price.
For internal security teams and vCISOs
Internal teams and vCISO programmes face the mirror image of the consultancy problem. The findings come from multiple sources (third-party pentests, scanner output, internal reviews), each source has its own format, and engineering wants tickets in their own tool. The fix is to keep the finding record as the canonical source of truth, link the engineering ticket to it, and track closure on the finding side. Auditors get the same export every cycle, executives see the same trend, and engineering keeps working in the tool they prefer.
Findings and tickets drift apart
When findings live in one tool and engineering tickets live in another, the two stop matching within weeks. Treating the finding record as the source of truth and using the ticket only for execution avoids the drift.
Risk acceptance has no paper trail
Accepting risk on a finding is a legitimate outcome, but it needs a written reason, an approver, and an expiry. A finding-level risk acceptance with an expiry date stops accepted risks from becoming forgotten risks.
Compliance auditors ask the same questions every cycle
Auditors want closure timestamps, SLA performance, and evidence per finding. A single export per engagement with that structure shortens audit prep from weeks to hours.
For the second pain point above, a structured risk acceptance form template captures the residual rating, the compensating controls, the named approver, and the review date so each acceptance is auditable instead of buried in a Slack thread. Wrap the form in a vulnerability acceptance and exception management workflow so the lifecycle from request through approval, periodic review, and renewal or closure runs on the engagement record rather than against a folder of one-off forms. For the per-finding operating record that drives a single vulnerability from triage through verified close, use the free vulnerability remediation worksheet as the canonical worksheet for owner, SLA, fix evidence, retest pair, closure decision, and audit trail.
How remediation tracking connects to the rest of the platform
Remediation tracking is the spine of the engagement. It sits on top of findings management for CVSS scoring, templates, and scanner imports, inside engagement management for scope and team assignment, and it feeds AI reports with the closure data that turns a static report into a live programme view. For framework-aligned programmes, the same finding records map straight into ISO 27001, SOC 2, and NIST SP 800-53 evidence packs without re-keying.
Compliance evidence by default
Every finding carries the closure timestamp, the SLA performance, the owner, and the retest evidence. That bundle is what auditors ask for, so the export is the audit artefact rather than a separate report you have to assemble.
Engineering-friendly handoffs
The finding stays in SecPortal and is the source of truth for closure. Engineering keeps working in their issue tracker. The two stop drifting because the finding record holds the SLA, the owner, and the retest, not the ticket. The scanner to ticket handoff governance workflow covers the routing rules, the ticket payload schema, and the closure verification cadence that keep the two systems reconciled.
Remediation tracking is one of those workflows that looks small from the outside and turns out to be the single biggest source of leverage in a security programme. Get it right and every finding has an owner, a deadline, and a paper trail. Get it wrong and every quarter starts with the same conversation about the same unfixed issues. The goal of this workflow is to make the right outcome the path of least resistance for both the security team and the people doing the fixes. For the slice of the lifecycle where the remediation route is a vendor patch coordinated with an IT or infrastructure team, the sister workflow on patch management coordination pairs the patch decision, maintenance window, pre-patch baseline, and post-patch rescan evidence to the original finding so the security-to-IT handoff stops being a parallel workstream and becomes a closure event on the engagement record. For the per-finding contract that ships each item to engineering with reproducible evidence, fix expectations, and named retest criteria before tracking begins, pair this workflow with the security finding evidence package for developers workflow so the closure cadence runs against a developer-ready record rather than against a one-line description and a screenshot. When the inbound finding stream is a third-party penetration test report PDF, the upstream intake workflow is the third-party penetration test report intake workflow, which extracts findings, recalibrates severity, dedupes against the existing scanner catalogue, and assigns named owners before remediation tracking takes over. For the platform capability that closes the loop (the FindingStatus lifecycle, separate resolved_at and verified_at timestamps, RBAC-gated transitions, and the activity log audit trail that proves the fix was verified), see the retesting workflows feature page.
Frequently asked questions about remediation tracking
What is vulnerability remediation tracking software?
Vulnerability remediation tracking software is a platform that records every security finding, the owner responsible for fixing it, the SLA the fix is held to, and the proof that the fix landed. SecPortal does this end to end: the finding is logged with severity and evidence, an owner and SLA are assigned, the client or internal team works the fix in a branded portal, a retest is paired to the original finding, and the closure timestamp lands in the same record so the audit trail is complete.
How is remediation tracking different from a vulnerability scanner?
A scanner produces findings. Remediation tracking is what happens after the scan. Scanners do not assign owners, do not enforce SLAs, do not give clients a place to update fix status, and do not pair retest evidence back to the original finding. SecPortal imports scanner output (Nessus, Burp Suite, CSV) into a structured workflow that handles every step from open to closed.
How should pentest firms track remediation with their clients?
Run remediation inside a branded client portal so the conversation stays attached to the finding. The client updates status, asks clarifying questions, and uploads fix evidence in one place. The retest pairs to the original finding when it runs. Closure timestamps are captured automatically. This replaces the email and PDF cycle that most pentest firms still use and gives the client a live picture of where they stand.
What SLAs should a remediation programme use by severity?
A common starting point is critical within 7 days, high within 30, medium within 90, low within 180, and informational on best effort. Tune the targets to your business risk tolerance and your release cadence. The point of the SLA is to make overdue findings visible early so they can be escalated, not to penalise a team for a one-off slip.
How does retesting fit into remediation tracking?
Retests verify that a fix actually landed and did not introduce a regression. Pair the retest to the original finding so the record shows the original scope, the fix described by the owner, the retest evidence, and the final outcome. If the retest fails, the finding moves back to open with regression notes and the SLA clock resumes. SecPortal models this directly so retests stop being a separate spreadsheet.
Can clients update remediation status themselves?
Yes. SecPortal serves clients on a branded subdomain where they can update finding status, post questions or context inside the finding, and attach fix evidence. Their actions are timestamped and recorded against the finding so the audit trail is complete without anyone manually logging changes.
How it works in SecPortal
A streamlined workflow from start to finish.
Open the finding with context
Capture severity, CVSS vector, affected asset, evidence, and remediation guidance. Pick from 300+ templates so the fix advice is concrete from day one.
Assign an owner and an SLA
Set a target close date by severity. Critical and high findings get shorter windows, lower severity items can be deferred or accepted with a written reason.
Track work in the client portal
Clients update status, ask clarifying questions, and attach fix evidence directly in their branded portal. No email chains, no version drift.
Retest and close
Run a retest, attach the result to the original finding, and move it to closed or back to open with the regression notes captured in the same record.
Stop chasing remediation over email
One workflow from open to closed. Every status, owner, and retest in one record.
No credit card required. Free plan available forever.