COMP 6660 · Enterprise Cybersecurity Vulnerability Assessment Techniques

00 Introduction

Threat modeling, examined in Lesson 3.2, identifies what could go wrong in a system's design. Vulnerability assessment identifies the specific weaknesses that make those threats exploitable — and the operational challenge of addressing them at scale.

Every enterprise has more vulnerabilities than it can remediate. Scanners routinely report hundreds, thousands, or tens of thousands of findings across a modern estate. The number grows as the estate grows: each new application, each new cloud service, each new container image introduces more code, more dependencies, and more potential weaknesses. At the same time, remediation capacity is finite — limited by engineering time, change windows, operational risk, and business priorities.

Vulnerability assessment is the discipline through which enterprises identify, evaluate, and prioritise vulnerabilities. It is not merely the operation of scanning tools. It is the management of a pipeline: from discovery through assessment, prioritisation, remediation, and verification. Enterprises that excel at vulnerability management are not those that scan the most; they are those that remediate the right things in the right order, with evidence that their remediation is effective.

This lesson examines vulnerability assessment in detail. It defines what vulnerability assessment is and how it differs from related activities. It surveys the vulnerability landscape — where weaknesses come from and what the principal categories are. It examines scanning and penetration testing — the two principal discovery techniques. It explains CVSS scoring and its limitations. It describes the vulnerability management lifecycle. And it addresses the central practical problem: how to prioritise remediation when the vulnerability count exceeds the capacity to fix.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 3 outcomes U3.2 (risk and vulnerability assessment) and U3.4 (mitigation strategies), and to Module 2 outcomes M2.2 and M2.4. See the Unit 3 learning outcomes page for the full mapping.

02 What vulnerability assessment is

Vulnerability assessment is a broad discipline. It encompasses automated scanning, manual testing, configuration review, architecture analysis, and the management processes through which findings are triaged, prioritised, remediated, and verified. The specific techniques vary — a cloud workload, a legacy on-premises application, and an industrial control system each require different approaches — but the underlying discipline is consistent.

Distinguishing related activities

Vulnerability assessment is frequently confused with related activities. The distinctions matter because each serves a different purpose and produces different outputs.

Why vulnerability assessment matters

Vulnerability assessment matters for several reasons:

• It reduces the window of exposure. Vulnerabilities are introduced continuously — through new software, configuration changes, and newly discovered weaknesses in existing components. Assessment shortens the period during which a known vulnerability remains unaddressed.
• It supports compliance. Many regulatory frameworks and contractual requirements mandate vulnerability assessment and timely remediation. Evidence of a functioning vulnerability management programme is frequently expected by auditors and by customers.
• It informs risk management. Vulnerability findings are among the most concrete inputs to enterprise risk assessment — they are specific, verifiable, and actionable.
• It supports prioritisation. The enterprise cannot fix everything, but it can fix the right things in the right order. Vulnerability assessment provides the data on which that prioritisation depends.
• It provides evidence of due diligence. When an incident occurs, the enterprise's vulnerability management records demonstrate whether it was managing its exposure responsibly — a consideration that is increasingly relevant in regulatory and legal contexts.

03 The vulnerability landscape

Vulnerabilities arise from many sources. Understanding the landscape helps the enterprise prioritise its assessment activity and its remediation capacity.

Where vulnerabilities come from

Notable vulnerability categories

Several categories of vulnerability recur across enterprises and warrant specific attention:

• Unpatched software. The classic vulnerability — known weaknesses in software that could be patched but has not been. Still one of the most common causes of enterprise breaches, despite decades of awareness. Equifax (Lesson 1.6) is the canonical example.
• Vulnerable dependencies. Components the enterprise uses but does not maintain. Software composition analysis and SBOMs are the emerging countermeasures.
• Misconfigured cloud resources. Public storage buckets, overly permissive identity policies, exposed management interfaces. Frequently the source of cloud-related breaches.
• Weak or default credentials. Default administrative passwords, shared accounts, weak authentication on management interfaces. A persistent source of compromise in IoT, OT, and enterprise systems.
• Injection vulnerabilities. SQL injection, command injection, and their variants. Well understood for decades but still commonly found in applications.
• Broken access control. Direct object references, missing authorization checks, privilege escalation flaws. Consistently ranked among the most severe application security issues.
• Cryptographic weaknesses. Weak algorithms, poor key management, inadequate randomness, improper certificate validation. Examined in Unit 2.
• Unmanaged assets. Systems, services, and applications that exist but are not inventoried. Frequently invisible to both the vulnerability programme and the security team.

