{"id":8109,"date":"2026-05-12T09:00:00","date_gmt":"2026-05-12T09:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8109"},"modified":"2026-05-12T09:00:00","modified_gmt":"2026-05-12T09:00:00","slug":"why-patching-slas-should-be-the-floor-not-the-strategy","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8109","title":{"rendered":"Why patching SLAs should be the floor, not the strategy"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

I\u2019ve been a CISO for two separate companies, know several CISOs personally, and interact with many others through various cybersecurity forums. We all have one thing in common. We can tell you our patching SLA numbers off the top of our heads. Ninety-five percent of criticals closed in 14 days. Eighty-something on highs. The board slide is green. The auditors are satisfied. The client questionnaires come back clean.<\/p>\n

Then I ask a different question: what still needs to be done? And the tone shifts from the confident \u201cWe\u2019ve got it all covered\u201d to \u201cWellll\u2026 we\u2019ve got some legacy tech debt holding us back.\u201d<\/p>\n

What they\u2019re really saying, when someone\u2019s been in the role long enough to stop performing, is usually some version of this: the stuff we closed fast was the stuff that was cheap to close. The stuff that\u2019s still open is the stuff that would require us to re-architect a service, take a critical system offline or fight with a business owner who doesn\u2019t want to hear it. So, we keep closing easy criticals to keep the dashboard green, and the hard problems age quietly in the backlog where no one looks.<\/p>\n

This is the part of vulnerability management nobody wants to say out loud: we have built an entire governance industry around measuring the wrong thing. SLAs tell you how disciplined your ticketing process is. They tell you almost nothing about your actual risk.<\/p>\n

The compliance trap<\/h2>\n

I\u2019ve watched this pattern play out across enough programs to be confident it\u2019s not an outlier. An organization commits to a thirty-day SLA for critical vulnerabilities. The vulnerability management team gets measured on that SLA. So, they get very, very good at hitting it \u2014 for the vulnerabilities that are easy to hit it on.<\/p>\n

What gets closed fast: anything an agent can patch remotely. Anything in a containerized workload that rebuilds nightly. Anything where the vendor has already shipped a clean update and the change advisory board will approve it without debate.<\/p>\n

What doesn\u2019t get closed: the legacy ERP module that can\u2019t be patched without breaking three downstream integrations. The embedded system in the warehouse that runs an operating system whose vendor went out of business in 2019. The Windows 2000 server under the sysadmin\u2019s desk who\u2019s been at the company since 1995. The misconfiguration in the core identity provider that, if changed, would lock out a business unit for a day while someone rebuilds their SSO flow. The architectural flaw in the authentication layer that\u2019s technically a CVSS 7 but practically an existential exposure because it sits in front of the crown jewels.<\/p>\n

Those don\u2019t move. They get relegated to the Island of Misfit Risks \u2014 exception queues, risk-accepted trackers, or the backlog of whatever team has owned the system or function since 2017. And the SLA report stays green because the denominator is dominated by the easy stuff, and the business has \u201caccepted the risk.\u201d<\/p>\n

I\u2019ve been the person who had to explain to a board that our SLA compliance was ninety-four percent and our biggest single point of failure was in the six percent. It is not a fun conversation. It is, however, the correct one. And the reason it almost never happens is because the entire reporting apparatus is structured to make it invisible.<\/p>\n

SLAs measure discipline, not risk<\/h2>\n

Here\u2019s the mental model I\u2019ve been pushing with my peers. Think of patching SLAs the way you think of fire drills. Fire drills are necessary. They prove that, on a predictable cadence, your organization can execute a known procedure. No one in charge of a building full of people would claim that a successful fire drill means the building is safe. They would tell you the building is safe when the sprinklers, the structural design, the exits and the materials all hold up to a scenario you didn\u2019t script.<\/p>\n

Patching SLAs are fire drills. They prove your program can execute a known procedure on a predictable cadence. They do not tell you whether you\u2019re protected against the scenario you didn\u2019t script \u2014 the chained exploit path, the misconfigured trust boundary, the control that looks present in the GRC tool but has been silently failing for eight months, or my favorite, \u201cthat control works for everywhere except XYZ business unit.\u201d<\/p>\n

When I ask a CISO how much cyber risk they have, they struggle to articulate it. They talk about the attack surface, the number of vulnerabilities, an audit score. Rarely do I hear them say something like, \u201cWe have $252M in cyber risk.\u201d What if we as CISOs could articulate how much risk we have in terms of dollars and finally be able to build a business case for solving those hard vulnerabilities, misconfigurations and control breakdowns instead of trying to sell fear, uncertainty and doubt?<\/p>\n

That question has an answer, and it\u2019s one the FAIR Institute has been formalizing for years<\/a>: cyber risk quantification, or CRQ. I\u2019m not here to evangelize a methodology. There are several \u2014 some more defensible than others \u2014 and the specific choice matters less than the discipline of forcing vulnerabilities, misconfigurations and control gaps into loss-exposure terms rather than severity labels. When I tell a CFO that an unpatched CVSS 9.8 exists on a server, their eyes glaze over. When I tell them we have an estimated twelve-million-dollar annualized loss exposure concentrated in one unremediated architectural flaw, we have a very different conversation \u2014 and, in my experience, a very different remediation budget.<\/p>\n

Three shifts that actually move the needle<\/h2>\n

If you\u2019re a security leader trying to pull your program out of SLA theater and into something that reflects real risk, here\u2019s what I\u2019ve seen work.<\/p>\n

Treat the SLA as the floor of what\u2019s required, not the ceiling of what\u2019s reported.<\/strong> Continue to meet your contractual and regulatory SLA commitments \u2014 they exist for good reasons and customers ask about them. But stop presenting SLA compliance as the headline metric of your vulnerability management program. It\u2019s a hygiene measure. Put it on a hygiene slide. The headline metric should be the trend of your quantified residual risk; broken out by the business services it threatens.<\/p>\n

Make your exception process produce better decisions, not just documented ones.<\/strong> In most of the programs I\u2019ve reviewed, the risk acceptance process is a filing exercise with risks living on the register for years. Someone signs a form, the ticket gets closed as \u201crisk accepted,\u201d and the exposure disappears from the SLA report until the exception expires in the GRC tool next year. That\u2019s not risk management. That\u2019s paperwork. A functional exception process requires the business owner to see the quantified loss exposure they\u2019re accepting, agree to revisit it on a defined cadence and \u2014 for the biggest exposures \u2014 commit to a remediation plan with a funded timeline. Research from Verizon\u2019s 2025 DBIR<\/a> found that among the edge device vulnerabilities featured in the report, the average time to patch was 209 days while attackers\u2019 median time-to-exploitation was five days \u2014 a gap that exists because the fixes live where change is hardest. That same pattern shows up in CISA\u2019s Known Exploited Vulnerabilities catalog<\/a>, populated largely with CVEs that had patches available long before they were used in the wild. That isn\u2019t a patching problem. That\u2019s an exception-hygiene problem.<\/p>\n

Fund remediation the way you fund other capital and opex projects.<\/strong> The hard vulnerabilities \u2014 the ones that require re-architecting a service, replacing an end-of-life platform or rebuilding an identity flow \u2014 aren\u2019t going to get solved out of the quarterly operational budget. They require capital and opex investment, and they compete with every other business investment. Quantified risk is what lets you compete on equal terms. \u201cWe need to rebuild the authentication layer because it\u2019s old and unsupported\u201d will lose that fight eight out of 10 times. \u201cWe need to rebuild the authentication layer because it represents a $10M cyber risk exposure, and a $1M investment to remediate will reduce our cyber risk by a net of $9M\u201d wins it often enough to matter.<\/p>\n

One final note, because I get this question every time I talk about CRQ with a skeptical audience. Your loss-exposure estimates are going to be imprecise. The inputs are uncertain, the ranges are wide and any honest quantification exercise produces results that could be picked apart by a determined critic. That\u2019s fine. A CFO or an actuary can argue the number is $8M rather than $10M \u2014 still fine. At least you have a number people can anchor to, versus the old patching scorecard that said everything was rainbows and unicorns.<\/p>\n

A green SLA dashboard tells an executive that their security team is disciplined. A quantified risk picture tells them where their actual exposure is and what it would cost to reduce it. One of those conversations gets the hard stuff fixed. The other one gets it documented and forgotten.<\/p>\n

SLAs are the floor. If that\u2019s all you\u2019re standing on, you\u2019re closer to the ground than you think.<\/p>\n

This article is published as part of the Foundry Expert Contributor Network.<\/strong>
Want to join?<\/a><\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

I\u2019ve been a CISO for two separate companies, know several CISOs personally, and interact with many others through various cybersecurity forums. We all have one thing in common. We can tell you our patching SLA numbers off the top of our heads. Ninety-five percent of criticals closed in 14 days. Eighty-something on highs. The board […]<\/p>\n","protected":false},"author":0,"featured_media":8110,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8109","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8109"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8109"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8109\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8110"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}