BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 21, 2026

Quick answer: A vulnerability assessment is a systematic identification of security weaknesses across your environment: networks, systems, applications, cloud infrastructure, and configurations. It uses authenticated scanning tools to enumerate every asset and compare it against known vulnerability databases, then layers manual validation to remove false positives, correlate findings across sources, and apply business context so the output is a prioritized list of what actually matters rather than a raw dashboard of thousands of scanner findings. It does not exploit the vulnerabilities it finds; that is what a penetration test does. The assessment tells you where you are exposed and how serious each exposure is. It does not demonstrate what an attacker could achieve by chaining exposures together.

Key Takeaways

• A vulnerability assessment is not the same as running a scanner. The scanner produces the raw findings; the assessment is the work that validates those findings, removes false positives, correlates duplicates, applies CVSS scoring with business context, and packages the output as a remediation roadmap the engineering team can act on.
• Vulnerability assessments do not exploit vulnerabilities. They identify and document weaknesses without attempting to breach the environment. This is what distinguishes them from penetration testing, which goes further by actively exploiting findings to demonstrate real-world impact and chain multiple findings into attack paths.
• Most compliance frameworks including SOC 2, ISO 27001, PCI DSS, HIPAA, and CMMC require vulnerability assessments on a regular schedule, typically quarterly or annually depending on the framework and the environment. The assessment produces the compliance documentation these frameworks require for vulnerability management controls.
• False positives are a major source of wasted engineering effort in unmanaged vulnerability programs. Modern scanners flag vulnerabilities that do not apply to the specific configuration of the scanned environment, that have compensating controls in place, or that are not reachable from any realistic attack path. Manual validation that removes false positives before the report is delivered protects the remediation team from spending limited capacity on vulnerabilities that do not exist in practice.
• The most useful output of a vulnerability assessment is not the finding count but the prioritized remediation roadmap: a ranked list of what to fix first, sequenced by risk reduction per unit of remediation effort, with timelines, ownership, and the compliance mapping the auditor will ask for.

What a Vulnerability Assessment Covers

A comprehensive vulnerability assessment covers every layer of the environment where security weaknesses can exist. Network infrastructure assessment scans routers, switches, firewalls, VPN gateways, and other network appliances for outdated firmware, misconfigurations, and exposed services that should not be accessible from the networks they face. System and workstation assessment scans Windows, Linux, and macOS endpoints for missing operating system patches, outdated application software, and configuration weaknesses measured against industry hardening benchmarks such as the CIS Benchmarks.

Web application scanning covers known vulnerability classes in web applications: injection flaws, authentication weaknesses, misconfigured headers, and components with known vulnerabilities. Cloud infrastructure assessment evaluates IAM configuration, exposed storage, security group misconfigurations, and posture against the cloud security benchmarks published for AWS, Azure, and Google Cloud. Database configuration review assesses access controls, encryption posture, audit logging, and hardening against database-specific benchmarks. Configuration compliance assessment measures system configurations against recognized hardening standards, identifying drift from secure baselines that traditional vulnerability scanners often miss because they look for known CVEs rather than configuration deviations.

The scope of a specific engagement is defined during the planning phase based on the organization’s asset inventory, criticality assessments, and compliance requirements. Not every engagement covers all surfaces; a targeted assessment may focus on the external perimeter or a specific application stack, while a comprehensive baseline assessment covers the full environment. The scope definition is what makes the engagement useful: a well-scoped assessment covers the surfaces that carry the most risk for the specific organization rather than running every available scan against every available target.

How Findings Are Validated and Prioritized

False positive removal

The most important step that separates a useful vulnerability assessment from raw scanner output is false positive removal. Modern vulnerability scanners are designed to be comprehensive and err on the side of over-reporting: they flag a potential vulnerability whenever the conditions that could indicate the vulnerability are present, even when additional context would reveal that the specific configuration of the target makes the vulnerability unexploitable. An organization with a mid-sized environment can easily receive thousands of findings from a single scan cycle. A significant fraction of those findings are false positives: vulnerabilities attributed to software versions that have been patched by a vendor update that changed the version string differently than the scanner expected, vulnerabilities flagged for services that are present but not reachable from any network path an attacker could use, or vulnerabilities in software components that are installed but not executed in any way that exposes the vulnerability.

