Home / Knowledge hub / Compensating control
Knowledge hub
Compensating control
A different safeguard used to cover a gap you cannot close directly.
What it means
A compensating control is an alternative safeguard that gives similar protection when the required or ideal control cannot be put in place. The usual reason is practical: a system cannot be patched, a legacy product cannot support encryption, or a fix needs a change you cannot make yet.
It does not erase the gap. It reduces the chance or the impact of something going wrong there, by some other means: a filter in front, tighter network limits, extra monitoring, or an approval step by a person. The aim is the same result by a different route.
Why it matters
Real organisations always have things they cannot fix on time. Without a way to handle that honestly, teams either leave the gap undocumented or claim a fix that did not happen. A compensating control gives an auditable middle path, with a reason, an owner and a review date.
Auditors and standards expect it to be more than an excuse. PCI DSS, for example, requires that a compensating control meets the intent and rigour of the original requirement, goes above other controls, and is documented. A weak substitute is a finding.
How it shows up
Typical examples: isolating an old server on its own network segment, putting a WAF rule in front of a flaw you cannot patch yet (see virtual patching), requiring a second person to approve sensitive actions, or logging every access to an unprotected store and reviewing the logs.
Write down what it replaces, why the original cannot be done, how the substitute works, who owns it, how you will check it keeps working, and when it ends. Then test it. A control that nobody has tried to get around is a belief. A failed test shows the gap is open, and passing one is evidence you can show.
Questions people ask
Compensating control, answered
Is a compensating control the same as a workaround?
Close, but the formal version is documented, reviewed and tested. A workaround is often an informal fix that nobody tracks.
Auditors want the paperwork as well as the protection.
Does a compensating control remove the finding?
Usually it changes how the finding is treated rather than removing it. The underlying flaw remains, and risk is lowered but not gone.
Many frameworks accept it with conditions.
How long can one stay in place?
As long as the reason holds, but with scheduled reviews. Permanent compensating controls tend to decay as systems change.
Set an end date or a review date at the start.
Who approves it?
The risk owner, often with security and sometimes an external assessor. Under PCI DSS, an assessor must review it.
Record the approval, not just the idea.
How do we prove it works?
Test it as an attacker would: try the original exploit against the compensated system and keep the result.
Repeat after any change to the surrounding setup.
Sources
Where this comes from
Related
Terms that sit next to this one
Mitigation
Reducing what a vulnerability can do without actually fixing it.
Virtual patching
Blocking an exploit with a filter while the real fix is still being built.
Risk acceptance
Deciding, on the record, to live with a known issue rather than fix it.
Defence in depth
Assume any one control will fail, and have something else behind it.
Patch management
The routine of tracking, testing and rolling out updates across your systems.
Does the substitute hold up?
A substitute control is a claim until it is tested. We can re-run the exact exploit against the protected app and show the result, request and response included. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.