You got the audit notice. Or maybe your cyber insurance carrier sent a renewal questionnaire that asked, in plain terms, whether you have a documented patch management process. You asked your IT contact. They said, "Yeah, we handle updates." You wrote that down and moved on.
That gap between "we handle updates" and a documented, defensible patching process is exactly where compliance violations live, and where breach liability begins.
This post explains how vulnerability patching connects directly to HIPAA, NIST, and ISO 27001 requirements, what auditors actually look for, and what a compliant patching process looks like in practice for a business your size.
Compliance frameworks may not use the word "patching" in their language, but they talk about "vulnerability management," "system hardening," and "risk remediation." All point to the same operational activity: identifying software weaknesses and fixing them on a defined schedule. Here's how the major frameworks break down.
HIPAA (Health Insurance Portability and Accountability Act) requires covered entities and business associates to implement technical security measures that guard against unauthorized access to electronic protected health information (ePHI). The Security Rule's Technical Safeguard provisions don't prescribe patch timelines by name, but HHS audit guidance has consistently treated unpatched systems as a failure to implement reasonable and appropriate safeguards.1 If a breach occurs and your systems were running known, unpatched vulnerabilities, that's a problem in front of an auditor.
NIST (National Institute of Standards and Technology) is more prescriptive. The NIST Cybersecurity Framework and NIST SP 800-53 both include explicit controls around patch management under the "Protect" and "Respond" functions.2 For organizations using NIST as their baseline, there's an expectation of defined patching windows, risk-tiered remediation timelines, and documented evidence that patches were applied and verified.
ISO 27001 takes a risk management approach. Annex A Control 8.8 of the 2022 standard, "Management of Technical Vulnerabilities," requires organizations to document their vulnerability management process, assign ownership, and act within defined timeframes based on the severity of the vulnerability.3 Certification auditors will ask to see your policy and your evidence log.
The common thread: all three frameworks treat patching as a managed, documented process, not a background task.
There's a difference between applying patches and managing vulnerabilities. "We do updates" typically means someone installs Windows updates when prompted, maybe restarts servers during off-hours, and calls it done. That approach leaves several gaps that auditors will find quickly.
No risk prioritization. Not all vulnerabilities carry the same risk. A critical vulnerability in a patient-facing web application is not the same as a minor update to a locally-installed PDF reader. Compliance frameworks expect you to triage based on severity, exploitability, and the sensitivity of the data involved.
No defined remediation windows. NIST and ISO 27001 both expect documented timelines: critical patches within 24–72 hours, high-severity patches within 7–14 days, and so on. Without defined windows, you have no way to demonstrate that your response was timely.
No documentation trail. If you can't produce a log showing what was patched, when, and by whom, auditors have no evidence to work with. The absence of documentation is treated as the absence of a process.
Incomplete asset coverage. Updates applied to workstations but not servers, or to on-site machines but not remote endpoints, create exploitable blind spots. A compliant patching program covers every managed asset, including cloud-hosted systems, third-party software, and network devices.
A defensible patching program has four components working together.
Asset inventory. You can't patch what you haven't catalogued. This means a current, maintained list of every device, operating system, and application in your environment. For HIPAA-covered organizations, this inventory should note which assets touch or transmit ePHI.
Vulnerability scanning. Automated tools scan your environment on a defined schedule, typically weekly or monthly, and produce a prioritized list of detected vulnerabilities. This is where you find out what's exposed before an attacker does.
Risk-tiered remediation timelines. Using a scoring system like CVSS (Common Vulnerability Scoring System), vulnerabilities get categorized by severity. Your written policy defines how quickly each tier must be addressed. This policy is what auditors read.
Documented evidence. Every patch applied gets logged: what system, what vulnerability it addressed, when it was applied, and by whom. That log becomes your compliance evidence. It also becomes your incident response starting point if something goes wrong.
For most businesses in the 20–80 employee range, this process runs through an RMM (remote monitoring and management) platform operated by your IT provider. The key is whether your provider is running that platform to produce compliance-grade documentation, or just using it to push updates reactively.
Ask your current IT provider for a patch compliance report. Specifically, ask for:
If they can't produce these within a few business days, you don't have a compliant patching process. You have someone applying updates. That distinction matters to your auditor, your insurer, and potentially to your customers if a breach occurs.
If you're unsure where your patching program stands relative to HIPAA, NIST, or ISO 27001, that's worth a direct conversation. Our managed IT and cybersecurity services are built to support compliance requirements, not just keep systems running.