Sources of vulnerability information

Vulnerability assessment draws on multiple sources of information:

04 Vulnerability scanning

Vulnerability scanning is the automated identification of weaknesses across systems, applications, and configurations. It is the most widely deployed vulnerability assessment technique, and the foundation of most enterprise vulnerability management programmes.

How scanning works

A scanner queries systems and services, compares what it finds against a database of known vulnerabilities, and produces findings. Depending on the scanner and configuration, the assessment may be:

• Unauthenticated (remote). The scanner probes from outside, observing what is exposed and comparing against known vulnerabilities. This is the perspective of an external attacker — valuable for understanding what is reachable from the internet.
• Authenticated (credentialed). The scanner logs into systems and inspects software versions, configurations, and missing patches directly. Substantially more thorough than unauthenticated scanning, because it can see what an external observer cannot.
• Agent-based. An agent installed on the system reports its state to a central management platform. Continuous, rather than periodic, and particularly suitable for endpoints and cloud workloads that may not be reachable by network scanning.
• Application scanning (DAST/SAST). Dynamic application security testing (DAST) tests running applications for vulnerabilities; static application security testing (SAST) analyses source code. Both complement infrastructure scanning.
• Software composition analysis (SCA). Analyses applications and their dependencies to identify vulnerable components. Essential where third-party libraries are used at scale.
• Cloud security posture management (CSPM). Assesses cloud configurations against best practice and policy — public storage, permissive identity policies, unencrypted data, and similar issues.

Scanner limitations

Scanners are valuable but limited. Understanding their limitations is essential to using them effectively:

• They find known vulnerabilities. Scanners compare against databases of known issues. Zero-days, logic flaws, and architectural weaknesses are not detected.
• They produce false positives. The scanner may report a vulnerability that is not exploitable in the enterprise's configuration, or that has been mitigated by other controls.
• They produce false negatives. The scanner may miss real vulnerabilities — because the affected service is not reachable, because the scanner lacks credentials, or because the vulnerability is not in the scanner's database.
• They assess in isolation. Scanners assess each system or component separately. They do not assess the interaction between components or the overall architecture.
• They produce volume. A single scan of a modern estate can produce thousands of findings. Without prioritisation, the output is not actionable.
• They can disrupt systems. Scanning can cause performance degradation, service interruptions, or unintended consequences in fragile environments — particularly operational technology.

Scanning programme design

Effective scanning requires planning. Useful considerations include:

• Scan scope and coverage. Which assets are in scope? How is coverage maintained as the estate changes? Unscanned assets are effectively unmanaged.
• Scan frequency. Balance thoroughness against operational impact. Critical assets and internet-facing systems generally warrant more frequent scanning than internal systems.
• Authenticated vs. unauthenticated. Authenticated scanning is more thorough but requires credential management. Both perspectives are useful, and many enterprises run both.
• Scan windows. Scans should be scheduled to minimise operational impact — during maintenance windows, or when load is low.
• Handling false positives. A process for reviewing and suppressing false positives is essential; otherwise the programme loses credibility and findings accumulate.
• Integration with ticketing and workflow. Findings should flow automatically into the systems through which they are triaged, assigned, and remediated.
• Reporting. Reports should serve the decisions they inform — technical teams need detail, executives need trends and priorities.

05 Penetration testing

Penetration testing is the practice of attempting to exploit vulnerabilities to demonstrate their impact. Where scanning identifies potential weaknesses, penetration testing demonstrates whether they are actually exploitable and what the consequences would be.

What penetration testing provides

• Evidence of exploitability. A scanner reports a potential vulnerability; a penetration test demonstrates that the vulnerability can actually be exploited. This distinction matters when prioritising remediation — not every potential vulnerability is exploitable in practice.
• Business-impact narrative. Penetration testing translates technical weaknesses into business consequences — "the tester was able to access customer records and exfiltrate them" is more meaningful to executives than a list of vulnerabilities.
• Detection of issues scanners miss. Logic flaws, authentication bypasses, chained exploits, and business-logic vulnerabilities are frequently identified by manual testing but not by automated scanning.
• Assessment of layered defences. A penetration test can assess how multiple controls interact — whether an initial foothold leads to further compromise, whether segmentation holds, and whether detection responds.
• Evidence of due diligence. Penetration testing reports are frequently expected by regulators, customers, and cyber insurers.

