Prove a compensating control by naming the exact attack path it blocks, testing that block with a real attempt, saving the result, and re-testing on a schedule. A control you describe but never test is a hope, not evidence, and approvers should not accept it.
What a compensating control is
It is a different safeguard that reduces the risk of a vulnerability you cannot fix right now. Examples: a network rule that stops untrusted traffic reaching the vulnerable service, a disabled feature, an input filter, or tighter privileges on the process.
It is not a reason the vulnerability is harmless. If the flaw cannot be exploited at all, that is a VEX not_affected case. A compensating control assumes the flaw is real and tries to cut the risk.
Step 1: Name the attack path
Write one sentence: "An attacker who can send X to Y can trigger Z." Then state where your control interrupts that path. If you cannot describe the path, you cannot judge the control.
Step 2: Test the block
Try the thing the control claims to stop.
| Control | Test |
|---|---|
| Network rule | Send traffic from an untrusted network position and confirm it fails |
| Feature disabled | Call the feature and confirm it is unavailable in the shipped build |
| Input filter | Submit a crafted request in a test environment and confirm rejection |
| Reduced privileges | Run the process and confirm it cannot reach the resource |
Test in an environment that matches production. A control that works in staging and not in production proves nothing about production. Do not test against systems you do not own or have no permission to test.
Step 3: Record the evidence
Attach to the exception:
- the attack path sentence,
- the test method, date and who ran it,
- the result, as output or a screenshot saved with the record,
- the control owner,
- the next retest date.
Step 4: Keep checking
Controls drift. Rules get cleaned up, flags flip, configurations get rebuilt. Add the control to monitoring where you can, and retest at least at each renewal. If the control fails, the exception ends. See what should revoke an exception automatically.
Partial controls
Sometimes a control only reduces risk. Say so. "Reduces exposure to internal users only" is more honest and more useful than "mitigated." Approvers can then decide whether the residual risk is acceptable and for how long. The ideas in ot-devices-with-passwords-you-cannot-change-compensating-controls apply in other settings too.
Where Safeguard fits
Safeguard keeps exceptions, their approvers and linked evidence together and ties them to policies and gates, so a retest date and its result stay attached to the finding.
Quick check
Is a firewall rule enough on its own?
Only if it blocks the specific path, and you have tested that from the right network position. A rule that exists on paper is not proof.
How often should we retest?
At every renewal at minimum, and after any change to the control or the asset. Shorter exceptions get an earlier retest.
Last reviewed: 19 October 2026.
