Vulnerability Assessment

A vulnerability assessment is a structured process for finding and rating the security weaknesses in an environment before an attacker does. It typically combines authenticated and unauthenticated scanning with manual verification, then reports each finding with a severity rating, an affected-asset list and clear remediation steps.

The distinction from penetration testing matters. A vulnerability assessment aims for breadth: it enumerates as many weaknesses as possible across the estate and ranks them. A penetration test aims for depth: it takes a smaller set of weaknesses and proves whether they can actually be exploited and chained to reach a business-critical outcome. Many organisations run frequent vulnerability assessments and periodic penetration tests, because the two answer different questions.

A rigorous assessment follows a repeatable methodology: define the scope and asset inventory, run credentialed and network scans, validate results to strip out false positives, rate each finding against a framework such as CVSS, and then re-rank by real-world exploitability using signals like EPSS probability and CISA KEV status. Raw CVSS alone tends to flag most findings as high or critical, which is why prioritisation by exploitation likelihood is the step that makes a report actionable.

Common categories a vulnerability assessment surfaces include missing patches and outdated software, insecure configurations and default credentials, exposed services and unnecessary open ports, weak encryption and certificate issues, and access-control gaps. External assessments look at the internet-facing perimeter, while internal assessments assume an attacker already has a foothold and examine what they could reach.

Frequency should match the rate of change in the environment. Static estates may only need quarterly assessments, whereas fast-moving cloud and DevOps environments benefit from continuous or monthly scanning so that new exposures are caught soon after they appear rather than at the next annual review. Regulatory frameworks including PCI DSS and ISO 27001 expect regular vulnerability assessment as part of a documented risk-management programme.

Deliverables separate a useful assessment from a noisy one. A strong report includes an executive summary that a non-technical stakeholder can act on, a technical section with reproduction detail and evidence for each finding, a clear severity and priority for every item, and specific remediation guidance rather than generic advice. It should also strip out the false positives that automated tools inevitably produce, because a report full of issues that turn out not to exist quickly loses the trust of the engineers expected to fix them.

Vulnerability assessment appears in most major compliance frameworks. PCI DSS, ISO 27001, SOC 2 and Cyber Essentials all expect regular assessment as evidence of a managed security programme, and many require it at a defined cadence. Treating assessment as a compliance tick-box, however, misses the point: the value is not the report itself but the remediation it drives, so the assessments that matter are the ones wired into a workflow that actually closes findings.

A vulnerability assessment is most valuable when it feeds a prioritisation and remediation workflow rather than sitting in a PDF. Precursor pairs assessment output with risk-based prioritisation, so teams work the small percentage of findings that attackers actually exploit rather than an undifferentiated list of hundreds.