Types of penetration testing

Penetration testing limitations

• Point-in-time. A penetration test assesses the state of the estate at a moment. Vulnerabilities introduced afterwards are not addressed by the test.
• Sample-based. Testers cannot examine every system, every application, or every configuration. The test is a sample, and gaps are inevitable.
• Tester-dependent. Results depend on the skill and thoroughness of the testers. Different testers find different issues.
• Expensive. A thorough penetration test requires skilled testers, substantial time, and significant cost. It is not practical to conduct comprehensive penetration testing continuously.
• Risk of disruption. Testing can disrupt systems or inadvertently cause data loss. Careful scoping, rules of engagement, and communication are essential.
• Does not demonstrate absence of vulnerabilities. A successful penetration test — one that finds no exploitable vulnerabilities — does not prove that none exist.

Penetration testing programme design

Effective penetration testing requires careful planning:

• Define scope and objectives. What is being tested, by whom, and to what end? Scope should be explicit, and changes should be agreed in writing.
• Establish rules of engagement. What is permitted and what is forbidden? What is the escalation process if a critical issue is discovered? What are the boundaries of testing?
• Select the right type. Black box for external exposure, grey box for internal assessment, white box for thorough coverage, red team for detection and response testing.
• Engage qualified testers. Penetration testing is a specialised skill. Certifications exist (OSCP, GPEN, and others), and references matter.
• Integrate with the vulnerability management programme. Findings from penetration testing should flow into the same assessment, prioritisation, and remediation processes as scanner findings.
• Retest after remediation. A penetration test that identifies vulnerabilities should be followed by a retest that confirms remediation was effective.

06 CVSS and vulnerability scoring

The Common Vulnerability Scoring System (CVSS) is the most widely used method for expressing the severity of a vulnerability. It provides a consistent, standardised way to describe how serious a vulnerability is — and, crucially, a common language for comparing vulnerabilities across systems, vendors, and enterprises.

How CVSS works

CVSS produces a numerical score between 0 and 10, accompanied by a qualitative severity rating. The current version — CVSS v3.1 — is the dominant standard, though CVSS v4.0 is emerging.

The CVSS metric groups

CVSS v3.1 scores a vulnerability based on three metric groups:

The three CVSS scores

Based on the metric groups, CVSS produces three scores:

• Base score. Computed from base metrics. Comparable across vulnerabilities and enterprises. The score most commonly reported and discussed.
• Temporal score. Adjusts the base score based on temporal metrics. Reflects the current state of the vulnerability.
• Environmental score. Adjusts the temporal score based on environmental metrics. Reflects the vulnerability's significance in the specific enterprise.

CVSS limitations

CVSS is widely used and useful, but it has significant limitations that are frequently overlooked:

• It is a severity score, not a risk score. CVSS describes the severity of a vulnerability, not the risk to the enterprise. A CVSS 9.8 vulnerability on a system that is not exposed, not containing sensitive data, and not reachable by a plausible adversary carries lower risk than a CVSS 7.0 vulnerability on a critical internet-facing service. This distinction — established in Lesson 3.1 — is the most important limitation to understand.
• It is frequently reported as base score only. Temporal and environmental metrics are frequently omitted, producing a score that does not reflect the vulnerability's actual significance in the enterprise.
• It does not consider threat intelligence. CVSS does not account for whether a vulnerability is being actively exploited in the wild, by whom, and against which sectors.
• It does not consider asset value or business impact. The same vulnerability has different significance depending on what system it affects. CVSS does not incorporate this.
• It can mislead prioritisation. Enterprises that prioritise exclusively by CVSS base score tend to remediate high-scoring vulnerabilities in low-value systems while leaving moderate-scoring vulnerabilities in critical systems unaddressed.
• Scoring is subjective. Different analysts may assign different scores to the same vulnerability, particularly for complex or ambiguous cases.
• It does not cover all vulnerability types. Some classes of vulnerability — logic flaws, design weaknesses — do not map cleanly to CVSS metrics.

Other scoring approaches

Recognising CVSS's limitations, several complementary approaches have emerged:

