A compensating control is an alternative safeguard that reduces the same risk as a control you cannot put in place, such as patching or upgrading. For a legacy system it usually means isolation, tight access and monitoring, written down with the gap it covers, an owner and a way to show it still works.
The definition in plain words
Every control exists to reduce a specific risk. If the standard control is out of reach, a compensating control is a different control that gets you a similar reduction. The word "similar" matters. A compensating control is not a promise to fix things later, and it is not a note saying the team is aware.
NIST's catalog gives a useful example in its discussion of unsupported components. It says the increased risk of using them can be mitigated, for example, by prohibiting their connection to public or uncontrolled networks, or by implementing other forms of isolation. It also says exceptions to replacing unsupported components include systems that provide critical mission or business capabilities where newer technology is not available, or systems so isolated that replacing components is not an option.
Compensating control, mitigation and workaround
These terms get mixed up in tickets. A simple way to separate them:
| Term | What it does | Needs an owner and review date? |
|---|---|---|
| Compensating control | Replaces a control you cannot implement, aimed at the same risk | Yes |
| Mitigation | Lowers likelihood or impact of a risk, not always tied to a missing control | Yes |
| Workaround | Gets the job done despite a blocker, with no claim about risk | Usually not, which is the problem |
If your note says "we asked users to be careful", that is a workaround. If it says "the host accepts traffic from two addresses only, enforced at the firewall, reviewed monthly", that is a compensating control.
Three tests a compensating control should pass
- It targets the gap. Name the control you cannot meet and the risk behind it. A firewall rule compensates for a missing patch on a network service. It does not compensate for a weak password policy.
- It is enforced by something other than people's habits. A firewall, a gateway, a policy engine or an access broker qualifies. A reminder email does not.
- You can show it works. Keep a test result, a configuration export or a log sample with a date on it.
Typical pairings for legacy systems
| Gap | Common compensating controls |
|---|---|
| No security patches available | Network isolation, deny by default rules, virtual patching at a gateway |
| No support for modern authentication | Access through a jump host that enforces multi-factor authentication |
| No endpoint agent possible | Network monitoring and log forwarding from neighbouring devices |
| Unsupported protocol still needed | Restrict it to one segment and block it elsewhere |
Each pairing has limits. Isolation does not help if the vulnerable service must be reachable by many hosts in the same segment. Monitoring detects, it does not prevent. Say that in the record.
What to write down
Keep the record short: the system and its owner, the control that cannot be met, the compensating controls with the evidence for each, residual risk in a sentence, a review date and a retirement target. NIST also describes a plan of action and milestones as a way to document planned remediation actions and update them as assessments and monitoring produce findings. A legacy exception without milestones tends to become permanent.
Where Safeguard fits
You cannot compensate for systems nobody has listed. Safeguard's asset discovery helps find them, and SBOM and dependency scanning show which software components sit inside the ones you can inspect. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is a compensating control the same as accepting the risk?
No. Accepting a risk means choosing to live with it as is. A compensating control reduces the risk by other means, and you may still accept what remains.
Can one control compensate for several gaps?
Yes, network isolation often covers several. Record each gap separately so a reviewer can see which risk the control addresses.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (SA-22 and CA-5 text and guidance)
Last reviewed: 19 October 2026.
