A critical update lands while the firm is closing its books or serving patients. Installing it immediately could interrupt a vital system. Waiting could leave a known weakness exposed.
That conflict is the daily work of patch management. A usable process reflects the governing rule, records when the clock starts, prepares for failed changes, and verifies the result.
The timing matters now. On June 10, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) issued a directive with tiered remediation deadlines. New York State Department of Financial Services (NYDFS) rules and January 2026 federal healthcare guidance also address vulnerability management.
This article focuses on those clocks and the operating process behind them. For the wider regulatory picture, see Nu-Age’s overview of evolving cybersecurity regulations.
What Is Patch Management?
The National Institute of Standards and Technology (NIST) defines enterprise patch management in its April 2022 guide. It is “the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.” The guide treats the work as preventive maintenance, not an occasional emergency response.
Patch management and vulnerability management are related but different. Vulnerability management finds, analyzes, and prioritizes weaknesses. Patch management handles one common form of remediation. Some risks instead require a configuration change, isolation, replacement, or another mitigation.
Patch Management Rules, Benchmarks, and Proposals
There is no single deadline for every regulated firm or vulnerability. The applicable clock depends on the governing rule and the risk.
| Framework | Who it applies to | What the timeline or duty means |
|---|---|---|
| CISA Binding Operational Directive (BOD) 26-04 | Federal civilian executive branch agencies | Runs from three days, with forensic triage, for the highest-risk cases to the next scheduled upgrade for the lowest-risk cases. Its timelines phase in over 180 days. Private firms are not bound. |
| NYDFS Part 500 | NYDFS covered entities subject to Section 500.5 | Requires vulnerability monitoring and timely remediation prioritized by risk. Scans, plus manual review where scans do not reach, follow the risk assessment and material system changes. |
| Current Health Insurance Portability and Accountability Act (HIPAA) Security Rule | HIPAA covered entities and business associates | Requires risk analysis and risk reduction to a reasonable and appropriate level. It has no general 15-day or 30-day patch deadline. |
| Proposed HIPAA Security Rule | Covered entities and business associates, only if finalized and applicable | Proposed critical-risk and high-risk patching deadlines, not current law. The proposed clock triggers are explained below. |
CISA’s BOD 26-04 weighs internet exposure, Known Exploited Vulnerabilities (KEV) status, exploit automation, and technical impact. Removing a system from the internet can be a valid mitigation. As of September 2026, its 180-day phase-in is underway; Table 1 deadlines become mandatory for agencies by early December 2026.
For an entity subject to 23 NYCRR 500.5, the rule requires vulnerability monitoring and timely remediation prioritized by risk. Under Section 500.22’s transition schedule, automated scanning took effect May 1, 2025, and asset inventory took effect November 1, 2025. Those dates have passed, but qualifying entities may have a limited exemption from Section 500.5.
Healthcare organizations should distinguish the current rule from the January 2025 proposal. For a critical risk, the proposal would set 15 calendar days from identifying the need when an update is available, or from when one becomes available. For a high risk, it proposes 30 calendar days from identifying the need. These are proposed deadlines, not current requirements.
A Seven-Step Patch Management Process
- Maintain the asset inventory. Record endpoints, applications, network devices, firmware, owners, exposure, and purpose.
- Identify applicable updates. Monitor vendor alerts and scan for vulnerabilities, missing patches, and obsolete software. Compare findings with CISA’s KEV catalog.
- Prioritize by actual risk. Record whether the asset is publicly exposed, whether the vulnerability appears in the KEV catalog, and whether an attacker can automate every step of exploitation. Also record whether exploitation grants partial or total control. Then account for the system’s business role.
- Acquire the approved update. Confirm that it applies to the affected version and comes from the approved source.
- Test before production where possible. The U.S. Department of Health and Human Services (HHS) recommends non-production testing where possible. Before deployment, have the service owner define essential business checks and a recovery plan. If testing would threaten a deadline or internal target, escalate before delaying the update.
- Install and verify. Check deployment status and the installed version. Rescan for the targeted vulnerability where the tool supports it, and confirm that the service still performs its required function.
- Document exceptions and mitigation. If an update cannot be installed by the applicable deadline or internal target, escalate to named business and compliance owners. Record the reason, temporary control, approval, review date, and remediation plan. Internal approval does not permit disregarding a requirement.
What a Patch Management Policy Should Contain
A patch management policy sets decision rights and evidence requirements. Keep it usable and testable.
- Scope and ownership: Define covered assets, system owners, operators, and business or compliance approvers.
- Risk and timing: Name priority sources, risk methods, clock triggers, and the authority behind each target.
- Testing and deployment: State when testing is expected, who approves urgent changes, and which recovery checks must be ready.
- Verification and evidence: Require deployment status, installed-version checks, targeted rescans where supported, and service checks.
- Exceptions and retention: Name the deferral approver, temporary control where feasible, review date, next remediation action, and applicable record-retention period.
CISA’s clock starts when it adds a vulnerability to the KEV catalog or an agency identifies it on an asset, whichever happens first. A later scan does not restart that clock.
For each finding, record the asset and owner, risk rationale, governing requirement or internal policy, trigger and timestamp, target date, approved action, and verification evidence. Label internal targets as internal. A record that says only “high priority” leaves the approver guessing why the target applies.
When a System Cannot Be Patched
A patch may be unavailable, or a legacy system may not accept it. Either condition needs a documented risk decision, not silent removal from the queue.
The HHS January 2026 guidance identifies hardening measures for systems that cannot be patched. Remove unneeded software, disable unnecessary services, change default passwords, or segment the system. Firmware in routers and firewalls also belongs in the review.
Connect the temporary control to the risk. Name an owner and review date. If replacement is the durable answer, schedule it. A temporary control changes no deadline unless the governing requirement allows it.
For healthcare, this work belongs inside the HIPAA risk analysis. HHS says the analysis includes risks to electronic protected health information (ePHI) from unpatched software. Its guidance also states that patching is not a one-time event. Nu-Age’s healthcare page describes the company’s stated risk analysis approach for healthcare organizations.
How Nu-Age Approaches This
Regulated firms need patch work to connect discovery, priority, deployment, and evidence. What follows is what Nu-Age says about its own service, followed by the questions that test it.
Nu-Age states that its managed information technology (IT) service includes automated patching and updates. According to the company, its vulnerability management service continuously discovers, assesses, and prioritizes risks across a client’s IT environment, with automated coordination between findings and patch management. The company also says it uses risk-based prioritization.
Treat those as service descriptions to validate during provider review. Ask Nu-Age to trace one relevant finding from discovery to verification and show which assets, applications, and firmware are covered. Ask who assigns priority, approves urgent work, and handles failed deployments. For an open finding, request the reason, temporary control where feasible, owner, and review date. Compare the workflow with the firm’s duties and policy. The company’s managed IT solutions page describes the services it advertises.
Key Takeaways
- Patch management is a complete cycle of identification, prioritization, acquisition, installation, and verification, supported by asset inventory and exception records.
- CISA’s three-day highest-risk tier is a federal benchmark; NYDFS Section 500.5 requires entities subject to that provision to prioritize timely remediation according to risk.
- The current HIPAA rule requires risk analysis and risk management, while the proposed numeric patch deadlines are not final.
- A patch management policy should define clock triggers, target authority, urgent-change approval, recovery plans, verification evidence, and exception handling.
Frequently Asked Questions
What is the patch management process?
The patch management process identifies updates, prioritizes risk, acquires approved packages, tests where possible, installs, and verifies. Support that NIST-based cycle with a current asset inventory and documented exceptions. Verification should combine deployment status and installed-version checks with a targeted rescan where supported.
How quickly should critical security patches be installed?
There is no universal deadline. CISA’s federal directive uses three days for its highest-risk tier, based on exposure, known exploitation, exploit automation, and technical impact. Private firms are not bound. They can use its variables as an internal benchmark while applying the deadline, trigger, and exception rules that govern them.
What does NYDFS Part 500 require for patch management?
For entities subject to Section 500.5, Part 500 requires vulnerability monitoring and timely remediation prioritized by risk. Automated scans and manual review where scans do not reach must follow the risk assessment and occur promptly after material system changes. It sets no single deadline for every vulnerability.
Does HIPAA require patches within 15 days?
Not under the current HIPAA Security Rule. HHS proposed requiring a patch, update, or upgrade within 15 calendar days of identifying the need to address a critical risk when one is available. If none is available, the proposed 15-calendar-day clock begins when one becomes available. For a high risk, the proposal states 30 calendar days from identifying the need. It is not final.
What are patch management best practices for regulated firms?
Maintain an asset inventory, monitor trusted sources, and rank exposed or known exploited systems first. Define each target’s trigger and authority. Prepare business checks and a recovery plan before urgent deployment. Use more than one verification source. If patching is impossible, escalate, document the temporary control, and set a review or replacement date.
Check One High-Risk Patch Record
Start with one high-risk finding. Trace it from discovery through approval, deployment, and verification. Check whether the record identifies the clock trigger, target authority, asset owner, recovery plan, and evidence of the installed version. If work was deferred, confirm that the decision reached the right business and compliance owners and did not assume an internal exception could override a requirement. Review Nu-Age’s cybersecurity solutions, then contact The Nu-Age Group at (866) 640-3999 or sales@thenuagegroup.us.
