We’re moving our critical patch SLA to 72 hours, and I’m debating how far to lean on temporary controls (WAF virtual patching, microsegmentation, and tightened EDR policies) when vendors lag. How are you documenting risk acceptance when EPSS is low but the asset is internet-facing, and do you tie emergency changes to attack surface scoring (e.g., Tenable VPR/Qualys TruRisk) or push via off-hours maintenance windows?
We went to a 72h SLA too; if EPSS is low but it’s internet-facing, we still flip it to “emergency” off VPR/TruRisk and push WAF virtual patch + tighter EDR within 24h — , vendor lags. We log a time‑boxed exception (max 14 days) in the change ticket with compensating controls, expiry, and an EPSS link (Exploit Prediction Scoring System (EPSS)) and require director sign‑off. If microsegmentation proves isolation we might accept for non-prod, but prod stays on the 72h clock — who owns your virtual patch SLA, platform or app?
Similar to @lucas_w93, we treat “internet-facing” with low EPSS as emergency when VPR >= 8 or it’s on CISA KEV; we push a targeted WAF rule and tighten EDR, both as 7-day auto-expiring exceptions while the vendor lags. Risk acceptance lives in the change ticket with business owner sign-off, a rollback test, and a note on microsegmentation boundaries; extensions past 72h need a GrayNoise/attack telemetry hit to justify. Small caveat: we don’t count microsegmentation as compensating unless egress to sensitive segments is demonstrably blocked.
And one thing that’s worked for us is making any exception time‑boxed with an auto‑expire, and we won’t mark risk accepted unless there’s a control‑evidence artifact attached (e.g., WAF block ID or EDR prevention event); if the host is internet‑exposed and shows up in our ASM/Shodan, we flip it to emergency even when EPSS is low. @d_thompson89 do you require proof‑of‑effect like this, or just the control being enabled?