Vulnerability Management — CIA Triad — Secure In Security

Secure In Security — Vulnerability Management — CIA Triad Policy / Contact / About

Vulnerability
Management

VM / CIA Triad

By N. Craig

Introduction to Vulnerability Management

Vulnerability management was one of the most relentless parts of my job. In the DoD, vulnerability notices arrive with compliance deadlines attached, the scans never stop, and there is always one more system that cannot be patched until next month. Over nearly three decades in federal IT and cybersecurity, much of it as an ISSM, I learned that the hard part is never finding vulnerabilities — any scanner will hand you thousands. The hard part is deciding which ones actually matter, getting them fixed, and proving they stayed fixed. This reference covers the VM lifecycle, how it protects the CIA Triad, the major scanning platforms, the weekly cycle that keeps a program moving, how to prioritize and assign remediation, and how to measure results — and the notes from the field share how I learned to cut through the noise.

Vulnerability Management (VM) is the continuous, proactive discipline of identifying, classifying, prioritizing, remediating, and verifying security weaknesses across an organization’s entire technology estate. It is not a one-time audit or annual exercise — it is an operational program that runs continuously because the threat landscape, the technology inventory, and the vulnerability database all change every day. A mature vulnerability management program is one of the highest-impact investments an organization can make in its security posture.

The CIA Triad — Confidentiality, Integrity, and Availability — provides the analytical framework for understanding why vulnerabilities matter. Every exploited vulnerability ultimately threatens one or more of these pillars: an unauthenticated remote code execution flaw threatens all three simultaneously; a path traversal vulnerability threatens Confidentiality; a denial-of-service bug threatens Availability; a privilege escalation flaw threatens Integrity. Vulnerability Management is the systematic practice of closing the windows and doors before attackers climb through them.

Key Concept

Vulnerability Management is not the same as patch management. Patching is one remediation technique within a broader VM program that also includes configuration hardening, compensating controls, risk acceptance, and proof-of-exploitation testing. Organizations that equate VM with patching systematically miss entire categories of exploitable weaknesses.

Vulnerability Management and the CIA Triad

CIA Pillar	VM Relevance
Confidentiality	Unpatched vulnerabilities in authentication systems, session management, access control enforcement, and data storage create pathways for unauthorized data access. SQL injection, SSRF, and insecure direct object reference flaws directly violate Confidentiality. VM identifies and closes these pathways before attackers exploit them.
Integrity	Vulnerabilities enabling code injection, privilege escalation, and supply chain compromise allow attackers to modify data, tamper with application logic, and persist undetected. VM detects and remediates the vulnerabilities that enable these Integrity violations before they are used in attacks.
Availability	Denial-of-service vulnerabilities, resource exhaustion flaws, and ransomware-enabling weaknesses directly threaten service Availability. Unpatched systems are the primary ransomware entry vector — VM is the most impactful preventive control against ransomware-driven Availability disruption.
Non-Repudiation	Vulnerabilities in audit logging systems, authentication controls, and digital signature implementations undermine the non-repudiation guarantees that make actions attributable to specific identities. VM protects the integrity of the audit and attribution controls themselves.
Compliance	PCI DSS, HIPAA, ISO 27001, NIST CSF, SOC 2, FedRAMP, and every major regulatory framework mandate documented vulnerability management programs with defined scan frequencies, remediation SLAs, and evidence of ongoing compliance. VM is both a security and a legal requirement.

The Vulnerability Management Lifecycle

A mature vulnerability management program follows a defined lifecycle that transforms raw vulnerability data into reduced organizational risk. Each phase has specific tools, processes, and measurable outcomes.

