5.1.2. Inhibitors to Remediation
💡 First Principle: Vulnerability remediation fails not because organizations don't know what to fix, but because legitimate organizational constraints make fixing it impractical — understanding these constraints is what enables analysts to recommend workable alternatives rather than just repeating "patch immediately."
Real-world vulnerability management constantly encounters friction between security priorities and business realities. These inhibitors are not excuses — they're documented constraints that shape the remediation approach.
| Inhibitor | What It Means | Security Response |
|---|---|---|
| MOU (Memorandum of Understanding) | Formal agreement between parties defining responsibilities — may restrict what changes can be made to a shared system | Escalate to the MOU governing body; update the MOU to require patching |
| SLA (Service-Level Agreement) | Contractual uptime requirements may prohibit taking systems offline for patching | Negotiate maintenance windows into SLAs; implement HA for rolling patches |
| Organizational governance | Change management approval processes, change advisory boards (CABs), may delay patches | Establish emergency change procedures for critical vulnerabilities |
| Business process interruption | Patching requires downtime that affects revenue-generating or mission-critical processes | Schedule during low-impact windows; implement compensating controls until maintenance window |
| Degrading functionality | Some patches break application functionality — vendor testing required before deployment | Coordinate vendor testing; deploy in test environment first |
| Legacy systems | Systems too old to patch (EOL OS, unmaintained custom code, vendor-locked versions) | Network isolation, enhanced monitoring, compensating controls, eventual decommission plan |
| Proprietary systems | Vendor-controlled systems where the organization can't apply patches independently | Require SLA for vendor patching; compensating controls; escalate to vendor |
Recognizing these inhibitors shapes the analyst's recommendation: if a system can't be patched due to legacy constraints, the recommendation isn't "patch it" — it's "isolate it, monitor it closely, and document the accepted risk."
⚠️ Exam Trap: Inhibitors to remediation require documentation and risk acceptance, not just acknowledgment. "We can't patch it because of the SLA" is not a complete response — the risk must be formally accepted by an appropriate authority, compensating controls must be implemented, and the exception must have an expiration date.
Contractual Agreements and Patch Availability
- Contractual agreements go beyond MOUs and SLAs. Hosting, managed-service and support contracts often limit who may change a system. On a provider-managed device, remediation goes through the provider: report the finding, invoke the contract's security terms for a fix date, and document the exposure. Patching it yourself can breach the contract and void support, and removing it from scan scope only hides the risk.
- Patch availability — the vendor has confirmed the flaw but has not released a fix. There is nothing to approve or test yet. Apply the vendor's workaround, add compensating controls (restrict exposure, increase monitoring), keep the finding open against the expected release, and deploy the fix as soon as it ships.
A quick way to tell the inhibitors apart: Is there a fix? (patch availability). Is the fix waiting on process? (governance). Does installing it need an outage? (business process interruption). Does it break something once installed? (degrading functionality). Does an agreement limit who can change the system? (contractual).
Other Inhibitors and How They Are Grouped
- Technical versus business/operational: technical inhibitors are a missing patch, a legacy system, or a patch that breaks a feature or dependency; business or operational inhibitors are change windows, downtime, budget, staffing, skills and contracts.
- Breaking patch or hard-coded dependency: apply compensating controls now, have development refactor the dependency, and set a remediation deadline tied to the development timeline. Do not accept the risk permanently.
- Skills or staffing gaps (for example, nobody can implement network segmentation): escalate the gap to management as a risk, recommend training or hiring, and bridge with a managed service provider. Do not drop the requirement or hand it to someone with no experience.
- Ownership and accountability: when business-unit-owned systems patch far more slowly than IT-owned ones, the usual cause is that security is not in the business units' objectives and they have no patching resources. Assign accountability and resources; do not exclude their systems from scanning.
- Exceptions: an open-exception count that grows faster than exceptions are resolved means the exception process has become a way to avoid remediation. Every exception needs an owner, compensating controls and an expiry date.
- Regulated devices such as medical equipment: with no vendor patch date, apply compensating controls (isolate the devices), press the vendor in writing for a timeline, report the vulnerability to the relevant regulator and coordinators (in the U.S., the FDA and CISA), and plan replacement if the vendor stays unresponsive.
Reflection Question: A vulnerability scanner identifies a critical vulnerability in a third-party payment processing application. The vendor says a patch won't be available for 60 days, and the application processes 100% of the organization's payment transactions 24/7. Identify the inhibitor category, the appropriate risk management response, and two compensating controls that could reduce exposure during the 60-day wait.
