When a Client Accepts the Risk Instead of Fixing It

When a client accepts the risk instead of fixing a finding, record it as accepted rather than closed, at its assessed severity, with who accepted it, what they were told, why, and when it will be revisited. Living with the risk is their decision to make; what it becomes in your records is yours, and most firms get it wrong in the same direction: they close the finding.

Closing it is tidy and it destroys the one thing the finding was for. Next year somebody asks whether this was known about, and a closed finding says it was dealt with. It was not dealt with. It was weighed and kept, which is a different sentence with different consequences.

Accepted is a state, not an outcome

A finding has an outcome when the weakness is gone: fixed, verified on a retest, closed. Risk acceptance is a state it sits in while remaining exactly as exploitable as the day you found it. Your report and your record should both say so in a word a non-tester reads correctly, which is why "accepted" beats "closed" and beats "risk accepted (closed)" by a distance.

The practical test: if this appeared in a breach timeline eighteen months from now, would your record show that the client knew? A closed finding does not. An accepted one does.

What has to be recorded

Four things, and the last is the one people skip.

• Who accepted it. A named person, not "the client". Acceptance is an authority question and the authority sits with somebody specific.
• What they were told. The severity, the exploitation path in one sentence, and what an attacker gets. Acceptance based on a summary that undersold it is not acceptance.
• Why. Cost, a dependency, a system being retired in March. The reason dates the decision.
• When it is revisited. This is the one that gets left out, and without it acceptance is permanent by default. A retirement in March means the finding comes back in April if the system is still there.

The conversation, and the part that is not yours

Testers often over-argue this. You found it, you rated it, you explained it. Whether the business carries that risk is a commercial judgement involving numbers you do not have. Pushing past a considered no makes you the vendor who cannot take an answer, and it costs you the next engagement.

What is yours: making sure the decision was informed. If the person accepting it thinks the finding needs an authenticated session and it does not, they are accepting a different risk from the one you found. Correct that once, plainly, in writing. Then record their answer.

When you should not simply accept the acceptance

There are two cases where a tester carries on.

The first is where the acceptance would be somebody else’s problem. Cardholder data, personal data at volume, a weakness in something the client sells to its own customers. The client can accept risk to itself. It cannot accept, on a form, risk that lands on third parties, and your report should note where those are not the same population.

The second is where the acceptance is really a deferral nobody has scheduled. "We will pick this up in the platform rewrite" is a fix with no date, which is an acceptance wearing a fix’s clothes. Ask when, write down the answer, and let the absence of one be visible.

Compensating controls, and when they are real

Half of what gets called acceptance is not acceptance at all. It is a claim that something else already reduces the risk: the box is behind a VPN, there is a WAF in front of it, only three people have accounts. Sometimes that is true and the finding genuinely sits lower than you rated it. Often it is a control nobody has tested, offered as a reason not to test it.

The way through is to treat the control as a claim and check it, briefly, rather than argue about it, which is the same approach that works when a client disputes a finding. If the answer is that the VPN is the only thing between the internet and an unauthenticated administrative interface, that is worth a paragraph in the report, because it means a single failure of one control is a full compromise rather than a step in a chain. If the answer is that the WAF blocks the specific payload you used but not a variant, you have turned an argument into a finding.

Where a compensating control is real, say so and adjust the rating with the reasoning attached, so a reader in a year knows why a high reads as a medium. Where it is asserted and untested, record it as asserted. Neither of those is confrontational, and both are the difference between a report that holds up and one that gets quietly disputed after you have left.

How it should read in the report

Leave the finding at its assessed severity. Do not downgrade a high to a medium because it was accepted: severity describes the weakness, not the client’s appetite. Add the acceptance as a status and a short note, and keep it out of the remediation count in the executive summary, where it would otherwise read as progress.

If an auditor later reads the report, the honest picture is "three highs, one accepted with a stated reason and a review date". That is a defensible document, and it is the evidence chain described in penetration testing for ISO 27001 and SOC 2. "Two highs" is not, and the difference is one editing decision made at half past six on a Friday.

At the next engagement, raise accepted findings again by name. Ask whether the reason still holds, whether the system was in fact retired, and whether anything about the exposure has changed. An acceptance that is never revisited is not a decision any more; it is an assumption with a date on it.