Asset DiscoveryMaintaining a complete, current inventory of all hardware, software, cloud resources, and third-party dependencies. You cannot assess what you do not know exists. Asset discovery is the foundational prerequisite for all subsequent VM phases.
Vulnerability AssessmentSystematic scanning and testing of the asset inventory to identify known vulnerabilities using authenticated and unauthenticated methods across network, application, cloud, and container attack surfaces.
PrioritizationRanking vulnerabilities by exploitability, asset criticality, business impact, and threat intelligence context. Not all critical CVSS-scored vulnerabilities are equally urgent — context-aware prioritization focuses remediation resources where they have the greatest risk reduction impact.
RemediationApplying patches, configuration changes, compensating controls, or risk acceptance decisions to reduce or eliminate the vulnerability. Remediation SLAs define maximum acceptable exposure windows by severity.
VerificationConfirming that remediation was effective through re-scanning, exploit testing, and configuration validation. Unverified remediation creates a false sense of closure that sophisticated attackers exploit.
Reporting & MetricsTracking Mean Time to Remediate (MTTR), vulnerability age, SLA compliance, and risk score trends to demonstrate program effectiveness and support executive decision-making.

From the Field — A Practitioner’s Take

The first scan report on a large network can be demoralizing: thousands of findings, hundreds of them labeled critical. The teams that made real progress stopped treating the list as a to-do list sorted by CVSS score and started asking a better question: which of these could actually be exploited on our systems, right now? A vulnerability on an internet-facing server that is already being exploited in the wild matters far more than a “critical” on an isolated lab box.

A few habits made the biggest difference. Run credentialed scans — unauthenticated scans miss most of what matters inside a system. Keep your asset inventory honest, because you cannot scan what you do not know you own. And when a fix truly cannot be applied yet, document a real compensating control and put the weakness on the POA&M with an owner and a date, instead of quietly suppressing the finding.

Finally, always rescan to verify. A ticket marked “closed” is not the same as a vulnerability that is gone. The verification scan is the only proof that counts.

Vulnerability Scanning Tools and Platforms

Vulnerability scanners are the primary data collection mechanism in the VM program. They systematically probe systems against databases of known vulnerability signatures, misconfigurations, default credentials, and missing patches to produce actionable findings. Scanner selection, configuration, authentication, and scan frequency all significantly affect the quality and completeness of vulnerability data produced.

Nessus / Tenable.io — Enterprise Vulnerability Management

Nessus (by Tenable) is the most widely deployed commercial vulnerability scanner in the world, with over 100,000 plugins covering CVEs, misconfigurations, compliance checks, and application vulnerabilities. Tenable.io extends Nessus into a cloud-based continuous vulnerability management platform with asset management, exposure scoring, and integration with the full security tool ecosystem.

Feature / Component	Description
CIA Pillar	All three pillars — Nessus/Tenable identifies vulnerabilities threatening Confidentiality (authentication bypasses, injection flaws), Integrity (privilege escalation, code injection), and Availability (DoS vulnerabilities, ransomware-enabling weaknesses).
Credentialed Scanning	Authenticated scans using local administrator credentials produce significantly more complete results than unauthenticated scans. Credentialed scanning identifies missing patches, insecure configurations, locally installed software vulnerabilities, and user-level settings that network-only scans miss entirely.
Plugin Architecture	Over 100,000 plugins covering Windows, Linux, macOS, network devices, cloud services, databases, web applications, SCADA/ICS, and compliance frameworks. Updated daily with new CVEs. Custom plugins support proprietary application vulnerability checks.
Asset Discovery	Nessus performs active network discovery, host enumeration, OS fingerprinting, service identification, and installed software inventory. This discovery data forms the foundation of the asset inventory required for all subsequent VM phases.
Tenable.sc / MSSP	Tenable Security Centre provides on-premises deployment for air-gapped and regulated environments. Supports distributed scanner deployment, role-based access control, and enterprise reporting. Tenable Lumin provides exposure scoring and benchmarking against industry peers.
Compliance Scanning	Pre-built audit files for CIS Benchmarks, DISA STIGs, PCI DSS, HIPAA, NIST 800-53, and SOX. Compliance scan results map configuration deviations directly to control failures — combining vulnerability assessment with compliance reporting in a single scan.

Qualys VMDR — Vulnerability Management, Detection & Response

Qualys VMDR (Vulnerability Management, Detection and Response) is a cloud-native vulnerability management platform that provides asset discovery, vulnerability assessment, threat prioritization, and patch orchestration in a single integrated platform. Its agent-based and agentless scanning approaches provide continuous coverage across on-premises, cloud, and remote endpoints.

