How to Build a Vulnerability Management Program That Passes Compliance Audits (SOC 2, ISO 27001, PCI DSS)

Sixty percent of confirmed breaches involve a known, unpatched vulnerability -- one that had a CVE number, a severity score, and a patch available before the attacker ever touched the system. The Verizon Data Breach Investigations Report has repeated this finding for years, and the number has not moved meaningfully downward. Organizations continue to get breached not by zero-days or nation-state-level attacks, but by vulnerabilities they already knew about and failed to fix in time.

Every major compliance framework now reflects this reality. SOC 2, ISO 27001, PCI DSS 4.0, and HIPAA all require organizations to operate a formal vulnerability management program -- not a quarterly scan, not a spreadsheet of CVEs, but a documented, repeatable lifecycle that discovers vulnerabilities, prioritizes them by actual risk, remediates them within defined timelines, and produces evidence that the entire process is working.

If your organization has vulnerability scanning in place but no formal program around it, you have a tool -- not a control. And auditors know the difference.

This guide covers how to build a vulnerability management program from the ground up that satisfies the requirements of SOC 2, ISO 27001, PCI DSS, and HIPAA simultaneously. It includes scanning cadence requirements, severity-based SLA templates, remediation workflows, tool recommendations, and the specific evidence auditors expect to see.

What Is a Vulnerability Management Program?

A vulnerability management program is a continuous, structured process for identifying, classifying, prioritizing, remediating, and reporting on security vulnerabilities across an organization's technology environment. It is not a single tool or a periodic activity. It is an operational program with defined ownership, documented procedures, measurable SLAs, and executive accountability.

Scope

A mature vulnerability management program covers every layer of the technology stack:

Infrastructure: Operating systems, network devices, firewalls, load balancers, hypervisors
Applications: Web applications, APIs, mobile applications, internal tools
Cloud resources: Virtual machines, serverless functions, storage buckets, IAM configurations, network security groups
Containers and orchestration: Container images, Kubernetes configurations, runtime environments
Third-party software: Open-source libraries, commercial software, SaaS integrations
Infrastructure as Code: Terraform modules, CloudFormation templates, Helm charts, Dockerfiles
Endpoints: Employee workstations, mobile devices (if in scope for the applicable framework)

If a component can be exploited, it must be in scope.

The Vulnerability Management Lifecycle

The program operates as a continuous loop, not a linear process:

Discover -- Identify all assets and scan them for known vulnerabilities
Prioritize -- Rank findings by actual exploitability and business impact, not just CVSS score
Assess -- Determine whether the vulnerability is relevant in your specific environment and context
Remediate -- Patch, reconfigure, mitigate, or accept the risk (with documented justification)
Verify -- Confirm that the remediation was effective through rescanning or manual validation
Report -- Produce metrics, trend data, and audit evidence for internal stakeholders and external auditors

Each phase must produce documented evidence. Auditors do not evaluate whether you have a scanner. They evaluate whether each phase of this lifecycle is operating, producing records, and meeting the SLAs you defined in your vulnerability management policy.

Vulnerability Management vs Vulnerability Assessment vs Penetration Testing

These three terms are frequently used interchangeably in casual conversation, but they represent fundamentally different activities with distinct compliance roles. Understanding the differences is critical because auditors treat them as separate controls.

	Vulnerability Management Program	Vulnerability Assessment	Penetration Testing
Nature	Ongoing operational program	Point-in-time evaluation	Point-in-time simulated attack
Frequency	Continuous (daily/weekly/monthly scans)	Periodic (quarterly/annually)	Annual minimum; after major changes
Depth	Broad coverage across all assets; automated detection	Focused evaluation of specific systems or applications	Deep exploitation; manual and creative
Output	Metrics dashboards, remediation tickets, trend reports, SLA compliance data	Report listing identified vulnerabilities with severity ratings	Narrative report with exploitation proof, attack paths, business impact
Who performs it	Internal security/operations team (with tooling)	Internal team or third-party assessors	Qualified third-party penetration testers
Compliance role	Satisfies ongoing monitoring and remediation requirements	Supplements the program with deeper periodic analysis	Validates that defenses work against skilled human attackers
Relationship	The overarching program	An activity within the program	A validation control that tests the program's effectiveness

A vulnerability assessment is a component of your vulnerability management program. A penetration test validates whether your program is working. You need all three, and auditors will look for evidence of each.

For a detailed breakdown of penetration testing requirements, see our Penetration Testing Guide.

Why Compliance Frameworks Require Formal Vulnerability Management

Every major compliance framework mandates vulnerability management because the data is unambiguous: unpatched vulnerabilities are the most common initial attack vector. The frameworks differ in specificity, but they converge on the same core expectation -- that organizations operate a continuous process for finding and fixing vulnerabilities.