• EPSS (Exploit Prediction Scoring System). Predicts the likelihood that a vulnerability will be exploited in the wild. Provides a data-driven input for prioritisation that CVSS does not.
• SSVC (Stakeholder-Specific Vulnerability Categorisation). A decision-tree framework — developed by Carnegie Mellon's CERT Coordination Center — that produces vulnerability categories based on exploitation status, technical impact, and mission impact. Designed explicitly for prioritisation, not for severity scoring.
• Vendor-specific severity. Many vendors publish their own severity ratings, sometimes incorporating context that CVSS does not.
• Threat intelligence platforms. Commercial and open sources that integrate vulnerability data with exploit activity and adversary intelligence.

07 The vulnerability management lifecycle

Vulnerability assessment is a lifecycle activity, not a discrete event. The vulnerability management lifecycle describes the stages through which findings pass, from discovery through remediation and verification.

08 Prioritising remediation

The central practical challenge in vulnerability management is prioritisation: how to decide which of the many findings to remediate first, when the enterprise cannot remediate them all at once.

Why prioritisation is necessary

A modern enterprise estate routinely produces tens of thousands of vulnerability findings from a single scanning cycle. Even large engineering organisations cannot remediate all findings simultaneously — remediation requires engineering effort, testing, change management, and often user communication. The result is a queue, and the enterprise must decide the order in which findings are addressed.

Prioritisation matters because remediation that addresses the wrong findings leaves the enterprise exposed to the risks that matter most. An enterprise that remediates all low-risk findings while leaving high-risk findings unaddressed has not materially reduced its exposure, regardless of the number of findings closed.

The severity-only approach and its failure

Many enterprises prioritise by CVSS base score. Findings are sorted by score, and the highest-scoring findings are remediated first. This approach is intuitive, defensible in conversation, and largely ineffective.

The reason is that CVSS scores severity, not risk. Prioritising by CVSS base score produces the following failure patterns:

• High-severity findings in low-value systems dominate the queue. A critical vulnerability on an internal development server consumes remediation capacity that would be better applied elsewhere.
• Moderate-severity findings in critical systems wait. A moderate vulnerability in an internet-facing service handling customer data may sit behind dozens of higher-scoring findings in less important systems.
• Actively exploited findings are not prioritised. CVSS does not consider whether a vulnerability is being exploited in the wild. A moderate vulnerability under active exploitation may be more urgent than a critical vulnerability that no one is exploiting.
• The queue becomes unmanageable. When prioritisation is driven by score alone, the queue grows faster than the enterprise can reduce it, producing a backlog that no one can work through.

Risk-based prioritisation

Risk-based prioritisation assesses each finding against the enterprise's actual context. It considers multiple factors in combination — severity being one input among several. The following factors are commonly included:

Prioritisation frameworks

Several frameworks support risk-based prioritisation. The following are commonly used:

09 Risk-based prioritisation in practice

The principles of risk-based prioritisation are straightforward. Applying them at scale requires a workable process. This section describes a practical approach.

A three-tier prioritisation model

Many enterprises find that a three-tier model balances rigour and practicality:

10 Metrics and reporting

Metrics determine what a programme focuses on. Poorly chosen metrics produce programmes that optimise for the metric rather than for the outcome. The choice of metrics is therefore consequential.

Activity versus outcome metrics

A useful distinction is between activity metrics — which measure what the programme does — and outcome metrics — which measure what the programme achieves.

Metrics that mislead

Certain metrics — commonly used, intuitive, and misleading — deserve specific caution:

• Number of findings closed. High closure volume may reflect easy findings being closed quickly while difficult findings accumulate.
• Percentage of findings remediated. The denominator includes findings the enterprise has accepted and findings that do not matter. A high percentage may mask significant unaddressed exposure.
• Mean time to remediate across all findings. Averaging across high-priority and low-priority findings obscures whether urgent findings are being addressed promptly.
• Scanner coverage percentage. Coverage is necessary but not sufficient. An estate that is 100% scanned but whose findings are not remediated is not more secure than one that is partially scanned.
• Count of critical findings. The count fluctuates with scanner configuration, database updates, and estate changes. A decrease in the count does not necessarily reflect a decrease in risk.

Metrics that inform

Metrics that meaningfully inform programme improvement typically include:

