A vulnerability assessment is a structured process for identifying, validating, prioritizing, and documenting security weaknesses in a defined set of assets. For IT and security teams, its purpose is to turn technical findings into remediation or mitigation work with an owner, a deadline, and a verifiable outcome.
Running a vulnerability scanner is only one part of the process. Results still need to be checked for accuracy and applicability, evaluated in business context, assigned to responsible teams, and retested after treatment. NIST SP 800-115 describes security assessment as a combination of planning, technical testing, analysis, and mitigation planning—not a single tool run.
Key Takeaways
- Vulnerability assessment is the process of identifying, validating, prioritizing, and documenting security weaknesses across a defined set of assets.
- Vulnerability scanning is only one part of an assessment. Findings must be validated and evaluated using factors such as exploit activity, exposure, asset criticality, and existing controls.
- Effective remediation requires ownership and verification. Each material finding should have a treatment plan, responsible owner, target date, and retest status.
- Vulnerability assessments do not provide complete coverage. Organizations may also need configuration reviews, application testing, code analysis, or penetration testing depending on the assets and risks involved.
What is a vulnerability assessment, and what does it find?
A vulnerability assessment examines selected systems, networks, applications, services, and configurations for weaknesses that could affect confidentiality, integrity, or availability. Depending on its scope and methods, it may identify:
- Known software vulnerabilities and missing security updates
- Unsupported or outdated software
- Insecure system and application configurations
- Unnecessary exposed ports, protocols, and services
- Weak authentication or access-control settings
- Publicly accessible administrative interfaces
- Vulnerable web application components
- Differences between approved configurations and deployed settings
The assessment should establish where each weakness exists, whether it applies to the asset in question, who owns the affected system, and what action is required.
Coverage is never unlimited. Results depend on whether the asset was inventoried, whether the assessment had sufficient access, which checks were enabled, and whether the selected tool understood the relevant technology. Custom software and business-logic weaknesses may require code review, manual application testing, or other methods. As NIST SP 800-115 notes, no single assessment technique provides a complete security picture.
Vulnerability scan vs. assessment vs. penetration test: Which do you need?
Vulnerability scanning, vulnerability assessment, and penetration testing serve different purposes. An organization may need more than one.
| Activity | Primary purpose | Typical output | Level of validation | When to use it |
|---|---|---|---|---|
| Vulnerability scan | Discover potential vulnerabilities and configuration issues at scale | Tool-generated list of suspected findings | Usually limited; results can include false positives or non-applicable issues | Routine discovery, asset monitoring, patch checks, and broad coverage |
| Vulnerability assessment | Analyze, validate, prioritize, and document weaknesses across a defined scope | Actionable findings with evidence, context, ownership, and treatment recommendations | Varies by method, but includes review beyond raw scanner output | Building and operating a repeatable vulnerability-management process |
| Penetration test | Attempt to exploit weaknesses and demonstrate attack paths or impact under agreed rules | Validated attack paths, evidence of access or impact, and remediation guidance | High for the tested objectives and paths | Testing whether controls can resist realistic attacks or whether weaknesses can be combined |
A scan is useful for finding possible issues across many assets. An assessment converts those results and other evidence into risk decisions. A penetration test goes further by attempting authorized exploitation against specific objectives, but it is usually time-bound and does not guarantee complete vulnerability coverage.
Types of Vulnerability Assessments
Organizations use different types of vulnerability assessments depending on the assets, systems, and risks in scope. Common types include:
- Network vulnerability assessment: Reviews internal and external networks for exposed ports, vulnerable services, insecure protocols, outdated software, and configuration weaknesses.
- Host and endpoint vulnerability assessment: Examines servers, laptops, desktops, and other endpoints for missing security updates, vulnerable or unsupported software, and insecure configurations.
- Application and API vulnerability assessment: Examines web applications, business applications, and APIs for vulnerable components, authentication and access-control weaknesses, input-validation issues, and insecure configurations.
- Cloud vulnerability assessment: Reviews cloud workloads, identities, storage, network configurations, and other cloud resources for vulnerabilities, excessive exposure, permissions issues, and configuration weaknesses.
- Container and Kubernetes vulnerability assessment: Examines container images, workloads, and cluster configurations for vulnerable packages, excessive privileges, exposed secrets, and insecure deployment settings.
- Database vulnerability assessment: Evaluates database systems for vulnerable software, insecure configurations, excessive permissions, weak access controls, and unnecessary exposure.
- Wireless vulnerability assessment: Reviews wireless networks and access points for insecure configurations, weak encryption, unauthorized devices, and segmentation weaknesses.
- External attack surface assessment: Identifies and evaluates internet-visible assets such as domains, subdomains, IP addresses, certificates, remote-access services, and other externally exposed systems.
Different assessment types may be used together because no single method provides complete coverage across an organization’s endpoints, networks, applications, cloud environments, and other infrastructure.
What should you include in a vulnerability assessment?
A useful assessment begins with a precise answer to three questions: what will be tested, how will it be tested, and who is authorized to make decisions if testing causes problems.
Inventory assets and choose internal and external targets
Start with an asset inventory that identifies systems to be assessed and their accountable owners. Assets may include:
- Public IP addresses, domains, gateways, and remote-access services
- Internal servers, endpoints, databases, and network devices
- Cloud workloads, storage services, and management interfaces
- Web applications and application programming interfaces
- Security appliances and identity infrastructure
- Managed and unmanaged devices where visibility is available
Classify each asset by exposure, business function, data sensitivity, and operational criticality. This context will later influence priority. A medium-severity weakness on an internet-facing identity system may require faster action than a nominally critical issue on an isolated test system.
Record exclusions explicitly. If a legacy production server, third-party service, or sensitive operational system cannot be tested, the final report should show that coverage gap rather than imply the environment was fully assessed. CISA guidance for internet-accessible systems likewise emphasizes maintaining asset visibility and coordinating remediation with system owners.
Confirm authorization, credentials, testing limits, and result handling
Obtain written authorization before scanning or testing systems. The rules of engagement should identify:
- Approved targets and excluded assets
- Testing dates and maintenance windows
- Permitted techniques and scan intensity
- Whether authenticated or credentialed checks are allowed
- Accounts provided for testing and how their credentials will be protected
- Prohibited actions, such as disruptive validation or denial-of-service testing
- Monitoring and escalation contacts
- Conditions that require testing to stop
- How reports, credentials, logs, and evidence will be stored and shared
Authenticated scans can inspect installed packages, patch levels, and local configurations that are not visible through unauthenticated network checks. The accounts should have only the access required for the assessment, be monitored during use, and be removed or disabled when no longer needed.
Production testing requires additional care. Pilot scan settings against representative assets, apply appropriate rate limits, monitor system health, and ensure system owners know when testing will occur. These controls reduce operational risk; they do not guarantee that testing will have no effect.
What is the vulnerability assessment process?
The assessment method should match the asset type and the weakness being investigated. Broad infrastructure scanning alone will not adequately assess a web application, custom software, or a cloud configuration.
Run appropriate scans and review the results
A practical assessment may combine:
- External infrastructure scanning to inspect internet-accessible hosts, services, and exposed interfaces
- Internal network scanning to identify weaknesses reachable from trusted or compromised network segments
- Credentialed endpoint or server scanning to inspect installed software, patch levels, and local configurations
- Web application scanning to test publicly available application behavior and components
- Configuration review to compare deployed settings with approved security requirements
- Manual checks where automated tools cannot establish applicability or business impact
Keep scanner content and vulnerability checks current. For nonfederal systems subject to NIST SP 800-171 Rev. 3 because they process, store, or transmit controlled unclassified information, the standard calls for scanning at organization-defined intervals, when relevant new vulnerabilities are identified, and with updated vulnerability information.
When a scan completes, review its health before reviewing individual findings. Check which targets responded, whether authentication succeeded, whether expected ports and services were inspected, and whether any jobs stopped early. A clean result from an unreachable host or failed credentialed scan is not evidence that the host is secure.
Validate findings and document affected assets
Validation prevents duplicate, stale, or inapplicable findings from overwhelming remediation teams. For each material finding, confirm:
- Asset identity: Verify the hostname, address, device record, environment, and owner.
- Affected condition: Confirm the installed version, configuration, package, or exposed service that triggered the result.
- Applicability: Determine whether the vulnerability affects the deployed version and configuration.
- Reachability and exposure: Establish whether a potential attacker can reach the vulnerable component and what access is required.
- Existing controls: Record segmentation, authentication, filtering, monitoring, or other controls that change practical risk.
- Evidence quality: Retain enough evidence for the system owner to reproduce the condition without exposing unnecessary secrets or sensitive data.
Validation does not always require exploitation. Version evidence, authenticated package data, configuration output, vendor advisories, and controlled manual checks may be sufficient. Active exploitation should occur only when necessary, authorized, and covered by the rules of engagement.
How do you prioritize and remediate findings?
Prioritization should answer which finding needs attention first in this environment, not which scanner label looks most alarming.
Weigh severity against exposure and business impact
Common Vulnerability Scoring System (CVSS) scores and scanner severity ratings are useful starting points, but they should not determine the remediation queue by themselves. Evaluate:
- Evidence that the vulnerability is being actively exploited
- Internet exposure and network reachability
- Asset criticality and business function
- Data sensitivity
- Required access and practical exploitability
- Availability of exploit code or vendor guidance
- Existing compensating controls
- Potential operational consequences of exploitation
- Operational risk created by the proposed fix
The CISA Known Exploited Vulnerabilities Catalog is an authoritative source for vulnerabilities known to be exploited in the wild. Catalog inclusion should increase urgency, but it remains one input alongside exposure, asset importance, and existing protections.
A simple decision sequence is often more useful than sorting by scanner score:
- Address actively exploited vulnerabilities on reachable systems.
- Prioritize high-impact weaknesses on internet-facing or critical assets.
- Resolve broadly exposed weaknesses that could support lateral movement.
- Schedule lower-risk issues according to defined response times.
- Document why any finding is deferred, accepted, or treated through compensating controls.
Assign a fix owner and track the outcome
Every accepted finding should have:
- An accountable remediation owner
- A target completion date
- A selected treatment
- Dependencies or planned maintenance windows
- Interim controls when the permanent fix cannot be applied promptly
- Evidence of implementation
- A retest status
Treatment may involve installing a patch, changing a configuration, disabling a service, updating custom code, restricting network access, replacing unsupported technology, or applying another mitigation. NIST SP 800-40 Rev. 4 describes patch management as identifying, prioritizing, acquiring, installing, and verifying updates, but not every vulnerability can be resolved through patching.
Risk acceptance is not the same as remediation. If the organization accepts a risk, record the decision-maker, rationale, scope, expiration or review date, and any monitoring requirements. Exceptions that remain open indefinitely can hide unresolved exposure.
What should a vulnerability assessment report include?
A finished assessment report should enable technical owners to act and decision-makers to understand residual risk. It should contain:
- Assessment objective, scope, dates, and methods
- Assets tested and assets excluded
- Authorization and relevant testing limitations
- Coverage issues, such as unreachable targets or failed authentication
- An executive view of material risks and remediation status
- Validated findings with affected assets and owners
- Evidence and risk rationale for each finding
- Recommended remediation or mitigation
- Target dates, status, and approved exceptions
- Retest results and remaining risk
A raw scanner export is useful supporting data, but it is not a finished assessment report. It generally does not establish whether findings were validated, how they affect the organization, who owns the response, or whether remediation succeeded.
Example finding: Evidence, risk, recommended fix, and retest result
The following fictional example shows the minimum information needed to make a finding actionable:
| Field | Example |
|---|---|
| Finding ID | VA-2025-014 |
| Finding | Outdated file transfer service with an applicable vendor security update |
| Affected asset and owner | files.example.internal; Infrastructure Operations |
| Evidence | Credentialed package inventory confirms the affected version. The service is reachable from two internal user network segments. |
| Risk rationale | The affected service processes business files and is reachable from a large internal network population. No evidence of internet exposure was found. |
| Recommended treatment | Install the vendor update. Until the maintenance window, restrict access to approved administrative and application hosts. |
| Target date and owner | 15 June 2025; Infrastructure Operations lead |
| Status | Update deployed; access restriction retained |
| Retest result | Credentialed rescan confirms the updated version. A network check confirms that access is limited to the approved hosts. Closed on 16 June 2025. |
The evidence, recommendation, and retest method should match the specific condition. Merely marking a ticket as complete does not prove that the vulnerability was removed or that a compensating control works.
When should you retest and reassess?
Retest a finding after the owner reports that remediation or a compensating control has been implemented. The retest should examine the original condition and, where relevant, confirm that the change did not leave another exposed path. If verification fails, reopen the finding with updated evidence.
Reassess assets when:
- A significant infrastructure, application, identity, or network change occurs
- A new relevant vulnerability becomes known
- A system becomes internet-facing or changes business function
- New assets are deployed or discovered
- An incident reveals an untested weakness or coverage gap
- A recurring assessment interval becomes due
There is no universal cadence suitable for every asset. Set assessment intervals according to exposure, criticality, change frequency, threat information, and applicable contractual or regulatory obligations. High-change or internet-accessible systems generally warrant closer monitoring than stable, isolated assets. A single annual scan should not be treated as continuous vulnerability management.
How does Scalefusion Veltar support vulnerability assessment?
Scalefusion Veltar helps IT and security teams identify and assess vulnerabilities affecting managed Windows and macOS endpoints. It provides visibility into OS and application vulnerabilities, affected endpoints, and risk signals such as CVSS scores, EPSS data, and CISA Known Exploited Vulnerabilities (KEV) information to help teams determine which findings require attention.
Teams can investigate vulnerability findings and prioritize them using vulnerability and endpoint context. When remediation requires an applicable OS or third-party application update, findings can connect to Scalefusion UEM patch-management workflows for deployment and status tracking.
This connects vulnerability assessment with endpoint remediation workflows, helping teams move from identifying and prioritizing vulnerabilities to tracking their remediation.
Explore Veltar Vulnerability Management Software.
FAQs
1. Can a vulnerability assessment find every security flaw?
No. Results are limited by scope, asset visibility, access, tool coverage, configuration, and the methods used. Automated scanning may miss custom-code defects, business-logic weaknesses, chained attack paths, newly disclosed vulnerabilities, and assets absent from the inventory. Configuration review, application testing, code analysis, penetration testing, and other methods may be needed to address those gaps.
2. Can you assess production systems without disrupting them?
Production systems can often be assessed with controlled risk, but no assessment method is guaranteed to have zero impact. Obtain authorization, coordinate with system owners, test conservative settings, use suitable rate limits, schedule sensitive activity carefully, monitor system health, and define escalation contacts and stop conditions. Particularly fragile or safety-critical systems may require alternative methods or testing in a representative environment.
3. Is a scanner report enough to meet compliance requirements?
Usually not by itself. Requirements vary by framework, contract, and jurisdiction, but a raw scanner report does not prove that the scope was complete, findings were reviewed, risks were prioritized, remediation or exceptions were approved, or fixes were verified. Keep evidence of the assessment scope, validation decisions, assigned actions, completed treatment, accepted risk, and retest results.
4. How often should vulnerability assessments be done?
There is no universal frequency for vulnerability assessments. Organizations should set assessment intervals based on asset criticality, internet exposure, change frequency, threat activity, and applicable compliance requirements. Reassessments should also occur after significant system changes, the discovery of relevant new vulnerabilities, or security incidents.
5. What tools are used for vulnerability assessments?
Vulnerability assessments may use network and endpoint scanners, web application scanners, configuration assessment tools, cloud security tools, and manual testing techniques. The tools selected depend on the assets being assessed, the required coverage, and whether teams need vulnerability discovery, configuration checks, validation, or deeper application testing.
