Vulnerability management is the ongoing process of finding security weaknesses in your systems and software, ranking them by risk, fixing or mitigating them within set timelines, and verifying that each fix worked.
A vulnerability is a weakness that an attacker or other threat could exploit. NIST defines it as a "weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source" (NIST glossary). Vulnerability management is the program that keeps those weaknesses found, owned, and closed. It is not a single tool or a single test. Scanners, dependency alerts, cloud configuration checks, vendor advisories, and penetration test findings all feed the same cycle.
In simple terms, vulnerability management answers:
- What weaknesses exist in the systems we run right now?
- Which ones matter most, and who fixes them by when?
- Did the fix work, and what did we decide about anything we left open?
This page defines the term. For the SOC 2 evidence playbook with scan cadence, severity SLAs, and sampling advice, read Vulnerability Management Evidence for SOC 2. For the related point-in-time assessment, see What Is a Penetration Test?.
Why Vulnerability Management Matters
New vulnerabilities appear constantly in operating systems, libraries, container images, and cloud services. Many attacks use weaknesses that already have a known fix.
Vulnerability management matters because:
- Known, unpatched weaknesses are among the easiest paths into a system.
- CISA maintains the Known Exploited Vulnerabilities (KEV) catalog, which it describes as the authoritative source of vulnerabilities that have been exploited in the wild, and recommends using it as an input to vulnerability prioritization.
- Customers ask about scan cadence and patch timelines in security questionnaires.
- An open critical finding can turn a small incident into a large one.
- Auditors look for proof that the cycle ran across the period, not one clean report before fieldwork.
The Vulnerability Management Lifecycle
Most programs run the same loop.
1. Know your assets
Keep an inventory of hosts, containers, cloud accounts, repositories, dependencies, and endpoints. You cannot scan or patch what you do not know exists.
2. Identify vulnerabilities
Use automated scanning for infrastructure, container images, and code dependencies. Add cloud configuration checks, vendor security advisories, bug reports, and penetration test findings.
3. Prioritize
Severity scores give a starting point. The Common Vulnerability Scoring System (CVSS), maintained by FIRST, captures the main characteristics of a vulnerability and produces a numerical severity score. Context then adjusts the order: internet exposure, evidence of active exploitation, data sensitivity, and compensating controls.
4. Remediate or mitigate
Patch, upgrade, change a configuration, or add a compensating control. Route fixes through normal change management so each one leaves a record. NIST SP 800-40 Rev. 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades.
5. Verify
Rescan or retest to confirm the weakness is gone. A closed ticket without a rescan is a claim, not proof.
6. Govern what stays open
When a fix must wait, record a time-bound exception with an owner, rationale, compensating controls, and expiry date.
7. Report and improve
Track open findings by age and severity, SLA adherence, and repeat causes. Use the trends to fix the process, not only the individual findings.
Vulnerability Management vs Penetration Testing
These terms are related but not interchangeable.
| Concept | What it is | Typical rhythm | Typical output |
|---|---|---|---|
| Vulnerability management | The ongoing program to identify, prioritize, fix, verify, and govern weaknesses | Continuous | Finding queue, SLA metrics, tickets, exceptions |
| Vulnerability scanning | Automated discovery of known weaknesses | Scheduled and frequent, often also after major changes | Scan results, CVE lists, severity scores |
| Penetration test | An authorized, scoped attempt to exploit weaknesses and prove impact | Planned engagements, often annual or after major changes | Report with findings, exploit narrative, and severity |
| Patch management | Identifying, acquiring, installing, and verifying patches and updates | Ongoing, on a schedule | Patch records and deployment logs |
The key difference is scope and rhythm. Vulnerability management is the always-on program. A penetration test is one deep, human-led input to it. Scans are wide and frequent; pen tests are narrow and deep, and they can find chained or business logic issues that scanners miss.
A pen test does not replace vulnerability management. An annual test with no scanning in between leaves most of the year uncovered. The reverse also holds: scanning alone can miss what a skilled tester finds. Many programs send pen test findings into the same remediation queue, with the same severity timelines, as scan findings.
Severity Timelines Are Your Policy
Most programs set remediation timelines (often called SLAs) by severity, with shorter windows for critical and actively exploited issues. SOC 2 does not set these numbers. Your policy does, and your auditor tests whether you met what you wrote. Pick timelines your team can actually hit, write them down, and track misses as exceptions rather than hiding them.
Evidence Auditors Often Request
| Evidence | Why it matters |
|---|---|
| Written vulnerability management policy or procedure | Shows scope, cadence, severity timelines, and owners were defined |
| Asset or scan scope list | Shows which systems the program covers |
| Scan schedules and dated results across the period | Proves scanning ran as described |
| Triage records and remediation tickets | Shows owners acted on findings |
| Rescan or retest results | Proves fixes worked |
| Approved exceptions with expiry | Shows open risk was a governed decision |
| Aging or SLA reports | Shows timelines were tracked and met, or misses were handled |
For broader evidence habits, see What Is SOC 2 Evidence? and audit evidence.
Framework Notes
SOC 2
The AICPA 2017 Trust Services Criteria with revised points of focus (2022) address vulnerabilities mainly in CC7.1, which covers detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. A point of focus under CC7.1 describes conducting vulnerability scans on a periodic basis and after significant changes, and acting to remediate deficiencies on a timely basis. Points of focus are illustrative guidance, not a mandatory checklist.
The criteria do not set a scan frequency or remediation timeline. For Type 2, auditors may sample scan results, closed findings with retests, and exceptions across the audit period. Remediation changes also connect to change management criteria. See SOC 2 Type 1 vs Type 2 and What Are the Trust Services Criteria?.
NIST
NIST SP 800-53 Rev. 5 includes RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation). The NIST Cybersecurity Framework (CSF) 2.0 includes the outcome ID.RA-01: vulnerabilities in assets are identified, validated, and recorded. These are reference frameworks, not SOC 2 requirements.
ISO 27001
ISO 27001 programs address the management of technical vulnerabilities in Annex A of ISO/IEC 27001:2022. Teams that run both programs often reuse one vulnerability process through control mapping.
Common Failures
- Scanning only part of the environment, such as servers but not containers or dependencies
- An asset inventory that is out of date, so new systems never get scanned
- Severity timelines in policy that nobody tracks
- Tickets closed without a rescan or retest
- Exceptions with no owner or expiry
- Treating the annual pen test as the whole program
- One clean scan report pulled right before fieldwork, with gaps elsewhere in the period
- Repeat findings with no look at root cause
Many of these become remediation items or audit exceptions when found late.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for vulnerability artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as Tenable, Snyk, Dependabot, GitHub, and Jira.
The focus is organizing dated proof so scan results, remediation tickets, fix pull requests, and exceptions can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the vulnerability program your organization defines. It does not scan your systems, does not fix vulnerabilities, does not replace your scanner or penetration tester, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
Vulnerability management is the ongoing cycle of finding weaknesses, ranking them by risk, fixing or formally accepting them within set timelines, and verifying the result. It is broader than a penetration test, which is one scoped, point-in-time input. For audits, the strongest proof is dated scan results across the period, tickets with owners, rescans that confirm fixes, and governed exceptions for anything left open.