SOC 2 Vulnerability Risk Acceptance: What to Do When There Is No Vendor Fix

A typical case: a scanner flags a high-severity CVE in an Ubuntu package, the remediation SLA in the vulnerability management policy is 30 days, and on day 31 the Ubuntu tracker still shows Vulnerable, fix deferred. The SOC 2 answer is vulnerability risk acceptance: a dated, approved record that names the CVE, the asset, the exploitability, the compensating controls, the owner and an expiry date, entered in the risk register before the SLA runs out.

Why a Missed Remediation SLA Becomes a SOC 2 Exception

A missed remediation SLA becomes a SOC 2 exception when the auditor finds an open finding past its deadline with no approved record explaining it. The CC7.1 point of focus Conducts Vulnerability Scans asks the entity to scan periodically and after significant changes, and says: Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity's objectives. The company's own policy defines timely, so the auditor tests against the SLA the company wrote.

In one bare-metal SaaS company running Ubuntu LTS on its own servers, the scanner reported a handful of CVEs where Ubuntu had marked the fix as deferred, and a few more where the fix was only available through Ubuntu Pro. The team had no way to patch the first group and had not decided on the second. By the time anyone looked, the 30-day SLA had passed on all of them, and the auditor would see every one in the scan exports.

Each of those findings needed a documented decision. The guide to SOC 2 vulnerability scanning on-prem covers scan coverage and SLA tiers; this post covers the findings that can't meet the SLA.

How to Tell a Missing Fix From a Fix That Requires Ubuntu Pro

The Ubuntu CVE page for the package and release tells you which case you are in, and the two cases need different decisions. Scanners report the CVE against a package version, so check the distribution's tracker before treating a finding as unfixable. Ubuntu lists the package version that contains the fix, which may differ from the upstream version the scanner expects.

On an attached machine, pro fix CVE-YYYY-NNNNN reports the same thing from the host. When the fix sits in ESM, its output includes A fix is available in Ubuntu Pro: ESM Infra.

The Available with Ubuntu Pro. case comes up often on bare metal. Standard LTS security support covers the main repository. Ubuntu Pro adds esm-apps for the universe repository and esm-infra for main after standard support ends, so a utility installed from universe can have a fix only Pro subscribers receive.

What a SOC 2 Vulnerability Risk Acceptance Record Contains

A SOC 2 vulnerability risk acceptance record contains enough detail for an auditor to confirm the risk was understood, reduced where possible, approved by the right person and reviewed on time. Keep one record per CVE per asset group, in a ticket or the risk register.

The exploitability field needs more than the CVSS score. FIRST's CVSS v4.0 user guide states that CVSS Base scores measure severity and should not be used alone to assess risk. EPSS estimates the probability that a CVE will be exploited in the next 30 days and is updated daily, so record the score with the date you checked it.

The SOC 2 patch management guide for on-prem covers exception tickets for whole systems that can't take a patch, such as appliances and legacy hosts.

Rules for Accepting Vulnerability Risk Under SOC 2

The rules for vulnerability risk acceptance belong in the vulnerability management policy, so every acceptance follows the same limits. A workable set:

1. Never accept a KEV-listed vulnerability without compensating controls. CISA adds a CVE to the KEV catalog when there is reliable evidence of exploitation in the wild, and urges all organizations to address KEV vulnerabilities as part of their vulnerability management plan. KEV entries require a clear remediation action, such as a vendor update, so a KEV-listed CVE on Ubuntu usually has a fix somewhere: upstream, in a newer release, or in ESM. Chase it.
2. Set the expiry by residual risk. For example: 30 days for high residual risk, 90 days for medium, 180 days for low. No acceptance is open-ended.
3. Approve before the SLA expires. An acceptance approved after the deadline still records a missed SLA. Raise it as soon as the tracker shows the fix won't arrive in time.
4. Match the approver to the risk. The engineering lead can approve low residual risk; the CTO or risk owner approves high residual risk and anything internet-facing.
5. Recheck at every review date. Look at the tracker, KEV and EPSS again. Close the record when a fix ships, then patch within the normal SLA.

Compensating Controls for Vulnerabilities With No Vendor Fix

Compensating controls for a vulnerability with no vendor fix reduce the chance an attacker can reach or trigger the vulnerable code. Pick controls that match how the CVE is exploited, and keep evidence that each one is in place.

• Network exposure. Remove the attack path: bind the service to localhost or an internal interface, restrict the port with host and edge firewall rules, or move the host to a segment the internet can't reach. Evidence: the firewall rule and an external scan showing the port closed.
• Disable the vulnerable module or feature. Many CVEs sit in an optional component: a web server module, a protocol handler, a kernel module the host doesn't load. Disable it in configuration or block it from loading, then confirm the scanner or a config check shows it off.
• Remove the package. If nothing depends on it, uninstalling the package closes the finding outright. This is often the answer for universe utilities installed once and forgotten.
• WAF or reverse proxy rule. For web-facing services, a rule that blocks the known exploit request reduces exposure while the fix is pending. Record the rule ID and test that it blocks a sample request.
• Extra monitoring. Alerting on the affected service helps detection. Pair it with one of the controls above, since monitoring alone leaves the attack path open.

