Vulnerability management: what 'good' looks like in your environment

Discover what good vulnerability management really looks like for SaaS and tech teams, from risk-based SLAs to audit-ready evidence for ISO 27001, SOC 2, NIS2, and DORA.

Most teams scanning their environments feel like they're doing vulnerability management. Scan, get a list of findings, patch the critical ones, repeat. It's a start. But if an auditor asks you to prove that your critical vulnerabilities were remediated within your stated SLA, and you can only offer a spreadsheet and a vague memory of what happened last quarter, that gap matters.

Good vulnerability management isn't just scanning. It's a continuous risk-management process with coverage, prioritisation logic, SLA discipline, verification evidence, and a reporting narrative that proves risk is actually going down. Here's what that looks like when it's working well.

Knowing what you own before you try to protect it

You can't prioritise a vulnerability on an asset you don't know exists. Your asset inventory is the foundation everything else rests on. That means servers and endpoints, cloud resources (VMs, storage, managed services), container images and running workloads, SaaS integrations, and third-party software components.

For each asset, you need at minimum: asset owner, environment (dev/stage/prod), internet exposure, and criticality classification. Without ownership tagging, vulnerabilities get triaged but never assigned. Without criticality, every finding looks equally urgent.

Risk-based prioritisation: beyond CVSS scores

CVSS gives you a severity score. It doesn't tell you whether an attacker is actively exploiting that vulnerability right now, or whether the affected asset holds your most sensitive customer data.

Good prioritisation combines three inputs:

• Exploitability context: is this vulnerability on CISA's Known Exploited Vulnerabilities (KEV) catalogue, or does credible threat intel suggest active exploitation in the wild?
• Exposure: is the asset internet-facing or internal-only?
• Criticality: does a breach of this asset cause a material incident?

A medium CVSS finding on an internet-facing payment service with a public exploit available should outrank a critical CVSS finding on an isolated dev box with no public exploit. Work your prioritisation model accordingly.

When a patch is available but genuinely unsafe to deploy (compatibility issues, no change window, rollback risk), that's not a reason to ignore the finding. It's a trigger for a compensating control and a time-bound exception. Log it, own it, and review it on a fixed schedule.

The operating lifecycle your team actually runs

The vulnerability management lifecycle has six working phases:

1. Aggregate: pull findings from your infrastructure scanner, EDR telemetry, CI/CD pipeline checks, dependency/SBOM scans, and the most recent penetration test results into one place.
2. Normalise and de-duplicate: the same CVE reported by three tools is one finding, not three. Deduplication keeps your queue honest.
3. Triage and assign: apply your prioritisation model and route findings to the right owner. Security team, Platform/IT, or App owner. A clear RACI prevents findings from sitting in no-man's land.
4. Remediate: patch, harden configuration, fix the code, or apply a compensating control with a documented exception.
5. Verify: re-scan or manually validate that the fix worked. Capture the evidence. This step is skipped more often than any other, and it's the first thing auditors check.
6. Report: produce a trend view showing whether your risk posture is improving. SLA compliance by severity. Mean time to remediate. Not just a count of open findings.

What vulnerability management SLAs should actually look like

Severity-based SLAs give you a starting point. A common baseline looks like this:

These are starting targets, not universal rules. Adjust them based on your asset criticality classifications and your realistic change windows. The point is to have documented targets and to measure against them.

Link your SLAs to three metrics:

• MTTR (Mean Time to Remediate): average days from detection to verified closure, by severity.
• Patch compliance rate: percentage of findings remediated within SLA, by severity tier.
• Re-open rate: findings that passed verification but recurred, which signals a process or config-drift problem.

Tracking metrics that show risk reduction, not just activity

A vulnerability management dashboard serves two audiences. Your ops team needs a queue-health view: findings by age, by owner, by severity, and SLA breaches in red. Your leadership team needs a trend view: is the total risk exposure going up or down quarter-on-quarter?

A small, honest KPI set:

• MTTD (Mean Time to Detect): how quickly new vulnerabilities appear in your register after disclosure.
• MTTR by severity tier.
• Vulnerability age: average days open for unresolved findings, segmented by criticality.
• Scan coverage: percentage of in-scope assets with a successful scan in the last 30 days.
• Exception count and age: how many compensating-control exceptions exist, and are any overdue for review?

One guardrail worth keeping visible: a rising count of findings is not a sign of failure. It often means your detection improved. Measure SLA adherence and MTTR trend, not raw finding volume.

Scanning in modern SaaS environments: build-time vs runtime vs continuous re-evaluation

This is where a lot of teams have blind spots. There are three distinct scanning contexts and each catches different things.

Build-time scanning (SAST, dependency/SCA, container image scanning in your CI/CD pipeline) catches issues before they reach production. Gate your releases on critical and high findings. A tool like Trivy or Grype in your pipeline stops a known-vulnerable base image from being deployed in the first place.