SOC 2 -- Trust Services Criteria CC7.1

CC7.1 requires organizations to "use defined configuration standards" and "monitor infrastructure and software to identify vulnerabilities." SOC 2 does not prescribe specific scanning tools or frequencies, but your auditor will expect to see:

Documented vulnerability management policy and procedures
Evidence of regular scanning (typically weekly or more frequent)
A defined prioritization methodology
Remediation SLAs with evidence of adherence
Trend reporting showing that vulnerability counts are stable or decreasing
Exception handling with documented risk acceptance for any vulnerabilities not remediated within SLA

The SOC 2 approach is principles-based. Your auditor determines whether your program is "suitably designed" and "operating effectively" -- which gives you flexibility but also means you cannot point to a checkbox and say "done." You must demonstrate that the program works.

For a complete overview of SOC 2 requirements, see our SOC 2 Compliance Guide.

ISO 27001 -- Annex A Control A.8.8

ISO 27001:2022 consolidates vulnerability management under Annex A control A.8.8 (Management of Technical Vulnerabilities). The control requires organizations to:

Obtain timely information about technical vulnerabilities of information systems in use
Evaluate the organization's exposure to such vulnerabilities
Take appropriate measures to address the associated risk
Track and verify remediation

ISO 27001 auditors will evaluate your vulnerability management process during the Stage 2 certification audit and every surveillance audit thereafter. They expect to see a documented procedure, defined roles, evidence of regular scanning, and records of remediation activities.

For ISO 27001 implementation guidance, see our ISO 27001 Certification Guide.

PCI DSS 4.0 -- Requirements 6.3 and 11.3

PCI DSS is the most prescriptive framework regarding vulnerability management. Requirements 6.3 and 11.3 specify:

Requirement 6.3.1: Security vulnerabilities are identified and managed. A process must exist to identify new security vulnerabilities using industry-recognized sources and to assign risk rankings (critical, high, medium, low) to newly discovered vulnerabilities.
Requirement 6.3.3: All system components are protected from known vulnerabilities by installing applicable critical and high-severity security patches within one month of release.
Requirement 11.3.1: Internal vulnerability scans are performed at least once every three months and after any significant change. High-risk and critical vulnerabilities (per the entity's risk ranking) are resolved and rescans confirm resolution.
Requirement 11.3.2: External vulnerability scans are performed at least once every three months and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). Scans must achieve a passing result.

PCI DSS explicitly mandates quarterly scanning with ASV involvement for external scans and requires critical/high patches within 30 days. There is no flexibility on these timelines -- they are hard requirements with specific evidence expectations.

HIPAA -- Security Rule Section 164.308(a)(1)

The HIPAA Security Rule requires covered entities and business associates to "implement policies and procedures to prevent, detect, contain, and correct security violations." The Risk Analysis standard under Section 164.308(a)(1)(ii)(A) requires organizations to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."

HIPAA does not prescribe specific scanning frequencies or tools, but the Office for Civil Rights (OCR) has made clear through enforcement actions that organizations handling ePHI are expected to maintain an ongoing vulnerability management process. A lack of regular vulnerability scanning and remediation has been cited as a contributing factor in multiple OCR settlement agreements exceeding $1 million.

The 6 Phases of Vulnerability Management

Phase 1: Discover

You cannot manage vulnerabilities in assets you do not know about. Discovery is the foundation of the entire program.

Asset inventory comes first. Before you run a single scan, you need a complete, continuously updated inventory of every system, application, container image, cloud resource, and endpoint in your environment. Shadow IT, forgotten development servers, untracked cloud resources, and legacy systems are where the most dangerous vulnerabilities hide -- precisely because nobody is scanning them.

Discovery activities include:

Automated network discovery scans to identify all connected devices and services
Cloud API enumeration to catalog all resources across AWS, GCP, and Azure accounts
Container registry scanning to inventory all images
Software composition analysis to catalog all open-source dependencies
CMDB reconciliation to ensure your asset inventory matches reality

Key output: A current, comprehensive asset inventory with ownership assigned. Every asset must have an owner who is accountable for vulnerability remediation on that asset.

Phase 2: Prioritize

A typical enterprise environment generates thousands of vulnerability findings per scan cycle. Attempting to remediate all of them simultaneously is operationally impossible. Prioritization determines what gets fixed first.

Effective prioritization considers multiple factors beyond the raw CVSS score (see the dedicated section below on why CVSS alone is insufficient):

Exploitability: Is there a known exploit in the wild? Is it being actively exploited?
Asset criticality: Does this vulnerability affect a production system handling sensitive data, or a development sandbox?
Exposure: Is the vulnerable system internet-facing, or is it behind multiple layers of network segmentation?
Compensating controls: Are there existing controls (WAF rules, network segmentation, runtime protection) that reduce the exploitability?
Business impact: What is the worst-case outcome if this vulnerability is exploited?

