Vulnerability Management and Prioritisation
Run a continuous vulnerability programme that prioritises by real risk rather than raw scanner counts.
- Certification
- CompTIA CySA+
- Recommended study time
- 5h 30m
- Status
- Not started
Recommended study time
About 5h 30m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson20 min
About 2,561 words at a careful technical reading pace.
- Second pass with notes12 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Design scanning coverage including authenticated and cloud assessment.
- Prioritise findings using exploitability, exposure, and business context.
- Track remediation with owners, deadlines, and verified closure.
Start here
About 8 minutes of reading, in 10 short parts.
Vulnerability management is the ongoing cycle of finding weaknesses across an organisation's systems, deciding which ones actually matter, and proving they get fixed. Every scanner produces far more findings than any team can act on, so the entire discipline is really about prioritisation and follow-through.
Where you meet it: A systems administrator gets a monthly list of hundreds of scan findings and has to decide, with a limited maintenance window, which ten to patch this week.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Imagine a building inspector who finds two hundred issues in a large office: a squeaky door, a cracked window on the ground floor facing the street, a loose railing on a rarely used back stairwell, and a fire exit that is blocked. All two hundred are technically 'problems', but nobody would fix them in the order they were written down. You fix the blocked fire exit and the ground-floor window facing a public street first.
Vulnerability management is that same triage applied to software flaws. A scanner finds hundreds of weaknesses across all your computers, but a security team has to decide which ones are actually reachable by an attacker, which ones attackers are already using in the wild, and which ones sit on a machine nobody could realistically get to.
Key ideas
If you remember nothing else from this topic, remember these.
- Vulnerability management is a continuous cycle of discovery, prioritisation, remediation, and verification, not a one-time scan.
- CVSS base scores describe technical severity in isolation and must be adjusted with environmental and threat context to prioritise real risk.
- Exploitability evidence, such as a public exploit or active exploitation in the wild, often matters more for prioritisation than the raw CVSS number.
- Asset criticality and exposure (internet-facing versus internal) change the real-world priority of an identical vulnerability.
- Remediation is not only patching; compensating controls and configuration changes can reduce risk when patching is not immediately possible.
- Verification scanning after remediation is required to confirm the fix actually closed the vulnerability, not just that a patch was deployed.
Prioritising a critical vulnerability under a patching deadline
A worked example, step by step.
A monthly authenticated scan reports CVE-2024-XXXX, a remote code execution flaw in an internet-facing web application server, with a CVSS base score of 9.8.
- 01Confirm CVSS vectorRead the vector string AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, confirming network attack vector, low complexity, no privileges or user interaction required, and high impact to confidentiality, integrity, and availability.
- 02Check exploit availabilitySearch exploit databases and vendor advisories and find a public proof-of-concept exploit was published two days ago, plus CISA KEV catalog listing indicating active exploitation.
- 03Assess exposureConfirm the affected server is internet-facing and hosts the customer payment portal, elevating business impact beyond the technical score alone.
- 04Assign environmental priorityCombine CVSS base score, KEV listing, and internet exposure to assign an internal priority of Critical with a 48-hour remediation SLA, overriding the standard 30-day window for high severity.
- 05Evaluate compensating controlsWhile the patch is staged for testing, deploy a WAF rule blocking the known exploit payload pattern as an interim mitigation.
- 06Coordinate patchingWork with the systems team to test the vendor patch in staging, then deploy to production within the 48-hour window with a rollback plan.
- 07Verify remediationRun an authenticated rescan confirming the vulnerability no longer appears and the patched version string is reported.
- 08Document and closeClose the finding in the vulnerability management system with evidence: scan date, patch version, and verification scan result.
Outcome: The critical internet-facing vulnerability is mitigated within hours via WAF rule and fully remediated within the 48-hour SLA, with verification evidence preventing a false sense of closure.
Vulnerability management reference
Worth keeping at hand while you work.
- CVSS AV
- Attack Vector: Network, Adjacent, Local, or Physical
- CVSS AC
- Attack Complexity: Low or High
- CVSS PR
- Privileges Required: None, Low, or High
- CVSS UI
- User Interaction: None or Required
- CVSS C/I/A
- Impact to Confidentiality, Integrity, Availability: None, Low, High
- CVSS Scope (S)
- Whether impact extends beyond the vulnerable component
- CISA KEV
- Known Exploited Vulnerabilities catalog indicating active exploitation
- Authenticated scan
- Scan performed with credentials, revealing more accurate findings than unauthenticated
- Compensating control
- Interim mitigation, such as a WAF rule, used when patching is delayed
- Remediation SLA
- Time window required to fix a finding based on its assigned severity
- Verification scan
- Rescan confirming a fix actually closed the finding
- False positive rate
- Proportion of scanner findings that do not represent a real vulnerability
Common misunderstandings
What most beginners get wrong here.
The CVSS base score alone determines remediation priority.
Environmental factors such as exposure, asset criticality, and active exploitation evidence should adjust the priority beyond the base score.
Running a scan is the same as managing vulnerabilities.
Vulnerability management is a full cycle including prioritisation, remediation, and verification, not just discovery.
Patching is the only valid remediation.
Compensating controls like WAF rules or network segmentation can reduce risk when immediate patching is not possible.
A deployed patch always means the finding is resolved.
A verification rescan is required to confirm the patch actually closed the vulnerability, since deployment can fail silently.
Unauthenticated scans give a complete picture of risk.
Authenticated scans reveal far more accurate findings, including missing patches and local misconfigurations invisible externally.
Exam traps
How the question writers try to catch you out.
- CySA+ commonly tests reading a CVSS vector string and identifying which metric changed between two scores, such as privileges required shifting from None to Low.
- Expect scenarios where a lower CVSS score vulnerability should be prioritised above a higher one due to active exploitation or internet exposure.
- Exam items test knowing that CVSS environmental and temporal metrics adjust the base score for organisational context.
- Watch for distinguishing a false positive from a false negative in scan results and the correct remediation workflow response to each.
- Questions often require recognising that closing a finding without a verification scan is a documentation gap, not proper closure.
Check yourself
Answer in your head first, then reveal. This is not scored.
What does an AV:N vector component mean?
Why might a CVSS 7.5 vulnerability be prioritised above a 9.8 one?
What is a compensating control?
Why is a verification scan necessary after patching?
What does CISA KEV listing indicate?
Why do authenticated scans find more issues than unauthenticated scans?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Vulnerability management is a continuous cycle: asset discovery, scanning (authenticated where possible), validation, prioritisation, remediation, and verification. Prioritisation combines CVSS severity with exploit availability, internet exposure, compensating controls, and asset criticality. Metrics track mean time to remediate and coverage rather than raw counts.
Why It Matters
A medium-severity flaw on an internet-facing system with a public exploit is more urgent than a critical on an isolated internal host. Programmes that ignore context waste effort and still get breached.
How It Works
- Discovery builds the asset list; scanners assess each against a vulnerability database.
- Findings are validated, deduplicated, and enriched with exposure and criticality context.
- Remediation is tracked to a verified rescan rather than a closed ticket.
Where You See It
- Monthly patch cycles, cloud posture management, penetration test follow-up, and audit evidence.
Key Terms
- Authenticated scan
- Scanning with credentials for accurate installed-software data.
- CVSS
- A standard severity score, not a complete risk measure.
- KEV
- Known exploited vulnerability catalogue used for prioritisation.
- Compensating control
- A control reducing risk when patching is not possible.
- Remediation SLA
- Agreed timeframe by severity for fixing findings.
Examples
- An unauthenticated scan may miss client-side software entirely, understating real exposure.
- A vulnerability with a public exploit and internet exposure warrants emergency change handling.
Common Problems
- Unscanned assets
- Unauthenticated-only scanning
- Unowned findings
- Endless backlog
- Unverified closure
How It Fails
- Assets outside the inventory are never scanned and become the breach path.
- Backlogs grow until the programme is ignored entirely.
- Findings closed without rescan reappear at the next audit.
How to Troubleshoot
- Reconcile scan coverage against asset inventory and cloud accounts.
- Verify credentials are working when results appear implausibly clean.
- Investigate repeated findings for a broken deployment or imaging process.
Practical Knowledge
- Give every finding an owner and a due date, or it will not be fixed.
- Track mean time to remediate for internet-facing critical findings as the headline metric.
Exam Coverage
- Scanning types and coverage
- Prioritisation and scoring
- Remediation tracking and validation
Interview Questions
- Why is CVSS alone insufficient for prioritisation?
- How would you handle a critical vulnerability that cannot be patched?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Professor Messer video channel — general CompTIA training (no dedicated CompTIA CySA+ course)
Professor Messer
WatchVideoFree
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Rank ten current findings using exposure and exploit availability, not just CVSS.
- 02Check whether your scan coverage matches the asset inventory.