Vulnerability Management Process Template

Overview

A vulnerability management process defines how an organization discovers, triages, prioritizes, remediates, and verifies vulnerabilities across its infrastructure and applications. It establishes scanning schedules, severity thresholds, remediation SLAs, and reporting procedures. Without a defined process, vulnerabilities accumulate and become exploitable attack vectors.

When to Use

• For alternatives, see Penetration Test Report Template.

• Establishing vulnerability management for a new organization

• Preparing for compliance audits (SOC 2, ISO 27001, PCI-DSS)

• Standardizing vulnerability handling across teams

• Defining remediation SLAs and accountability

• Setting up automated vulnerability scanning in CI/CD

Solution

# Vulnerability Management Process — `<Organization Name>`

## Process Overview

| Field | Value |
|-------|-------|
| Organization | Example Corp |
| Process Version | 2.0 |
| Last Updated | 2026-07-05 |
| Process Owner | Security Team |
| Approved By | CISO |
| Review Cycle | Quarterly |
| Next Review | 2026-10-05 |
| Compliance Frameworks | SOC 2, ISO 27001, PCI-DSS |
| Scanning Tools | Trivy, Snyk, Nessus, GitLeaks |
| Ticketing System | Jira |

## 1. Vulnerability Discovery

### Scanning Schedule

| Asset Type | Tool | Frequency | Scope | Owner |
|------------|------|-----------|-------|-------|
| Container images | Trivy | Every build (CI) | All images | DevOps |
| Application dependencies | Snyk | Every PR + daily | All repos | Developers |
| Infrastructure (cloud) | Prowler | Weekly | All cloud accounts | Security |
| Network (hosts) | Nessus | Weekly | All subnets | Security |
| Kubernetes clusters | kube-bench | Weekly | All clusters | DevOps |
| Source code | GitLeaks + Semgrep | Every PR | All repos | Developers |
| Secrets in code | GitLeaks | Every PR + nightly | All repos | Security |
| SSL/TLS certificates | SSLyze | Daily | All endpoints | DevOps |
| DNS configuration | DNSRecon | Weekly | All domains | Security |
| Web applications | OWASP ZAP | Weekly + on release | Production URLs | Security |

### Scan Configuration

| Tool | Configuration | Threshold | Fail Build? |
|------|--------------|-----------|-------------|
| Trivy | `--severity CRITICAL,HIGH` | 0 critical, 0 high | Yes |
| Snyk | `--severity-threshold=high` | 0 high | Yes (on PR) |
| Nessus | Credential scan, full policy | All CVEs | N/A (report) |
| GitLeaks | All patterns, custom rules | 0 findings | Yes |
| Semgrep | Custom rules + default | 0 high | Yes (on PR) |
| Prowler | CIS benchmarks | All checks | N/A (report) |
| kube-bench | CIS Kubernetes benchmark | All checks | N/A (report) |

### Asset Inventory

| Asset Category | Inventory Source | Update Frequency | Owner |
|----------------|-----------------|------------------|-------|
| Cloud resources | AWS Config | Real-time | DevOps |
| Kubernetes resources | kubectl + cluster API | Real-time | DevOps |
| Container images | Container registry | On push | DevOps |
| Source code repos | GitHub API | On creation | Engineering |
| Dependencies | Lockfile analysis | On commit | Developers |
| SSL certificates | ACM + external | Daily | DevOps |
| DNS records | Route53 + external | Daily | DevOps |
| Third-party services | Manual registry | Quarterly | Security |

## 2. Vulnerability Triage

### CVSS Scoring

| CVSS Score | Severity | Color | Action |
|------------|----------|-------|--------|
| 9.0 - 10.0 | Critical | Red | Immediate remediation |
| 7.0 - 8.9 | High | Orange | Remediate within SLA |
| 4.0 - 6.9 | Medium | Yellow | Remediate within SLA |
| 0.1 - 3.9 | Low | Blue | Track, remediate opportunistically |
| 0.0 | None | Green | No action needed |

### Triage Criteria

| Factor | Question | Weight |
|--------|----------|--------|
| CVSS score | What is the base CVSS score? | 40% |
| Exploitability | Is a public exploit available? | 25% |
| Exposure | Is the affected service internet-facing? | 15% |
| Data sensitivity | Does the vulnerability expose PII/PHI? | 10% |
| Business impact | What is the business impact of exploitation? | 10% |

### Triage Decision Matrix

| CVSS | Public Exploit | Internet-Facing | PII Exposure | Final Severity |
|------|---------------|-----------------|--------------|----------------|
| Critical | Yes | Yes | Yes | Critical (SEV-0) |
| Critical | Yes | Yes | No | Critical (SEV-0) |
| Critical | No | Yes | Yes | High (SEV-1) |
| High | Yes | Yes | No | High (SEV-1) |
| High | No | No | No | Medium (SEV-2) |
| Medium | Yes | Yes | No | Medium (SEV-2) |
| Medium | No | No | No | Low (SEV-3) |
| Low | No | No | No | Low (SEV-4) |

