Compensating control, when the required control will not fit

Most compensating controls a risk team meets arrive inside a vendor's answer to a security questionnaire: the vendor cannot do the thing the control asks for, and offers something else instead. Small vendors cannot always segregate duties across a four-person engineering team. A legacy system may not support multi-factor authentication.

The answer is not automatically a failure, and treating it as one trains vendors to write "yes" where the honest answer is "no, but". What makes a compensating control acceptable is that it addresses the same risk, not that it exists. Compensating for absent MFA with quarterly password rotation does not, because the risk is credential replay and rotation barely touches it. Compensating with hardware-key access from managed devices on a restricted network does.

Four questions, and the fourth is the one that gets skipped. What risk did the original control address? Does the alternative address that same risk, to a comparable standard? Who approved the exception, and against what risk appetite? And when does it expire?

An exception without an expiry date is a permanent change to your control baseline, agreed by someone who thought they were agreeing to a temporary one. Record them in the risk register with an owner and a review date, and re-test at renewal — the constraint that justified the exception is often gone, and nobody has revisited it because nothing forced them to.