Feature / Component	Description
CIA Pillar	All three pillars — Qualys VMDR provides continuous visibility across the full attack surface protecting all CIA Triad pillars through its integrated discovery, assessment, prioritization, and remediation capabilities.
Qualys TruRisk	Qualys’s proprietary risk scoring system combines CVSS scores with threat intelligence (active exploitation, EPSS, Qualys Threat Intelligence) and asset criticality to produce a contextualized risk score that prioritizes remediation beyond raw CVSS severity alone.
Cloud Agent	Lightweight agents deployed on endpoints provide continuous assessment without network scan traffic, enabling assessment of remote workers, laptops, and systems behind firewalls that traditional network scanners cannot reach.
Container Security	Qualys Container Security scans Docker images, Kubernetes pods, and container registries for vulnerabilities in both the container image and its running configuration — addressing the expanding container attack surface.
VMDR Patch Management	Integrated patch management module enables one-click patch deployment directly from vulnerability findings, significantly reducing the gap between detection and remediation. Supports Windows, Linux, and macOS patch orchestration.
Integration Ecosystem	Native integrations with ServiceNow, Jira, Splunk, Microsoft Sentinel, CrowdStrike, and major ITSM platforms enable vulnerability findings to flow directly into existing ticketing and security workflows without manual data export.

OpenVAS / Greenbone — Open-Source Vulnerability Management

OpenVAS (Open Vulnerability Assessment Scanner), maintained by the Greenbone community and available commercially as Greenbone Enterprise, is the leading open-source vulnerability scanner. It provides comprehensive vulnerability assessment capability without licensing costs, making it viable for organizations with budget constraints or air-gapped environments.

Feature / Component	Description
CIA Pillar	All three pillars — OpenVAS identifies the same categories of CIA-threatening vulnerabilities as commercial scanners through its community-maintained NVT (Network Vulnerability Tests) feed.
NVT Feed	Greenbone maintains 70,000+ Network Vulnerability Tests (NVTs) covering CVEs, misconfigurations, and application vulnerabilities. The Community Feed provides free access; the Enterprise Feed includes additional commercial checks and faster update cadence.
GVM Architecture	Greenbone Vulnerability Manager (GVM) provides the management layer for OpenVAS, including scan task scheduling, result management, role-based access, and reporting. Supports distributed scanner deployment for large network assessment.
Atomic Deployment	Greenbone Security Manager (GSM) hardware appliances provide pre-configured, air-gap-compatible deployment for regulated environments. Containerized deployment via Greenbone Community Containers simplifies open-source deployment.
Limitations	OpenVAS community edition has a smaller plugin library than commercial alternatives, slower update cadence for new CVEs, no built-in threat intelligence integration, and limited cloud/container coverage. Appropriate for infrastructure scanning; commercial platforms recommended for enterprise-scale continuous VM programs.

Key Concept

Vulnerability scanner results are only as complete as the scanner’s access to the target. Unauthenticated scans miss the majority of real-world vulnerabilities. Every production vulnerability scanner deployment must include credentialed scanning with privileged credentials stored in a secrets management system — ideally using service accounts with minimum required privileges to read patch status and software inventory without enabling lateral movement if the scanner is compromised.

The Weekly Vulnerability Management Cycle

The lifecycle described above is easy to draw as a circle on a slide. Making it turn every week — across hundreds or thousands of systems and several technical teams — is what separates a real program from a scanner that produces reports nobody reads. In many government and enterprise environments, that rhythm is set by a weekly cycle: scan, triage, assign, remediate, verify, report — and then do it all again.

A weekly cadence works because it is short enough that new vulnerabilities do not pile up for a month before anyone sees them, yet long enough for administrators to test and deploy fixes inside an approved maintenance window. It also creates accountability: every team knows that whatever it did not fix this week will appear again on next week’s report.

Anatomy of a Weekly Cycle

