Risk Treatment vs. Vulnerability Management: Why Your Patching Strategy Is Wrong

TL;DR

Vulnerability management says “patch the critical CVEs first.” Risk treatment says “which vulnerabilities matter to this asset, in this environment, with this data, and what’s the cheapest way to reduce the risk?” They agree on about 30% of decisions. The other 70% is where the arguments happen — and where real risk reduction gets missed because the patching queue doesn’t know about business context.

The two queues

Every security team has a vulnerability queue. It looks like this:

This queue is ordered by CVSS score. It’s also ordered by nothing else. It tells you nothing about whether any of these CVEs actually affect your infrastructure, whether the exploit is in the wild, whether patching one breaks production, or whether a compensating control makes the patch optional.

Risk treatment starts with the same CVEs but asks different questions:

The order changed. CVE-2026-85706 moved to top not because it has the highest CVSS — it ties with CVE-2026-19490. It moved to top because it’s actively exploited (KEV), affects a critical asset (GitLab), and has a WAF rule that reduces but doesn’t eliminate risk.

The items that moved down? CVE-2026-19490 (NetScaler decommissioned — highest CVSS, lowest priority) and CVE-2026-42018 (Artifactory on unaffected version).

How risk treatment works

ISO 27001 Clause 6.1.2 and A.5.23 describe risk treatment as one of three phases in the risk management cycle:

1. Risk Assessment — Identify assets, threats, vulnerabilities, and calculate risk (likelihood × impact)
2. Risk Treatment — Select controls to modify the risk to an acceptable level
3. Risk Acceptance/Residual Risk — Document what’s left and who owns it

Vulnerability management sits inside phase 1 (assessment) and partly phase 2 (treatment via patching). But treating the vulnerability queue as the entire risk treatment plan misses the other treatment options:

A vulnerability queue only captures “fix.” Real risk treatment uses all five options.

The decision matrix

Here’s the framework I use when deciding what goes into the patching queue versus what gets a compensating control:

                    High Impact
                      │
          ┌───────────┼───────────┐
          │           │           │
          │  FIX      │  FIX      │
          │  (critical│ (high CVSS│
          │   assets) │  + KEV)   │
    ──────┼───────────┼───────────┼─────
          │  MITIGATE │  ACCEPT   │
          │  (compens.│ (low risk │
          │   control)│  or narrow│
          │           │  exploit) │
          └───────────┼───────────┘
                      │
                  Low Impact
                  Low ←──────→ High Likelihood

Fix (top-left): Highest impact and highest likelihood. Patch immediately. This is the 20–30% of CVEs where vulnerability management and risk treatment agree.

Mitigate (bottom-left): High impact, medium/low likelihood. Compensating controls reduce the likelihood enough that immediate patching isn’t required. A WAF rule, network segmentation, or configuration change that blocks the exploit path.

Accept (bottom-right): Low impact, low likelihood. The CVE affects a component with minimal exposure or the exploit requires a rare configuration. Document the acceptance, set a review date, move on.

Avoid (implicit): If you can remove the vulnerable component entirely, that’s better than patching. Decommissioning the old NetScaler was avoidance — better than the mitigation of updating it.

Real example: this week’s CVEs

Using the KEV data from this week’s RSS feed:

CVE-2026-85706 (GitLab path traversal) — KEV’d, CVSS 9.8, ransomware exploitation observed.

• Impact: High (source code access on GitLab EE)
• Likelihood: High (actively exploited, public exploit)
• Treatment: Fix — patch GitLab to patched version. WAF rule mitigates during patch window.

CVE-2026-53266 (Linux ebtables SNAT OOB write) — KEV’d, CVSS 8.8, ransomware exploitation observed.

• Impact: High (kernel memory corruption)
• Likelihood: Medium (ebtables with SNAT rules on bridges is a specific config)
• Treatment: Fix — kernel update is standard. But prioritize by which hosts actually use ebtables SNAT. Hosts without that config can accept for the next patch cycle.

CVE-2026-19490 (Citrix NetScaler auth bypass) — KEV’d, CVSS 9.8, ransomware exploitation observed.

• Impact: High (admin panel access)
• Likelihood: High (actively exploited)
• Treatment: Fix — but only on NetScaler instances still in use. The decommissioned ones are “avoid.”

CVE-2026-42016 (JFrog Artifactory auth bypass) — KEV’d, CVSS 8.1.

• Impact: Medium ( Artifactory repos)
• Likelihood: Medium (publicly accessible Artifactory instances)
• Treatment: Mitigate — auth proxy in front of Artifactory blocks the exploit path. Patch during next maintenance window.

CVE-2026-42018 (JFrog Artifactory RCE) — KEV’d, CVSS 8.8.

• Impact: Medium–High
• Likelihood: Medium–High
• Treatment: Fix — patch immediately. If the auth proxy blocks the affected endpoint, downgrade to mitigate.

How vulnerability management feeds risk treatment

A good vulnerability management program doesn’t stop at CVSS ordering. It feeds the risk treatment process with:

1. Asset correlation — Which CVEs affect which assets? A CVSS 9.8 on an obscure internal tool may be lower priority than a CVSS 7.0 on a customer-facing API.

2. KEV status — Is the vulnerability in CISA’s catalog? Is it actively exploited by ransomware? This is the single strongest signal for likelihood.

3. Exploit availability — Public exploit, Metasploit module, commercial exploit, or only in the lab? Each level changes the likelihood estimate.

4. Compensating controls — What’s already in place? WAF rules, network segmentation, auth proxies, feature flags. Document them. They change the treatment decision.

5. Patch risk — Will the patch break something? Staging validation, rollback procedures, maintenance windows. High patch risk may mean mitigate-first.