How Vulnerability Risk Acceptance Maps to SOC 2 Criteria

Vulnerability risk acceptance maps mainly to CC7.1 and CC3.2, with CC9.1 relevant where the vulnerability could disrupt the service.

Auditors map controls differently, so confirm at the planning meeting which criterion your auditor tests vulnerability exceptions under. The SOC 2 risk management guide for hybrid and on-prem environments covers how the risk register and risk assessment fit together.

What SOC 2 Auditors Sample for Vulnerability Risk Acceptance

SOC 2 auditors sample vulnerability findings from scan reports across the observation period and check each one against the policy. In our experience, a Type 2 sample usually includes:

• Findings past their SLA. For each, the auditor asks for proof of the fix or an approved acceptance record dated before the deadline.
• The acceptance record itself. Approver, approval date, expiry date and compensating controls, checked against the fields the policy requires.
• Expired acceptances. An acceptance whose review date passed without a recheck counts as an open finding with no approval.
• Evidence of compensating controls. The firewall rule, the disabled module, the WAF rule, captured during the period.
• The risk register. Each accepted vulnerability appears there with the same owner and expiry as the ticket.

The guide to SOC 2 evidence collection on-prem covers capturing dated evidence from systems a GRC platform can't read.

Keeping Accepted Vulnerabilities in the SOC 2 Risk Register

Accepted vulnerabilities belong in the risk register so the risk owner and management see them alongside every other accepted risk. A register entry can summarize several CVEs that share an asset and a compensating control, as long as it links to each ticket.

Review the accepted vulnerabilities at each risk review, at least quarterly. Check three things: which records expire before the next review, which now have a fix in the tracker, and whether any CVE has moved onto the KEV catalog. A register with ten open acceptances and a dated review history is stronger audit evidence than a scan report with ten silent findings.

SOC 2 Vulnerability Risk Acceptance Comes Down to Deciding Before the Deadline

SOC 2 vulnerability risk acceptance turns an unfixable finding into a documented decision an auditor can test. Check the Ubuntu tracker, separate no fix from paid fix, put compensating controls in place, and get approval before the SLA passes. The SOC 2 for bare metal and on-prem infrastructure page lists the other controls that change when you run your own servers.

Related Guides

• Datadog for SOC 2 Vulnerability Scanning: Datadog vs Wazuh vs Nessus On-Prem
• SOC 2 Automatic Patching: Do Unattended Security Updates Need a Change Ticket?

Frequently Asked Questions

Can you accept a vulnerability risk for SOC 2?

Yes. CC3.2 includes deciding whether to accept, avoid, reduce or share a risk. For a vulnerability, SOC 2 auditors expect a documented acceptance record that names the CVE, asset, exploitability, compensating controls, owner, expiry date and approver, approved before the remediation SLA expires and entered in the risk register.

What does fix deferred mean on the Ubuntu CVE tracker?

Vulnerable, fix deferred means the package is affected on that Ubuntu release, but the Ubuntu Security team has deferred the fix. The CVE page usually explains why in the notes. For SOC 2, treat it as no fix available: record a risk acceptance with compensating controls and recheck the tracker at each review date.

Should we buy Ubuntu Pro to close SOC 2 vulnerability findings?

Buy Ubuntu Pro when the findings that block your SLA have fixes marked Available with Ubuntu Pro. on the Ubuntu CVE pages. ESM covers critical, high and selected medium vulnerabilities across the archive, including universe. If you choose not to subscribe, the risk acceptance record should state that a paid fix exists and why compensating controls were chosen.

Can a KEV-listed vulnerability be risk-accepted?

A vulnerability on the CISA KEV catalog has reliable evidence of exploitation in the wild, so accepting it needs compensating controls that block the attack path, a short expiry and senior approval. KEV entries require a clear remediation action, so look for a fix upstream, in ESM or in a newer release before accepting.

How long can a SOC 2 risk acceptance stay open?

SOC 2 sets no maximum. The company's vulnerability management policy sets expiry periods, usually tied to residual risk, for example 30 days for high and 180 days for low. Each acceptance needs a fixed review date; one that passes its date without a recheck is treated as an unapproved open finding.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• Ubuntu, About the Ubuntu CVE tracker statuses
• Ubuntu CVE Tracker README (raw status names)
• Ubuntu, CVE-2024-6387 (example of a fix available with Ubuntu Pro)
• Ubuntu Pro
• Ubuntu Pro Client documentation, About ESM
• Ubuntu Pro Client documentation, Fix scenarios
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, Known Exploited Vulnerabilities criteria
• FIRST, CVSS v4.0 User Guide
• FIRST, Exploit Prediction Scoring System (EPSS)