Stage	Typical Timing	Activity	Primary Owner	Output
1. Automated Scan	Start of cycle, often scheduled overnight or over the weekend	Credentialed network and host scans run against the full asset inventory; configuration and compliance checks run alongside vulnerability checks	VM team / scanning administrators	Raw results for every in-scope asset
2. Triage & Validation	Day 1	Remove false positives, de-duplicate findings, add asset criticality and threat context, and flag anything already being exploited in the wild	VM team, ISSM / ISSO	Validated, prioritized findings list
3. Assignment	Days 1–2	Route each finding to the team that owns the affected component, with a due date based on severity and exposure	VM team, team leads	Tickets or task lists for each team
4. Remediation	Days 2–5	Patch, reconfigure, upgrade, or apply compensating controls during approved maintenance windows, coordinated through change management	System, network, and database administrators; developers	Fixes deployed, change records closed
5. Verification	Next scheduled scan or a targeted rescan	Confirm each fix actually removed the finding; reopen anything that persists	VM team	Confirmed closures and reopened items
6. Reporting & POA&M Update	End of cycle	Report trends to leadership; record anything that cannot be fixed on time as a POA&M item or formal risk acceptance	VM team, ISSM, system owner	Weekly metrics, updated POA&M

Key Concept

The verification scan for one week is usually the discovery scan for the next. That overlap is the point: the cycle never “finishes.” New CVEs are published every day, new systems join the network, and configurations drift. A weekly program is designed to absorb that change continuously rather than in occasional, overwhelming bursts.

Continuous Monitoring Between Scans

A weekly scan is a snapshot. Between scans, a new service can be installed, a configuration can be changed, malware can land on a workstation, or an attacker can begin probing a server — and none of it will appear until the next scan runs. Mature programs therefore pair periodic scanning with host-based security monitoring: agents installed on servers and workstations that watch activity in real time and report to a central management console.

The open-source platform Wazuh is a good public example of the concept. Lightweight agents collect logs, monitor file integrity, check configurations against security policies, inventory installed software, and send alerts to a central manager. Large organizations, including the DoD, use centrally managed endpoint security and monitoring platforms built on the same idea and tailored to their own policies and networks.

Typical host-based monitoring capabilities include:

Real-Time AlertingSuspicious processes, intrusion-prevention events, and malware detections are reported to a central console as they happen, not a week later.
File Integrity MonitoringChanges to critical system files, binaries, and configuration files are detected and logged, revealing tampering or unauthorized changes.
Policy & Configuration ComplianceAgents continuously compare host settings against an approved security baseline and flag drift between scheduled scans.
Software & Patch InventoryAgents report installed software and patch levels, giving the VM team near-real-time visibility into newly exposed systems.
Device & Application ControlRules can block unauthorized USB devices or unapproved applications, closing gaps a scanner can only report.
Centralized ManagementPolicies are pushed from a central server, and the console shows which hosts are reporting, which are out of compliance, and which agents have gone silent — itself an important warning sign.

Periodic Scanning vs. Continuous Host-Based Monitoring

Aspect	Weekly Vulnerability Scanning	Continuous Host-Based Monitoring
Question it answers	What known weaknesses exist on this system?	What is happening on this system right now?
Frequency	Scheduled snapshot (for example, weekly)	Continuous, near real time
Data source	Network probes and credentialed checks from a central scanner	An agent on each host reporting to a central manager
Strengths	Broad, consistent coverage of CVEs and misconfigurations across the whole inventory	Immediate detection of suspicious activity, tampering, and configuration drift
Blind spots	Misses anything that changes between scans; limited by scanner access and credentials	Covers only hosts with a healthy, reporting agent
Feeds into	Remediation queues, the POA&M, compliance reporting	SOC triage, incident response, compliance dashboards

From the Field — The Weekly Rhythm

In my experience, vulnerability management in the DoD ran on a weekly heartbeat. The automated vulnerability scan ran every week, and in between, a DoD-tailored host-based security and monitoring system — similar in nature to Wazuh, but built for the DoD’s own policies and networks — watched our hosts in real time and raised alerts as things happened. The scan told us what was weak; the host-based system told us what was happening.

Once the scan results came in, the work fanned out. System administrators took the operating system patches and configuration findings, network administrators handled the routers, switches, and firewalls, database administrators owned the database findings, and programmers fixed the issues that lived in our own code. The job on the security side was to keep that flow moving: make sure every finding had an owner, that the owner understood the deadline, and that nothing quietly fell off the list.

Then the next week’s scan ran, and the cycle started again. That repetition is what made it work. Nobody could bury a finding for long, because it would be back on the report seven days later — and leadership could see, week over week, whether the numbers were actually moving.