6. Business context — Is the affected asset revenue-generating? Does it hold PII? Is it internet-facing? This changes the impact calculation.

The risk treatment plan

ISO 27001 requires a documented Risk Treatment Plan (RTP). It’s not a spreadsheet. It’s a living document that says:

• Which risks we’re treating and which we’re accepting
• Which controls address each risk
• Which treatment option we chose and why
• Who owns each residual risk
• When we review accepted risks

The RTP should include vulnerability-related risks but not only vulnerability-related risks. A typical RTP covers:

The vulnerability queue feeds one row of a much bigger table.

Common mistakes

Mistake 1: CVSS is risk. CVSS measures technical severity, not business risk. A CVSS 9.8 on a decommissioned product is zero risk. A CVSS 4.0 on a customer-facing payment API might be the highest priority in the queue.

Mistake 2: Patch everything. “Fix” isn’t always the right treatment. Sometimes a compensating control is faster, cheaper, and more reliable than a patch. Sometimes acceptance is fine. Sometimes avoidance (decommission) is best. Patching everything means you patch the wrong things first.

Mistake 3: No documented acceptance. Every CVE that doesn’t get patched has a treatment decision. If you didn’t decide, the risk is accepted by default. Document the decision, set a review date, and actually review it.

Mistake 4: Treating the RTP as a one-time document. The risk treatment plan should be reviewed quarterly — at minimum. New CVEs change likelihood. New assets change impact. Compensating controls get removed. The RTP should reflect the current state, not the state from your last audit.

Mistake 5: No ownership. Every residual risk needs an owner. Not “the security team.” Not “IT.” A specific person. When the risk triggers, they’re the one who gets called.

Building a risk-driven patching queue

Here’s a practical pattern for turning your vulnerability queue into a risk-driven one:

# Pseudocode for risk-driven prioritization
for cve in vulnerability_scan:
    asset = find_asset_affected(cve)
    if not asset:
        treat_as = "accept"  # not in scope
        continue

    likelihood = calculate_likelihood(
        cvss=cve.cvss,
        in_kev=cve.in_kev,
        exploit_available=cve.exploit_available,
        asset.internet_facing,
        asset.exposure_level,
    )

    impact = calculate_impact(
        asset.criticality,
        asset.data_sensitivity,
        cve.impact_type,  # confidentiality/integrity/availability
    )

    risk_score = likelihood * impact
    compensating = find_compensating_controls(asset, cve)

    if compensating:
        residual_risk = risk_score * compensating.efficacy
        if residual_risk < threshold:
            treat_as = "mitigate"
        else:
            treat_as = "fix"
    else:
        if risk_score > critical_threshold:
            treat_as = "fix"
        elif risk_score > medium_threshold:
            treat_as = "fix"  # or mitigate if patch risk is high
        else:
            treat_as = "accept"

    record_risk_treatment(cve, asset, treat_as, risk_score)

The output isn’t just a prioritized list. It’s a treatment decision for each CVE with a reason:

• CVE-2026-85706: FIX — likelihood 0.85, impact 0.92, risk 0.78 > critical threshold
• CVE-2026-53266: FIX — likelihood 0.62, impact 0.88, risk 0.55 > medium threshold
• CVE-2026-42016: MITIGATE — likelihood 0.45, impact 0.65, risk 0.29; WAF rule efficacy 0.75 → residual 0.07 < accept threshold
• CVE-2026-19490: ACCEPT — likelihood 0.12, impact 0.72, risk 0.09 < accept threshold (NetScaler decommissioned)

The connection to ISO 27001

ISO 27001:2022 doesn’t prescribe how to prioritize CVEs. It requires:

• A.8.8 (Management of technical vulnerabilities): “Information on security vulnerabilities shall be routinely obtained, the resulting risks evaluated and appropriate remediation plans implemented.”
• Clause 6.1.2 (Risk assessment): Risks shall be identified and assessed.
• Clause 6.1.3 (Risk treatment): Risk treatment plan shall be developed and maintained.
• A.5.23 (Information security during disruption) — not directly about vulns, but the treatment plan feeds into disruption planning.

A.8.8 is where vulnerability management lives in the standard. The management of technical vulnerabilities. But the treatment decisions — fix, mitigate, accept, avoid — come from the risk treatment plan at the Clause 6.1.3 level.

Your vulnerability management tool produces the input. Your risk treatment plan produces the output. Most teams confuse the two tools and skip the treatment step.

What to do next

If your patching queue is just a CVSS-sorted CVE list:

1. Add asset correlation. Which CVEs affect which assets? Use your CMDB or a manual mapping if you don’t have one.

2. Check KEV status. Add a column for “in CISA KEV” and “in ransomware exploit chains.”

3. Document compensating controls. WAF rules, auth proxies, network segmentation. Know what’s already reducing risk.

4. Build a simple decision matrix. Likelihood (low/medium/high) × Impact (low/medium/high) → Fix/Mitigate/Accept. Start simple.

5. Write down your treatment decisions. For every CVE that isn’t being patched, write why. Accept, mitigate, avoid. Set review dates for accepted risks.

6. Review quarterly. New CVEs, new assets, new controls. Update the RTP.

The difference between a vulnerability queue and a risk treatment plan is the difference between “here’s a list of broken things” and “here’s what we’re doing about them, in order, and why.”

Further Reading

• ISO 27001:2022 Clause 6.1.3 — Risk treatment plan requirements
• ISO 27001:2022 A.8.8 — Management of technical vulnerabilities
• CISA KEV Catalog — Known exploited vulnerabilities
• First.org EPSS — Exploit Prediction Scoring System
• NIST SP 800-37 Rev. 2 — Risk Management Framework (USG reference, widely applicable)
• BOD 26-04 — Federal vulnerability prioritization built on KEV