Patching — The Most Common Remediation Technique
When a vulnerability is identified and a vendor releases a security update, installing the patch is the most direct and effective way to remove the vulnerability. Patching is not a one-time event — it is an ongoing operational process that runs in parallel with continuous vulnerability discovery. New patches arrive constantly; the job of patch management is never finished.
Patches are distributed in two modes. Scheduled patches follow predictable cycles — monthly or quarterly update releases from vendors who batch their security fixes on a calendar. Administrators can plan for scheduled patches: test in staging, schedule maintenance windows, and deploy with appropriate validation. Unscheduled patches are released outside the normal cycle in response to urgent vulnerabilities, particularly zero-days where active exploitation is occurring in the wild. Unscheduled patches compress the normal testing and deployment timeline; organizations must decide how much testing to skip in exchange for closing a vulnerability that attackers are actively exploiting.
The patching process has a standard shape: vendor releases patch, organization tests patch in a staging environment, patch is deployed to production, and deployment is verified. The challenge at scale is doing this continuously across hundreds or thousands of systems, across multiple software vendors, with different patch cycles and different urgency levels. Automation is essential; manual patch management is not feasible at enterprise scale.
Failure to patch on a reasonable timeline is one of the most common causes of significant security incidents. Many large-scale breaches exploit vulnerabilities for which a patch has been available for weeks or months — the attacker is exploiting known vulnerabilities against organizations that have not yet deployed the fix.
Cybersecurity Insurance — Transferring Financial Risk
Cybersecurity insurance transfers a portion of the financial consequences of a security incident to an insurer rather than bearing the full cost internally. It does not prevent incidents or reduce the probability of attack; it reduces the financial impact after an incident occurs. Insurance is a risk transfer strategy, not a risk elimination strategy — it belongs in the remediation framework as a complement to technical controls, not a replacement for them.
Coverage under a typical cybersecurity insurance policy may include: lost revenue resulting from a service outage caused by an attack; data recovery costs for restoring systems and data after a breach or ransomware attack; financial losses from phishing where employees were deceived into transferring funds or credentials; and privacy lawsuit costs when affected customers or partners pursue legal action following a data breach.
Cybersecurity insurance does not cover everything. Standard exclusions include: intentional acts by insured parties (an insider deliberately destroying systems is not a covered claim); unauthorized fund transfers initiated by the insured organization, particularly in business email compromise scenarios; and in some policies, certain acts of negligence or failure to maintain documented security baselines. The rising frequency of ransomware attacks has driven significant growth in cybersecurity insurance adoption across all organization sizes — insurers now commonly require evidence of security controls (MFA, endpoint detection, regular backups) as a condition of coverage or premium pricing.
The correct security posture treats insurance as a backstop: organizations should implement all technically and operationally feasible controls first, and use insurance to cover residual financial risk that cannot be eliminated through those controls.
Segmentation — Limiting the Scope of Exploitation
Segmentation divides the network into isolated zones so that a successful attack on one zone cannot freely spread to the rest of the environment. Even if an attacker exploits a vulnerability on a segmented system, the damage is contained to that segment — they cannot reach systems in adjacent segments without crossing a controlled boundary. Segmentation does not prevent exploitation; it limits its blast radius.
Segmentation is especially important when patching is not immediately possible. If a system cannot be patched due to vendor support limitations, compatibility conflicts, or operational constraints, the next best response is to place it in an isolated segment that restricts its communication with the rest of the network. In the most extreme cases — where a system cannot be patched and cannot be adequately protected by firewall rules — an air gap removes the system from network connectivity entirely, eliminating any remote exploit path while the organization resolves the patching obstacle.
Physical segmentation uses separate physical hardware for each segment: different switches, different cabling, different infrastructure. There is no shared hardware between the segments, making communication between them physically impossible without dedicated interconnect devices. Physical segmentation provides the strongest isolation but is expensive and inflexible.
Logical segmentation via VLANs uses Virtual Local Area Networks to divide a single physical switch into multiple isolated broadcast domains. Ports on the switch are assigned to a VLAN; devices on the same VLAN can communicate with each other; devices on different VLANs cannot communicate directly. The critical rule: inter-VLAN communication requires a Layer 3 device (a router or Layer 3 switch). Without routing, traffic cannot cross VLAN boundaries. VLANs provide flexible, cost-effective segmentation on shared hardware — they are the standard approach in most enterprise environments.
Next-generation firewalls (NGFWs) placed between segments provide visibility and control over inter-segment traffic. Unlike basic firewalls that filter by IP and port, NGFWs can identify the specific application being used — so if a server that should only be serving web traffic suddenly initiates an SSH connection outbound, the NGFW logs and can block that anomalous traffic. NGFWs are the enforcement and monitoring layer that makes segmentation operationally meaningful.
Compensating Controls — Reducing Risk When the Optimal Fix Is Not Available
A compensating control is a security measure deployed as a substitute or supplement when the primary remediation action — typically patching — cannot be performed. Compensating controls do not eliminate the vulnerability; they reduce the likelihood or impact of its exploitation while the organization works toward full remediation. They are a bridge, not a destination.
Common compensating controls for an unpatched vulnerability include:
- Disable the vulnerable service — if the service that contains the vulnerability is shut down, it cannot be exploited. This is the most definitive compensating control short of patching, but it also makes the service unavailable to legitimate users.
- Revoke application access — removing user access to the affected application prevents exploitation through that vector, but also eliminates legitimate use. Appropriate when the user base is small or the risk is immediate.
- Limit external access — firewall rules at the network edge can block inbound access to the vulnerable service from external sources. This protects against remote exploitation but does not protect against insiders or attackers already inside the network.
- Modify internal security controls — router access control lists, host-based firewalls installed on the application server itself, or network-layer restrictions can constrain who can reach the vulnerable service. Useful when internal firewalls are not available.
The hierarchy: patching the application is the best solution. When patching is not immediately possible, compensating controls are used to reduce exposure until the patch can be deployed. Compensating controls should never be treated as permanent solutions; they should be accompanied by a documented plan and timeline for full remediation.
Exceptions and Exemptions — Formal Risk Acceptance
In real-world environments, not every vulnerability can be patched. A patch may cause conflicts with critical software, the vendor may no longer support the system, or operational constraints may make deployment impossible during the required timeframe. When a vulnerability cannot be remediated and compensating controls are insufficient or infeasible, an organization can formally accept the risk through an exception or exemption process.
An exception is the decision to leave a vulnerability unremediated, with documented justification. This is not the same as ignoring the vulnerability — it is a deliberate, governed decision that the risk is acceptable given the specific context. A security committee or change control committee typically owns this decision. A single person should not have the authority to grant exceptions for significant vulnerabilities; the process should require multiple stakeholders to review the vulnerability, evaluate the risk, and formally approve the exception as a group.
Not all vulnerabilities warrant the same response. Some vulnerabilities can only be exploited if an attacker has local, physical access to the affected device. For a server housed in a secured data center with strict physical access controls, the practical risk of local-access-only exploits may be genuinely low. The committee can weigh the exploitation requirements against the remediation cost and operational disruption, and decide that an exception is the appropriate risk management response until the patch conflict is resolved.
Exceptions must be documented, time-limited where possible, and reviewed periodically. An exception granted today because of a patch conflict should be revisited when the conflict is resolved or the software is upgraded. Exceptions are not permanent approvals; they are documented risk acceptance decisions with review obligations.
Validation of Remediation — Confirming the Fix Actually Worked
Deploying a patch does not guarantee that the vulnerability has been remediated. Patches can fail to install silently, be rolled back by conflicting software, or be applied to the wrong set of systems. Systems that were offline during deployment may have been missed entirely. Validation is the process of confirming that the remediation actually removed the vulnerability.
Rescanning: After deploying a patch, run a vulnerability scan against the patched systems. A scan that shows the vulnerability is no longer detected is positive evidence that the patch was installed and is effective. Rescanning also identifies systems that should have received the patch but did not — systems that were offline, missed in the deployment scope, or failed to install the patch successfully.
Auditing: Review deployment records, patch management logs, and system configurations to verify that the patch was applied correctly. Auditing provides accountability and documentation for compliance purposes, and can identify gaps between what the deployment system reports ("patch deployed") and what the system actually shows (patch present and active).
Verification: For critical systems or complex vulnerabilities, manual verification may be required — physically or remotely logging into the system to confirm the patch version, check the specific configuration change, or in some cases attempt to reproduce the exploit to confirm it is no longer possible. Manual verification is time-intensive but provides the highest confidence for high-risk systems.
Validation is especially important for Critical and High severity vulnerabilities. Believing a system is patched when it is not is functionally the same as a false negative: the organization has a false sense of security while the real risk remains.
Reporting — Continuous Visibility Across the Remediation Pipeline
Vulnerability remediation at scale requires a reporting infrastructure that provides ongoing visibility into the state of all identified vulnerabilities across all systems. Manual tracking is impractical once an organization grows past a handful of systems — an environment with hundreds or thousands of endpoints requires automated tooling to monitor the patching pipeline continuously.
Continuous vulnerability reports should track: the total number of identified vulnerabilities in the environment (the overall exposure picture); patched vs. unpatched systems (remediation progress and gaps); new threat notifications as newly published CVEs are identified that affect systems in the environment; patch errors where deployment attempts failed; and exceptions and exemptions where vulnerabilities have been formally accepted rather than remediated. Together these metrics give security leadership, system administrators, and management a real-time view of organizational risk.
Automated reporting tools also drive accountability. When a report shows that a Critical vulnerability has been open on a specific system for 14 days and the SLA requires 72-hour remediation, the reporting system creates a documented gap that management can act on. Reporting converts the patch management process from a reactive, ad-hoc activity into a measured, governable operation with clear metrics and accountability.