• Time to remediate, segmented by priority tier. Shows whether the enterprise is meeting its service levels for urgent findings separately from routine ones.
• Percentage of findings under active exploitation that remain unaddressed. Direct measure of the enterprise's exposure to threats that are actually being used.
• Exposure trend. Whether the enterprise's aggregate exposure — measured on a consistent basis — is increasing or decreasing over time.
• Coverage and freshness. What proportion of the estate is under management, and how recently each part has been assessed.
• Ageing distribution. How findings are distributed by age, segmented by priority. Long-tail ageing signals a backlog that will not clear on its own.
• Recurrence rate. How often the same vulnerability class recurs, indicating whether the underlying cause is being addressed.

11 Common pitfalls

Vulnerability management programmes fail in predictable ways. Recognising the patterns accelerates improvement.

Pitfall 1 — Prioritising by CVSS alone

Treating the CVSS base score as the priority. The result is remediation of high-scoring findings in low-value systems while critical exposures remain unaddressed.

Mitigation: Adopt risk-based prioritisation, incorporating exploitability, exposure, asset value, and control effectiveness alongside severity.

Pitfall 2 — Incomplete coverage

Scanning only the systems the enterprise knows about, leaving legacy systems, cloud environments, and shadow assets unscanned. Coverage gaps undermine the programme regardless of how well the scanned portion is managed.

Mitigation: Invest in asset discovery; integrate cloud and container scanning; automate coverage monitoring.

Pitfall 3 — Findings without action

Producing findings that are not triaged, assigned, or remediated. The programme becomes a reporting exercise disconnected from remediation.

Mitigation: Integrate findings with ticketing and workflow systems; assign ownership for every finding; track remediation to completion.

Pitfall 4 — No verification

Closing findings based on the assumption that remediation was effective, without verification. The vulnerability may remain, or the remediation may have introduced new issues.

Mitigation: Verify remediation — rescan, retest, or equivalent confirmation — before closing findings.

Pitfall 5 — Backlog accumulation

Producing findings faster than the enterprise remediates them, so that the backlog grows indefinitely. A growing backlog is a signal that prioritisation, capacity, or both, are failing.

Mitigation: Address the underlying cause — capacity, automation, or prioritisation discipline. Consider whether some findings should be explicitly accepted rather than silently carried in the backlog.

Pitfall 6 — Repeated remediation of the same class

Remediating instances of the same vulnerability class repeatedly without addressing the underlying cause — the development practice, configuration pattern, or deployment process that produces it.

Mitigation: Analyse recurring findings; address the underlying cause through process change, automation, or organisational learning.

Pitfall 7 — Unbalanced programme

Investing heavily in scanning and reporting while under-investing in remediation capacity. The programme identifies far more than the enterprise can address.

Mitigation: Balance discovery investment with remediation capacity. Automate remediation where possible; consider whether the enterprise's scanning frequency or scope exceeds what it can act on.

Pitfall 8 — Metrics without meaning

Reporting on activity — scans run, findings closed — rather than on outcomes — exposure trend, time to remediate, percentage of actively exploited findings addressed.

Mitigation: Choose metrics that reflect the enterprise's actual exposure and its trend. Segment by priority; report on outcomes.

12 Key concepts

The terms below are used throughout Module 2. Capture them in your own words as you work through the lesson.

Vulnerability assessment

The systematic identification, evaluation, and prioritisation of weaknesses in an enterprise's systems, applications, configurations, and processes. Produces a picture of the enterprise's exposure and a basis for remediation decisions.

Vulnerability scanning

The automated identification of weaknesses across systems, applications, and configurations. May be unauthenticated, authenticated, agent-based, or application-focused.

Penetration testing

The practice of attempting to exploit vulnerabilities to demonstrate their impact. Provides evidence of exploitability and business-impact narrative that scanning alone does not.

Black box / grey box / white box testing

Penetration testing approaches distinguished by the amount of knowledge provided to the tester — none, partial, or full.

Red teaming

Adversary emulation against the full enterprise, testing detection and response capability rather than vulnerabilities alone.

CVE

Common Vulnerabilities and Exposures — a catalogue of publicly disclosed vulnerabilities, each assigned a unique identifier. The common reference point for discussing specific vulnerabilities.

NVD

National Vulnerability Database — the US government's repository of vulnerability data, including CVSS scores, affected products, and references.

CVSS

Common Vulnerability Scoring System — a standardised method for expressing the severity of a vulnerability, producing a numerical score (0–10) and a qualitative rating (None, Low, Medium, High, Critical).

