← All posts

Patch Management for SMBs: The Security Control You Can't Afford to Get Wrong

The average time from vulnerability disclosure to exploit is now 15 days. If your patching cycle is 90 days, attackers have a 75-day head start.

Patch management sounds like an IT housekeeping task. It's not. It's one of the most critical security controls your business has — and one of the most commonly failed controls in every compliance assessment I run.

Every major breach report tells the same story: the attacker exploited a known vulnerability for which a patch was available. Not a zero-day. Not an advanced persistent threat using nation-state tools. A known, patched vulnerability that nobody applied.

This guide explains why patching matters more than most businesses realise, what the compliance frameworks require, and how to build a patching process that actually works for an SMB.

Why Patching Is a Board-Level Issue

Patching isn't just an IT task — it's a risk management decision. Here's why it matters beyond the technical:

Regulatory exposure. NIS2 Article 21 requires vulnerability handling and disclosure. ISO 27001 Annex A 8.8 requires technical vulnerability management. DORA requires ICT systems to be maintained and updated. GDPR Article 32 requires security measures "appropriate to the risk" — running unpatched systems processing personal data is hard to defend as appropriate.

Insurance exposure. Cyber insurers routinely ask about patch management processes. Some now require evidence of patching SLAs. Claims have been denied where the insurer demonstrated that a patch was available for the exploited vulnerability and the policyholder failed to apply it within a reasonable timeframe.

Contractual exposure. Enterprise clients increasingly require suppliers to demonstrate a patch management process as part of vendor security assessments. If you can't show a defined process, you risk losing contracts.

The Numbers That Should Worry You

The threat landscape around unpatched vulnerabilities is stark:

  • The average time from CVE disclosure to exploit in the wild has dropped to approximately 15 days
  • Over 50% of successful cyberattacks exploit vulnerabilities for which a patch has been available for more than a year
  • Ransomware groups actively scan for known unpatched vulnerabilities as their primary initial access vector
  • The Cybersecurity and Infrastructure Security Agency (CISA) maintains a Known Exploited Vulnerabilities (KEV) catalogue — every entry is a vulnerability being actively exploited in the wild

What Compliance Frameworks Require

Every major framework addresses patch management, but with different levels of specificity:

NIS2 — Article 21(2)(e) requires "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." In practice, this means a documented vulnerability management process with defined remediation timelines.

ISO 27001 — Annex A 8.8 (Technical Vulnerability Management) requires organisations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures in a timely manner. The standard expects a documented process with defined responsibilities and timeframes.

DORA — Article 7 requires financial entities to maintain and update their ICT systems. The resilience testing requirements in Pillar 3 include vulnerability assessments at least annually. Unpatched systems would be flagged in any DORA assessment.

NIST CSF — The Identify and Protect functions both address vulnerability management. NIST expects organisations to identify, prioritise, and remediate vulnerabilities based on risk.

Cyber Essentials — Explicitly requires that software is kept up to date with patches applied within 14 days for critical and high-severity vulnerabilities.

Building an SMB-Friendly Patching Policy

You don't need a 30-page policy. You need a clear, practical process that your team can follow. Here's a framework:

Define Your Patching SLAs

Classify patches by severity and set maximum timeframes for each:

  • Critical (actively exploited or CVSS 9.0+): 14 days
  • High (CVSS 7.0–8.9): 30 days
  • Medium (CVSS 4.0–6.9): 90 days
  • Low (CVSS below 4.0): Next scheduled maintenance window

These timelines should be documented in a policy and approved by management.

Maintain an Asset Inventory

You can't patch what you don't know about. Maintain a list of all systems, operating systems, and software versions. Include cloud services, SaaS applications, and third-party components. This is also a requirement of ISO 27001 and NIS2.

Establish a Patch Review Process

Not every patch can be applied immediately. Your process should include:

  • Monitoring for new patches (subscribe to vendor advisories, monitor CISA KEV)
  • Assessing relevance to your environment
  • Testing patches in a non-production environment where possible
  • Scheduling and applying patches within your SLA
  • Verifying successful deployment
  • Documenting exceptions with risk acceptance and compensating controls

Automate Where Possible

For SMBs, manual patching across every system is unsustainable. Use:

  • Automatic updates for operating systems (Windows Update, macOS Software Update)
  • Managed patching tools for endpoint fleet management
  • Automated container image rebuilds for containerised applications
  • Dependency scanning for software development (Dependabot, Snyk, Renovate)

Track and Report

Keep records of:

  • Patches applied (what, when, to which systems)
  • Outstanding patches and their SLA status
  • Exceptions and risk acceptances
  • Metrics: average time to patch, percentage of systems within SLA

These records are what auditors, insurers, and clients will ask for.

Common Mistakes

  1. No defined SLA — "We patch regularly" isn't a policy. Without defined timeframes, there's no accountability and no way to measure compliance.

  2. Ignoring third-party software — Operating system patches get attention, but third-party applications (browsers, PDF readers, Java, productivity tools) are frequently exploited and often overlooked.

  3. No asset inventory — If you don't know what's running in your environment, you can't assess your exposure when a new vulnerability is disclosed.

  4. Patching only servers, not endpoints — Laptops and workstations are the most common initial access vector. They need the same discipline as servers.

  5. No exception process — Sometimes a patch can't be applied (compatibility issues, legacy systems). That's fine — but the exception must be documented with a risk assessment and compensating controls.

How ShieldIQ Helps

ShieldIQ's compliance assessments across NIS2, ISO 27001, DORA, NIST CSF, and Cyber Essentials all evaluate your vulnerability and patch management processes. The AI-powered analysis identifies gaps and prioritises remediation.

Ready to find out where your patch management stands?

Start your free compliance assessment at app.shieldiqcyber.com

No credit card. No sales call. Under 15 minutes.