A vulnerability remediation workflow turns scan results into fixed systems on a schedule your auditors, customers, and insurers can actually verify. Get the structure right once and every scan afterwards runs itself.
Why this matters
Most businesses run vulnerability scans. Far fewer run a vulnerability remediation workflow that closes findings on time and proves it.
That gap is where audits fail. Cyber Essentials Plus assessors reject applications over unpatched critical vulnerabilities sitting past the 14-day window. ISO 27001 auditors raise nonconformities when scan reports exist but nobody can show a ticket, an owner, or a fix date. SOC 2 Type II reports pick up exceptions when a vulnerability was found in month one and closed in month five with no explanation.
A scanner alone doesn't fix anything. The workflow around it — triage, assignment, deadlines, verification — is what turns a report into a closed risk. That's the part most teams skip, and it's the part OneClickComply automates so evidence collects itself instead of living in someone's inbox.
What you'll need
- A vulnerability scanner (Nessus, Qualys, Intruder, or your MSP's platform)
- An asset inventory with a named owner against every device, server, and application
- A ticketing system — Jira, ServiceNow, or a shared board, doesn't need to be fancy
- Severity-based SLA windows agreed in writing before your first scan
- A verification step that means a rescan, not a checkbox someone ticks
- Two to three hours to set the workflow up, then 30-60 minutes a week to run it
The steps
1. Build the asset inventory first
You can't remediate what you can't name. List every server, laptop, cloud instance, and application in scope, and assign one named owner to each — not a team, a person.
Without this, findings land in a shared inbox and nobody moves. Expected outcome: every future scan finding maps to a specific person within minutes, not days. Common mistake: leaving "IT" as the owner field — that's nobody, and it shows in your ticket aging report.
2. Set severity-based SLA windows
Decide, before you scan, how fast each severity level gets fixed. Cyber Essentials Plus sets the floor: critical and high vulnerabilities patched within 14 days of the vendor releasing a fix, in 2026 as in prior years.
A workable structure: critical — 14 days, high — 14 days, medium — 30 days, low — 90 days or next patch cycle. Write these down. Expected outcome: every ticket gets a due date the moment it's created, no debate. Common mistake: setting 30-day windows for critical findings because that's "more realistic" — it isn't compliant with Cyber Essentials Plus and it won't survive an ISO 27001 audit either.
3. Automate the scan cadence
Set your scanner to run on a fixed schedule — weekly for internet-facing assets, monthly for internal ones is the common baseline in 2026. Manual, ad-hoc scanning is how six-month-old critical vulnerabilities get discovered during an audit instead of during a scan.
Expected outcome: a predictable, dated stream of findings instead of a panic scan the week before certification renewal. Common mistake: scanning once before an audit and calling it "vulnerability management" — assessors can tell from the scan history.
4. Triage every finding before it becomes a ticket
Not every scanner result needs a ticket. Triage strips out false positives, duplicates, and accepted-risk items before they hit your team's queue.
Check the CVSS score, check exploitability, check whether the asset is internet-facing. Expected outcome: your team works a queue of real findings, not scanner noise. Common mistake: sending raw scan output straight to a ticketing tool — engineers stop trusting the queue within a month and start ignoring it.
5. Assign tickets with SLA-driven due dates
Every ticket needs an owner (from step 1), a severity (from step 2), and a due date calculated automatically from that severity. Don't let engineers set their own deadlines.
Expected outcome: an aging report that shows exactly which tickets are on track and which are overdue, sortable by severity. Common mistake: assigning tickets without a due date and relying on "we'll get to it" — this is the single biggest cause of missed Cyber Essentials Plus windows.
6. Verify with a rescan, not a checkbox
A ticket marked "resolved" isn't evidence. A rescan showing the vulnerability is gone is evidence. Build the rescan into your workflow as the closing step, every time, no exceptions.
Expected outcome: an audit trail — scan date, ticket, fix date, verification scan — that any auditor can follow end to end. Common mistake: closing tickets on the engineer's word alone. Auditors ask for the rescan and if it doesn't exist, the finding gets reopened.
7. Report exceptions and track aging monthly
Some findings won't get fixed on time — a vendor patch isn't out yet, or a legacy system can't be touched without downtime. Document these as formal exceptions with a compensating control and a review date, not silence.
Expected outcome: a defensible exceptions register instead of a pile of overdue tickets nobody can explain. Common mistake: letting overdue tickets sit unflagged — auditors read silence as a missed control, not a managed risk.
See your remediation workflow automated
OneClickComply turns scan findings into tracked, audit-ready evidence automatically.
Troubleshooting
The same vulnerability keeps reappearing after you "fixed" it. Check whether the patch reached every instance of the asset, not just the golden image or template — cloned VMs and containers built from an old image will keep failing the same check.
SLA windows get missed every cycle. The severity ratings are usually too aggressive for your team's real capacity, or tickets have no clear owner. Rebalance the SLA table in step 2 before you blame the team.
The scanner floods you with false positives. Tune the scan policy and exclude plugins that consistently misfire on your stack — an unfiltered scanner trains your team to ignore the queue entirely.
Auditors reject tickets marked closed with no evidence. Your closing criteria is missing the rescan step from step 6. Add it as a mandatory field before a ticket can move to "resolved."
The remediation backlog grows every month. Your fix capacity doesn't match your finding volume. Automate OS-level patching where you can, so human time goes to the findings that actually need judgment.
Tools and resources
- A scanner with authenticated scanning enabled — unauthenticated scans miss the majority of software-level vulnerabilities
- A ticketing tool with SLA-based due dates and an aging report view
- If you're outsourcing scanning, read how to scope a penetration test before you buy one before signing a contract
- A compliance automation platform — OneClickComply centralises scan evidence, ticket status, and audit trail in one place instead of three disconnected tools
What to do next
A vulnerability remediation workflow is one control among many that Cyber Essentials Plus assessors check. Once the workflow above is running, walk through what else the assessment covers — start with how to prepare for a Cyber Essentials Plus audit so remediation evidence sits alongside the rest of your audit pack, not separate from it.
Frequently asked questions
One last thing
The fastest fix for a finding that keeps reappearing isn't a better patch cycle — it's pulling the asset off the network and rebuilding it from a hardened image. Teams that keep patching the same broken template every month are solving the wrong problem. Fix the image once, and the vulnerability remediation workflow stops flagging the same box every quarter.