We need to rethink patching going forward, Apu Pavithran, CEO and founder of Hexnode argues. It’s just not possible to immediately address every vulnerability, so risk prioritization becomes a defensible, evidence-based posture.
In June, the Cybersecurity and Infrastructure Security Agency (CISA) gave compliance teams an unexpected gift: permission not to patch most of their vulnerabilities, provided they can defend the decision.
The new directive seeks to redefine urgency against a rising tide of automated vulnerabilities. Federal agencies are therefore moving away from updating software based on a calendar or severity score and toward assessing risk and fast-tracking fixes for the most dangerous within three days.
This is a unique posture that businesses should consider mirroring for this moment. Bad actors are probing networks more aggressively and reducing the time between vulnerability disclosure and exploitation. Matching their speed is near-impossible, so determining what’s a priority and what’s deferrable is the next best course of action.
Crucially, chief compliance officers (CCOs) receive much-needed ammunition to explain to auditors or insurers what’s left unpatched and why. As a result, patch prioritization is becoming both a compliance essential and security foundation.
This shift acknowledges the reality of the AI age. Last year, around 50,000 common vulnerabilities and exposures (CVEs) were announced, up two-thirds from 2023. The notion to “patch everything” as soon as a new vulnerability arrives is no longer feasible in this landscape.
It’s telling that this perspective is gaining traction at a federal level: The nation’s cyber-defense agency is formally instructing teams to stop treating all vulnerabilities as equal and instead triage by risk. Under the directive, a vulnerability is assessed across several factors — public exposure, automatable exploitation, whether exploitation hands an attacker full system control and evidence of real-world exploitation — with only the highest-risk few fast-tracked. Enterprises should sit up and pay attention to this because, in effect, the standard-setter is conceding that risk-based patching is the preferable posture.
Consider this alongside NIST’s recent decision to enrich fewer vulnerability records with severity scores and affected product details. It, too, is struggling with the scale of new vulnerabilities and deciding to focus on threats that appear in the known exploited vulnerabilities (KEV) catalog, affect software used within the federal government or apply to “critical software”.
The onus is increasingly on internal teams not only to decide what to patch first but to log the reasoning behind it. This represents a major change because prompt patching has long been a cornerstone for keeping auditors and insurers onside. But in a triage model, a clear record of what you didn’t patch and why matters just as much.
NIST Database Change Rebalances Burden of Risk
Register of common vulnerabilities and exposures will have less federal context, leaving organizations to decide if a vulnerability warrants quick remediation
Read moreDetailsA compliance decision that creates formal risk acceptance
By taking a page from CISA, corporate compliance can become stronger by plugging the most serious holes and documenting the what and the why of every deferral. This is a beneficial technical and cultural evolution for a few reasons.
First, deferral creates formal risk acceptance. Targeting the worst-of-the-worst vulnerabilities creates a new decision-making chain that takes some of the pressure off IT and loops in the CCO. This way, companies can intentionally defer less serious vulnerabilities and connect patching to governance with an owner, rationale and record.
Second, we already know that very few enterprises remediate every known vulnerability. Last year, only one-quarter (26%) of critical vulnerabilities on CISA’s KEV catalog were fully remediated by organizations, down from 38% the previous year. Given the context of both more sophisticated and numerous threats, the stronger position in front of a regulator is a reasoned, criteria-based decision. Incorporating and enforcing a consistent risk-based stance separates a decision from an excuse, turning “we didn’t get to it” into “we assessed it and deferred it on these grounds.”
This kind of audit trail (what was deferred, against which criteria, signed off by whom and reviewed when) is valuable internally and externally. Most security and regulatory frameworks already require that vulnerability management be evidenced, not merely performed. And cyber-insurers increasingly want to see your thought process at renewal. Being able to align vulnerability management standards with a recognized third-party benchmark puts you in a far stronger position in an exam or breach post-mortem.
Remember, there’s an important difference between ignoring and deferring patches, and this posture gives teams the flexibility to focus on the most dangerous gaps as they emerge.
Moving patch prioritization from theory to practice
Putting this into practice (and making deferral less dangerous) starts with establishing a named owner and approval path. Define who signs, at what risk threshold and how escalations are handled. Having this record ready now, and in the format that an auditor or insurer will ask for, makes things much smoother if and when a breach occurs.
Also connect risk-based patching with your current reporting. For example, SOC 2 — the independent audit of whether a company’s data-security controls actually work as stated — already requires evidence of vulnerability management. However, the framework doesn’t set a rule. Instead, it requires the company itself to establish a defensible, documented and consistently applied process and prove it. This is where teams can incorporate the risk criteria and response timelines defined by CISA, providing a much stronger process than a homegrown one that must be justified from scratch.
Finally, ensure that security and compliance co-own the patch call. The deferral decision needs the former’s risk read and the latter’s documentation discipline. Siloed, it fails both sides of the enterprise. Further, the risk framework only holds if the decision can actually be executed and demonstrated across the ecosystem.
