I treat a risk register as a starting point - not proof that patients are safer. To reduce risk, I rank threats by patient harm and exposure, assign decision and task owners, and set deadlines with clear tests for success.

My approach comes down to 4 steps:

  • Put patient care first. Check how an attack could interrupt treatment, expose PHI, or outlast safe downtime workflows.
  • Turn each risk into assigned work. Name who approves the response, who completes each task, and when temporary controls and fixes must be ready.
  • Check the results. For an unpatched clinical application or third-party vendor risk, verify that the fix reduces exposure - not just that someone closed a ticket.
  • Track what remains. Require approval and an expiration date for accepted risk. Escalate missed deadlines, failed tests, and risk above tolerance.

Software can help track the work. This is critical for effectively managing third-party risk across the organization. Tools such as Censinet RiskOps™ keep owners, tasks, and proof together. But <u>leaders still own the decisions</u> - including whether the remaining patient-care risk is acceptable.

Healthcare Risk Management: From Register to Action

Healthcare Risk Management: From Register to Action

Healthcare Cyber Risk Mitigation: Addressing Complexity, Patching, and Third-Party Threats

Prioritize Risks by Patient-Care Impact and Exposure

CVSS scores the flaw, not the clinical risk. Set the order for portfolio risk management and remediation - not just reporting - by weighing exploitability, patient harm, clinical dependencies, and verified safeguards. NIST SP 800-66 Revision 2 separates likelihood from harm to ePHI confidentiality, integrity, and availability. HHS’s Healthcare and Public Health Cybersecurity Performance Goals help teams prioritize high-impact work. Neither provides a universal healthcare scoring formula.[8][1] Use this ranking to decide what the team acts on first.

Assess Harm to Patients and Attack Paths

Start with what clinicians might be unable to do, do late, or do incorrectly. Document diagnostic delays, treatment disruptions, medication errors, and missing or altered clinical data. Identify the affected services and patient populations. Record how long downtime procedures can support safe care, not just whether a plan exists.

Trace the routes an attacker could use to reach the asset: internet exposure, remote access, stolen credentials, excessive privileges, or third-party connections. Assess exploitability, active threats, accessible PHI, and potential spread across connected systems and facilities. Link each factor to care disruption or clinical data loss.

Verify segmentation, restoration tests, and access controls. Consider time to harm: delaying treatment carries more risk when safe clinical workarounds are limited.

Set Decision and Escalation Rules by Priority

Have clinical, operational, security, privacy, legal, and executive leaders approve rules for your organization:

  • Urgent: Contain the risk immediately and conduct same-day clinical and security reviews when patient safety, active exploitation, or uncontrolled PHI exposure is at stake.
  • High: Fund a treatment plan with a near-term deadline.
  • Moderate: Place the item in a scheduled queue when exposure is limited and safeguards work.

Define notification deadlines and escalation triggers, including failed safeguards, missed treatment dates, and expanding exposure. Apply legal, regulatory, and contractual obligations alongside risk tolerance - not beneath it.

Acceptance is a treatment decision, not a lower severity rating. Record the approver, rationale, remaining patient-care and privacy impact, compensating controls, monitoring requirements, and review date. State what revokes acceptance, such as active exploitation, failed controls, or a new clinical dependency. Risk tolerance does not override legal obligations.[6] Once priority is set, give each item a treatment plan with a named owner and deadline.

Turn Register Entries Into Treatment Plans

Once you’ve set priorities, turn each entry into a risk statement ready for treatment: threat → vulnerability → affected asset → clinical or operational consequence. Attach supporting evidence, such as a scan or vendor assessment. Include the asset’s users, data, connections, and safeguards.[7][9] Then link the entry to a treatment plan with tasks, dependencies, due dates, proof of completion, and a residual-risk review.[5]

Assign Risk Owners and Action Owners

The risk owner approves treatment and owns the residual risk. The action owner does the work. Assign one owner to each task and require evidence before closing it.[10][4]

Choose the response that fits the risk: mitigation reduces likelihood or harm; avoidance stops or redesigns the activity; acceptance retains residual risk with approval; and transfer shifts financial or contractual liability. A plan can combine these responses. But contracts and insurance don’t remove patient-care consequences or accountability.[4]

Set Deadlines and Verify Results

Set separate deadlines for temporary controls, implementation, and validation. Base those deadlines on clinical criticality, exploitability, exposure, safeguards, and safe-care windows - not a fixed calendar interval. Include testing, third-party vendor risks, backups, and rollback steps as dependencies. If remediation has to wait, document temporary controls, the approving authority, and a revised due date.[7][9]

Define success before work starts. Require proof of full patch coverage, account removal, effective access restrictions, or a downtime test that meets recovery objectives. Review residual exposure before closing the plan.[4][5]

