Home Compliance & Certification Vulnerability Management Process Guide

Vulnerability Management Process Guide

Last updated on Jan 05, 2026

1. Purpose of This Guide

This guide helps you show that your organisation systematically identifies, prioritises, and fixes security weaknesses, using recognised industry standards. Bugs are normal, ignoring them is not.

This matters because you are expected to:

  • Enforce secure configurations (not defaults)

  • Use industry benchmarks (e.g. CIS, OWASP)

  • Regularly test systems for vulnerabilities

  • Remediate high-risk findings, not just document them

This artefact proves your vulnerability management is:

  • Intentional

  • Risk-based

  • Aligned with recognised security standards, not ad-hoc or reactive.

2. What You Will Submit

You will submit a documented Vulnerability Management Process, which explains how your organisation:

  • Identifies vulnerabilities across systems and applications

  • Uses industry standards to assess risk

  • Prioritises and remediates high-risk vulnerabilities

  • Verifies fixes after remediation

This is process and governance evidence, not raw scan output.

3. How to Collect / Obtain / Generate This Evidence

StrongKeep customers can adapt the provided template. Non-StrongKeep customers can follow the steps below:

Step 1: Define the Standards You Follow

Your document should clearly state that vulnerability management is aligned to recognised benchmarks, for example:

  • CIS Benchmarks for:

    • Desktops

    • Servers

    • Network devices

  • OWASP Top 10 for:

    • Web applications

    • APIs

  • Risk scoring based on:

    • CVSS scores

    • Vendor-provided severity ratings

    • Business impact

You do not need to implement every benchmark in full — you need to show alignment and intent.

Step 2: Explain How Vulnerabilities Are Identified

Describe how vulnerabilities are discovered, such as:

  • Automated vulnerability scanning

  • Security baseline analysis

  • Internet-facing scans (e.g. mail server / web server scans)

  • Penetration testing (periodic or before commissioning)

  • Vendor security advisories

This demonstrates that vulnerabilities are actively looked for, not passively discovered.

Step 3: Describe Risk Assessment and Prioritisation

Your process must explain how vulnerabilities are classified, including:

  • Risk ratings (e.g. Low / Medium / High)

  • Factors considered:

    • Severity (e.g. CVSS score)

    • Exposure (internet-facing vs internal)

    • Impact on availability, confidentiality, integrity

Key requirement:
High-risk vulnerabilities are explicitly prioritised for remediation.

Step 4: Define Remediation Expectations

Your document should clearly state that:

  • High-risk vulnerabilities must be remediated

  • Remediation methods may include:

    • Patching

    • Configuration hardening

    • Feature removal

    • Compensating controls

  • Fixes are applied:

    • Before production use (where applicable)

    • After major changes

    • On a periodic basis

This is a core requirement — auditors look for this explicitly.

Step 5: Verification and Follow-Up

Explain how fixes are confirmed, such as:

  • Re-scanning after remediation

  • Validation checks

  • Tracking status (open / mitigated / resolved)

Optional but strong:

  • Reference to a risk register

  • Reference to security testing reports

4. Evidence Format

Accepted file types

  • PDF

  • DOCX

Suggested naming format
YourCompanyName_VulnerabilityManagement_Process_Date

Example
AcmePteLtd_VulnerabilityManagement_Process_2025-07-01.pdf

5. What “Good” Looks Like

Your evidence is strong if it shows:

  • Visible element: Reference to CIS benchmarks and/or OWASP Top 10
    Why it matters: Demonstrates industry-aligned secure configuration

  • Visible element: Defined process for identifying vulnerabilities
    Why it matters: Shows proactive security posture

  • Visible element: Clear prioritisation of high-risk issues
    Why it matters: Meets mandatory remediation expectations

  • Visible element: Verification after fixes
    Why it matters: Confirms vulnerabilities are actually resolved

6. Tips from Sir Stonk 🛡️

  • You don’t need perfect CIS compliance — you need reasonable, documented alignment.

  • Say the words “High-risk vulnerabilities are remediated.” Auditors look for that exact intent.

Secure configuration isn’t about being flawless.
It’s about knowing where the cracks are — and fixing the dangerous ones first.