How to Build a Vulnerability Management Program That Passes Compliance Audits (SOC 2, ISO 27001, PCI DSS)
A vulnerability management program is not optional for any organization pursuing compliance certification. SOC 2, ISO 27001, and PCI DSS each require documented, repeatable processes for identifying, prioritizing, and remediating security vulnerabilities. Yet most organizations fail their first audit on vulnerability management -- not because they lack scanning tools, but because they lack a structured program with clear ownership, defined SLAs, and proper evidence trails.
This guide walks through what auditors actually look for, how to structure your vulnerability management program by framework, and the practical steps QuickTrust engineers take to build audit-ready VM programs from scratch.
What Auditors Actually Evaluate
Auditors are not interested in whether you run a vulnerability scanner. They want to see a complete lifecycle: identification, classification, prioritization, remediation, verification, and reporting. They evaluate whether your program is documented as policy, executed consistently, and produces evidence that proves it.
Common audit findings that lead to failures include the absence of a formal vulnerability management policy, inconsistent scanning schedules, no defined remediation timelines, missing evidence of rescans after fixes, and a lack of executive reporting on vulnerability trends.
Vulnerability Management Requirements by Framework
SOC 2
SOC 2 addresses vulnerability management primarily through the Common Criteria (CC) related to risk management and system operations. CC7.1 requires organizations to detect and monitor security vulnerabilities. CC7.2 requires monitoring system components for anomalies. There is no prescriptive scanning frequency in SOC 2, but auditors expect at minimum quarterly vulnerability scans and evidence that critical vulnerabilities are addressed in a timely manner. Organizations must demonstrate that vulnerability management is part of their broader risk assessment process and that identified vulnerabilities are tracked through remediation.
ISO 27001
ISO 27001 Annex A control A.8.8 (Management of Technical Vulnerabilities) requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. The standard requires a documented process for vulnerability management, including defined roles and responsibilities. ISO 27001 auditors look for integration between your vulnerability management program and your risk treatment plan. Vulnerabilities should be logged in your risk register when they represent material risk, and treatment decisions must be documented.
PCI DSS
PCI DSS is the most prescriptive of the three frameworks regarding vulnerability management. Requirement 5 mandates anti-malware protections, while Requirement 6 requires secure development practices including vulnerability scanning. Requirement 11.3 specifically requires:
- Internal vulnerability scans at least quarterly and after any significant change
- External vulnerability scans by an Approved Scanning Vendor (ASV) at least quarterly
- Rescans until passing results are achieved
- All four quarterly scans completed within the most recent 12-month period
PCI DSS 4.0 further tightens requirements with Requirement 6.3.3, which mandates that all system components are protected from known vulnerabilities by installing applicable security patches within defined timeframes.
Scanning Frequency and Scope
A baseline scanning cadence that satisfies all three frameworks looks like this:
- Weekly: Automated vulnerability scans of production infrastructure and applications
- Monthly: Full network scans including internal and external assets
- Quarterly: Formal scan with documentation for audit evidence (required minimum for PCI DSS)
- Ad hoc: Scans triggered by significant infrastructure changes, new deployments, or newly disclosed critical vulnerabilities
Scope must cover all in-scope systems, which varies by framework. For SOC 2, this means all systems that process, store, or transmit data relevant to the trust services criteria in your system description. For PCI DSS, it covers all systems within the cardholder data environment (CDE) and connected systems. For ISO 27001, scope is defined by your ISMS scope statement.
Remediation SLAs by Severity
Auditors expect documented remediation timelines tied to vulnerability severity. The following SLA structure satisfies the expectations of SOC 2, ISO 27001, and PCI DSS auditors:
| Severity | CVSS Score Range | Remediation SLA | Notes |
|---|---|---|---|
| Critical | 9.0 - 10.0 | 24-72 hours | Actively exploited vulns: immediate action |
| High | 7.0 - 8.9 | 14 days | Must have compensating controls if delayed |
| Medium | 4.0 - 6.9 | 30 days | Document risk acceptance if exceeding SLA |
| Low | 0.1 - 3.9 | 90 days | Track for trending, batch remediation acceptable |
| Informational | 0.0 | Next scheduled maintenance | Log but no SLA required |
These SLAs must be documented in your vulnerability management policy and consistently enforced. Auditors will sample remediation tickets and compare actual resolution times against your stated SLAs.
Patch Management as a Core Component
Patch management is a subset of vulnerability management but critical enough to warrant its own documented process. Your patch management program should address:
Patch identification: How you monitor vendor advisories, CVE databases, and threat intelligence feeds for new patches relevant to your technology stack.
Testing and validation: A defined process for testing patches in a non-production environment before deployment. This satisfies change management controls required by all three frameworks.
Deployment cadence: Regular patch cycles (monthly at minimum, aligned with vendor release schedules like Microsoft Patch Tuesday) plus emergency patch procedures for zero-day vulnerabilities.
Rollback procedures: Documented steps for reverting patches that cause operational issues, including backup verification before deployment.
Coverage tracking: Evidence that patches are deployed across all in-scope systems, not just a subset. Auditors frequently check for systems that were missed during patch cycles.
Reporting and Metrics
Vulnerability management reporting serves two purposes: demonstrating program effectiveness to auditors and providing executive visibility into security posture. Key metrics to track and report include:
- Mean time to remediate (MTTR) by severity level
- SLA compliance rate (percentage of vulnerabilities remediated within defined timelines)
- Vulnerability density (vulnerabilities per asset or per application)
- Aging analysis (count of open vulnerabilities beyond their SLA)
- Recurrence rate (vulnerabilities that reappear after remediation)
- Scan coverage (percentage of in-scope assets scanned in each cycle)
Generate reports monthly for operational teams and quarterly for executive stakeholders and audit evidence packages. Include trend analysis showing improvement over time -- auditors view sustained high vulnerability counts as a program effectiveness concern.
Tools and Technology Stack
An effective vulnerability management program typically requires several integrated tools:
Network and infrastructure scanning: Tools like Nessus, Qualys, or Rapid7 InsightVM provide authenticated scanning of servers, network devices, and endpoints. Choose tools that integrate with your ticketing system for automated remediation tracking.
Application scanning: DAST (Dynamic Application Security Testing) tools like OWASP ZAP or Burp Suite for web application scanning. SAST (Static Application Security Testing) tools integrated into CI/CD pipelines for catching vulnerabilities before deployment.
Container and cloud scanning: Tools like Trivy, Snyk, or AWS Inspector for scanning container images, infrastructure-as-code templates, and cloud configurations.
Dependency scanning: Software composition analysis (SCA) tools for identifying vulnerable open-source libraries in your codebase.
Ticketing and tracking: Integration with Jira, ServiceNow, or similar platforms to create remediation tickets automatically and track SLA compliance.
Evidence Collection for Audits
Auditors will request specific evidence artifacts. Prepare and maintain the following:
- Vulnerability management policy: Formally approved, reviewed annually, covering scope, roles, scanning cadence, remediation SLAs, and exception processes
- Scan reports: Raw output from each scanning cycle showing identified vulnerabilities, severity ratings, and affected assets
- Remediation tickets: Closed tickets demonstrating vulnerabilities were addressed within SLA, including verification scans
- Exception documentation: Formal risk acceptance records for vulnerabilities that exceed SLA or cannot be remediated, signed by appropriate risk owners
- Trend reports: Quarterly summaries showing vulnerability counts, MTTR, SLA compliance rates, and improvement trends
- Scan coverage evidence: Documentation proving all in-scope assets are included in scanning schedules
Common Pitfalls That Cause Audit Failures
Inconsistent scanning cadence. Missing a quarterly scan cycle -- even once -- creates an audit gap. Automate your scanning schedule and set up alerts for missed scans.
No formal policy. Running scans without a documented, approved vulnerability management policy means you have a practice, not a program. Auditors require the policy.
Ignoring low and medium findings. Letting medium-severity vulnerabilities age beyond 90 days signals a weak program. Auditors look at aging reports.
Lack of rescanning. Closing a remediation ticket without a verification scan leaves the audit trail incomplete. Always rescan to confirm the fix.
Scope gaps. Failing to scan all in-scope systems -- particularly new assets added between scan cycles -- is a frequent finding.
How QuickTrust Engineers Build Vulnerability Management Programs
QuickTrust takes a full-loop approach to vulnerability management. Our Security and DevOps engineers do not just recommend tools and write policies -- they implement the entire program in your environment.
The engagement starts with asset discovery and scope definition, ensuring every system relevant to your compliance framework is cataloged. Engineers then deploy and configure scanning tools appropriate to your infrastructure (cloud-native scanners, container scanning in CI/CD pipelines, network vulnerability scanners) and integrate them with your ticketing system for automated remediation workflows.
QuickTrust engineers draft your vulnerability management policy aligned to your target framework, configure scanning schedules that satisfy audit requirements, and establish remediation SLA tracking dashboards. For the initial scan cycle, engineers work through the backlog of findings, implementing fixes directly in your cloud environment -- from patching operating systems to updating application dependencies to reconfiguring TLS settings.
The result is a program that produces audit-ready evidence from day one, with scanning, remediation, and reporting running on autopilot. Organizations typically reduce their internal engineering time spent on vulnerability management by 90%, with QuickTrust engineers handling the implementation work that would otherwise pull product teams off their roadmaps.
Conclusion
A vulnerability management program that passes compliance audits requires more than scanning tools. It demands documented policy, consistent execution, defined SLAs, proper evidence trails, and executive reporting. Whether you are pursuing SOC 2, ISO 27001, or PCI DSS, the fundamentals remain the same: identify vulnerabilities systematically, remediate them within defined timelines, verify the fixes, and prove it all to your auditor.
Organizations that treat vulnerability management as a continuous program rather than a periodic scanning exercise will find their audit experiences significantly smoother -- and their actual security posture meaningfully stronger.