Control rule: compensating controls are temporary risk reducers, not permanent substitutes for remediation. Every control needs scope, owner, proof, residual risk, expiry, and a review trigger.
Compensating Controls Library
Reduce exposure while patching catches up.
Use this page when a fix is delayed, a change window is unsafe, a vendor workaround is partial, or residual risk needs a temporary control with evidence.
Network
Restrictreachability, paths, ports, management planesIdentity
Constrainprivilege, sessions, tokens, authentication pathsDetection
Watchtelemetry, hunts, alerting, abuse patternsOperations
Reviewexpiry, owner, evidence, residual riskControl Families
Choose the safest temporary control for the risk shape
Access restriction
Limit who can reach the vulnerable path
Use firewall rules, allowlists, VPN requirements, admin-plane restrictions, or temporary geofencing when exposure is too broad.
Service isolation
Separate high-risk systems from normal paths
Use segmentation, isolated maintenance access, jump hosts, service relocation, or temporary removal from public routing.
Feature disablement
Turn off the vulnerable capability if business can tolerate it
Disable affected modules, risky protocols, upload paths, legacy auth, scripting, or optional integrations until a fix is safe.
Identity controls
Reduce blast radius if access is abused
Add MFA, shorten sessions, revoke tokens, rotate secrets, reduce privileges, tighten conditional access, or isolate service accounts.
Detection uplift
Make attempted exploitation easier to see
Add focused hunts, Sigma or YARA drafts, IOC monitoring, endpoint telemetry checks, log retention, and alert ownership.
Vendor support path
Use external guidance as part of the control
Track workarounds, hotfixes, support cases, supersedence, safe versions, and vendor caveats before accepting residual risk.
Choosing a Control
Match the control to the reason patching is blocked
Patch delayed but fix exists
Use access restriction, staged rollout, rollback planning, and closure evidence. Keep the final patch date visible so the control does not become permanent.
No patch exists
Use isolation, feature disablement, vendor guidance, detection uplift, exception approval, and a review trigger tied to vendor updates.
Exposure is uncertain
Validate reachability before over-restricting production. Use inventory, logs, CIDR checks, owner confirmation, and external exposure review.
Business impact is high
Require a risk owner, compensating control evidence, response timeline, and escalation path before accepting delayed remediation.
Control Evidence
What to capture before calling a mitigation real
Scope
Assets, product versions, affected paths, users, ports, networks, business service, and excluded systems.
Owner
Technical owner, risk owner, approver, review cadence, and escalation contact if the control weakens or expires.
Deployment proof
Change record, rule ID, policy screenshot reference, configuration diff, telemetry test, or owner confirmation.
Residual risk
Known bypasses, uncovered assets, business constraints, detection gaps, expiry date, and trigger-based re-review conditions.
Quality Traps
Common ways temporary controls quietly fail
Untested control
A firewall, WAF, policy, or detection rule that was deployed but never validated should not be treated as risk reduction.
No expiry date
Controls without review dates become invisible exceptions. Add a review date and a trigger such as PoC release, KEV inclusion, or vendor update.
Too broad to survive
A control that breaks normal operations will be bypassed or removed. Prefer narrow scope, staged rollout, and owner-reviewed exceptions.
Detection without telemetry
A hunt or rule is weak if logs are missing, fields are unmapped, retention is too short, or no one owns the alert path.
Copy Template
Compensating control note
Control: [access restriction / isolation / disablement / identity / detection / vendor workaround] Reason patch is delayed: [testing, no fix, change window, outage risk, vendor guidance] Scope: [assets, product, version, network, users, business service] Proof: [change record, rule ID, config diff, telemetry test, owner confirmation] Residual risk: [uncovered systems, bypass limits, detection gaps, business constraints] Owner: [technical owner]. Risk owner: [approver] Review trigger: [date, KEV, PoC release, vendor update, exposure change, failed validation]
Recommended next move: select one narrow control, record evidence, then link the item to an exception, response SLA, or closure proof.