What is a compensating control?
A compensating control is a substitute. A policy, standard or framework calls for a specific control, but the organization can't put it in place because of a legitimate technical, cost or business constraint. Instead of leaving the gap open, it deploys a different control that delivers similar protection. The classic case is a legacy system that can't be patched or can't support multifactor authentication.
Compensating is defined by its relationship to the missing control, not by when it acts. A compensating control usually has a second, functional type as well: a firewall rule that isolates a host is preventive in function and compensating in purpose.
When organizations use compensating controls
- A system runs an operating system the vendor no longer supports, and the application it hosts can't be moved.
- Equipment such as an industrial controller or medical device can't run an endpoint agent.
- A team is too small to separate duties fully.
- A primary control is temporarily broken, such as a failed badge reader awaiting repair.
- Replacing a system is approved but not funded until next year.
Examples
| Required control that can't be used | Compensating control |
|---|---|
| Patching an unsupported imaging workstation | Isolated VLAN with firewall rules that allow only the imaging server, plus extra monitoring |
| MFA on a legacy payroll application | Access only through a jump server that requires MFA |
| Separation of duties in a three-person office | Owner approves every payment over a set amount, and the bank sends daily transaction alerts |
| Badge reader on a server room door | Guard posted at the door until the reader is repaired |
| A SIEM the budget can't cover yet | Weekly manual review of firewall and server logs |
Each substitute addresses the same risk as the original requirement. Isolating the unpatched workstation doesn't fix its vulnerabilities, but it removes most of the paths an attacker would use to reach them.
Compensating controls in PCI DSS
PCI DSS uses the term formally. It accepts a compensating control only when a legitimate, documented technical or business constraint prevents meeting a requirement as written. The substitute must meet the intent and rigor of the original requirement, provide a similar level of defense, go beyond what other PCI DSS requirements already demand, and be proportionate to the extra risk of not meeting the requirement. The organization documents it on a compensating controls worksheet, and the assessor validates it at each assessment. Outside PCI DSS, common practice follows the same logic: record why the primary control is infeasible, what the substitute is, who owns it and when it will be reviewed.
Compensating vs. corrective controls
The two are easy to confuse because both come up when something is wrong. A corrective control responds to an incident: something happened, and the control limits or repairs the damage. A compensating control responds to a gap: a required control is missing, so a substitute stands in, whether or not anything has been attacked. Isolating an unpatchable controller on its own VLAN is compensating. Isolating a laptop because it is spreading malware right now is corrective. A compensating control also differs from risk acceptance, where the organization decides to live with the gap and adds nothing.
Compensating control on the CompTIA Security+ exam
Control types, compensating among them, belong to SY0-801 objective 1.1. The signal words are constraints: legacy, unsupported, can't be patched, can't afford, temporary, until it is replaced, alternative and instead of. Those words point to compensating even when the measure itself, such as a firewall rule, a guard or a log review, would otherwise read as preventive or detective. Remove the constraint from the scenario and the functional type usually becomes the answer. Corrective is the most common distractor, so ask whether the scenario describes an incident or a missing control.