Key output: A prioritized queue of vulnerabilities ranked by actual risk, with each finding assigned a severity level (critical, high, medium, low) and a corresponding remediation SLA.

Phase 3: Assess

Not every vulnerability flagged by a scanner is relevant in your environment. The assessment phase involves security engineers reviewing prioritized findings to determine:

Is the finding a true positive? Scanners produce false positives. A reported vulnerability in a library that is included but never invoked in your application may not represent actual risk.
Is the vulnerable code path reachable? A dependency vulnerability in a function your application never calls may warrant a lower priority than the CVSS score suggests.
Are compensating controls already in place? A SQL injection vulnerability in an application behind a WAF with a relevant blocking rule is still a vulnerability that must be remediated, but the effective risk is lower.
Is risk acceptance appropriate? Some vulnerabilities may be accepted with documented justification -- for example, a medium-severity finding in a system scheduled for decommission within 30 days.

Key output: For each vulnerability, a documented assessment decision: remediate (with assigned owner and SLA), mitigate (with compensating control documentation), accept (with risk acceptance justification and expiration date), or dismiss (with false positive justification).

Phase 4: Remediate

Remediation is where the program delivers actual security improvement. This is also where most programs fail -- not because organizations lack the intent to patch, but because the operational mechanics of remediation are difficult.

Remediation methods include:

Patching: Applying vendor-supplied security patches. This is the preferred remediation for most vulnerabilities.
Configuration changes: Hardening system configurations to eliminate the vulnerability (e.g., disabling a vulnerable protocol, tightening access controls).
Code fixes: For application-level vulnerabilities, deploying code changes that address the root cause.
Compensating controls: When a patch is not immediately available or cannot be applied without unacceptable business disruption, implementing alternative controls that reduce the exploitability of the vulnerability.
Decommission: Removing the vulnerable system from the environment entirely.

Remediation must be tracked in a ticketing system. Every vulnerability assigned for remediation must have a corresponding ticket (Jira, Linear, ServiceNow, or equivalent) with an assigned owner, a severity-based SLA deadline, and status tracking. Auditors will request a sample of vulnerability remediation tickets and verify that SLAs were met.

Key output: Remediation tickets with owner, SLA, status, and timestamps for every vulnerability above the risk acceptance threshold.

Phase 5: Verify

Remediation is not complete until verification confirms it was effective. Verification methods include:

Automated rescanning: Run the same scanner against the remediated asset to confirm the vulnerability is no longer detected.
Manual validation: For complex vulnerabilities, a security engineer manually verifies that the fix addresses the root cause.
Regression testing: Confirm that the remediation did not introduce new vulnerabilities or break application functionality.

Key output: Rescan results or manual verification records confirming that the vulnerability was successfully remediated. This is critical audit evidence -- auditors will check not just that you opened a ticket, but that you closed the loop.

Phase 6: Report

Reporting serves two audiences: internal stakeholders who need to understand program performance, and external auditors who need evidence that the program operates effectively.

Internal reporting includes:

Executive dashboards showing vulnerability counts by severity, remediation trends, and SLA compliance rates
Team-level reports showing each asset owner's open vulnerability backlog
Trend analysis showing mean time to remediation, aging vulnerability counts, and scan coverage metrics

External (audit) reporting includes:

Vulnerability management policy document
Scanning schedules and evidence of adherence
Remediation SLA definitions and compliance metrics
Sample remediation tickets with complete lifecycle evidence (discovery, assignment, remediation, verification)
Risk acceptance documentation for any unresolved vulnerabilities
Exception tracking with justification and expiration dates

Key output: Structured reports that demonstrate the program is operating continuously, meeting defined SLAs, and producing measurable improvement over time.

Vulnerability Scanning: Types, Tools, and Frequency Requirements

Scanning is the detection engine of your vulnerability management program. Different vulnerability types require different scanning approaches.

Network Vulnerability Scanning

Scans IP ranges, ports, and services for known vulnerabilities in operating systems, network devices, and server software.

Tools: Nessus, Qualys VMDR, Rapid7 InsightVM, OpenVAS (open source), Microsoft Defender for Endpoint

What it finds: Unpatched operating systems, misconfigured services, open ports, weak encryption protocols, default credentials, end-of-life software

Web Application Scanning

Scans web applications and APIs for vulnerabilities including the OWASP Top 10.

Tools: Burp Suite Enterprise, OWASP ZAP (open source), Qualys WAS, Rapid7 InsightAppSec, Invicti

What it finds: SQL injection, cross-site scripting, broken authentication, insecure direct object references, server-side request forgery, security misconfigurations

Container Image Scanning

Scans container images for known vulnerabilities in base images and installed packages.