Risk-Based Prioritization

No organization can fix every finding at once. A large network can produce thousands of results in a single scan, and administrators have limited time and limited maintenance windows. Prioritization decides which vulnerabilities get that time first. Done well, it focuses effort on the weaknesses most likely to be exploited and most damaging if they are. Done poorly — usually by sorting on severity score alone — it buries teams in “criticals” that pose little real risk while genuinely dangerous issues wait.

CVSS Severity Ratings

The Common Vulnerability Scoring System (CVSS), maintained by FIRST, rates the technical severity of a vulnerability on a scale of 0.0 to 10.0. CVSS v4.0, released in November 2023, is the current version, although many scanners and vulnerability databases still display v3.1 scores. The qualitative ratings below are the starting point for most remediation policies.

Severity	CVSS Score	Example Remediation Target*	Typical Handling
Critical	9.0 – 10.0	7–15 days	Highest priority; emergency change if the system is exposed or the vulnerability is known to be exploited
High	7.0 – 8.9	30 days	Next available maintenance window
Medium	4.0 – 6.9	90 days	Normal patch cycle
Low	0.1 – 3.9	180 days or next major update	Bundled with routine maintenance
None	0.0	—	Informational; no action required

*Example targets only. Real timelines are set by organizational policy, contracts, and regulation, and are often much shorter for internet-facing systems and for vulnerabilities already being exploited.

Beyond CVSS — Adding Threat and Business Context

CVSS describes how severe a vulnerability could be in general. It does not know whether attackers are actually using it, whether the affected system is exposed to the internet, or whether that system runs payroll or a test lab. Modern programs layer additional context on top of the base score:

Factor	What It Tells You	Common Source
Known exploitation	Whether attackers are already using the vulnerability in real attacks	CISA Known Exploited Vulnerabilities (KEV) catalog
Exploit probability	The estimated likelihood that a vulnerability will be exploited in the next 30 days	FIRST Exploit Prediction Scoring System (EPSS)
Decision framework	A structured Track / Track* / Attend / Act decision based on exploitation status, exposure, and impact	CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
Asset criticality	How important the affected system and its data are to the mission or business	Asset inventory, system categorization, business impact analysis
Exposure	Whether the system is internet-facing, segmented, or isolated	Network architecture, firewall rules, attack-surface tools
Compensating controls	Whether other protections already reduce the risk	Security architecture, host-based protections, configuration baselines

Key Concept

Under CISA Binding Operational Directive 22-01, federal civilian agencies must remediate vulnerabilities listed in the Known Exploited Vulnerabilities (KEV) catalog by the due dates CISA assigns. Organizations that are not bound by the directive increasingly treat KEV as a “fix first” list anyway, because every entry is a vulnerability confirmed to be exploited in the wild.

Who Fixes What — Remediation Ownership

A scan report is not a remediation plan. Findings have to reach the people who can actually fix them, and in most organizations that is several different teams. A finding with no clear owner is a finding that never closes.

Team	Typical Findings	Common Remediation Actions
System Administrators	Missing OS patches, outdated third-party software, insecure services, weak local configurations on servers and workstations	Apply vendor patches; harden settings against baselines such as DISA STIGs or CIS Benchmarks; remove unneeded software and services
Network Administrators	Outdated firmware on routers, switches, and firewalls; insecure management protocols; default SNMP community strings; weak TLS or SSH settings	Upgrade firmware; disable insecure protocols; tighten access control lists and management-plane access
Database Administrators	Unpatched database engines, default or shared accounts, excessive privileges, unencrypted connections	Apply database patches; remove default accounts; enforce least privilege; enable encryption and auditing
Developers / Programmers	Vulnerable code (injection, cross-site scripting), outdated libraries and dependencies, insecure API settings	Fix the code; update dependencies; add static analysis and software composition analysis to the build pipeline
Application & System Owners	Vendor product flaws, end-of-life software, fixes that need downtime or funding	Coordinate vendor fixes; schedule upgrades or replacement; approve POA&M entries or risk acceptance
Security / VM Team	Scan coverage gaps, failed credentialed scans, false positives	Maintain scanner credentials and coverage; validate findings; track closures and overdue items

