Evidence rule: do not mark a vulnerability mitigated because a control was requested. Record deployed state, checked scope, validation method, owner, residual risk, expiry, and the trigger that reopens the decision.
Compensating-Control Evidence Examples
A temporary control only counts when it can be proven.
Use these examples when patching is delayed, risky, incomplete, or unavailable and the team needs evidence that a compensating control actually reduces exposure.
Change record, rule ID, policy state, config diff, support response, or owner-attested deployment.
Path check, access test, telemetry check, query result, blocked request, or configuration review.
Assets, users, paths, ports, business service, excluded systems, and known bypass conditions.
Owner, review date, expiry condition, residual risk, and target permanent fix or acceptance path.
Examples
Common compensating controls and evidence that makes them reviewable
Access restriction
Firewall, allowlist, VPN, or admin-plane rule
The vulnerable service is reachable only from approved networks or users while remediation is pending.
Service isolation
Segmentation or temporary removal from public routing
The affected service is moved behind a restricted path, isolated network, maintenance access path, or jump-host-only route.
Feature disablement
Vulnerable module, protocol, or integration turned off
The vulnerable feature exists in the product but is disabled until a patch, hotfix, or vendor workaround is safe.
WAF or gateway rule
Exploit path is blocked at the edge
A rule blocks known exploit patterns or risky request paths while preserving enough service availability.
Identity control
Privilege, session, token, or MFA hardening
Access abuse is constrained by privilege reduction, MFA enforcement, token revocation, shorter sessions, or conditional access.
Detection uplift
Hunt, alert, or telemetry coverage added
The team cannot fully prevent exploitation yet, but SOC can watch for exploitation attempts or post-exploit behavior.
Weak Evidence
Claims that need more proof before closure
Control requested
A ticket or chat request is not deployment proof. Capture the deployed rule, policy state, or owner-attested change.
Control deployed but untested
A rule that was never tested should not be treated as risk reduction. Add a path test, blocked request, or telemetry check.
Scope is implied
"All servers" or "the application" is too vague. Name assets, networks, users, paths, business services, and excluded systems.
No expiry or owner
Temporary controls become invisible when they lack an owner, review date, permanent fix target, or trigger for re-review.
Copy Template
Compensating-control evidence note
Control outcome: mitigated by compensating control CVE/advisory: [ID and source URL] Control type: [access restriction / isolation / feature disablement / WAF / identity / detection / vendor workaround] Reason patch is delayed: [no fix / unsafe change / testing / vendor ambiguity / business window] Scope covered: [assets, users, networks, ports, paths, business service] Deployment proof: [rule ID, policy ID, config diff, change record, support case, owner confirmation] Validation method: [path test, blocked request, telemetry check, query test, config review] Residual risk: [uncovered systems, bypasses, visibility gaps, business constraints] Owner and reviewer: [technical owner, risk owner, SOC owner if applicable] Review date and reopen trigger: [date, patch release, KEV, PoC, exposure change, failed validation]
Recommended route: choose a narrow control, collect deployment proof, validate it, then record the residual risk and review trigger.