Compensating Controls

What are compensating controls?

A compensating control is a measure that reduces the likelihood or impact of an exploit while the underlying vulnerability remains unfixed — a WAF virtual patch, an IPS block, an EDR policy tightening, or network segmentation. It is an interim measure by definition, applied because the real fix cannot ship inside a risk-appropriate window.

Key takeaways

• A control changes the odds, not the state. The vulnerability is still there. What changes is how hard it is to reach and how likely a given attempt is to succeed.
• Signature-based controls are evadable. Substituting an equivalent expression for a blocked one defeats a signature. A rule stops the best-known payload, not the attack.
• Blocking carries its own outage risk. An inline rule that misfires takes down a production service, which is why a recommendation to block is not a free action.
• Controls need an expiry date. A virtual patch that outlives the memory of why it exists becomes permanent undocumented configuration.
• Detection is the durable half. Because containment can be bypassed, the exposure still needs to be detectable — a control and a detection do different jobs.

Why it matters

Most exposures cannot be fixed immediately. The median time to fully remediate a CISA KEV vulnerability is 43 days and only 26% are ever fully fixed (Verizon 2026 DBIR), and those are the most unambiguous priorities in the industry. Change windows, upgrade risk and coupled dependencies are real constraints rather than excuses, so the interval between decision and fix has to be covered by something.

The failure mode is treating that cover as the outcome. A finding marked mitigated because a WAF rule exists looks closed in every report while the exposure it describes is intact and the control in front of it is one substitution away from being bypassed.

The common controls and what each is good for

• WAF virtual patch. A rule blocking the known exploit pattern for a specific web vulnerability. Fast to deploy, effective against commodity exploitation, weak against a deliberate attacker.
• IPS or firewall block. Network-level prevention of the traffic pattern. Useful where the vulnerable service should not be reachable from where the traffic originates.
• EDR policy tightening. Restricting the behaviour the exploit depends on — a process spawn, a script interpreter, a write to a particular location.
• Segmentation. Reducing who can reach the vulnerable service at all. Slower to implement and the most durable of the four.
• Configuration change. Disabling the vulnerable feature or module. Often the strongest option and the most frequently overlooked.

Where the term comes from

The vocabulary is older than the current tooling and it is defined in standards rather than by vendors. PCI DSS has recognised compensating controls formally for two decades, with a documented worksheet requiring the entity to state the constraint that prevents the original requirement being met, the objective of that requirement, the additional risk introduced, the control put in place, and how it is validated and maintained. NIST SP 800-53 uses the term comparably: an alternative control employed in place of a baseline control, selected because the baseline cannot be applied, and providing equivalent protection.

Two features of those definitions are worth carrying into everyday practice, because informal use drops them. A compensating control is justified against a stated constraint rather than chosen for convenience, and it carries an obligation to be reviewed — a documented position, not a status a finding is moved into and forgotten.

Why evasion matters more than it appears to

Signature-based controls match patterns, and patterns have equivalents. A rule written to block a specific injection payload is looking for a literal string; an attacker who substitutes a logically equivalent expression, changes the casing, inserts inline comments, or applies an encoding the inspection layer decodes later than the rule reads it, produces a request the rule does not recognise and the application interprets identically. None of this requires novel research.

That distinction sets the right expectation. Against opportunistic scanning and commodity exploitation, a virtual patch is genuinely valuable, because commodity tooling uses the payloads the signature was written from. Against someone specifically interested in this organization, the same rule is a speed bump, and treating it as equivalent to a fix is how an organization ends up surprised.

Blocking versus monitoring

An inline blocking rule prevents the attack and can also prevent legitimate traffic, which means deploying one under time pressure, against a vulnerability nobody has fully characterised, is itself a change with an outage risk. A monitoring posture — detect the attempt, alert, do not interfere with traffic — carries no such risk and provides no prevention.

The reasonable default depends on which failure is worse in that lane, and it is worth deciding deliberately rather than inheriting the default of whichever tool is doing the deploying. A useful discipline is to deploy in monitoring mode first, observe what the rule would have blocked over a representative period, and switch to blocking only once the false positive rate is known rather than assumed.

How to keep a control from becoming permanent

The recurring operational problem is not writing the control. It is that controls outlive their reason and nobody can safely remove them years later. Five practices prevent that.

• Link the control to the finding. A rule recorded against the specific CVE and asset it covers can be found again when the patch ships. A rule recorded only in the appliance configuration cannot.
• Set an expiry with the deployment. A review date attached at creation forces a decision later; an open-ended mitigation never gets one.
• Keep mitigated and remediated as separate states. Collapsing them into a single closed status removes the queue's ability to show how much of the backlog is covered rather than fixed.
• Pair every control with a detection. Containment can be bypassed silently. A detection on the same exposure is what still functions after an evasion, and it produces the evidence that an attempt happened.
• Verify the control does what it claims. A rule deployed to the wrong virtual host, in the wrong mode, or in front of only one of three load-balanced paths is common enough that a positive test is worth the time.

FAQ

Is a compensating control the same as a virtual patch? A virtual patch is one kind of compensating control — typically a WAF rule blocking the exploit pattern for a specific vulnerability. Segmentation, EDR policy and configuration changes are others.

Can a finding be closed once a control is in place? It should not be. The vulnerability is unchanged and the control is bypassable. Mitigated and remediated are different states and conflating them makes a backlog look better than it is.

Why prefer detection over blocking? Because a blocking rule can be evaded and can break production, and neither of those is true of a detection. A control buys time; a detection still works after someone routes around the control.

Sources

• Verizon, 2026 Data Breach Investigations Report.
• CISA, Known Exploited Vulnerabilities Catalog, ongoing.
• PCI Security Standards Council, Payment Card Industry Data Security Standard v4.0, 2022.
• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, 2020.
• OWASP, ModSecurity Core Rule Set project documentation, 2024.
• MITRE Corporation, ATT&CK for Enterprise knowledge base, 2025.