Base / temporal / environmental metrics

The three CVSS metric groups: base metrics describe intrinsic characteristics; temporal metrics describe characteristics that change over time; environmental metrics adjust the score for the enterprise's specific context.

EPSS

Exploit Prediction Scoring System — predicts the likelihood that a vulnerability will be exploited in the wild. Complements CVSS for prioritisation.

SSVC

Stakeholder-Specific Vulnerability Categorisation — a decision-tree framework producing vulnerability categories based on exploitation status, technical impact, and mission impact. Designed for prioritisation rather than severity scoring.

Vulnerability management lifecycle

The stages through which findings pass: discovery, assessment, prioritisation, remediation, verification, reporting, and continuous improvement.

Time to remediate

The period between when a vulnerability is identified and when it is fixed. The most consequential metric in vulnerability management, determining the window of exposure.

Remediation service level

A target timeframe for remediating findings of a given priority. Converts prioritisation into an enforceable discipline.

Compensating control

A control used in place of, or in addition to, a preferred remediation when the preferred remediation is not feasible. Reduces the residual risk of an unpatched vulnerability.

Risk-based prioritisation

Prioritising remediation based on the assessed risk of each finding in the enterprise's context — incorporating exploitability, exposure, asset value, control effectiveness, and business impact, not severity alone.

Actively exploited vulnerability

A vulnerability for which exploitation has been observed in the wild. One of the strongest signals for urgent remediation.

SBOM

Software Bill of Materials — a machine-readable inventory of the components that make up a software artifact, allowing enterprises to identify exposure when a component is later found vulnerable.

Software composition analysis (SCA)

Analysis of applications and their dependencies to identify vulnerable components. Essential where third-party libraries are used at scale.

Cloud security posture management (CSPM)

Assessment of cloud configurations against best practice and policy — public storage, permissive identity policies, unencrypted data, and similar issues.

False positive

A finding reported by a scanner that is not actually a vulnerability in the enterprise's context — for example, because the affected service is not enabled or is mitigated by other controls.

False negative

A vulnerability that exists but is not reported — because the scanner cannot reach it, lacks credentials, or lacks the relevant signature.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 3.4. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined vulnerability assessment — the discipline through which the enterprise identifies, evaluates, and prioritises the weaknesses that make threats exploitable. The essential points are:

• Vulnerability assessment is a management discipline, not merely the operation of scanning tools. It encompasses discovery, assessment, prioritisation, remediation, verification, and continuous improvement.
• Vulnerabilities arise from many sources. Software defects, third-party dependencies, configuration weaknesses, architectural flaws, operational weaknesses, and human factors. The unmanaged asset is often the most consequential vulnerability.
• Scanning provides broad, continuous coverage. It may be unauthenticated, authenticated, agent-based, or application-focused. Scanners are valuable but limited — they find known vulnerabilities, may produce false positives and negatives, and cannot assess architectural weaknesses.
• Penetration testing demonstrates exploitability and business impact. It complements scanning by confirming what actually matters and by identifying issues scanners miss. It is point-in-time and sample-based, and does not prove absence of vulnerabilities.
• CVSS provides a standardised severity score. It has base, temporal, and environmental metric groups. Its most consequential limitation is that it measures severity, not risk.
• The vulnerability management lifecycle is continuous. Discovery, assessment, prioritisation, remediation, verification, reporting, and improvement. Time to remediate is the most consequential metric.
• Risk-based prioritisation is the solution to the volume problem. It incorporates exploitability, exposure, asset value, control effectiveness, and business impact alongside severity. Severity-only prioritisation produces the wrong remediation decisions.
• Prioritisation must be enforced to be effective. Remediation service levels, ownership, tracking, and escalation convert prioritisation into a functioning discipline.
• Metrics determine what the programme optimises for. Outcome metrics — exposure trend, time to remediate by priority tier, percentage of actively exploited findings addressed — are more meaningful than activity metrics.
• Common pitfalls recur. Prioritising by CVSS alone; incomplete coverage; findings without action; no verification; backlog accumulation; repeated remediation of the same class; unbalanced programme; metrics without meaning.

These ideas prepare for Lesson 3.4, which examines malware and ransomware — the attack classes that most frequently exploit unpatched vulnerabilities and that have driven the urgency of vulnerability management over the past decade.