VPN Risk Report Ignored? Write the Decision, Not the Score

A risk note that ends with a severity ranking gives a manager a verdict and no action. That is why so many of them come back with "thanks, noted" and nothing else. The notes that get approved share a shape: one narrow checkable claim, two named options with a price, and a person who has to answer by a date. Everything below is about producing that shape without overstating what you know.

The score answers a question nobody asked

Likelihood-times-impact arithmetic produces a number that sorts findings against each other. It does not tell a director what to sign, and it invites an argument about the multiplier instead of a decision about the gateway. I have watched a two-decimal exposure figure absorb an entire meeting while the actual question, whether to fund an upgrade this quarter, went unasked.

There are only a few real decisions in this space. Fund the upgrade, accept a bounded exposure until a stated date, or shrink who can reach the service. Each one has a different owner and a different cost, and none of them is "reduce risk by 40 percent".

Severity inflation makes the problem worse. When every finding is critical, the ranking stops discriminating and the reader falls back on the only signal left, which is who complained loudest. A note that says the release is out of support, that this is the second quarter it has been out of support, and that a specific group of staff depends on it is far more actionable than a red badge.

Vagueness is the other failure. "The VPN is insecure" cannot be resolved, because it does not say which deployment, which version, or who can reach what. A sentence a reader can check is the minimum unit of a useful report.

Shrink the claim until someone can check it

Anchor the claim to a published boundary rather than to an opinion. Out of vendor support, missing a required authentication step, or reachable by a network segment that should not see it are all claims with a test behind them. For the first, the test is three commands on the gateway itself:

openvpn --version | head -n 1
dpkg-query -W -f='${Version}\n' openvpn
openssl x509 -in /etc/openvpn/server.crt -noout -enddate

The version line and the package query normally agree, and when they do not you have found a second problem worth reporting separately. The certificate end date is the field people forget to check until clients start failing to connect, and it belongs in the same evidence attachment as the release string.

Record where each output came from and when it was taken. A note that says "gateway gw1, collected Tuesday" can be re-run by a sceptic; a screenshot cropped to the interesting line cannot. Strip keys, private addresses and account names before the file leaves your machine.

Write the note as a choice between named options

A decision note is short because it is doing one job. This is the shape I use, filled in for an invented mid-sized organisation whose remote access release went out of support:

Ask: approve one of two upgrade paths for remote access before 30 June.
Claim: gw1 runs a release that left vendor support in January.
Evidence: version output and vendor notice, attached, collected 14 March.
Option A: upgrade in place, one maintenance window, staff on the current client build.
Option B: replace the gateway, two windows, client reinstall for 180 staff.
Cost of waiting: no security fixes for a service 180 staff use daily.
Owner: platform team. Decision needed from: IT director, by 28 March.

Each line earns its place. The ask is one sentence and contains a date. The claim is checkable. Option B exists so that Option A is a choice rather than a formality, and it names the client reinstall because that is the cost people underestimate. The cost of waiting describes a consequence, not a probability.

What the note must not do is smuggle in a conclusion you cannot support. If no compromise has been demonstrated, say so in one line, because a reader who discovers an overstatement later will discount your next three notes as well.

What accepting the risk has to contain

Acceptance is not the absence of a decision, and it is not silence. If the answer is to live with the exposure for a while, the note needs three additions: an end date, a monitoring step someone actually performs, and a named person who reopens the question when the date arrives.

An interim control needs the same treatment. Restricting the service to a smaller group reduces exposure only if the restriction is enforced somewhere and someone maintains the list. A block that quietly stops a nightly batch job is not a control, it is an outage with better paperwork.

Keep the change owner and the decision owner apart when they are different people. The platform team executes; the director accepts. Writing both names into the note removes the most common stall, which is a well-prepared plan waiting for a person who never saw it.

Verify the note against the deployment before you send it

Claims age badly in organisations with more than one gateway. A finding copied from a forum thread about a different release, or from a host that was rebuilt last month, will be challenged in the meeting and the rest of the note goes with it. Re-run the evidence on every host the note names:

for h in gw1 gw2; do
  ssh "$h" 'openvpn --version | head -n 1; systemctl is-active openvpn@server'
done

If the two hosts disagree, the note is now about a mixed fleet, which is a different and usually more convincing finding. If the service is inactive on a host you believed was serving traffic, stop and correct the inventory before the note goes anywhere.

Then attach the output, put the decision date in the subject line, and send it to the person who can say yes rather than to the group that will discuss it. If the answer comes back as "not now", ask for the date it becomes "now" and write that date into the next version of the note.