### Triage Process

| Step | Action | Responsible | SLA |
|------|--------|-------------|-----|
| 1 | Scan completes and findings ingested | Automated | Immediate |
| 2 | Deduplicate against existing tickets | Automated | Immediate |
| 3 | Apply triage criteria | Security Analyst | 24 hours |
| 4 | Assign final severity | Security Analyst | 24 hours |
| 5 | Create remediation ticket | Automated (Jira) | Immediate |
| 6 | Assign to asset owner | Security Analyst | 24 hours |
| 7 | Notify owner | Automated (Slack) | Immediate |

## 3. Remediation SLAs

### SLA by Severity

| Severity | Remediation SLA | Exception Process | Reporting |
|----------|----------------|-------------------|-----------|
| Critical (SEV-0) | 24 hours | CISO approval required | Daily until resolved |
| High (SEV-1) | 7 days | Manager + Security approval | Weekly |
| Medium (SEV-2) | 30 days | Manager approval | Monthly |
| Low (SEV-3) | 90 days | Track in backlog | Quarterly |
| Informational (SEV-4) | No SLA | N/A | Quarterly |

### SLA by Context

| Context | Critical | High | Medium | Low |
|---------|----------|------|--------|-----|
| Internet-facing production | 24 hours | 3 days | 14 days | 60 days |
| Internal production | 48 hours | 7 days | 30 days | 90 days |
| Staging environment | 7 days | 14 days | 60 days | 180 days |
| Development environment | 14 days | 30 days | 90 days | 180 days |
| End-of-life systems | 24 hours | 7 days | N/A | N/A |

### Remediation Methods

| Method | When to Use | Example | Verification |
|--------|-------------|---------|--------------|
| Patch | Vendor patch available | Update package to fixed version | Re-scan, verify version |
| Configuration change | Misconfiguration | Disable vulnerable protocol | Re-scan, verify config |
| Code fix | Custom code vulnerability | Fix in source code | SAST scan, code review |
| Compensating control | No patch available | WAF rule to block exploit | Penetration test |
| Risk acceptance | Low risk, high cost to fix | Document and accept | Risk acceptance form |
| Decommission | System no longer needed | Remove vulnerable system | Verify removal |

### Exception Process

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Document exception request | Asset Owner | 1 day |
| 2 | Describe compensating controls | Asset Owner | 1 day |
| 3 | Specify expiration date | Asset Owner | — |
| 4 | Security review | Security Team | 3 days |
| 5 | Risk acceptance sign-off | CISO (critical/high) or Manager (medium) | 2 days |
| 6 | Record exception | Security Team | 1 day |
| 7 | Track exception to expiration | Security Team | Ongoing |
| 8 | Re-review at expiration | Security Team | At expiry |

## 4. Remediation Workflow

### Standard Remediation

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Receive vulnerability ticket | Asset Owner | Within SLA |
| 2 | Investigate affected component | Asset Owner | 1-4 hours |
| 3 | Identify remediation method | Asset Owner | 1-4 hours |
| 4 | Implement fix | Asset Owner | Per SLA |
| 5 | Test fix in staging | Asset Owner | 1-2 hours |
| 6 | Deploy to production | Asset Owner | Per deployment process |
| 7 | Verify remediation | Security Team | 24 hours |
| 8 | Close ticket | Security Team | 24 hours |

### Emergency Remediation (Critical)

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Receive critical vulnerability alert | On-call Engineer | Immediate |
| 2 | Page security team | Automated | Immediate |
| 3 | Assess impact | On-call + Security | 30 min |
| 4 | Implement immediate mitigation | On-call Engineer | 1-4 hours |
| 5 | Deploy permanent fix | Engineering Team | Within 24 hours |
| 6 | Verify remediation | Security Team | 24 hours |
| 7 | Post-remediation review | Security Team | 3 days |
| 8 | Update detection rules | Security Team | 3 days |

### Dependency Upgrade Process

| Scenario | Approach | Risk | Verification |
|----------|----------|------|--------------|
| Patch version (x.y.Z) | Auto-update in CI | Low | Run tests |
| Minor version (x.Y.z) | Update after test pass | Medium | Full test suite + staging |
| Major version (X.y.z) | Manual review + migration | High | Migration plan + full QA |
| Breaking change | Evaluate alternatives | High | Migration + penetration test |
| No patch available | Compensating control | N/A | WAF rule + monitoring |

## 5. Verification

### Verification Methods