Removing false positives requires manual analysis: reviewing the specific finding in the context of the specific target’s configuration, confirming that the conditions for the vulnerability are actually present, and documenting the evidence for the confirmation or removal. This work is time-consuming and requires security expertise that most internal IT teams do not have available at the scale a comprehensive scan requires. Assessments that deliver validated findings, with false positives removed and duplicates correlated across scanners, give the remediation team a list of real vulnerabilities rather than a noise-contaminated inventory that wastes capacity on non-existent problems.

CVSS scoring with business context

The Common Vulnerability Scoring System (CVSS) provides a standardized numerical score for each vulnerability, ranging from 0.0 to 10.0, based on factors including the attack vector (network, adjacent, local, or physical), the attack complexity, the privileges required, the impact on confidentiality, integrity, and availability, and whether user interaction is required. CVSS scores provide a consistent baseline for comparing the severity of different vulnerabilities. They are not, on their own, a sufficient basis for remediation prioritization.

The limitation of raw CVSS scores for prioritization is that they do not reflect the specific context of your environment. A critical CVSS score on a vulnerability in software running on a server that is not reachable from any external network and that does not hold sensitive data is not the same remediation priority as a high CVSS score on a vulnerability in a publicly accessible authentication service. Business context adjustment modifies the raw CVSS score based on the asset criticality (how important is the affected system to business operations), the exploitability in the specific environment (is the vulnerability actually reachable given the network architecture), and the real-world exploitation activity (is this vulnerability being actively exploited in the wild, and is it listed in CISA’s Known Exploited Vulnerabilities catalog). The adjusted score reflects what actually matters to your organization, not what matters to a generic organization with no specific context applied. Those adjusted, business-ranked findings are what belong on a security risk register as tracked, owned exposures rather than left to expire in a scanner export.

What the Output Looks Like

A well-structured vulnerability assessment delivers several distinct outputs serving different audiences. The executive summary provides board-ready metrics: the total finding count by severity, the most significant findings described in business impact terms, the trend comparison against the prior assessment cycle, and the prioritized remediation focus areas. Executives and audit committees who need to understand the organization’s vulnerability posture without reviewing technical detail use this section.

The detailed finding inventory documents every confirmed vulnerability with its CVSS score, the affected asset, the evidence of the finding, the business impact, and specific remediation steps written for the engineer who will close it. The prioritized remediation roadmap ranks findings by the combination of risk score and remediation effort, sequencing the work so that the highest risk reduction per unit of engineering time is achieved first. Compliance mapping shows which findings satisfy which framework requirements, making the assessment output directly usable as audit evidence for SOC 2, ISO 27001, PCI DSS, HIPAA, and CMMC. Armour Cybersecurity delivers all of these outputs as standard deliverables on every vulnerability assessment engagement.

Frequently Asked Questions

How is a vulnerability assessment different from a penetration test?

A vulnerability assessment identifies and documents security weaknesses without attempting to exploit them. It answers the question: what vulnerabilities exist in my environment and how serious are they? A penetration test goes further by actively attempting to exploit identified vulnerabilities, chain multiple findings into realistic attack paths, and demonstrate the actual business impact an attacker could achieve. Vulnerability assessments are typically conducted more frequently (quarterly or annually) and cover the full environment broadly. Penetration tests are conducted less frequently and focus depth of adversarial simulation over breadth of coverage. Most compliance frameworks require both: vulnerability assessments for ongoing hygiene and penetration testing for periodic adversarial validation. The two complement each other: the vulnerability assessment produces the inventory, and the penetration test demonstrates which items in that inventory chain into material business impact. The distinction is covered in depth in our guide to penetration testing versus vulnerability scanning.

What is CVSS and how does it work?

