Compensating Control
A compensating control is an alternative safeguard you implement when the standard, expected control isn’t feasible — mitigating the same risk by a different route. The canonical example: a legacy system that can’t support MFA, compensated with network isolation, tightened access, and enhanced monitoring on every path to it.
What makes one legitimate
Auditors accept compensating controls under conditions, and PCI DSS formalizes them explicitly: the compensation must address the same risk as the original requirement, be at least as rigorous in effect, and be documented — the constraint, the rationale, the alternative, and how you verify it operates. “We couldn’t do X” is a gap. “We couldn’t do X because of Y, so we do Z, and here’s the evidence Z operates” is a control.
Where teams misuse the concept
As a euphemism for exceptions. A compensating control that’s cheaper, weaker, and chosen for convenience rather than necessity is just a gap with paperwork — and experienced auditors dismantle those quickly. The test is honest equivalence: would a skeptical reviewer agree the risk is as covered as the standard control would leave it?
The practical advice
Use them sparingly, document them thoroughly, and put an expiry on each: compensating controls that outlive the constraint that justified them (“the legacy system was migrated in 2024; the exception remains”) are a classic finding. Track them in the risk register with review dates.
Access Review — An access review is the periodic check that everyone's system access matches their role — the most-sampled SOC 2 control and the most common exception.
Inherent vs Residual Risk — Inherent risk is exposure before controls; residual risk is what remains after. Auditors check that the gap between them maps to real, operating controls.