The conventional wisdom
Most compliance teams treat vulnerability management as a patch deployment problem. The logic is straightforward: a CVE gets published, your vulnerability scanner flags affected systems, you test the vendor patch, and you deploy it within your risk treatment plan's timeline. SOC 2 CC6.1 and ISO/IEC 27001 control 8.8 both require timely remediation of technical vulnerabilities. The audit evidence is simple: patch deployment logs, scan reports showing the CVE cleared, and a closed ticket.
This works fine when patches exist. It breaks completely when they don't.
Why this approach is incomplete
The patch-centric model assumes vendors will deliver fixes faster than attackers can exploit disclosed vulnerabilities. That assumption no longer holds. ShieldBreak (CVE-2026-69414) illustrates the problem: a public proof-of-concept dropped on August 12, 2026, Microsoft assigned the CVE two days later, and as of publication, no patch exists. If you're running Windows 11 25H2 or Windows Server 2025 with Microsoft Defender, you've got a local privilege escalation path from low-privileged user to SYSTEM, and your patch queue can't help you.
Your auditor won't care that Microsoft hasn't shipped a fix yet. They'll care whether you identified the exposure, assessed the risk, and implemented a control to reduce it. ISO/IEC 27001's Annex A control 8.8 requires you to "apply patches or other Technological Controls" when vulnerabilities are identified. SOC 2's CC7.1 demands detection and response to security incidents and vulnerabilities. Neither framework gives you a pass because the vendor is still working on it.
The gap isn't in your patch management process. It's in your risk treatment framework. If your only remediation option is "deploy vendor patch," you've built a compliance program that stalls the moment a zero-day or unpatched vulnerability enters your environment.
The evidence
Look at what control 8.8 actually says: "apply patches or other Technological Controls." That "or" isn't decorative. ISO/IEC 27001 explicitly acknowledges that patches aren't always available or immediately deployable. The standard expects you to have alternative Technological Controls ready.
SOC 2's CC6.1 requires that the entity "implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software." The criterion doesn't specify patch deployment as the only acceptable action. It specifies control implementation and detection capability.
Both frameworks require you to maintain a risk treatment plan that documents how you'll handle identified risks. When a vulnerability like ShieldBreak appears, your plan should already contain decision criteria: What do we do when no patch exists? What compensating controls can we apply? How do we verify those controls are effective?
The Qualys VMDR detection for CVE-2026-69414 gives you visibility. The TruRisk Eliminate mitigation gives you a patchless remediation option that you can verify through reassessment. That's not a vendor pitch, it's an example of what "other Technological Controls" looks like in practice: you apply a configuration change or system hardening measure that closes the attack path without waiting for Microsoft's timeline.
What to do instead
Build your vulnerability management control around risk reduction, not patch deployment. Your risk treatment plan should include:
1. Detection independent of patch availability. Your vulnerability scanner should flag CVEs whether or not a patch exists. If you're only tracking patchable vulnerabilities, you're blind to zero-days and vendor delays. Configure your VMDR tooling to surface all identified CVEs, not just those with available patches.
2. Documented decision criteria for unpatched vulnerabilities. When a CVE appears without a patch, you need a repeatable process: Assess exploitability (is there a public PoC?), assess exposure (which systems are affected?), assess impact (what's the privilege escalation or data access risk?), and document the decision to accept, mitigate, or isolate. For ShieldBreak, the decision tree is simple: public PoC exists, SYSTEM-level escalation is possible, affected systems are identifiable via VMDR query. That's a high-risk exposure requiring immediate mitigation.
3. Technological Controls beyond patching. Your toolkit should include system hardening, configuration changes, access restrictions, and monitoring rules that reduce risk while you wait for vendor fixes. The TruRisk Eliminate mitigation for ShieldBreak is one example. Network segmentation is another. Disabling vulnerable services is a third. Document these options in your risk treatment plan so you're not improvising during an incident.
4. Verification evidence that satisfies auditors. When you apply a non-patch control, you need evidence that it worked. For ShieldBreak, that means running a post-mitigation scan in VMDR to verify the remediation outcome. Your audit trail should show: vulnerability identified (date, affected systems), risk assessed (severity, exploitability), control applied (what you did, when), and verification completed (scan results showing the exposure closed). That evidence package satisfies both SOC 2 and ISO/IEC 27001 requirements without waiting for Microsoft.
When the conventional wisdom is right
Patches are still the gold standard when they're available. They're vendor-tested, widely deployed, and auditors understand them. If Microsoft ships a fix for ShieldBreak tomorrow, you should test and deploy it, then remove the interim mitigation. Your risk treatment plan should always prefer vendor patches over compensating controls when the patch is stable and doesn't introduce operational risk.
The conventional wisdom is also correct that you can't mitigate everything. Some zero-days hit components so deep in the stack that your only option is isolation or system replacement. If the vulnerability is in your hypervisor or your hardware root of trust, configuration changes won't help. Accept that risk, document it, and escalate it to leadership.
But here's the distinction: accepting risk because no control exists is a defensible compliance position. Accepting risk because you're waiting for a patch that may not arrive for weeks is not. One demonstrates mature risk management. The other demonstrates process rigidity that auditors will flag as a control deficiency.
Your compliance program needs to work when patches don't exist. Build the framework now, before the next zero-day forces you to explain to your auditor why you stayed exposed for 14 days waiting for Microsoft.