CVSS stands for Common Vulnerability Scoring System, a published standard maintained by the Forum of Incident Response and Security Teams (FIRST). It provides a numerical score from 0.0 to 10.0 for each vulnerability based on characteristics of the vulnerability itself. The base score reflects factors including how the vulnerability is accessed (remotely over the network, from an adjacent network, locally, or physically), how complex the attack is, what privileges are required, whether user interaction is needed, and the impact on the confidentiality, integrity, and availability of the affected component. Scores of 9.0 and above are Critical, 7.0 to 8.9 are High, 4.0 to 6.9 are Medium, and 0.1 to 3.9 are Low. CVSS version 3.1 remains the most widely used version; CVSS 4.0 was released in November 2023 and adoption is growing across scanners and vulnerability databases. The raw base score is a useful starting point for prioritization but should be adjusted for the specific organizational context.

How often should we conduct a vulnerability assessment?

The right cadence depends on your compliance requirements, the pace of change in your environment, and your risk appetite. PCI DSS is the most prescriptive: Requirement 11.3.1 requires internal vulnerability scans at least once every three months (and after significant change), and Requirement 11.3.2 requires external scans at least once every three months performed by an Approved Scanning Vendor. Both are quarterly, not annual. SOC 2 and ISO 27001 expect vulnerability management evidence consistent with a regular assessment cycle, which most auditors interpret as quarterly for internet-facing systems and at least semi-annually for internal systems. HIPAA and CMMC have similar expectations. Beyond compliance requirements, organizations with active development programs, frequent infrastructure changes, or cloud environments that evolve rapidly benefit from more frequent assessment cycles because the vulnerability landscape of their environment changes more quickly than an annual assessment can track.

What is an authenticated scan and why does it matter?

An authenticated scan provides the scanning tool with valid credentials for the systems being scanned, allowing it to log into each system and assess it from the inside: installed software versions, patch status, local configuration settings, and system-specific vulnerability indicators. Authenticated scanning produces significantly more comprehensive and accurate results than unauthenticated scanning. It finds vulnerabilities in locally installed software that is not externally visible, identifies missing patches that only the local system can report, and assesses configuration weaknesses that require internal system access to evaluate. Unauthenticated scanning assesses only what is visible from the network without credentials, simulating what an external attacker can observe. Both are valuable, and authenticated internal scanning is no longer just best practice under PCI DSS: Requirement 11.3.1.2 makes authenticated internal scanning mandatory, a change that took effect on March 31, 2025.

Can we use a vulnerability assessment report for our SOC 2 or PCI DSS audit?

Yes, provided the report is structured to satisfy the specific requirements of the applicable framework. For SOC 2, the vulnerability assessment provides evidence for the CC7.1 control, which requires that the entity uses detection and monitoring procedures to identify configuration changes and new vulnerabilities. For PCI DSS, the quarterly external scan must be conducted by an Approved Scanning Vendor (ASV) for the scan results to satisfy Requirement 11.3.2, while the quarterly internal scan under Requirement 11.3.1 can be run by qualified internal staff or a third party and does not require an ASV. Not all vulnerability assessment providers are ASV-qualified, so confirming ASV status is important for PCI DSS-scoped external scanning. Armour Cybersecurity structures all assessment reports for direct use during audit engagements, with findings mapped to applicable framework requirements and methodology documentation that satisfies typical assessor expectations.

The Bottom Line

A vulnerability assessment is only as useful as the work that happens after the scan runs. The scanner produces thousands of raw findings; the assessment is the validation that strips out the false positives, correlates the duplicates, applies CVSS scoring adjusted for your actual environment, and turns what remains into a prioritized remediation roadmap your engineers can act on and your auditors can accept. It tells you where you are exposed and how serious each exposure is, but it stops short of proving what an attacker could chain together, which is the job of a penetration test. Run on the cadence your framework requires, quarterly internal and external scans under PCI DSS Requirements 11.3.1 and 11.3.2, with authenticated internal scanning now mandatory, and paired with periodic penetration testing, the assessment becomes the backbone of an ongoing vulnerability management program rather than a once-a-year noise dump. Armour Cybersecurity delivers validated, business-ranked findings and audit-ready compliance mapping as standard on every vulnerability assessment engagement.