When may a compensating control lower a finding's CVSS rating, and what does that number then depend on?
answer
- an adjusted score is a conditional claim
- structural context versus configured context
- the precondition is invisible in the number
- controls get retired, ratings do not follow
- rescoring drifts one direction without governance
basics
~20 sOnly when the control provably blocks the attack path, and only through environmental metrics, leaving the base score untouched. The lowered number then depends on that control existing, so record it as a precondition with a rescore trigger.
solid answer
~50 sA compensating control can legitimately move a rating, because a flaw whose attack path is genuinely severed is not the same risk as one wide open. But an adjusted score is a conditional statement, and the condition is invisible in the number. So my rule has three parts. First, the adjustment goes into the environmental metrics and never into the published base vector, so the inherited claim and my correction are both visible. Second, the control must be verified as actually covering the path, not assumed from a diagram. Third, the adjustment is recorded with the control it depends on, so that retiring or reconfiguring that control triggers a rescore rather than silently leaving a stale number in place. The failure I am guarding against is an organisation that rescored hundreds of findings down years ago and now runs on numbers whose preconditions nobody has checked since.
go deeper
Understand that a firewall rule or allowlist in front of a flaw changes how exposed you are, but does not change the number the vulnerability was published with.
Be able to say that compensating controls are expressed through environmental metrics, never by editing the base vector, and that the adjusted score assumes the control is present.
Show that you verify a control in the running configuration before crediting it, and that you attach the adjusted rating to that control so a change to it brings the finding back for re-rating.
Own the governance: what an adjusted number in the register means, how you keep rescoring symmetric and audited, and when the honest call is to stop adjusting downward because the bookkeeping to do it safely does not exist.
## Two different kinds of context It helps to separate deployment context that is structural from context that is configured. A service that has no route from the internet because it lives inside a private network is structural: changing it means changing the architecture, and that is a visible, deliberate act. A two-address source allowlist on a partner file drop is configured: someone can widen it in a change window on a Tuesday, for good reasons, without anyone connecting that change to a risk rating recorded a year earlier. Both can legitimately move a score. They differ in how likely the precondition is to evaporate quietly, and therefore in how much bookkeeping the adjustment deserves. ## The worked case A legacy insurance-claims file drop carries a finding scored 8.1: a parsing flaw in the intake path reachable by anyone who can deliver a file. In production the endpoint accepts connections from exactly two partner addresses. The realistic attacker is therefore not an anonymous internet user but a compromised partner or a vendor employee abusing legitimate access, and the asset at stake is a body of personal claims data. That is a real reduction in exposure and it is honest to reflect it. The modified attack vector is arguably unchanged — it is still network — but the population of parties who can reach it has collapsed to two organisations, and depending on how the allowlist is enforced the honest encoding may be a modified attack complexity or a scoping note rather than a metric change at all. The important discipline is not which metric you touch; it is that you write down that the number assumes the allowlist. Now ask the question that separates a lead from a practitioner: what is this finding the day the allowlist is retired? A migration onboards eleven new partners, or the allowlist moves to a load balancer that fails open, or a cloud egress redesign puts a shared NAT address on the permitted list. The rating silently reverts to 8.1 and nobody notices, because nothing in the record connected the two. ## What an adjusted rating obliges you to record At minimum, four things travel with a downward adjustment: - **The control it depends on**, named specifically enough that someone can find and test it. - **The unadjusted score**, kept visible beside the adjusted one so the size of the credit is obvious. - **Evidence that the control covers this path**, gathered once by someone who checked the running configuration rather than the design document. - **A rescore trigger**, tied to that control's lifecycle: if it is removed, widened, or migrated, the finding comes back for re-rating. Note what is deliberately not on that list. Deciding to live with whatever risk remains after the adjustment is a separate act of risk treatment with its own owner and its own review; it is not something a scoring adjustment quietly performs on your behalf. Keeping those two steps distinct is what stops rescoring from becoming a way to make findings disappear without anyone signing for them. ## The organisational failure mode Rescoring is asymmetric in practice. The person who wants a number lowered is motivated, present and has a deadline; the person who would benefit from it being raised is a future incident responder. Left ungoverned, a rescoring programme drifts one way, and after two years the finding register describes a defensive posture that no longer exists. The counters are structural rather than moral. Require that the same practice be used to raise scores on critical assets, and audit that it happens — a rescoring log that only ever goes down is evidence of a broken process, not of a well-defended estate. Require a second reader for any adjustment above some threshold of movement. Re-verify a sample of control-dependent adjustments on a fixed cadence, and treat a failed verification as a finding in its own right about the process, not just about that one score. ## What a lead should actually own The policy question is not whether compensating controls may influence ratings — they must, or every rating is a fiction about an undefended system. It is what an adjusted number in your register *means*, and whether your organisation can still answer, two years later, what it was conditioned on. If it cannot, the honest options are to stop adjusting downward at all and prioritise on unadjusted scores plus exploitation data, or to invest in the bookkeeping that makes adjustment safe. Choosing the first because you cannot afford the second is a defensible, senior answer; pretending you are doing the second while actually doing neither is the common one.
- Should the compensating control change the base score or the environmental score?The environmental score, always. Base metrics are a shared, deployment-independent reference, and rewriting them destroys the ability to reconcile your findings with anyone else's or to see that an adjustment was made. Environmental scoring produces a distinct number beside the untouched original, which is precisely the transparency an adjustment needs.
- How do you stop rescoring from becoming a tool teams use to make findings go away?By making the practice symmetric and auditable. Require the same environmental method to raise scores on critical assets and check that raises actually appear in the log; require a second reader for large downward movements; keep the unadjusted score visible next to the adjusted one; and re-verify a sample of control-dependent adjustments on a cadence. A log that only ever moves downward is itself the finding.
- A team wants to downgrade a finding because a firewall rule blocks the path. What do you ask?Who has verified the rule in the running configuration rather than the diagram, what else that rule permits, whether any other path reaches the same component, and what change process could widen it. Then I ask what happens to this rating if the rule is removed, and I only accept the downgrade once that answer is written down alongside the score.
Lowering a rating for a compensating control is like reducing an insurance premium for an alarm system. Fine while the alarm is armed, and worthless once it is unplugged and nobody updates the policy.
saying these in an interview costs you the question
- Adjusts the published base vector to reflect local controls
- Downgrades on a control shown in a diagram but never verified
- Records the lowered score with no note of what it depends on
- Treats a rescore as if it also accepted the remaining risk
- Runs a rescoring practice whose log only ever moves downward