| Method | When to Use | Tool | Pass Criteria |
|--------|-------------|------|---------------|
| Re-scan | After patch or config change | Original scan tool | 0 findings for target CVE |
| Version check | After package update | Package manager | Version >= fixed version |
| Configuration check | After config change | Audit script | Config matches expected state |
| Penetration test | After major remediation | External tester | No exploitation possible |
| Code review | After code fix | Senior developer | Fix addresses root cause |
| Automated test | After code fix | SAST/DAST | 0 findings for target rule |

### Verification Checklist

| Check | Method | Responsible | Status |
|-------|--------|-------------|--------|
| Vulnerability no longer detected | Re-scan | Security | ✅/❌ |
| Fixed version deployed | Version check | DevOps | ✅/❌ |
| No regression introduced | Test suite | Developer | ✅/❌ |
| No new vulnerabilities introduced | Full scan | Security | ✅/❌ |
| Configuration documented | Wiki update | Developer | ✅/❌ |
| Ticket updated with evidence | Jira | Developer | ✅/❌ |

## 6. Reporting and Metrics

### Vulnerability Dashboard

| Metric | Target | Current | Trend |
|--------|--------|---------|-------|
| Total open vulnerabilities | < 50 | 32 | ↓ |
| Critical vulnerabilities (open) | 0 | 0 | ✅ |
| High vulnerabilities (open) | < 5 | 3 | ↓ |
| Medium vulnerabilities (open) | < 20 | 15 | ↓ |
| Low vulnerabilities (open) | < 30 | 14 | ↓ |
| SLA compliance rate | > 95% | 97% | ✅ |
| Mean time to remediate (critical) | < 24 hours | 18 hours | ✅ |
| Mean time to remediate (high) | < 7 days | 5.2 days | ✅ |
| Exceptions active | < 10 | 4 | ✅ |
| Exceptions expiring soon | 0 | 0 | ✅ |

### Reporting Schedule

| Report | Audience | Frequency | Content |
|--------|----------|-----------|---------|
| Executive summary | C-suite | Monthly | Risk posture, trends, SLA compliance |
| Technical report | Engineering leads | Weekly | Open vulnerabilities by team, SLA status |
| Compliance report | Auditors | Quarterly | Remediation evidence, exception log |
| Board report | Board of Directors | Quarterly | High-level risk posture, major findings |
| Team scorecard | Team managers | Monthly | Team-specific remediation performance |

### Vulnerability Trends

| Month | New Findings | Remediated | Net Change | Open Total |
|-------|-------------|------------|------------|------------|
| Jan 2026 | 45 | 52 | -7 | 38 |
| Feb 2026 | 38 | 41 | -3 | 35 |
| Mar 2026 | 42 | 47 | -5 | 30 |
| Apr 2026 | 35 | 38 | -3 | 27 |
| May 2026 | 40 | 36 | +4 | 31 |
| Jun 2026 | 37 | 36 | -1 | 30 |

## 7. Integration with CI/CD

### Pipeline Security Gates