Tools: Trivy (open source), Snyk Container, Aqua Security, Sysdig Secure, Amazon ECR scanning, Google Artifact Analysis

What it finds: Vulnerable packages in base images, outdated base images, root user configurations, exposed secrets in image layers

Cloud Configuration Scanning (CSPM)

Scans cloud infrastructure for misconfigurations that could expose resources to unauthorized access.

Tools: AWS Security Hub, Google Security Command Center, Azure Defender, Prowler (open source), Wiz, Orca Security, Prisma Cloud

What it finds: Publicly accessible storage buckets, overly permissive IAM policies, unencrypted databases, missing logging configurations, unrestricted security group rules

Software Composition Analysis (SCA)

Scans application dependencies for known vulnerabilities in open-source libraries.

Tools: Snyk, Dependabot (GitHub native), Renovate, OWASP Dependency-Check (open source), Mend (formerly WhiteSource), Sonatype Nexus

What it finds: Vulnerable open-source library versions, license compliance issues, outdated dependencies with known CVEs

Infrastructure as Code (IaC) Scanning

Scans Terraform, CloudFormation, Kubernetes manifests, and Dockerfiles for security misconfigurations before deployment.

Tools: Checkov (open source), tfsec, KICS, Snyk IaC, Bridgecrew, Prisma Cloud

What it finds: Hardcoded secrets, overly permissive resource configurations, missing encryption settings, non-compliant resource definitions

Scanning Frequency Requirements by Framework

Framework	Internal Scanning	External Scanning	After Significant Changes
SOC 2	Not prescriptive; auditors expect weekly minimum, continuous preferred	Not prescriptive; periodic expected	Yes -- auditors expect scans after infrastructure changes
ISO 27001	Regular intervals; auditors expect at least monthly	Regular intervals; expected for internet-facing systems	Yes -- per A.8.8 vulnerability management requirements
PCI DSS 4.0	At least quarterly (Req 11.3.1); after significant changes	At least quarterly by ASV (Req 11.3.2); after significant changes	Explicitly required; must rescan after changes
HIPAA	Not prescriptive; regular scanning expected as part of risk management	Not prescriptive; expected for internet-facing systems	Expected as part of ongoing risk management

Practical recommendation: Run automated scans weekly at minimum. For container images and IaC, scan on every build in your CI/CD pipeline. For cloud configurations, run CSPM continuously. The marginal cost of more frequent scanning is low; the cost of missing a critical vulnerability because your scan cadence was too slow is high.

Vulnerability Prioritization: CVSS, EPSS, and Risk-Based Approaches

Why CVSS Alone Is Insufficient

The Common Vulnerability Scoring System (CVSS) assigns a severity score between 0.0 and 10.0 to each vulnerability. Most organizations use CVSS as their primary prioritization mechanism: critical (9.0-10.0), high (7.0-8.9), medium (4.0-6.9), low (0.1-3.9).

The problem: CVSS measures the theoretical severity of a vulnerability in isolation. It does not consider whether the vulnerability is actually being exploited in the wild, whether the vulnerable system is internet-facing, or whether compensating controls are in place. Research from Kenna Security (now part of Cisco) found that only 2-5% of published vulnerabilities are ever exploited in the wild, yet a CVSS-only approach treats all 9.0+ vulnerabilities as equally urgent.

This creates two failure modes:

Alert fatigue: Teams are overwhelmed with "critical" findings that will never be exploited, causing them to deprioritize or ignore vulnerability remediation entirely.
Misallocation: A CVSS 7.5 vulnerability with a public exploit and active exploitation campaigns gets the same priority as a CVSS 8.0 vulnerability that has no known exploit and requires local physical access.

EPSS: Exploit Prediction Scoring System

The Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. EPSS uses machine learning models trained on real-world exploitation data to produce a probability score between 0 and 1.

EPSS is a probability; CVSS is a severity. They answer different questions. A vulnerability with a CVSS of 9.8 and an EPSS of 0.01 is theoretically severe but extremely unlikely to be exploited. A vulnerability with a CVSS of 7.0 and an EPSS of 0.95 is moderately severe but almost certainly being exploited right now. The second one should be fixed first.

Risk-Based Prioritization Matrix

The most effective approach combines multiple data points:

Factor	Data Source	Weight
CVSS base score	NVD, vendor advisories	Baseline severity
EPSS score	FIRST.org EPSS model	Exploitation likelihood
Known exploited	CISA KEV catalog	Immediate priority elevation
Asset criticality	Internal asset inventory	Business impact multiplier
Internet exposure	Network architecture, CSPM	Accessibility factor
Compensating controls	Security architecture review	Risk reduction factor

Practical recommendation: Adopt a tiered prioritization model:

