Why vulnerability management is a make-or-break audit control
Ask any SOC 2 auditor what they check first and most will say access control and vulnerability management. Together they account for the majority of CC6 and CC7 evidence requests — and vulnerability management is the control that most early-stage SaaS teams get wrong.
Not because they're not scanning. Most teams do something. The problem is the gap between scanning and having a documented, evidenced programme. Auditors want to see: a written policy, scanning logs, a vulnerability register, remediation timelines by severity, and evidence that you actually patched things.
ISO 27001 A.8.8 (formerly A.12.6.1) is equally explicit: organisations must obtain timely information about technical vulnerabilities, evaluate their exposure, and take appropriate measures to address risk.
What compliance frameworks require
| Framework | Reference | Requirement Summary |
|---|---|---|
| SOC 2 | CC7.1 | Detect, respond to, and remediate vulnerabilities; monitor infrastructure for threats |
| ISO 27001:2022 | A.8.8 | Timely identification of technical vulnerabilities; evaluated exposure; appropriate measures taken |
| ISO 27001:2022 | A.12.6.1 (2013) | Same requirement in older version — management of technical vulnerabilities |
| PCI DSS v4.0 | Req 6.3 | Security vulnerabilities identified and addressed; critical patches within 1 month; all patches within defined timeframe |
| NIS2 | Art. 21(2)(e) | Vulnerability handling and disclosure as one of 10 mandatory security measures |
| HIPAA | §164.308(a)(5) | Malicious software protection; security reminders; log-in monitoring |
| GDPR | Art. 32 | Encryption, pseudonymisation, and "ongoing process" TOMs — unpatched vulnerabilities are a GDPR compliance risk |
| NIST SP 800-40 | Rev. 4 | Enterprise patch management — prioritisation, testing, deployment, verification |
| CIS Controls | Control 7 | Continuous vulnerability management — automated scanning, remediation tracking, evidence |
The four components auditors actually check
A mature vulnerability management programme has four parts. Auditors will ask for evidence of all four:
1. Scanning programme (what you scan and how often)
You need to scan all of your attack surface, not just the parts that are easy to scan. Most SaaS companies start with dependency scanning (Dependabot, Snyk) and forget about infrastructure, containers, and external attack surface.
| Asset Type | Scanning Approach | Minimum Frequency | Common Tools |
|---|---|---|---|
| Open-source dependencies | SCA (Software Composition Analysis) | Continuous (on every commit) | Snyk, Dependabot, npm audit |
| Source code | SAST (Static Application Security Testing) | Continuous (on every PR) | SonarQube, Semgrep, CodeQL |
| Container images | Container image scanning | On every build + weekly for running images | Trivy, Snyk Container, AWS Inspector |
| Cloud infrastructure | CSPM / infrastructure scanner | Continuous or weekly | AWS Inspector, Wiz, Prisma Cloud |
| External attack surface | DAST / external scan | Weekly automated + annual pen test | OWASP ZAP, Burp Suite, Detectify |
| Internal network | Network vulnerability scanner | Monthly | Nessus, Qualys, Rapid7 |
2. Severity classification (not all CVEs are equal)
The most common standard is CVSS v3.1 (or v4.0 for newer programmes). But CVSS base score is just a starting point. What matters for your risk exposure is:
- Is there a known exploit available? A CVSS 7.0 with a public exploit is more urgent than a CVSS 9.0 with no exploit code.
- Is the vulnerability in a production, internet-facing system? Same CVE in dev vs production has different risk.
- What data could be exposed? Vulnerabilities touching PII, PHI, or PCI CHD warrant severity upgrade.
- Is it in the CISA KEV (Known Exploited Vulnerabilities) catalogue? These are being actively weaponised — treat as Critical regardless of CVSS.
| Severity | CVSS v3.1 Range | Remediation SLA | Escalation |
|---|---|---|---|
| Critical | 9.0–10.0 | 24–48 hours | Immediate — Security Lead + Engineering Lead |
| High | 7.0–8.9 | 7 days | Security Lead approval required for exceptions |
| Medium | 4.0–6.9 | 30 days | Engineering Lead tracks |
| Low | 0.1–3.9 | 90 days | Standard sprint backlog |
| Informational | N/A | Next scheduled maintenance | None |
3. Patch management (getting the fix in)
PCI DSS Req 6.3.3 requires critical patches within one month. SOC 2 doesn't specify timelines but auditors look at your defined SLAs and whether you met them. ISO 27001 says "timely" — your policy sets the definition of timely.
The patch management lifecycle that auditors want to see documented:
- Identification — CVE alert from scanner or vendor advisory
- Assessment — severity classification, affected systems, business impact
- Testing — staging environment test, regression testing, rollback plan
- Deployment — change-controlled production deployment
- Verification — post-patch scan confirming resolution
- Documentation — vulnerability register updated, change record closed
For containerised environments: base image rebuilds are your patch mechanism. Document which base images you use and how often you rebuild. Auditors will ask.
4. Exception and risk acceptance process
Sometimes you can't patch within the SLA — vendor hasn't released a patch, breaking change risk, business-critical system requiring extended maintenance window. That's fine, but you need a documented process:
- Written exception request with business justification
- Risk owner sign-off (Security Lead for High, CISO/CTO for Critical — ideally no exceptions for Critical)
- Compensating controls documented (WAF rule, network segmentation, increased monitoring)
- Expiry date (maximum 90 days for High severity)
- Exception register reviewed quarterly
What a vulnerability register looks like
Your vulnerability register is your audit evidence. At minimum it should contain:
| Field | Example | Why Auditors Care |
|---|---|---|
| Vulnerability ID | VUL-2026-047 | Traceability |
| CVE reference | CVE-2026-12345 | Links to public NVD record |
| Affected system | api-service (Node 18.12.0) | Shows scope |
| Severity | High (CVSS 7.8) | Justifies SLA selection |
| Discovery date | 2026-06-01 | SLA clock start |
| Target remediation | 2026-06-08 | Demonstrates SLA compliance |
| Actual resolution | 2026-06-05 | Proves patched within SLA |
| Resolution method | Patched to Node 18.20.4 | Specific, verifiable action |
| Evidence | PR #847, post-patch scan report | Auditor can verify |
| Verified by | Alex Smith, Security Lead | Accountability |
Key metrics your programme should track
- Mean Time to Remediate (MTTR) by severity — Critical, High, Medium separately
- Open Critical/High count — target: zero Critical open >48h, zero High open >7 days
- SLA compliance rate — % of vulnerabilities remediated within defined timeline (target: >95%)
- Exception rate — % requiring exception/risk acceptance (target: <5%)
- Scanning coverage — % of in-scope assets scanned within cadence (target: 100%)
7 common vulnerability management failures (and what to do instead)
| Failure | Why It's a Problem | Fix |
|---|---|---|
| Scanning only dependencies, not infrastructure | Misses OS CVEs, container base image vulnerabilities, cloud misconfigurations | Add infrastructure and CSPM scanning |
| No documented remediation timelines | Auditors have no SLA to evaluate compliance against | Define and publish SLAs in the policy |
| Scanning but not tracking in a register | No evidence trail — scanner reports ≠ vulnerability programme | Add every finding to a tracked register with owner + deadline |
| No post-patch verification scan | Can't prove the vulnerability was actually resolved | Require a post-remediation scan as standard step |
| Developer closes ticket without deploying fix | "Fixed" in code but not in production — audit evidence shows false compliance | Require deployment + post-scan before closing |
| No exception process — just ignore overdue items | Overdue vulnerabilities with no documentation = immediate audit finding | Formal exception register with compensating controls |
| Annual pen test treated as the whole programme | Pen test is a point-in-time assessment, not ongoing management | Continuous scanning + annual pen test as combined programme |
Generate your Vulnerability Management Policy
A free Vulnerability Management Policy Generator is available that creates a complete policy covering scanning tools, severity classification, remediation timelines, patch management approach, exception process, and compliance framework mappings for SOC 2 CC7.1, ISO 27001 A.8.8, PCI DSS Req 6, NIS2, and NIST SP 800-40.
Related generators: Information Security Policy, Access Control Policy, Incident Response Plan, SOC 2 Gap Assessment, ISO 27001 Gap Assessment.
Related reading: SOC 2 Gap Analysis Before Audit, SOC 2 Evidence Collection Guide, ISO 27001 Gap Assessment Guide, Change Management Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Vulnerability management requirements vary by compliance framework and audit firm interpretation. Engage a qualified information security professional for your specific programme.