Remediation Options

Patching is the most common fix, but it is only one of several legitimate responses to a vulnerability:

Patch or UpgradeApply the vendor’s fix or move to a supported version. This is the preferred option whenever a fix exists and can be tested.
Configuration ChangeDisable a vulnerable feature, protocol, or service, or harden a setting. Many findings are misconfigurations rather than missing patches.
Compensating ControlReduce the risk another way — network segmentation, additional access restrictions, enhanced monitoring — while a permanent fix is pending.
Risk AcceptanceA formal, documented decision by an accountable official to accept the remaining risk for a defined period. It is not the same as ignoring the finding.
Decommission or IsolateRetire the system, or remove it from the network, when it can no longer be secured — often the right answer for end-of-life software.

Exceptions, Risk Acceptance & the POA&M

Some findings simply cannot be fixed by their due date. The vendor has not released a patch, the fix breaks a mission-critical application, or the system is already scheduled for replacement. A mature program does not ignore these findings or suppress them in the scanner. It records them formally. On federal systems under the Risk Management Framework, that record is the Plan of Action and Milestones (POA&M), required by NIST SP 800-53 control CA-5.

POA&M Element	What a Good Entry Includes
Weakness	The specific vulnerability or finding, the affected systems, and how it was identified
Owner	A named person or team responsible for closing it — not just “IT”
Interim Mitigation	The compensating controls in place now to reduce the risk
Milestones	Concrete, dated steps toward the fix (vendor patch expected, test window, deployment)
Scheduled Completion	A realistic completion date, reviewed and updated as the work progresses
Resources	Any funding, staff time, or vendor support the fix requires

Common Pitfall

Suppressing findings in the scanner to make the dashboard look green does not reduce risk — the weakness is still there, now invisible. A POA&M only has value if it is worked: reviewed regularly, updated as milestones slip or close, and treated as a living plan rather than a checklist for the next inspection.

Metrics, Reporting & Governance

A vulnerability management program that cannot show its results will struggle to keep funding, staff, and leadership attention. Good metrics answer three questions: are we seeing everything, are we fixing what matters fast enough, and is our overall exposure going down?

Key Performance Indicators

Metric	What It Measures	Why It Matters
Scan Coverage	Percentage of known assets scanned in the current cycle	Unscanned systems are unknown risk; coverage gaps often hide the worst problems
Credentialed Scan Success Rate	Percentage of scans that authenticated successfully	Failed authentication silently produces incomplete results
Mean Time to Remediate (MTTR)	Average time from detection to verified fix, tracked by severity	Shows whether the most dangerous findings are being fixed fastest
Due-Date Compliance	Percentage of findings closed within their target timeline	Measures whether policy timelines are realistic and being met
Vulnerability Age	Number of open findings past 30, 60, 90, and 180 days	Aging findings point to blocked fixes, missing owners, or unrecorded exceptions
Recurrence Rate	Findings that reappear after being closed	Signals configuration drift, rebuilt systems from old images, or unverified fixes
Known-Exploited Exposure	Open findings that appear in the CISA KEV catalog	The most direct measure of real-world risk; the target should be at or near zero
Agent Health	Percentage of hosts with a healthy, reporting host-based monitoring agent	Hosts with silent agents are blind spots between scans

Reporting to Different Audiences

Audience	What They Need	Typical Format
Technical Teams	Specific findings, affected hosts, fix guidance, and due dates	Ticket queues or weekly task lists for each team
Security Leadership (ISSM / CISO)	Trends, overdue items, known-exploited exposure, coverage gaps	Weekly dashboard
Executives & Authorizing Officials	Overall risk posture, direction of the trend, major risk acceptances	Monthly or quarterly summary
Auditors & Assessors	Evidence: scan history, remediation records, POA&M status	Exported reports and records

Common Program Pitfalls