Tier 1 (Immediate): Any vulnerability on the CISA Known Exploited Vulnerabilities (KEV) catalog, or any vulnerability with CVSS >= 9.0 AND EPSS >= 0.5 on an internet-facing production system
Tier 2 (Urgent): CVSS >= 7.0 with known exploits or EPSS >= 0.3 on production systems
Tier 3 (Standard): CVSS >= 4.0 on production systems, or CVSS >= 7.0 on internal/development systems
Tier 4 (Scheduled): All remaining findings above the risk acceptance threshold

This approach ensures that actively exploited vulnerabilities on critical systems are remediated first, regardless of whether their CVSS score is the highest in the queue.

Remediation SLAs: Setting Realistic Timelines by Severity

Remediation SLAs define how quickly vulnerabilities must be fixed after discovery. Your vulnerability management policy must document these SLAs, and your program must produce evidence of adherence.

Recommended SLA Framework

Severity	Definition	Remediation SLA	Example
Critical	CVSS 9.0-10.0, or CISA KEV listed, or EPSS > 0.9 on production system	24-48 hours	Remote code execution in internet-facing web server with public exploit
High	CVSS 7.0-8.9 with known exploit, or CVSS 9.0+ on non-production system	7 days	Privilege escalation vulnerability in production database with proof-of-concept exploit
Medium	CVSS 4.0-6.9, or CVSS 7.0+ without known exploit on internal systems	30 days	Cross-site scripting in internal admin tool; information disclosure in non-sensitive API
Low	CVSS 0.1-3.9, or informational findings	90 days	Verbose error messages exposing software version; missing security headers on non-sensitive pages

SLA Considerations

Critical SLA (24-48 hours): This is deliberately aggressive. A critical vulnerability on a production system with a public exploit represents an imminent threat. The 24-48 hour window assumes you have an emergency patching process that can deploy out of the normal change management cycle. If you do not have an emergency change process, build one before your audit.

PCI DSS alignment: PCI DSS Requirement 6.3.3 mandates that critical and high security patches be installed within one month of release. Your internal SLAs should be more aggressive than PCI DSS minimums -- 30 days for a critical vulnerability is a compliance floor, not a security target.

Risk acceptance as an SLA exception: When a vulnerability cannot be remediated within SLA due to legitimate operational constraints (e.g., the patch breaks a critical business application, the vendor has not released a patch), the exception must be documented with:

Business justification for the delay
Compensating controls implemented to reduce risk
Revised remediation date
Management approval (named individual, title, date)
Periodic review schedule (exceptions should not be permanent)

Auditors will sample SLA compliance. Expect your auditor to select a random sample of 15-30 vulnerabilities from the audit period, trace each one from discovery to remediation, and verify that SLAs were met. If your SLA compliance rate is below 80-85%, expect it to be flagged as a finding. Below 70%, expect a significant deficiency.

Patch Management: The Operational Core of Vulnerability Management

Patch management is not a separate program -- it is the operational execution layer of vulnerability management. Most vulnerability remediations involve applying a patch, so your patch management process is where the program either succeeds or fails.

Patch Management Workflow

Patch identification: Subscribe to vendor security advisories (Microsoft MSRC, Ubuntu USN, AWS Security Bulletins, etc.) and CVE monitoring feeds. Integrate these with your vulnerability scanner results.
Patch testing: Test patches in a staging environment that mirrors production before deployment. For critical vulnerabilities, testing may be abbreviated but should never be skipped entirely.
Patch deployment: Deploy patches according to the SLA timeline. Use automated patch management tools for operating system and infrastructure patches; use your CI/CD pipeline for application dependency patches.
Patch verification: Confirm that the patch was successfully applied across all affected systems. Rescan to verify the vulnerability is resolved.
Documentation: Record the patch deployment with timestamps, affected systems, deploying personnel, and verification results.

Patch Management Tools

Environment	Tools
Linux servers	Unattended-upgrades, Ansible, Puppet, Chef, AWS Systems Manager Patch Manager
Windows servers	WSUS, SCCM/MECM, Azure Update Management, AWS Systems Manager
Container images	Rebuild images with updated base images; automate via CI/CD pipeline triggers on base image updates
Application dependencies	Dependabot (GitHub), Renovate, Snyk, automated PR creation on vulnerable dependency detection
Cloud infrastructure	Terraform/CloudFormation updates; CSP-managed patching for managed services

What Auditors Check

Is there a documented patch management procedure?
Is there evidence that patches are tested before deployment?
Are critical and high-severity patches applied within the defined SLA?
Is there a process for emergency patching outside normal change windows?
Are systems that cannot be patched (end-of-life, vendor constraints) documented with compensating controls?

Vulnerability Management for Cloud-Native and SaaS Companies

Cloud-native architectures introduce vulnerability management challenges that traditional network-centric programs do not address. If your infrastructure runs on containers, serverless functions, and managed cloud services, your program must adapt.

