Compensating Controls in CTEM: What to Do When You Cannot Patch

• When a compensating control is the right answer
• The five control options ranked by durability
• Why a control only counts once it is validated
• How to write an exception that survives an audit
• How to stop temporary controls becoming permanent by accident
• How to report accepted risk to executives honestly

Not everything can be patched, and pretending otherwise breaks programmes

Legacy applications with no vendor support, medical and industrial systems under certification, embedded software with no update path, and business critical systems with rare change windows all exist in real environments. A CTEM programme that only recognises patching as success generates a permanent overdue backlog and loses credibility with the teams it depends on. Recognising compensating controls as a real outcome keeps the loop honest.

Pick the control against the technique, not the score

The most common mistake is choosing a generic control because it feels strong. If the exposure is exploited over an authenticated internal protocol, an internet facing web firewall rule does nothing. Start from the attack path: what does the attacker need to reach, and which of those requirements can you remove most reliably?

1. 1Remove reachability. Taking the service off the internet or restricting sources is the most durable option because it removes the precondition entirely.
2. 2Break the path. Segment the network, remove a trust relationship or revoke the privileged role the exploit depends on.
3. 3Block the technique. Virtual patching, application allow listing, protocol hardening or disabling the vulnerable feature.
4. 4Reduce the value. Remove or relocate sensitive data, rotate secrets and shrink the blast radius so success is worth less.
5. 5Increase detection. A tuned, high confidence alert with a tested response is the weakest option alone, but valuable alongside the others.

A control you have not tested is a hope

The whole value of validation in CTEM applies here. Before an exception is approved, emulate the specific technique against the protected asset and confirm three things: the technique fails, the failure is caused by the control rather than by chance, and the attempt generates the alert you expect. Record the evidence with the exception. This is the difference between a compensating control and an assumption written on a form.

Write an exception someone can defend a year later

Exceptions become dangerous when they are anonymous and open ended. A defensible exception names a person, states the business reason, links validated evidence for the compensating control, sets an expiry and defines what would force an earlier review, such as confirmed exploitation appearing in the wild.

Stop temporary controls becoming permanent by accident

Most compensating controls in long lived environments were meant to last three months. Two safeguards prevent the drift: every exception expires automatically rather than being closed by someone remembering, and every renewal requires re validation, because the environment around the control has usually changed since it was tested.

• Expiry dates are enforced by the ticketing workflow, not by a spreadsheet reminder
• Renewal requires fresh validation evidence, not a copy of the original test
• Ownership transfers explicitly when the accountable person changes role
• Confirmed exploitation of the underlying vulnerability triggers an immediate review
• The total number and age of open exceptions is reported to the executive sponsor

Report accepted risk honestly

Executives can accept risk they understand. They cannot accept risk that is hidden inside a compliance percentage. Report the count of active exceptions, how many protect crown jewel services, how many have validated controls and how many are past their review date. That last number is usually the most useful indicator of whether the exception process is working at all.

• Add compensating control as a formal, first class outcome in your remediation workflow.
• Choose controls from the attack path, starting with reachability removal.
• Require validation evidence before any exception is approved.
• Enforce expiry in the ticketing system and require re validation on renewal.
• Report exception count, age and validation status to the executive sponsor each quarter.

• Approving an exception with no named owner and no expiry date.
• Choosing a generic control that does not address the actual technique.
• Counting a deployed rule as a control without testing it.
• Renewing exceptions automatically without re validating them.
• Hiding accepted risk inside an aggregate compliance score.