<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Reporting patching and vulnerability metrics in Governance, Risk, Compliance</title>
    <link>https://community.isc2.org/t5/Governance-Risk-Compliance/Reporting-patching-and-vulnerability-metrics/m-p/89591#M1475</link>
    <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/1591601117"&gt;@Dom&lt;/a&gt;&amp;nbsp;wrote:&lt;BR /&gt;&lt;P&gt;I'm interested in how others are handling patching metrics.&amp;nbsp;We currently report patching using:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;% endpoints missing critical/important patches outside a 14-day SLA (aligned to UK Cyber Essentials), and&lt;/LI&gt;&lt;LI&gt;total high/critical vulnerabilities aged &amp;gt;14 days.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;The idea was to show both patching coverage and the depth of exposure.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This has worked pretty well historically, but over the last 6 months we’ve been rolling out new laptops and have hit some patching issues. As a result, we’ve now got ~16% of devices outside SLA, and they’re missing multiple &lt;A href="https://deltaxecutr.com.mx/" target="_self"&gt;&lt;FONT color="#333333"&gt;patch&lt;/FONT&gt;&lt;/A&gt; cycles, which is driving a big spike in vulnerability counts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I’m starting to get some pressure internally that the metrics are either too harsh or don’t reflect operational performance properly.&amp;nbsp;I still think they’re right from an infosec risk perspective.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Interested in how others are balancing patch SLA vs vulnerability metrics in reporting?&lt;/STRONG&gt;&lt;/P&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;I think your metrics are reasonable from a risk point of view, but I can also see why people are pushing back if the numbers suddenly look much worse during a laptop rollout. The problem may not be the metrics themselves, but how they’re being presented.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What I’ve seen work well is separating operational performance from security risk. For example, keep your current metrics because they show real exposure, but add context around them. You could report something like: % outside SLA, mean age of overdue patches, and business/risk impact of the vulnerabilities rather than only raw counts. Raw vulnerability numbers can spike fast when devices miss several cycles, which sometimes makes things look worse than they actually are operationally.&lt;/P&gt;</description>
    <pubDate>Tue, 12 May 2026 09:21:47 GMT</pubDate>
    <dc:creator>sanixa</dc:creator>
    <dc:date>2026-05-12T09:21:47Z</dc:date>
    <item>
      <title>Reporting patching and vulnerability metrics</title>
      <link>https://community.isc2.org/t5/Governance-Risk-Compliance/Reporting-patching-and-vulnerability-metrics/m-p/89270#M1473</link>
      <description>&lt;P&gt;I'm interested in how others are handling patching metrics.&amp;nbsp;We currently report patching using:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;% endpoints missing critical/important patches outside a 14-day SLA (aligned to UK Cyber Essentials), and&lt;/LI&gt;&lt;LI&gt;total high/critical vulnerabilities aged &amp;gt;14 days.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;The idea was to show both patching coverage and the depth of exposure.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This has worked pretty well historically, but over the last 6 months we’ve been rolling out new laptops and have hit some patching issues. As a result, we’ve now got ~16% of devices outside SLA, and they’re missing multiple patch cycles, which is driving a big spike in vulnerability counts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I’m starting to get some pressure internally that the metrics are either too harsh or don’t reflect operational performance properly.&amp;nbsp;I still think they’re right from an infosec risk perspective.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Interested in how others are balancing patch SLA vs vulnerability metrics in reporting?&lt;/STRONG&gt;&lt;/P&gt;</description>
      <pubDate>Sun, 19 Apr 2026 08:03:50 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Governance-Risk-Compliance/Reporting-patching-and-vulnerability-metrics/m-p/89270#M1473</guid>
      <dc:creator>Dom</dc:creator>
      <dc:date>2026-04-19T08:03:50Z</dc:date>
    </item>
    <item>
      <title>Re: Reporting patching and vulnerability metrics</title>
      <link>https://community.isc2.org/t5/Governance-Risk-Compliance/Reporting-patching-and-vulnerability-metrics/m-p/89591#M1475</link>
      <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/1591601117"&gt;@Dom&lt;/a&gt;&amp;nbsp;wrote:&lt;BR /&gt;&lt;P&gt;I'm interested in how others are handling patching metrics.&amp;nbsp;We currently report patching using:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;% endpoints missing critical/important patches outside a 14-day SLA (aligned to UK Cyber Essentials), and&lt;/LI&gt;&lt;LI&gt;total high/critical vulnerabilities aged &amp;gt;14 days.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;The idea was to show both patching coverage and the depth of exposure.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This has worked pretty well historically, but over the last 6 months we’ve been rolling out new laptops and have hit some patching issues. As a result, we’ve now got ~16% of devices outside SLA, and they’re missing multiple &lt;A href="https://deltaxecutr.com.mx/" target="_self"&gt;&lt;FONT color="#333333"&gt;patch&lt;/FONT&gt;&lt;/A&gt; cycles, which is driving a big spike in vulnerability counts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I’m starting to get some pressure internally that the metrics are either too harsh or don’t reflect operational performance properly.&amp;nbsp;I still think they’re right from an infosec risk perspective.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Interested in how others are balancing patch SLA vs vulnerability metrics in reporting?&lt;/STRONG&gt;&lt;/P&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;I think your metrics are reasonable from a risk point of view, but I can also see why people are pushing back if the numbers suddenly look much worse during a laptop rollout. The problem may not be the metrics themselves, but how they’re being presented.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What I’ve seen work well is separating operational performance from security risk. For example, keep your current metrics because they show real exposure, but add context around them. You could report something like: % outside SLA, mean age of overdue patches, and business/risk impact of the vulnerabilities rather than only raw counts. Raw vulnerability numbers can spike fast when devices miss several cycles, which sometimes makes things look worse than they actually are operationally.&lt;/P&gt;</description>
      <pubDate>Tue, 12 May 2026 09:21:47 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Governance-Risk-Compliance/Reporting-patching-and-vulnerability-metrics/m-p/89591#M1475</guid>
      <dc:creator>sanixa</dc:creator>
      <dc:date>2026-05-12T09:21:47Z</dc:date>
    </item>
  </channel>
</rss>