Container Vulnerability Management

Containers are ephemeral, which creates a false sense of security. A container running a vulnerable base image is just as exploitable as a vulnerable virtual machine -- it may just be exploitable for a shorter window before it is replaced. But if the next container is built from the same vulnerable image, you have not remediated anything.

Requirements:

Scan all container images in your registry, not just images currently running in production
Integrate image scanning into your CI/CD pipeline so that vulnerable images are blocked before deployment
Establish a process for rebuilding and redeploying containers when base image vulnerabilities are discovered
Monitor running containers for newly discovered vulnerabilities (a container that was clean at build time may become vulnerable when a new CVE is published)

Infrastructure as Code (IaC) Vulnerability Management

IaC scanning catches misconfigurations before they reach production. This is a preventive control that complements your detective scanning controls.

Requirements:

Scan Terraform, CloudFormation, Kubernetes manifests, and Dockerfiles in every CI/CD pipeline run
Block merges that introduce critical or high-severity misconfigurations
Maintain a baseline policy set that defines your organization's security standards for cloud resources (e.g., all S3 buckets must have public access blocked, all RDS instances must have encryption enabled)

API Security

APIs are the primary attack surface for most SaaS companies, yet many vulnerability management programs focus exclusively on infrastructure and web application scanning while ignoring API-specific vulnerabilities.

Requirements:

Include API endpoints in your web application scanning scope
Test for OWASP API Security Top 10 vulnerabilities (broken object-level authorization, broken authentication, excessive data exposure, lack of rate limiting)
Scan API specifications (OpenAPI/Swagger definitions) for security misconfigurations
Monitor for undocumented or shadow APIs that are not covered by your scanning program

Serverless and Managed Services

For serverless functions (AWS Lambda, Google Cloud Functions, Azure Functions) and fully managed services (RDS, CloudSQL, managed Kubernetes), the shared responsibility model shifts some vulnerability management to the cloud provider. However, your program must still cover:

Application code and dependencies deployed in serverless functions
Configuration of managed services (encryption settings, access controls, network exposure)
IAM policies governing access to managed resources

Documenting Your Program for Audit Evidence

Auditors evaluate your vulnerability management program through documentation and evidence sampling. Having a strong program that produces no documentation is, from an audit perspective, equivalent to having no program at all.

Documents Auditors Expect

1. Vulnerability Management Policy

A formal, management-approved policy document that defines:

Program scope (which systems, networks, and applications are covered)
Roles and responsibilities (who owns the program, who performs scanning, who is accountable for remediation)
Scanning types and frequencies
Severity classification methodology
Remediation SLAs by severity
Exception and risk acceptance procedures
Reporting requirements and frequencies
Policy review cycle (at least annual)

2. Vulnerability Management Procedure

An operational document that describes the step-by-step process for each phase of the lifecycle. This is not the policy (which defines what must be done) but the procedure (which describes how it is done).

3. Asset Inventory

A current inventory of all in-scope systems with assigned ownership. The inventory must be updated regularly and reconciled against actual infrastructure.

4. Scanning Evidence

Scanner configuration showing scope, frequency, and credential settings
Scan execution logs with timestamps
Scan result summaries for each scan cycle
Evidence that full scope was covered (no assets excluded without documented justification)

5. Remediation Evidence

Ticketing system records showing the complete lifecycle: vulnerability identified, ticket created, owner assigned, remediation performed, verification completed
SLA compliance metrics showing percentage of vulnerabilities remediated within SLA
Exception documentation for any vulnerabilities exceeding SLA

6. Risk Acceptance Records

For vulnerabilities not remediated within SLA or accepted without remediation:

Named individual approving the risk acceptance (must be management-level)
Business justification
Compensating controls description
Expiration date and review schedule

7. Program Metrics and Reporting

Monthly or quarterly vulnerability management reports
Trend data showing program effectiveness over time
Board or executive-level reporting (required by some frameworks and expected by most auditors)

Evidence Collection Tips

Automate evidence generation. Export scan results, SLA compliance reports, and remediation metrics automatically. Manual evidence collection does not scale and introduces errors.
Maintain an evidence repository. Store all vulnerability management evidence in a centralized, access-controlled location with immutable timestamps.
Capture point-in-time snapshots. Auditors evaluate a specific audit period. Ensure you can produce evidence for any point within that period, not just the current state.
Retain evidence for the audit period plus one year. SOC 2 Type II audits cover a specific period (typically 6-12 months). Retain evidence for the entire audit period plus sufficient time for the audit itself.

Vulnerability Management Metrics and KPIs

What gets measured gets managed. These metrics demonstrate program effectiveness to auditors and help internal teams identify operational improvements.

Core Metrics

Mean Time to Remediate (MTTR)

The average time between vulnerability discovery and verified remediation, segmented by severity level.