Deployed runtime scanning covers what's actually running in production: infrastructure scanners against your cloud environments, container runtime assessments against live workloads, and cloud configuration/IaC checks. This catches drift between what was deployed and what's running now.

Continuous re-evaluation of newly disclosed vulnerabilities means re-assessing your existing asset inventory whenever a new CVE is published that matches something you own. Your SBOM (Software Bill of Materials) is your best tool here: a dependency you deployed six months ago might become vulnerable today due to a newly disclosed CVE. SBOM-driven vulnerability detection through software composition analysis (SCA) catches transitive dependencies that build-time checks can miss if the disclosure post-dates your last build.

For cloud and IaC environments, map scanning to dev, staging, and production separately. A misconfiguration in your Terraform that's fine in dev can be a critical exposure in prod.

Audit-ready evidence: what you actually need to produce

When an auditor or an enterprise customer's security team asks to review your vulnerability management programme, they're looking for a specific set of artefacts:

• A written vulnerability management policy with scope, SLAs, and exception criteria.
• An asset inventory with criticality and ownership tagging.
• A vulnerability register showing all findings, status, assigned owner, and target remediation date.
• Ticket/workflow history showing that findings were assigned, actioned, and closed in your tracking system.
• Verification evidence (re-scan results, screenshots, change records) for closed findings.
• An exception register for any compensating-control decisions, with approvals and review dates.
• A reporting cadence: who gets what report, how often.

For ISO 27001, Annex A control 8.8 specifically addresses technical vulnerability management and expects documented procedures, timely patching or risk-accepted exceptions, and periodic review of remediation effectiveness.

For SOC 2, your evidence needs to demonstrate that the controls you've described (vulnerability scanning, patch management, access review) are actually operating, not just documented.

For NIS2 and DORA, the expectation is a continuous, risk-proportionate ICT risk management process with documented evidence that vulnerabilities are identified, assessed, and addressed on a defined timescale. The EUCC Scheme guidelines published by ENISA (February 2025) further reinforce that certificate holders must follow formal vulnerability management rules as part of their obligations.

This is where a Single Audit, Multiple Standards approach pays off. Securance's model covers SOC 1, SOC 2, ISAE 3402, ISO 27001, NIS2, and DORA requirements through one streamlined process. Rather than assembling separate evidence packages for each standard, you build one coherent set of artefacts that satisfies all of them. Less duplication, fewer gaps.

A 30/60/90-day roadmap to reach 'good'

If your programme is still maturing, this is a realistic sequence:

Days 1–30: Complete your asset inventory with criticality and exposure tagging. Stand up baseline infrastructure scanning across all in-scope environments. Build your triage workflow (even a spreadsheet-based one). Document your initial SLA targets. Start tracking MTTR and scan coverage.

Days 31–60: Automate the ticket-creation workflow from scanner findings into your issue tracker (Jira, ServiceNow, or equivalent). Integrate CI/CD pipeline scanning for critical applications. Expand coverage to cloud configuration and container images. Enforce the exception process: every unpatched finding past SLA needs a documented owner, compensating control, and review date.

Days 61–90: Mature your verification loop so no finding closes without evidence. Set a monthly reporting rhythm for leadership. Build your runbook for incident-triggered remediation (when a zero-day drops, who does what and in what order). Review your exception register and close anything overdue.

At Securance, monthly scans are a standard part of the cyber scanning offering, which means the continuous re-evaluation piece is built in rather than bolted on. For teams working towards NIS2 compliance or a SOC 2 audit, that cadence directly supports the evidence requirements.

A few questions we hear often

How often should we scan? Monthly scanning is a sensible continuous baseline for most environments. Internet-facing assets and production systems warrant more frequent scans (weekly or on every deployment). The right cadence is the one you can sustain consistently and evidence clearly.

Do we need penetration testing as well? Pen testing and vulnerability scanning answer different questions. Scanning tells you what's present. A network penetration test tells you what's exploitable in context, including chained attack paths that no scanner will find. Both have a place in a mature programme; they're not substitutes for each other.

What about false positives? Log them. Document why the finding was assessed as a false positive (asset not present, version mismatch, not applicable in your environment), who reviewed it, and when. That evidence protects you in an audit and prevents the same false positive from being re-opened every scan cycle.

How do we manage vulnerabilities we genuinely can't patch? End-of-life software, vendor-managed components with no patch available, or systems where a patch breaks critical functionality all fall into this category. The answer isn't to ignore them. It's a compensating control (network segmentation, WAF rule, enhanced monitoring) plus a time-bound exception with a named owner and a review date. The cybersecurity risk assessment process should formally capture these residual risks.

Good vulnerability management is absolutely achievable without a large team or a perfect toolchain. What it does require is consistency: scanning regularly, prioritising honestly, remediating with evidence, and reporting on risk reduction rather than just activity. Start there, and the maturity will follow.