Risk Acceptance: How to Document a Vulnerability Your Client Won't Fix

Sooner or later a client says no. The finance system only runs on an old version of Windows. The vendor won't support the patch. The fix means a weekend of downtime they can't afford this quarter.

That is a legitimate business decision. The problem is what happens next: the finding stays on every report, someone marks it "ignore" in the scanner, and a year later nobody remembers who decided, or why. If that system is ever the way in, "we knew about it" is a hard conversation to have without paperwork.

Risk acceptance is the paperwork. Done well, it takes ten minutes and protects both you and the client.

When acceptance is the right call

Acceptance fits when fixing the finding costs more than the risk it removes, and the client understands that trade. Common cases:

• Legacy systems that a business application depends on
• Medical, industrial or lab equipment that the manufacturer must patch
• Fixes that need budget or downtime the client has deferred
• Findings on systems scheduled for retirement soon

It is not the right call when nobody has looked at the finding yet, or when the real reason is that the ticket got lost. That is a backlog, not a decision.

What a risk acceptance record should include

Keep it short enough that people actually fill it in:

The decision owner matters most. Your technician can recommend, but only the client can accept risk to their business. An owner, practice manager or IT lead signing their name is what makes it a decision instead of a shrug.

Compensating controls

Acceptance rarely means "do nothing". It usually means "do something cheaper than the fix":

• Move the system to its own network segment and limit who can reach it
• Block the vulnerable service at the firewall, or allow it only from specific hosts
• Turn off the affected feature if the business doesn't use it
• Add monitoring or alerting on that host
• Restrict which accounts can log in to it

Write down which ones are in place. They also give you something to check at the next review.

Set an expiry, and reopen early when the risk changes

Six or twelve months is a sensible default. When it expires, ask the same question again: can it be fixed now? Often the answer has changed: a vendor released an update, the budget came through, or the system was finally retired.

Some changes should reopen the decision before the date:

• The CVE is added to CISA's Known Exploited Vulnerabilities catalog
• Its EPSS score jumps, meaning exploitation has become much more likely
• The system becomes reachable from the internet
• A compensating control is removed

How accepted risks should appear in reports

Accepted findings should stay visible, just in their own place. A separate "Accepted risks" section, with the owner and expiry date next to each one, keeps the main action list focused on work that will happen, while making it clear nothing has been hidden.

In the summary, one line is enough: "Three findings are accepted risks with compensating controls; the next review is due in March." That sentence tells the client you're tracking it, and it reminds them a decision is theirs to revisit.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports with prioritized actions. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Vulnerability remediation SLAs · CVSS vs EPSS vs CISA KEV