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:
| Field | What to write |
|---|---|
| Finding and systems | The vulnerability, its CVE where there is one, and the exact hosts |
| Why it can't be fixed now | One or two sentences in plain language |
| What could happen | The realistic consequence, for example "someone on the internal network could take control of the finance server" |
| Compensating controls | What reduces the risk in the meantime (see below) |
| Decision owner | A named person at the client with authority to accept business risk |
| Accepted on / expires on | Dates. Every acceptance should expire |
| Review trigger | What reopens it early, such as the finding appearing on the CISA KEV list |
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
This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.
