Vulnerability Management Programme Guide: From Scanning to Remediation (2026)

Vulnerability management is one of the most operationally demanding security disciplines — and one of the most frequently examined by auditors under DORA, NIS2 and ISO 27001. This guide walks through how to build a programme that is complete, defensible and proportionate: from scan architecture and asset coverage, through risk-based prioritisation, to SLAs, metrics and regulatory evidence.

Why vulnerability management is not just scanning

Many organisations run a scanner and believe they have a vulnerability management programme. Scanning is the first step — not the whole process. A mature vulnerability management programme requires:

• Asset inventory. You cannot scan what you do not know exists. Without an accurate, current asset inventory, scan coverage is unknown — and unknown coverage is a risk in itself.
• Risk-based prioritisation. Scanners produce thousands of findings. Without a triage methodology, teams are overwhelmed and the most dangerous vulnerabilities may not receive attention first.
• Remediation ownership. Identified vulnerabilities need owners who are responsible for fixing them, tracked through a workflow with measurable SLAs.
• Metrics and reporting. Management and auditors need to see evidence of programme effectiveness, not just a list of findings.
• Continuous improvement. Coverage, tooling, SLAs and processes need regular review as the environment changes.

Building the asset inventory first

An asset inventory is the foundation every audit will check first. For vulnerability management purposes, you need:

• A list of all hardware assets (servers, endpoints, network devices, OT/IoT where applicable)
• All software assets and versions running in the environment
• Clear classification of assets by criticality (critical, important, standard) — linked to your business functions
• Cloud assets included — cloud VMs, containers and serverless workloads are frequently missing from inventories
• Third-party managed components clearly identified — responsibility for scanning and remediation must be defined
• The inventory is reviewed and updated at least quarterly, or when significant changes occur

Scan architecture and coverage

The goal of scan architecture is complete, authenticated coverage with findings that are accurate and timely. Common choices:

Authenticated vs. unauthenticated scanning

Unauthenticated (network-based) scanning sees what an attacker can see from the network. Authenticated scanning logs into systems and provides a much more complete picture of installed software, patch levels and local configuration. For any serious programme, authenticated scanning is the standard — unauthenticated scanning alone will miss the majority of vulnerabilities.

Scan frequency

• Scan credentials are maintained and rotated according to the organisation's access management policy
• Scan coverage is measured as a percentage of the known asset inventory — and that metric is reported
• Exclusions from scanning are documented with a business justification and reviewed periodically
• Cloud assets are covered — either through agent-based scanning or via cloud-native integrations
• Scan results are retained for audit purposes (at minimum 12 months, longer under DORA)

Risk-based triage and prioritisation

A CVSS score alone is not a sufficient basis for prioritisation. CVSS measures the intrinsic severity of a vulnerability in isolation; it does not account for your environment, exploitability in the wild, or asset criticality. A mature prioritisation approach combines:

• CVSS base score — a starting point, not the finish line
• Asset criticality — a Critical severity finding on a system supporting a core banking function is more urgent than the same finding on a test server
• Exploitability in the wild — CISA's Known Exploited Vulnerabilities (KEV) catalogue and threat intelligence feeds identify which vulnerabilities are actively exploited; these are typically the highest priority regardless of CVSS
• Exposure — internet-facing systems carry higher risk than internally-only systems with strong network segmentation
• Compensating controls — a vulnerability may be mitigated in context by a WAF, network control or configuration that reduces real-world exploitability

• A documented risk-scoring methodology exists and is applied consistently
• The organisation subscribes to relevant threat intelligence (at minimum CISA KEV, NVD, ENISA advisories and vendor security bulletins)
• Critical and actively exploited vulnerabilities have an expedited triage and remediation path, separate from the standard SLA

SLAs and remediation workflow

SLAs make the programme measurable and auditable. Without defined remediation timeframes, every finding is effectively optional. DORA and NIS2 both require documented patch management processes; auditors will ask for SLA definitions and evidence of compliance.

• SLAs are defined per severity tier and formally approved
• Vulnerability findings are tracked in a ticketing system (or vulnerability management platform) with an owner, due date and status
• SLA compliance is measured and reported — the percentage of findings remediated within SLA is a core KPI
• Exception and risk-acceptance processes exist: findings that cannot be patched within SLA are risk-accepted with documentation, not silently missed
• Remediated findings are verified with a follow-up scan, not just marked closed by the owner

DORA and NIS2 requirements for vulnerability management

Both DORA and NIS2 explicitly address vulnerability and patch management as required security capabilities:

• DORA (Article 9): ICT risk management must include patch management as a protection measure, covering all ICT assets. Vulnerability identification and remediation are explicitly expected.
• DORA (Pillar 3 / Article 25): The resilience testing programme must include vulnerability assessments and penetration testing. Findings from testing must be tracked and remediated — not just documented.
• NIS2 (Article 21(2)(e)): Security in network and information systems acquisition, development and maintenance includes vulnerability handling and disclosure policies, and patch management as a minimum measure.
• NIS2 (Article 21(2)(g)): Cybersecurity hygiene practices explicitly include patching.

• Vulnerability management is documented as a formal programme with a policy, scope, process and accountable owner
• The programme covers all systems supporting critical or important functions (as defined under DORA) or core business functions (under NIS2)
• Evidence exists for auditors: scan reports, remediation records, SLA compliance metrics and exception logs
• Penetration testing findings are tracked through the vulnerability management workflow, not in a separate silo

Metrics that matter

A vulnerability management programme should produce metrics that mean something to both technical teams and management. The most useful ones:

• Coverage rate: percentage of the asset inventory successfully scanned in the last scan cycle
• Mean time to remediation (MTTR): average time from finding identification to verified closure, per severity tier
• SLA compliance rate: percentage of findings remediated within the defined SLA, by severity tier
• Critical backlog: number of open critical and high findings — the trend is as important as the absolute number
• Recurrence rate: how often findings reappear after closure — a high rate signals remediation quality issues
• Exception age: how long risk-accepted exceptions have been open without re-review

The five maturity gaps we see most often

1. Partial coverage they believe is full coverage. Organisations exclude large portions of their estate from scanning (cloud, OT, remote sites) and don't measure the gap. Coverage metrics make the blind spots visible.
2. CVSS as the only triage signal. Without exploitability data and asset criticality, teams spend effort on low-risk High findings while KEV-listed Critical ones wait in the queue.
3. Findings with no owner. Vulnerability management requires a named owner per finding, not just a team queue. Anonymous backlogs grow unchecked.
4. SLAs that exist but aren't measured. Defining SLAs in a policy document and actually measuring compliance are different things. Auditors ask for evidence of compliance, not the definition alone.
5. Penetration test findings in a separate spreadsheet. Results from pen tests and TLPT exercises belong in the vulnerability management workflow. Siloed tracking means they age without systematic follow-up.

How SephiraSec can help

SephiraSec designs and matures vulnerability management programmes across enterprise environments — including Tenable SC scan architecture, risk-based triage frameworks, SLA definition, CMDB integration, DORA/NIS2 evidence packs, and management reporting. Based in Vienna, available across the EU, working in English, German and Romanian.