Every organisation now has far more known vulnerabilities than it can fix, and the vulnerability analyst is the person who decides which ones matter and makes sure they actually get fixed. The role sits between scanners, threat intelligence and the IT teams who patch, and it is as much about prioritisation and persuasion as about technical depth. This guide explains what vulnerability analysts do, the skills and tools behind good prioritisation, realistic routes in, certifications that help and where the role leads. It is written for SOC and IT operations staff, junior security analysts and career changers considering vulnerability management as a specialism.
Key takeaways
- Prioritisation is the job. Scanners produce thousands of findings; the analyst's value is ranking them by exploitation, exposure and business impact, not by CVSS base score alone.
- Remediation is a team sport. Analysts rarely patch anything themselves, so clear tickets, sensible deadlines and good relationships with system owners decide outcomes.
- Know the scoring systems and their limits. CVSS describes severity, EPSS estimates likelihood of exploitation, KEV records exploitation already seen, and SSVC turns them into decisions.
- Asset context beats scan volume. An analyst who knows what is internet-facing, who owns it and what it supports will out-prioritise one with a better scanner.
- The role is a strong base. It leads to exposure management, penetration testing, application security, cloud security or security architecture.
What the role does
NIST's NICE Framework includes tasks such as "Perform risk and vulnerability assessments" and skills such as "Skill in scanning for vulnerabilities" in its Vulnerability Analysis work role. In practice a vulnerability analyst runs a repeating cycle:
- Discover: keep scan coverage complete across servers, endpoints, cloud accounts, containers and network devices, and reconcile scanner targets against the asset inventory so nothing is silently missed.
- Assess: validate findings, remove false positives, and work out whether the vulnerable component is actually reachable and in use.
- Prioritise: combine severity, exploitation evidence, exposure and asset criticality into a ranked list with deadlines.
- Drive remediation: raise tickets with system owners, agree fixes or mitigations, and chase overdue items.
- Handle exceptions: document risk acceptances with an owner, compensating controls and an expiry date.
- Verify and report: rescan to confirm fixes and report trends to IT and leadership.
On top of the cycle sit urgent events: a widely exploited flaw in an edge device, a vendor emergency advisory, or a new entry in CISA's Known Exploited Vulnerabilities (KEV) catalogue that matches your estate. On those days the analyst finds every affected instance within hours and coordinates the response. The NCSC's vulnerability management guidance frames the same work as six principles, including updating by default, identifying assets, triaging and prioritising, and making the decision not to update an owned, senior-level risk decision. See the Vulnerability Management Guide for the programme view.
| Role | Main question | Typical output |
|---|---|---|
| Vulnerability analyst | Which known weaknesses in our estate matter most, and are they getting fixed? | Prioritised findings, remediation tickets, exceptions, metrics |
| Penetration tester | Can an attacker chain weaknesses to reach an objective in this scope? | Time-boxed test report with proven attack paths |
| Vulnerability researcher | Is there an unknown flaw in this product? | New CVEs, disclosure to the vendor |
| Patch or endpoint engineer | How do we deploy the fix safely? | Tested patch deployments and rollback plans |
Core skills and tools
Scoring and prioritisation
| Input | What it tells you | Limits |
|---|---|---|
| CVSS v4.0 (FIRST) | Severity from Base metrics, refined by Threat metrics (such as exploit maturity) and Environmental metrics (your controls and asset importance). Labels CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE show which groups were used | A Base-only score ignores exploitation and your environment; many feeds publish only CVSS-B. See the CVSS v4 Guide |
| EPSS (FIRST) | Estimated probability that a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE | A probability across the whole internet, not a statement about your estate |
| CISA KEV catalogue | Vulnerabilities with evidence of active exploitation, with required action and due dates for US federal agencies | Lists confirmed exploitation only; absence does not mean safe |
| SSVC (CISA and CMU SEI) | A decision tree using exploitation status, technical impact, automatable, mission prevalence and public well-being impact, producing Track, Track*, Attend or Act | Needs local knowledge of mission prevalence and impact to be meaningful |
| Asset context | Internet exposure, data held, business service, owner, compensating controls | Only as good as the inventory and CMDB |
A practical rule many teams use: anything in KEV or with strong exploitation evidence on an internet-facing asset goes to the top regardless of its CVSS score, while a critical CVSS score on an isolated, low-value system with no exploitation evidence can wait for the normal cycle. Writing that logic down, and getting it agreed, is a core analyst task. See the Risk-Based Vulnerability Management Guide.
Technical skills
- Operating systems and networking: how Windows and Linux are patched, how packages and libraries are versioned, which services listen on which ports, and why a finding on port 445 or 3389 facing the internet is urgent.
- Reading advisories: pull affected versions, preconditions, workarounds and exploitation status from vendor advisories and CVE records. See the How to Read a CVE Advisory Guide and the CVE, CWE and CPE Guide.
- Scanning: authenticated versus unauthenticated scans, agent versus network scanning, scan windows, and why credentialed scans find far more. Scanner service accounts hold wide privileges, so treat them as privileged identities.
- Cloud and containers: image scanning, cloud posture findings and the difference between a vulnerable package in an image and one actually running.
- Software composition: reading an SBOM to answer "are we affected?" when a library flaw lands. See the SBOM Guide.
- Data handling: SQL or Python to join scanner exports with asset and ownership data, deduplicate findings and build trend reports.
- Communication: tickets a system owner can act on without a meeting, and a one-page monthly report leadership reads.
Tool categories: network and agent vulnerability scanners, cloud security posture and container image scanners, software composition analysis, attack surface management for unknown internet-facing assets, a ticketing system, and a prioritisation or exposure management platform in larger teams. The Attack Surface Management Guide covers the external view.
Routes into the role
| Starting point | What transfers | Gap to close |
|---|---|---|
| System administrator or IT operations | Patching, change management, knowing the estate and its owners | Scoring systems, threat context, reporting |
| SOC analyst | Threat awareness, ATT&CK, incident urgency | Patching realities and remediation negotiation. See the SOC Analyst Career Guide |
| Junior security or GRC analyst | Risk language, exceptions, audit evidence | Hands-on scanning and technical validation. See the GRC Analyst Career Guide |
| Graduate or career changer | Analysis, data skills, writing | Lab experience with a scanner and a few deliberately vulnerable VMs |
The US Bureau of Labor Statistics includes this work in its information security analysts occupation, which it reports had a median wage of $129,180 in May 2025 and projected growth of 21% from 2025 to 2035, typically with a bachelor's degree. The category is broad, so treat the figures as context rather than a vulnerability analyst salary.
Building evidence: in a home lab, run an open source or free-tier scanner against deliberately vulnerable VMs you own, then write a prioritised remediation plan for the results using CVSS, EPSS and KEV, explaining every ranking decision. Patch, rescan and show the before and after. Only ever scan systems you own or have written permission to scan; unauthorised scanning can breach computer misuse law and employer policy. See the Building a Cybersecurity Home Lab Guide.
Certifications that help
Facts below are from the certifying bodies' own pages, as checked 26 Oct 2026. Formats and prices change; confirm before booking.
| Certification | Body | Relevance | Format (as checked 26 Oct 2026) |
|---|---|---|---|
| CySA+ (CS0-004) | CompTIA | The closest general fit: Vulnerability Management is 26% of the exam, and CompTIA recommends about four years as a SOC or vulnerability analyst | Up to 85 questions, 165 minutes, pass mark 750 on a 100 to 900 scale; V4 launched 23 June 2026, V3 English exam retires 22 December 2026 |
| Security+ | CompTIA | Entry foundation before CySA+ | See the Cybersecurity Certifications Guide |
| GEVA (Enterprise Vulnerability Assessor) | GIAC | Was the specialist vulnerability assessment credential | GIAC states it is "currently in abeyance and no longer available for purchase"; existing holders renew through CPEs |
| Penetration testing certifications (for example OSCP) | OffSec and others | Useful for validating exploitability and for a later move into testing | See the OSCP Certification Guide |
| Vendor scanner and cloud certifications | Tool and cloud vendors | Valuable once you work with a specific platform | Check the vendor's training site |
Hiring managers for this role tend to weigh evidence of prioritisation thinking and stakeholder handling as heavily as certificates. A written remediation plan from your lab is a strong interview artefact.
Progression
| Path | What changes | Read next |
|---|---|---|
| Vulnerability management lead | Owning the programme: policy, SLAs, exceptions, tooling and metrics | Vulnerability Management Maturity Model |
| Exposure management | From CVEs to all exposures: misconfigurations, identities, attack paths | Exposure Management and CTEM Guide |
| Penetration testing | From finding known flaws to proving attack paths under authorisation | Penetration Tester Career Guide |
| Application security | Fixing flaws in code before release, SCA and SAST programmes | Application Security Engineer Career Guide |
| Cloud security engineering | Posture, image and infrastructure-as-code scanning at scale | Cloud Security Engineer Career Guide |
| Vulnerability research | Finding new flaws and coordinating disclosure | Bug Bounty and Vulnerability Disclosure Guide |
Choosing: analysts who enjoy the programme and the politics move towards leadership and exposure management; those drawn to the technical "is it really exploitable?" question move towards testing or research. For organisations, small teams usually combine this role with patching or SOC duties, while large ones split scanning engineering, analysis and remediation coordination.
Where identity fits
Patching is not always the end of a vulnerability. In the CitrixBleed breach, session tokens stolen before the upgrade stayed valid until sessions were explicitly terminated, and at least one organisation was breached after it had patched. Analysts who include "rotate credentials and revoke sessions" in remediation tickets for edge device and identity platform flaws close that gap. Scanner credentials themselves are powerful machine identities; see the Patch Management Guide for securing patching and scanning tooling.
Measuring the work
- Scan coverage: percentage of inventoried assets scanned with credentials in the last cycle.
- Mean time to remediate by priority: especially for KEV-listed and internet-facing findings, against agreed SLAs. See the Remediation SLAs and Vulnerability Exceptions Guide.
- SLA compliance: share of findings fixed within their deadline.
- Exception health: number of open risk acceptances and how many are past expiry.
- Recurrence: findings that return after being closed, which point to build or image problems.
Framework mapping
| Framework | Where vulnerability analysis sits |
|---|---|
| NICE Framework (NIST SP 800-181 Rev. 1) | Vulnerability Analysis work role |
| NIST CSF 2.0 | ID.RA-01 (vulnerabilities identified, validated and recorded), ID.RA-08 (vulnerability disclosure processes), PR.PS-02 (software maintained commensurate with risk) |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation, RA-3 Risk Assessment |
| NIST SP 800-40 Rev. 4 | Guide to Enterprise Patch Management Planning: patching as preventive maintenance |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management |
| ISO/IEC 27001:2022 Annex A | 8.8 Management of technical vulnerabilities |
| MITRE ATT&CK v20 | T1190 Exploit Public-Facing Application, the technique most prioritisation is trying to pre-empt |
Common failure patterns
- Sorting by CVSS base score: teams chase hundreds of "critical" findings on internal systems while an exploited medium on an internet-facing device waits.
- Scanning what you know about: scanner scope copied from an old inventory misses new cloud accounts and shadow internet-facing services.
- Throwing reports over the wall: sending system owners a spreadsheet of thousands of rows instead of a short, prioritised ticket with the fix.
- Permanent exceptions: risk acceptances with no owner or expiry that quietly become the norm.
- Closing without verifying: marking a finding fixed on the owner's word without a rescan, or without revoking sessions where the flaw leaked tokens, as in the CitrixBleed case.
Practitioner checklist
- Learn CVSS v4.0, EPSS, KEV and SSVC well enough to explain why each would rank a given CVE differently.
- Build a lab with a scanner and deliberately vulnerable VMs you own, and write a prioritised remediation plan from the results.
- Practise reading five vendor advisories and extracting affected versions, workarounds and exploitation status.
- Learn enough SQL or Python to join scanner output with asset ownership data.
- Draft a sample prioritisation policy with SLAs and an exception process.
- Take CySA+ or an equivalent once you have hands-on scanning experience.
- Build working relationships with the patching and platform teams you will depend on.
- Pick a progression path within two years and seek projects that build towards it.
Standards and references
- CISA NICCS: NICE Framework, Vulnerability Analysis work role
- FIRST: CVSS v4.0 Specification Document
- FIRST: Exploit Prediction Scoring System (EPSS)
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NCSC: Vulnerability management
- CompTIA: CySA+ V4 (CS0-004)
- US Bureau of Labor Statistics: Information Security Analysts
Related NHI Mgmt Group resources: Vulnerability Management Guide · Risk-Based Vulnerability Management Guide · CVSS v4 Guide · Malware Analyst Career Guide · Cybersecurity Careers Guide