Why it matters: MTTR is the single most important metric for demonstrating program effectiveness. A decreasing MTTR trend shows that your program is improving.
Benchmark: Critical < 48 hours, High < 7 days, Medium < 30 days, Low < 90 days
Auditor expectation: MTTR should align with your documented SLAs. If your policy says critical vulnerabilities are remediated in 48 hours but your MTTR for critical is 12 days, you have a control failure.

Scan Coverage

The percentage of in-scope assets that are actively scanned, measured against your asset inventory.

Why it matters: A vulnerability management program that only scans 60% of your environment has a 40% blind spot.
Benchmark: Target 100% of in-scope assets. Anything below 95% should trigger investigation.
Auditor expectation: Auditors will compare your scanning scope against your asset inventory. Gaps will be flagged.

SLA Compliance Rate

The percentage of vulnerabilities remediated within their severity-based SLA deadline.

Why it matters: SLA compliance demonstrates that your program is not just identifying vulnerabilities but actually fixing them on time.
Benchmark: Target > 90% for critical and high severity. > 85% for medium. > 80% for low.
Auditor expectation: SLA compliance below 80% for high-severity vulnerabilities will likely result in an audit finding.

Vulnerability Aging (Open Vulnerability Count by Age)

The number of open vulnerabilities segmented by how long they have been open, typically in buckets: 0-7 days, 8-30 days, 31-60 days, 61-90 days, 90+ days.

Why it matters: Aging vulnerabilities represent accumulating risk. A growing backlog of old vulnerabilities indicates a program that cannot keep pace with discovery.
Benchmark: Zero critical and high-severity vulnerabilities should be open beyond their SLA deadline without a documented exception.
Auditor expectation: Auditors will ask for your aging vulnerability report and scrutinize anything older than 90 days.

False Positive Rate

The percentage of scanner findings that are determined to be false positives during the assessment phase.

Why it matters: A high false positive rate wastes engineering time and contributes to alert fatigue. It may also indicate scanner misconfiguration.
Benchmark: Below 15% is good. Above 30% indicates a tuning problem.

Reporting Cadence

Report	Audience	Frequency
Vulnerability status dashboard	Security team, engineering leads	Real-time / daily
SLA compliance report	Security leadership, CTO	Weekly
Program metrics summary	Executive team, board of directors	Monthly
Audit evidence package	External auditors	Per audit period
Trend analysis and improvement plan	Security leadership	Quarterly

Common Vulnerability Management Audit Failures

Understanding why organizations fail vulnerability management audits helps you avoid the same mistakes. These are the most frequent findings, drawn from real audit reports.

1. No Formal Policy

The organization runs vulnerability scans but has no documented vulnerability management policy. Without a policy, the auditor cannot validate that management has defined expectations for the program. Even if scanning and remediation are occurring, the absence of a policy is a control gap in every framework.

Fix: Write and approve a vulnerability management policy that covers scope, roles, scanning cadence, SLA definitions, and exception handling. Review annually.

2. Incomplete Asset Coverage

Scans cover production servers but miss development environments, container images, cloud resources, or third-party-managed systems. The auditor compares the scanning scope to the asset inventory and finds gaps.

Fix: Reconcile your scanning scope against your asset inventory quarterly. Ensure every asset category is covered by an appropriate scanning tool.

3. No Defined Remediation SLAs

Vulnerabilities are identified but there is no documented timeline for remediation. The auditor cannot determine whether the organization is remediating in a timely manner because "timely" was never defined.

Fix: Define severity-based SLAs in your vulnerability management policy. Track SLA compliance as a metric.

4. SLA Non-Compliance Without Exceptions

Vulnerability findings exceed their SLA deadlines with no documented risk acceptance or exception. The auditor sees critical vulnerabilities that have been open for 6 months with no explanation.

Fix: Implement a formal exception process. If a vulnerability cannot be remediated within SLA, document the justification, compensating controls, and revised timeline with management approval.

5. No Verification of Remediation

Vulnerabilities are marked as "fixed" in the ticketing system but there is no evidence of rescanning or verification. The auditor cannot confirm that the vulnerability was actually resolved.

Fix: Require a rescan or manual verification step before any vulnerability can be closed. Include rescan evidence in the remediation ticket.

6. Scan Results Not Reviewed

Scans run on schedule, but the results are not reviewed or triaged. Thousands of findings accumulate with no prioritization or assignment. The program generates data but no action.

Fix: Assign vulnerability triage responsibility to a named individual or team. Define a triage SLA (e.g., all new critical and high findings triaged within 24 hours of scan completion).

7. Risk Acceptance Without Documentation

Vulnerabilities are acknowledged and intentionally not fixed, but the risk acceptance is verbal or informal. The auditor asks for risk acceptance records and finds none.