Incomplete Asset InventorySystems that are not in the inventory are not scanned, not monitored, and not patched. Shadow IT and forgotten servers are frequent breach entry points.
Unauthenticated Scanning OnlyScanning from the outside alone misses most missing patches and local misconfigurations.
Severity-Only PrioritizationSorting purely by CVSS score treats a lab system the same as an internet-facing server and ignores whether a vulnerability is actually being exploited.
No Clear OwnershipFindings sent to a shared mailbox or a generic “IT” queue tend to stay open indefinitely.
Closing Without VerificationA ticket marked closed is not proof of a fix. Only a rescan confirms the vulnerability is gone.
Hiding Instead of TrackingSuppressing or excluding findings to improve the numbers removes them from view without removing the risk.
Reports Nobody Acts OnA scan that produces a report but no assignments, deadlines, or follow-up is activity, not vulnerability management.

Vulnerability Management in Frameworks & Compliance

Almost every major security framework and regulation expects a working vulnerability management process. The wording differs, but the expectations are consistent: know your assets, scan them regularly, fix what you find within defined timeframes, and keep records that prove it.

Framework / Standard	Relevant Requirement	What It Expects
NIST SP 800-53 Rev 5	RA-5 Vulnerability Monitoring and Scanning; SI-2 Flaw Remediation; CA-7 Continuous Monitoring; CA-5 Plan of Action and Milestones	Scan on a defined schedule and when new vulnerabilities are reported, remediate within defined timeframes, monitor continuously, and track open weaknesses
NIST CSF 2.0	ID.RA-01	Vulnerabilities in assets are identified, validated, and recorded
NIST SP 800-40 Rev 4	Guide to Enterprise Patch Management Planning (2022)	Treat patching as routine preventive maintenance, with plans for both regular and emergency patching
CIS Controls v8.1	Control 7 — Continuous Vulnerability Management	A documented process, automated scanning, and risk-based remediation on a recurring schedule
PCI DSS v4.0.1	Requirement 11.3	Internal and external vulnerability scans at least once every three months, with external scans performed by an Approved Scanning Vendor
ISO/IEC 27001:2022	Annex A control 8.8 — Management of technical vulnerabilities	Obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures
HIPAA Security Rule	45 CFR §164.308(a)(1) — Risk analysis and risk management	Identify vulnerabilities to ePHI as part of the required risk analysis and reduce them to a reasonable and appropriate level

Vulnerability Management Program Checklist

Area	Checklist Item	Status
Assets	Complete, current inventory of hardware, software, cloud resources, and owners
Assets	Every asset assigned a criticality rating
Scanning	Automated credentialed scans on a fixed schedule (for example, weekly)
Scanning	Scan coverage and authentication success tracked every cycle
Monitoring	Host-based monitoring agents deployed and reporting on servers and workstations
Prioritization	Severity, known exploitation (KEV), exposure, and asset criticality all used to rank findings
Ownership	Every finding routed to a named team with a due date
Remediation	Fixes deployed through change management in approved maintenance windows
Verification	Every closure confirmed by rescan; reopened findings tracked
Exceptions	Unfixable findings recorded as POA&M items or formal risk acceptances with owners and dates
Metrics	MTTR, due-date compliance, vulnerability age, and KEV exposure reported to leadership
Governance	VM policy, timelines, and roles documented and reviewed at least annually

Recommended Resources

National Vulnerability Database (NVD) — CVE details and severity scores (nvd.nist.gov)
CISA Known Exploited Vulnerabilities Catalog — vulnerabilities confirmed to be exploited in the wild (cisa.gov)
FIRST CVSS and EPSS — the scoring specification and exploit-prediction scores (first.org)
CISA SSVC — Stakeholder-Specific Vulnerability Categorization decision guide (cisa.gov)
NIST SP 800-40 Rev 4 — Guide to Enterprise Patch Management Planning (free at csrc.nist.gov)
CIS Controls v8.1 — Control 7, Continuous Vulnerability Management (cisecurity.org)
DISA STIGs — security configuration baselines for hardening (public.cyber.mil)
Wazuh Documentation — open-source host-based monitoring, a hands-on way to learn the concepts (documentation.wazuh.com)

About the Author — N. Craig

N. Craig is the founder of Secure In Security and a civilian with nearly three decades in IT and cybersecurity at a large federal organization, including extended service as an Information Systems Security Manager (ISSM). N. Craig holds the CISSP certification and a Master of Science in Information Technology, and writes SIS to turn hard-won practitioner experience into reference material that beginners and working professionals can actually use.