| Stage | Tool | Gate Criteria | Fail Action |
|-------|------|---------------|-------------|
| Commit | GitLeaks | 0 secrets found | Block commit |
| PR (SAST) | Semgrep | 0 high findings | Block merge |
| PR (deps) | Snyk | 0 critical/high | Block merge |
| Build (container) | Trivy | 0 critical/high | Block build |
| Build (IaC) | tfsec | 0 high findings | Block build |
| Deploy (config) | kube-bench | CIS compliance | Warn (don't block) |
| Post-deploy | OWASP ZAP | 0 high findings | Alert security team |

### CI/CD Configuration

```yaml
# GitHub Actions security scanning workflow
name: Security Scans
on: [push, pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1

  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Snyk test
        uses: snyk/actions/node@master
        with:
          severity-threshold: high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: GitLeaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

## Explanation

A vulnerability management process has five stages: discovery, triage, remediation, verification, and reporting. Each stage has specific tools, criteria, and responsibilities. The process runs continuously — new vulnerabilities are discovered daily as new CVEs are published and new scans run.

Discovery uses automated scanning tools. Container images are scanned on every build with Trivy. Dependencies are checked on every PR with Snyk. Infrastructure is scanned weekly with Nessus and Prowler. Source code is scanned for secrets with GitLeaks and for code vulnerabilities with Semgrep. The scanning schedule balances coverage with scan cost — daily scans for high-value targets, weekly for internal infrastructure.

Triage prioritizes vulnerabilities based on more than just CVSS scores. A critical vulnerability with a public exploit on an internet-facing service is more urgent than a critical vulnerability on an internal-only system with no exploit available. The triage criteria combine CVSS score, exploitability, exposure, data sensitivity, and business impact into a final severity rating.

Remediation SLAs enforce timely fixes. Critical vulnerabilities must be remediated within 24 hours. High within 7 days. Medium within 30 days. Low within 90 days. SLAs are tighter for internet-facing production systems and looser for development environments. Exceptions require documented compensating controls and management approval with an expiration date.

The remediation workflow ensures fixes are tested before deployment. A patch is applied in staging, tested, then deployed to production. Emergency remediation for critical vulnerabilities follows an expedited path with immediate mitigation followed by a permanent fix within 24 hours. Dependency upgrades are categorized by version change severity — patch versions can be auto-updated, major versions require migration planning.

Verification confirms the fix worked. Re-scanning with the original tool confirms the vulnerability is no longer detected. Version checks confirm the fixed version is deployed. Test suites confirm no regressions. Without verification, remediation tickets can be closed while the vulnerability persists — the fix didn't work or wasn't deployed correctly.

Reporting provides visibility into the vulnerability posture. Executive summaries show risk trends for the C-suite. Technical reports show open vulnerabilities by team for engineering leads. Compliance reports provide evidence for auditors. Metrics track SLA compliance, mean time to remediate, and vulnerability trends over time.

CI/CD integration prevents vulnerabilities from reaching production. Security gates block builds with critical or high vulnerabilities. Secret scanning blocks commits with leaked credentials. SAST blocks merges with high-severity code findings. Container scanning blocks builds with vulnerable images. These gates shift vulnerability detection left — catching issues before deployment rather than after.

## Variants

| Context | Approach | Notes |
|---------|----------|-------|
| Startup | Focus on CI/CD scanning, manual triage | Trivy + Snyk + GitLeaks |
| Enterprise | Full process with dedicated team | All tools, automated triage, SLA tracking |
| Healthcare | Add PHI-specific scanning | HIPAA compliance checks, PHI data discovery |
| Financial | Add PCI-DSS scanning | ASV scans, PCI-specific remediation SLAs |
| Cloud-native | Focus on container and IaC scanning | Trivy, tfsec, kube-bench |
| Air-gapped | Offline scanning tools | Nessus offline, local CVE database |

## What Works

1. Automate scanning in CI/CD — catch vulnerabilities before deployment
2. Use CVSS as a baseline, not the only factor — context matters
3. Enforce SLAs with reporting — what gets measured gets done
4. Block builds on critical/high — shift security left
5. Verify remediation with re-scans — don't trust, verify
6. Track exceptions with expiration dates — exceptions shouldn't be permanent
7. Report regularly to executives — visibility drives investment in security

## Common Mistakes

1. Scanning but not remediating — scan reports sit unread
2. No SLA enforcement — vulnerabilities stay open indefinitely
3. CVSS-only prioritization — ignores exploitability and exposure context
4. No CI/CD gates — vulnerable code reaches production
5. No verification — fixes assumed but not confirmed
6. Exceptions without expiration — temporary exceptions become permanent
7. No asset inventory — can't scan what you don't know about

## Frequently Asked Questions

### How do we handle vulnerabilities with no available patch?

Use compensating controls. If the vulnerability is in a library with no fix, implement a WAF rule to block the exploit vector. If it's a configuration issue, change the configuration. If it's a protocol vulnerability, disable the protocol. Document the compensating control, its effectiveness, and an expiration date for when the exception will be re-evaluated. Track it as a risk acceptance with management approval.

### What is the difference between vulnerability management and patch management?

Patch management is a subset of vulnerability management. Patch management focuses on applying vendor patches to software and systems. Vulnerability management is broader: it includes patching, but also configuration changes, code fixes, compensating controls, and risk acceptance. Not all vulnerabilities have patches — some require configuration changes or code fixes.

### Should we scan production or just staging?

Both. Staging scans catch vulnerabilities before they reach production. Production scans catch vulnerabilities that were missed or introduced after deployment (e.g., a new CVE published for an already-deployed dependency). Production scans should be non-intrusive (credential scans, not exploit scans). Use staging for intrusive testing (penetration tests, DAST scans).

### How do we prioritize when we have hundreds of vulnerabilities?

Start with critical and high severity vulnerabilities on internet-facing systems. These are the most likely to be exploited. Next, address vulnerabilities with public exploits regardless of severity. Then, work through medium severity by asset importance. Low severity vulnerabilities can be batched and addressed during maintenance windows. Use the triage criteria to rank within each severity level.

### How do we handle false positives?

Document the false positive with evidence (why it's a false positive, what was verified). Mark the finding as a false positive in the scanning tool to prevent it from reappearing. If the same false positive recurs, tune the scanner rules to exclude it. Track false positive rates per tool — if a tool has a high false positive rate (> 10%), consider replacing it or adjusting its configuration.