Fix: Require written risk acceptance with management signature, business justification, compensating controls, and expiration date for every accepted vulnerability.

8. No Trend Reporting

The program operates on a scan-by-scan basis with no longitudinal metrics. The auditor asks for trend data and receives individual scan reports instead. The auditor cannot assess whether the program is effective over time.

Fix: Implement monthly or quarterly trend reporting showing MTTR, SLA compliance, aging vulnerability counts, and scan coverage over time.

Frequently Asked Questions

How often should vulnerability scans be performed?

At minimum, weekly for infrastructure and network scans, on every build for container images and application dependencies, and continuously for cloud configuration monitoring. PCI DSS mandates at least quarterly for internal and external scans, but this is a compliance minimum, not a security recommendation. Most mature programs scan daily or continuously.

Do we need an external vulnerability scan if we already scan internally?

Yes. Internal and external scans serve different purposes. Internal scans identify vulnerabilities visible from within your network. External scans (particularly ASV scans for PCI DSS) evaluate your attack surface from an attacker's perspective on the public internet. Some vulnerabilities are only visible from one perspective. Additionally, PCI DSS explicitly requires external scans by an Approved Scanning Vendor.

Can we use open-source vulnerability scanning tools for compliance?

Yes. Compliance frameworks do not mandate specific commercial tools. Open-source tools like Trivy (container scanning), OpenVAS (network scanning), OWASP ZAP (web application scanning), and Checkov (IaC scanning) can satisfy compliance requirements if they are configured properly, run on the required cadence, and produce documented results. The tool itself is less important than the process, coverage, and evidence it generates.

What is the difference between a vulnerability management policy and a vulnerability management procedure?

The policy is a management-approved document that defines what the organization will do: scope, SLAs, responsibilities, and standards. The procedure is an operational document that describes how each step is performed: which tools to run, how to triage results, how to create remediation tickets, how to verify fixes. Auditors expect both. The policy demonstrates management intent; the procedure demonstrates operational capability.

How do we handle vulnerabilities in third-party software we cannot patch ourselves?

Document the vulnerability, contact the vendor for a remediation timeline, implement compensating controls (network segmentation, WAF rules, access restrictions), and track the vulnerability under your exception process with a documented risk acceptance. Include the vendor's expected patch timeline in the exception record. If the vendor has no timeline, evaluate whether the product should be replaced.

What should our vulnerability management program cover if we are a cloud-native SaaS company with no on-premises infrastructure?

Your program should cover container images, application dependencies (open-source libraries and frameworks), cloud infrastructure configurations (IAM, networking, storage, encryption), Infrastructure as Code templates, API endpoints, and any third-party SaaS integrations with access to your data. The attack surface of a cloud-native company is different from a traditional enterprise, but it is not smaller.

How do we demonstrate vulnerability management program effectiveness to auditors?

Through metrics. Specifically: MTTR trending downward or stable within SLA targets, SLA compliance rates above 85%, scan coverage at or near 100% of in-scope assets, aging vulnerability counts trending downward, and documented evidence of the complete vulnerability lifecycle (discovery through verification) for a representative sample of findings. Auditors assess effectiveness through data, not assertions.

Is a vulnerability management program required for SOC 2 Type I, or only Type II?

Both. SOC 2 Type I evaluates the design of controls at a point in time. An auditor performing a Type I engagement will verify that you have a vulnerability management program designed and implemented. Type II evaluates operating effectiveness over a period (typically 6-12 months), so the auditor will also verify that the program operated consistently throughout the audit period. The program requirements are the same; the evidence requirements differ.

Build Your Vulnerability Management Program on a Solid Foundation

A vulnerability management program that satisfies SOC 2, ISO 27001, PCI DSS, and HIPAA auditors requires more than scanning tools. It requires documented policies, defined SLAs, a prioritization methodology that goes beyond raw CVSS scores, remediation workflows with accountability, verification processes that close the loop, and metrics that demonstrate the program is working.

Building this program from scratch while simultaneously preparing for a compliance audit is where most organizations struggle. The policy documents, the scanning configuration, the SLA tracking, the exception management, the remediation evidence, the trend reporting -- each piece is manageable individually, but assembling them into a cohesive, audit-ready program requires significant coordination.

QuickTrust automates the operational backbone of your vulnerability management program. The platform integrates with your existing scanning tools, automatically maps findings to compliance framework requirements across SOC 2, ISO 27001, PCI DSS, and HIPAA, tracks remediation SLAs with real-time compliance dashboards, and generates the audit evidence packages your auditor expects -- all without manual evidence collection or spreadsheet tracking.

Instead of spending engineering cycles assembling vulnerability management evidence for your next audit, let QuickTrust collect, organize, and present it automatically.

Start your free QuickTrust assessment and see how your current vulnerability management practices map to audit requirements across every framework you are pursuing.