Compensating control

Real environments have constraints frameworks don’t: a legacy database that predates SSO, a vendor tool with no MFA support, a manufacturing system that can’t take an agent. A compensating control acknowledges the constraint without abandoning the objective — if the goal is “only authorized people access production data,” restricted network paths, short-lived credentials, and reviewed access logs can get there by a different road. The bar is comparable assurance, not convenience; frameworks like SOC 2 are objective-based precisely so teams can meet the criteria in the way that fits their stack.

An undocumented compensating control is indistinguishable from a gap. What auditors want on paper: the requirement, why the standard control isn’t feasible, the alternative measure, how it meets the same objective, and the evidence showing it operates. Skip that write-up and the “alternative” reads as a missed control and lands in the report as an audit exception.

One boundary worth keeping sharp: a compensating control still meets the objective; risk acceptance means management has decided to live with the objective unmet. Auditors treat the two very differently, and so do the customers reading your report.

A payments team runs a vendor-managed service account that cannot be rotated to individual identities. Rather than pretend the requirement away, they vault the credential, restrict retrieval to two named engineers, log every checkout, and review the log monthly with sign-off. Objective met — accountable, auditable access — by a different mechanism, with a paper trail proving each piece operates. That write-up is what turns a permanent constraint into a testable control.