Accepted residual risk needs approval, a rationale, an expiration date, a monitoring owner, and reassessment triggers. Escalate overdue work, failed validation, or residual risk above tolerance to a named decision-maker within a set response time.[4][5]

Examples: Clinical System and Vendor Risks

Two common cases show how these rules work: an exposed clinical application and a vendor with excessive access.

Hypothetical Example: An Unpatched Clinical Application

Hypothetical scenario: A critical, actively exploited vulnerability affects an application used for emergency-department documentation. The register entry should name the application, the services at risk, the active exposure, the deadline, and who approves any remaining risk. The clinical service executive owns the risk; the application or infrastructure team owns patch testing and deployment. Set an expedited deadline measured in days, based on exposure and clinical validation needs - not the next routine maintenance window.[1][7]

During testing and cutover, the priority is safe care and controlled exposure. While testing the patch, limit nonessential inbound and outbound traffic, preserve required clinical interfaces, and monitor for exploitation. Before deployment, confirm that staff can use downtime workflows and that rollback is ready to protect care during cutover. Close only after deployment records, a rescan, and clinical validation of patient identity, orders, medication documentation, and results review. Failed testing or a missed deadline triggers escalation rather than leaving the item open as patch pending.[7][14]

Hypothetical Example: Excessive Vendor Data Access

A different treatment pattern applies when the risk is vendor access rather than a patchable flaw. Hypothetical scenario: A support vendor has standing administrative privileges and PHI access beyond its documented support need, increasing PHI exposure and attack surface. The vendor relationship owner coordinates the plan; IAM, privacy, legal, security, and the vendor each own actions. Separate the permissions needed for support from unnecessary read, write, export, and administrative rights.[11][12][13]

Remove unnecessary permissions, replace shared access with individually attributable accounts, require strong authentication, and limit approved access by role and time. Verify the result through an approved access matrix and logs showing authentication, privilege changes, PHI access, and exports. If a legacy integration prevents immediate reduction, require approved, time-limited acceptance with an expiration date, restricted connections, shorter sessions, and enhanced monitoring.[14][15]

Track Progress and Remaining Risk

Once treatment starts, the register should show whether exposure is falling. Completed tasks do not prove risk reduction. Close a risk only when verified results confirm lower exposure, or approve a time-limited acceptance of the remaining risk.[18]

Review Exceptions, Results, and Escalations

Review urgent issues weekly or biweekly, high-priority plans monthly, and accepted risk quarterly. Reassess sooner when new threats, incidents, system changes, or changes in clinical dependencies occur. Make sure priority work has an owner, funding, and milestones - not just a due date.

These reviews should measure whether patient-care risk and exposure are falling, rather than simply count closed tasks. Track critical risks without owners, overdue high-priority actions, time to reduce critical exposure, verified treatment results, expired acceptances, repeated findings, and residual risk above tolerance. Fewer open entries do not mean less exposure. Send expired exceptions and above-tolerance risks to leadership for a decision instead of extending deadlines.[4][10]

Coordinate Risk Actions in Censinet RiskOps™

Use that same evidence trail to anchor review meetings in verified results. Censinet RiskOps™ brings assessments, risk actions, ownership, status, evidence, and portfolio visibility into one place. This helps teams assign work, track milestones, and verify evidence.[16][17]

Software supports the process; accountable leaders choose treatment, approve exceptions, and validate that remaining patient-care risk is acceptable.

FAQs

How do we prioritize risks across competing clinical needs?

Go beyond technical severity scores. Use consistent, repeatable scoring that weighs exploitability alongside patient safety, the importance of clinical workflows, and potential downtime. Put risks to critical clinical assets - such as EHRs, real-time monitoring, and life-support systems - ahead of risks to administrative or rarely used integrations.

When clinical and technical teams disagree, have a multidisciplinary risk committee check the scores against day-to-day operating conditions. Give each high-priority risk a named owner and a firm remediation deadline.

What if a critical system cannot be patched safely?

Use a formal risk management process to reduce exposure until a permanent solution is available. Put compensating controls in place, such as network isolation or increased monitoring.

Record the clinical impact, the reason for the patching delay, and the controls in the central risk register. Obtain formal, time-bound risk acceptance from an executive sponsor or governance committee. Include a scheduled review date and keep the decision traceable in the register.

How do we decide whether residual risk is acceptable?

Compare the post-mitigation risk score with your organization’s risk appetite and tolerance levels [1][2]. Back the decision with scan results, logs, or penetration tests - not just documentation [2].

High or critical risks must be accepted by an executive sponsor or a formal risk governance committee, rather than individual system owners [3]. For every accepted risk, document the business justification, set an expiration date, and schedule a review to reassess it as conditions change [3][2].

Related Blog Posts