Login
Login
Book a Demo
Book a Demo
“As soon as they think they are patching fast enough, they need to patch faster.”
Epic Chief Security Officer Stirling Martin made that comment to The New York Times after Epic used an AI model to find configuration flaws that could let someone view patient records without the access appearing in an audit trail. At Epic's Users Group Meeting in August, he had already told health system IT teams to expect a higher-than-usual number of urgent security fixes.
When Becker's Hospital Review asked health system technology and security leaders to respond, they largely agreed. Jefferson Health now patches daily, sometimes more than once a day. Even so, its chief digital and information officer, Luis Taveras, named operational complexity, legacy systems, testing requirements and the need to keep clinical care running as the main obstacles.
Erlanger Health's chief information security officer, Dennis Leber, drew the line more firmly: “Patient safety is the boundary condition.”
A security patch may arrive with urgency. Implementing it still takes people, coordination and evidence.
Someone must determine what is affected. Someone must test the relevant workflows. Someone must coordinate the deployment. And someone must confirm that the updated environment is ready to support care.
The entire change process has to keep up.
Leaving a vulnerability unresolved carries risk. Introducing a change into a clinical environment carries risk too.
NIST's enterprise patch management guidance recognizes this tension. Faster deployment reduces the opportunity for attackers, while testing helps reduce the risk of operational disruption. It recommends planning for routine patches, emergency patches and temporary mitigations when circumstances require them.
Leber described the same approach in practice. An actively exploited or internet-facing vulnerability should move immediately, while lower-risk issues follow a disciplined cadence. When an immediate patch isn't operationally safe, compensating controls and formal risk acceptance bridge the gap.
That decision is rarely made with complete information. Michigan Medicine's CISO, Jack Kufahl, said his team often receives vague warnings and spends a lot of time sorting urgent patches from routine ones “on partial information.” Leaders asked Epic and other vendors to tell them sooner and tell them more: earlier notification, clear exploitability information, precise affected versions and tested rollback procedures.
Leber summed up what separates the organizations that will succeed: they will get much faster at deciding what matters, acting safely and verifying that the risk is actually gone.
So what does that take in practice?
Our view: being ready to change starts well before a patch arrives. NIST makes the same point: planning has to be done in advance, so that when a new vulnerability becomes known, a decision can be made quickly. An urgent update is a difficult moment to discover that the test cases are scattered across spreadsheets, the deployment instructions are buried in email and the people involved have different understandings of what happens next.
Kufahl noted that testing patches before deploying them helps limit unexpected downtime. For a laboratory, that testing may involve much more than confirming that an application opens.
Depending on the change, its dependencies and the local configuration, relevant checks might include whether orders arrive correctly, specimen information remains intact, middleware rules behave as expected and results reach their intended destination.
These are illustrative checks. The actual scope should follow the impact assessment.
The preparation is reusable. Maintain test cases for critical workflows, define expected outcomes and retain the issues discovered during previous changes. When another update arrives, the team can review and adapt those assets rather than reconstructing the work from memory.
But successful testing is only part of implementing a change.
A patch can be tested and ready while the production cutover still requires several people to complete interdependent tasks.
For a cutover requiring downtime, a shared checklist should coordinate the people responsible for:
Each person signs off their assigned tasks as they complete them. The team can see what is finished, what remains outstanding and where a problem needs attention. Afterward, the record shows who did what, and when.
That is the baton handoff in deployment: one person's completed work establishes the starting point for the next.
The checklist should reflect the actual environment, responsibilities and sequence, including the agreed response if the cutover cannot proceed as planned. That is where a vendor's tested rollback procedure becomes a local, assigned task.
Why does this coordination deserve attention? A 2022 study of security patching in healthcare, by Dissanayake and colleagues, examined 132 delayed patching tasks across two organizations over four years. Coordination delays were the most prominent cause, and 54% of the delayed tasks occurred during patch deployment. The teams coordinated through biweekly meetings and a shared spreadsheet tracker, a common approach at the time. The coordination problems the researchers recorded included slow approvals, limited awareness of task progress and uncertainty about who owned which task. The study's scope was limited, but it shows why a faster response depends on how people organize and complete the work, not only on the technology.
Installation alone does not complete the process. NIST's guidance includes verifying that deployed patches have taken effect and monitoring them afterward.
Different people need different evidence. Security teams need evidence that the vulnerability has been addressed. Clinical and operational teams need evidence that essential workflows continue to function. The people managing the cutover need visibility into every task that moves production safely through the change.
Leber put it plainly: patching can no longer be treated as a monthly maintenance exercise. It is becoming a continuous risk-management function. That makes the evidence from one change the starting point for the next.
For healthcare leaders, a useful measure of readiness is how much of this work is already organized before the next urgent update arrives.
The researchers behind that 2022 study closed by calling for computer-supported tools that improve coordination across patching tasks and stakeholders. Cymetryc is one answer to that call. Teams use it to maintain reusable test cases and to bring results, supporting evidence, issues and retesting together for review. They also use it to run cutover and new-build checklists, so every change is documented the same way every time, with a clear record of who did what, and when.
If a critical patch arrived tomorrow, would your team have a current test plan, a clear cutover checklist and an accountable person for every handoff?
Talk with us about managing testing and deployment coordination in Cymetryc: hello@cymetryc.com
Security & compliance
SOC 2
Type 2
ISO
27001:2022
HIPAA
Compliant
GDPR
Compliant
