A Practical SMB Patch Cadence: Risk-Based Triage Without a SOC

Patching every CVE the day it ships is how a one-person IT team breaks the business. A sustainable cadence is risk-based: triage with public signals, patch on a predictable schedule, and prove the work to the owner.

A solo IT admin or a team of three drowns in CVEs. The National Vulnerability Database publishes thousands a year, and the instinct to "patch everything immediately" produces two failures at once — instability from rushed updates on core servers, and burnout that leaves the long tail unpatched anyway. The fix is not more effort. The fix is a cadence that treats patching as a scheduled, measurable practice instead of a panic response.

ISO/IEC 27001:2022 asks for exactly this in Annex A control A.8.8 Management of technical vulnerabilities: "Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken." The standard does not say patch everything instantly. It says obtain, evaluate, act — a triage loop. This article builds that loop for an SMB.

Stop chasing every CVE

The volume is the enemy. Trying to remediate every published vulnerability means the team never finishes and never measures. Worse, the highest-risk fixes get the same urgency as a low-severity disclosure on a component you barely use.

A risk-based cadence inverts that. You accept that some vulnerabilities will sit unpatched for weeks — by design — because the exposure is low. You concentrate the team’s limited hours on the small fraction that matters. That fraction is identified with two free public signals, not with gut feel.

The risk-based triage framework

Two datasets do the heavy lifting, and both are free.

CISA’s Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of active exploitation in the wild. If a CVE is on KEV, someone is using it right now — patch it first, regardless of the CVSS score. KEV is the closest thing to a "patch today" list that exists.

EPSS (Exploit Prediction Scoring System), run by FIRST, gives a probability score from 0 to 1 that a given CVE will be exploited in the next 30 days. A CVSS 9.5 with an EPSS of 0.001 is theoretical; a CVSS 6.5 with an EPSS of 0.9 is the one that will hit you. EPSS sorts the long tail by likelihood, which is what a small team actually needs.

The triage rule for an SMB:

1. On KEV? Patch within 72 hours. Exploitation is confirmed.
2. EPSS above 0.5 (or top quartile for your stack)? Patch within 14 days.
3. CVSS 7+ but low EPSS, not on KEV? Roll into the monthly cycle.
4. CVSS below 4, low EPSS? Batch quarterly, or accept with a documented rationale.

This is the "evaluate" step of A.8.8. You are not ignoring the rest — you are sequencing it.

A sustainable monthly cadence

Pick a fixed day. The second Tuesday (Microsoft’s Patch Tuesday) is a common anchor because vendor patches land then anyway. Build the month around it.

• Criticals (KEV or EPSS > 0.9): within 72 hours of disclosure, with a rollback plan.
• Highs (EPSS > 0.5, or CVSS 8+ on internet-facing systems): within 14 days, in the next maintenance window.
• Moderates: the monthly Patch Tuesday batch, applied to workstations automatically and to servers after a test pass.
• Lows: quarterly batch, documented.

The predictability is the point. The SMB owner can be told "patches land the second Tuesday and the following Tuesday for validation," and that becomes a business rhythm instead of a string of surprises. A.8.8 expects "appropriate measures" — a documented cadence with time-bound targets is exactly that, and it is auditable evidence.

Automation versus manual control

Treat workstations and servers differently. Workstations are numerous, largely interchangeable, and low-blast-radius if one fails — automate. Servers are few, business-critical, and high-blast-radius — validate manually.

• Workstations: automated deployment through the MDM or patch tool, staged rollouts (10% pilot, then the rest), with a rollback if telemetry spikes.
• Core servers (domain controllers, the ERP, the database, the payment handler): manual. Apply in a maintenance window, on a snapshot or backup, with a defined validation checklist and a tested rollback.

The split matches A.8.9 Configuration management: "Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored and reviewed." A patched server is a configuration change, and configuration changes on critical assets get reviewed, not pushed blindly.

The validation phase: do not break the business

A patch that takes down the ERP on Monday morning is worse than the vulnerability it fixed. Validation does not require a QA lab. For an SMB, a short checklist is enough:

• Snapshot or backup the system before patching.
• Apply the patch in a maintenance window.
• Run the three business-critical transactions the system serves (log in, run the report, send the test invoice).
• Check the application log and the OS event log for new errors.
• If anything fails, roll back from the snapshot and log the failure for the next window.

Keep the checklist as a one-pager in the runbook. A.8.8’s "appropriate measures" includes verification — an auditor will ask how you know a patch worked, and "the ERP came up and the test invoice posted" is a better answer than "it looked fine."

Reporting the invisible work

Patch management is invisible until something breaks. That makes it hard to justify budget. Three simple metrics, tracked monthly, fix that:

• Patch coverage: percentage of in-scope systems at or below your accepted exposure threshold (e.g. "92% of systems have no KEV-listed CVE outstanding").
• Mean time to remediate (MTTR) by severity: average days from disclosure to patch, split by Critical / High / Moderate.
• Deferred patches with rationale: the count of accepted-risk items and their review dates.

These three numbers, in a one-line email or a dashboard tile, show the owner the network is getting safer over time and give the auditor concrete evidence that A.8.8 and A.8.9 are operating, not just documented.

How this fits the series

This cadence is one operational control inside the broader ISO 27001 system. It maps to the technological theme of Annex A (A.8.8 and A.8.9), and the risk-sequence logic mirrors the risk assessment process — same triage discipline applied to a different input. If you have not yet built the Statement of Applicability that records these controls, the SoA template shows the columns.

What to do next

Pull the CISA KEV catalog and your asset list, cross-reference them this week, and patch everything on KEV within 72 hours. That single pass closes the exposures most likely to hit you. Then pick the second Tuesday as your anchor day, write the four-tier cadence into the runbook, and start logging coverage and MTTR. A defensible patch practice is a month of work, not a quarter.

Need an outside check on your patch practice before an audit? Book a 30-min ISO 27001 readiness assessment — we map your current patch and configuration controls against Annex A and flag the gaps. → /iso-27001-assessment/