The IoMT Blind Spot. Why Biomedical Devices Belong in Your GRC Program.

If your connected medical devices sit outside GRC, you have risk with no clear owner. In many hospitals, IoMT devices are tracked for maintenance but not for risk, controls, exceptions, or compliance. That leaves gaps across cyber, patient safety, HIPAA, vendor access, patching, and incident response.

Here’s the short version:

• IoMT risk is not just an IT issue. It can affect care delivery, device function, PHI, and downtime at the same time.
• The blind spot often starts with split ownership. Clinical engineering, IT, security, compliance, and vendors each handle part of the job, but no one runs the full device risk process.
• The scale is hard to ignore.
  • 23% of medical devices have at least one known exploited vulnerability
  • 99% of hospitals have at least one IoMT device with a known exploited vulnerability
  • 76%+ of medical devices are affected by supply-chain vulnerabilities
• Some device groups need faster attention. Infusion pumps, bedside monitors, imaging systems, and implant programmers each bring different risk based on patient use, network exposure, software age, and vendor support.
• What to add to GRC is straightforward:
  • one IoMT inventory tied to risk decisions
  • device risk scoring based on technical exposure and clinical impact
  • control mapping for HIPAA, FDA, and internal policy
  • one workflow for vulnerabilities, patches, and exceptions
  • vendor review tied to each device fleet
  • named owners from procurement through retirement
  • incident playbooks built for device environments, not just laptops and servers
• Risk acceptance must be formal. If a device cannot be patched, the record should list the exact devices, the control gap, compensating controls, owner approvals, and the next review date.
• Leadership has to be involved. High-risk device decisions should not live in email threads or side spreadsheets.

A simple way to think about it: if a device connects to your network, stores or sends PHI, depends on vendor software, or can affect patient care, it belongs in your GRC program.

This article explains how I would fold biomedical devices into inventory, risk review, third-party oversight, ownership, remediation, and response so fewer device risks get left behind.

1. What risks IoMT adds to healthcare operations

Cyber, safety, compliance, and operational risks are linked but not identical

When an infusion pump or imaging workstation gets compromised, the damage goes beyond a data breach. Care can stall. Therapy can be interrupted. Diagnosis can be delayed. That's why risk classification becomes the next big GRC job.

IoMT risk cuts across cyber, patient safety, compliance, and day-to-day operations. Those areas overlap, but they are not the same thing. Each one needs its own controls, owners, and escalation points. That distinction matters because the FDA treats cyber controls as part of device safety. In plain terms, a security gap can also become a patient-safety issue.

Take network segmentation for infusion pumps. It does more than block attack paths. It helps protect continuous therapy delivery, supports HIPAA-aligned access controls, and contains the blast radius if something goes wrong. GRC programs that lump all of this into one bucket tend to miss the full risk picture.

How risk changes by device category and clinical criticality

Risk shifts a lot from one device type to another. Network exposure, patient dependence, software age, and vendor support status all change the equation. A bedside monitor in a telemetry unit and a connected implant programmer used in a follow-up visit are both IoMT devices, but the risk mix is very different.

The data makes that clear. Infusion pumps account for about 38% of a typical hospital's IoT footprint, and about 73–75% of the pumps studied had at least one vulnerability that could affect patient safety, data confidentiality, or service availability. ^[5][4] Around 8% of imaging systems - including CT, MRI, X-ray, and ultrasound - have vulnerabilities tied to ransomware and insecure internet connectivity, affecting 85% of organizations that use them. ^[3] On top of that, one-third of all bedside IoT devices have an identified critical risk. ^[5][4]

Use device criticality and exposure to decide what needs attention first.

Priority should follow two things: clinical criticality and network exposure. Those factors need to show up directly in inventory, assessment, and remediation workflows.

sbb-itb-535baee

Cybersecurity Essentials for Medical Professionals w/ Didier Jourdain | Industry Ep. 98

2. What to add to your GRC program for biomedical devices

Bring IoMT into your current GRC workflow: inventory, risk register, control mapping, and remediation tracking. Don’t leave it sitting in a separate clinical engineering spreadsheet. Use your risk rankings to decide how much detail each inventory record needs, how deep the control mapping should go, and how tightly each remediation step should be tracked.

Build an IoMT inventory that supports risk decisions

A governance-ready IoMT inventory is a risk decision tool, not just a checklist. At a minimum, capture device identity, clinical function, owner, version, network location, connectivity, exposure, support status, maintenance window, data flows, and vendor dependencies. ^[10][15][18]

Each field should lead to a clear GRC action. Version data helps with CVE mapping. End-of-life status points to compensating controls. Maintenance windows shape remediation timing. Data flows show whether HIPAA applies.

Pull data from medical-device-aware discovery tools, CMMS imports, and CMDB records. Then reconcile those sources on a regular basis to spot orphan devices. Tie inventory updates to onboarding, decommissioning, firmware changes, and network moves. ^[10][18]

Once the inventory is in place, use it to score exposure and set remediation priority.

Add risk assessments, control mapping, and residual-risk tracking

Use a two-part lens: technical exposure and clinical impact. Technical exposure covers known CVEs, network reachability, authentication strength, logging capability, legacy component status, and how feasible remediation is. Clinical impact looks at whether the device is life-sustaining or diagnostic-only, how continuously it is used, and whether a data integrity failure could affect a clinical decision. A ventilator with moderate technical exposure but high clinical criticality should still rank High. ^[7][8][9]

Map IoMT into your current framework. That includes HIPAA administrative controls for risk analysis, vendor review, and training; technical controls for segmentation, authentication, encryption, and logging; physical controls for access to stored devices and programming equipment; and FDA guidance for vulnerability intake, risk-based patching, and compensating controls. ^{[6][7][8][11][12][13]}

If a control can’t be put in place, document the exception in that same workflow.

Residual-risk acceptance should be a formal approval, not a quiet workaround. If full remediation isn’t possible - for example, a legacy infusion pump OS that the vendor no longer supports - the GRC record needs to name the exact devices, explain the limitation, state the assessed risk level, and list measurable compensating controls. Route high-risk acceptances to the clinical leader, CISO, and compliance lead, or to the risk committee for critical items. Set a review date of 90 or 180 days, and define triggers for an earlier review, such as a new vendor patch, an FDA communication, or an incident. ^{[7][8][14][16][17][21]}

Track vulnerabilities, patches, and exceptions in one workflow

Route every device advisory or CVE into one auditable workflow - not a separate tracker or an email chain. Auto-match affected devices by model and firmware, score risk by severity and clinical criticality, and assign remediation to the right owner. Keeping advisories, patches, and exceptions in one governed record helps prevent orphaned risk. ^[19][20]

For devices that can’t be patched while in use, log the exposure, compensating controls, affected scope, and exception window. Link the exception to the vulnerability record, and enforce severity-based patch SLAs: routine patches on a standard cadence, critical advisories on a faster timeline, with escalation to compliance when deadlines slip. ^{[14][16][17][19][20][22]}

3. Extend third-party oversight to the IoMT supply chain

Once devices are in the inventory, the next step is figuring out who stands behind them.

An IoMT device relies on more than the company that made it. Cloud services, remote-access vendors, and embedded software suppliers can all add risk. If one link breaks, that problem can reach both patients and day-to-day operations. A 2025 analysis found that more than 76% of medical devices are affected by supply-chain vulnerabilities. ^[2] And yet, most third-party risk programs were never designed for this kind of device stack.

What vendor reviews should cover for connected medical devices

Review IoMT vendors based on device-level dependencies, not just a broad security checklist. When you assess a device manufacturer or service provider, the review should look past general security posture and focus on the device’s actual upstream vendors and components.

These items are no longer just good practice. They’re starting to become the floor set by regulation. Under FD&C Act §524B, manufacturers of cyber devices must now submit a postmarket vulnerability monitoring and remediation plan, a secure update and patch plan, and a machine-readable SBOM as part of premarket submissions. ^[1][23][24] That gives procurement teams something concrete to put into contracts, not only at onboarding, but across the full useful life of the device.

Add a contract clause that requires security updates for the device and its supporting components for the full useful life of the product, at no extra cost. ^[25][26]

How to run device vendor oversight through healthcare risk workflows

Contract terms help only when they move through the same governance workflow as the device itself.

A repeatable process starts during procurement. Any connected medical device purchase should trigger a standard third-party risk review with IoMT-specific controls. Security leads the technical assessment. Clinical engineering and clinical leadership weigh in on patient safety and workflow impact. Compliance checks alignment with HIPAA and FDA guidance. If a device is high risk or high criticality, it should get formal sign-off from a technology governance committee or patient-safety committee before deployment.

A shared risk workflow keeps vendor reviews, evidence, and remediation tied to each device fleet. Say a new advisory appears for an imaging system’s remote-access module. That finding should connect straight to internal incident response tasks and kick off a reassessment workflow, so nothing gets lost between security, clinical engineering, procurement, and compliance.

That shift matters. It turns vendor oversight into a device-risk control, not just a procurement checkbox. For that to happen, ownership has to be explicit.

4. Define accountability across clinical, IT, security, and compliance

Once vendor requirements are set, your internal team has to turn them into day-to-day action. That’s the point where oversight either works or falls apart. If no one owns the work, gaps show up fast.

Vendor oversight works best when each task has a named person or team behind it.

Assign ownership for each step of the device risk life cycle

The IoMT risk life cycle starts at selection and ends at retirement. That includes procurement, deployment, operations, incident response, and disposal. Every stage needs a named owner, not just a broad department label.

Clinical engineering owns device configuration, maintenance, and clinical validation. IT infrastructure owns network connectivity, segmentation, and endpoint controls. Cybersecurity leads threat triage, vulnerability management, and incident response. Compliance and privacy handle regulatory alignment, HIPAA duties, and breach-reporting decisions. GRC owns the risk framework: scoring, tracking, and escalation. In plain terms, GRC decides how IoMT risk is measured, routed, and escalated, while technical and clinical teams carry out the controls.

When devices aren’t tracked, the governance gap becomes obvious in a hurry. One large health system found far more devices on its network than IT had estimated - tens of thousands of medical devices never formally tracked - and had to build a single registration workflow across IT, procurement, and clinical engineering to close that blind spot. ^[30]

Use a clear ownership model to prevent orphaned risk

A clear ownership model helps stop risk from getting stranded between assessment, remediation, and exception approval.

Exception approvals need extra care. If a patch can’t be applied - for example, if a vendor warns that a security update could affect FDA clearance on an MRI system - someone with the authority to do so has to formally accept that risk, document compensating controls, and set a review date.

That call shouldn’t float around in email threads. It should go to a designated senior leader, such as the CISO, Chief Compliance Officer, or a cross-functional risk committee, based on your governance model. Track exceptions in a central risk register linked to specific devices and review dates.

ANSI/AAMI/IEC 80001-1 makes this point directly: top management must set policy, assign owners, fund the process, define acceptance criteria, and approve risk results. ^[28][29] Biomedical device risk isn’t just a technical issue pushed down the org chart. It sits at the leadership level.

With ownership in place, the next move is building a repeatable workflow from discovery to remediation.

5. Run IoMT risk management from discovery through response

With ownership in place, the next step is execution: one repeatable workflow that runs from discovery to response.

Run a repeatable workflow for discovery, prioritization, and remediation

Once ownership is clear, move IoMT into one repeatable GRC workflow from discovery to closure. That workflow should feed straight into core GRC outputs: risk register updates, exception approvals, reassessment triggers, and incident records. Each step should push the next one forward.

Prioritization is where discipline matters most. You can't fix every device at the same time, so the queue should start with devices that are internet-exposed, running unsupported operating systems, tied to known exploited vulnerabilities (KEVs), or used directly in patient therapy. Claroty's 2025 analysis of more than 2.25 million IoMT devices across 351 healthcare organizations found that 99% of hospitals were managing IoMT devices with KEVs, and 96% had KEVs linked to active ransomware campaigns. ^[27] That means the queue should be driven by exposure, exploitability, and clinical criticality.

Track open actions, exceptions, and overdue items in the GRC record. If a patch can't be applied, document that choice as a formal risk acceptance with compensating controls and a review date. It should not sit buried in an email thread.

And this workflow can't stop at patching. It also needs to cover containment, downtime, and recovery.

Prepare incident response and periodic reassessment for device environments

A security incident involving a connected infusion pump or patient monitor is not handled the same way as a compromised laptop. Isolation steps need validation from clinical engineering before anyone uses them. Pulling a device from service without making sure there's a safe backup in place can create patient harm faster than the threat you were trying to stop.

An effective IoMT incident response playbook should cover:

• Detection triggers tied to medical subnets
• Network-level containment methods, such as segmented containment, that avoid sudden device shutdowns
• Escalation paths that bring in clinical leadership when patient safety may be affected
• Pre-defined downtime workflows for affected units
• Validation before the device returns to service

Industry reporting found that 22% of healthcare organizations experienced cyberattacks that directly impacted medical devices, and 75% of those incidents disrupted patient care, with 24% requiring patient transfers to other facilities. ^[31] Downtime planning isn't optional. It's the difference between a managed disruption and a clinical crisis.

Reassessment should happen on a schedule and in response to events. High-risk and patient-critical devices should be reviewed at least quarterly. But don't wait for the calendar. Trigger a reassessment when a new high-severity CVE is published for a device's OS, when a firmware update changes the device's risk profile, when ownership or location changes, or when an end-of-support date is getting close. Each reassessment should update the risk score, confirm that controls still work, and feed the results back into the enterprise risk register so IoMT risk stays visible to leadership alongside other technology risk.

This isn't about adding process for the sake of process. It's about ending up with fewer orphaned devices and fewer unmanaged clinical risks.

Conclusion: Close the IoMT blind spot before it becomes a patient-safety event

IoMT belongs in GRC because it affects patient safety, compliance, uptime, and financial exposure at the same time. Organizations that formalize IoMT now lower the odds of a preventable patient-safety event later.

FAQs

How do we start adding IoMT devices to GRC?

Start with a full asset inventory of IoMT devices. Track the make, model, firmware version, connectivity method, and whether the device handles ePHI. This gives you a clear picture of what’s in your environment and where the biggest exposure may sit. It also helps stop the all-too-common problem where devices live in separate spreadsheets that no one fully owns.

Ownership should be shared across IT, security, clinical engineering, and compliance. That matters because no single team sees the whole picture. IT may know the network, clinical engineering may know the device life cycle, security may know the threat data, and compliance may know what auditors will ask for.

From there, rank devices based on patient safety impact and downtime tolerance. A bedside device tied to care delivery is not the same as a lower-risk support system. If one device can be offline for hours and another can’t be down for even a few minutes, your risk approach should reflect that.

It also helps to map risks to a framework like NIST. Doing this brings structure to reviews, keeps teams speaking the same language, and makes audit prep far less painful. Instead of scattered notes and one-off judgments, you get a repeatable way to track issues and decisions.

Procurement needs to be part of the process too. Build security requirements into purchasing so risks are reviewed before devices land on the network. That often includes:

• Security questionnaires
• SBOMs
• MDS2 forms

Finally, centralize risk, vulnerability, and assessment data so teams can find it in one place. When records are spread across email threads, ticketing systems, and local files, auditability takes a hit fast. A single source of record makes reviews easier, supports follow-up work, and gives you a cleaner trail for audits.

Who should own IoMT risk in a hospital?

IoMT risk shouldn’t sit with just one department. In hospitals, it calls for a federated governance model backed by a cross-functional medical device cybersecurity committee. That group should include IT security, clinical engineering, compliance, clinical leadership, and procurement.

The CISO usually sets the strategy. From there, a RACI matrix makes it clear who owns inventory, vulnerability monitoring, and incident response. At the device level, ownership is split: a business owner handles clinical use, while a technical owner in IT or security handles the technical side.

What makes one medical device riskier than another?

A medical device’s risk comes from two sides: its technical exposure and its clinical impact.

A vulnerability score is useful. But on its own, it doesn’t tell you what a failure could mean for patient safety. That’s the part that changes the stakes.

Devices that support or sustain life - such as infusion pumps, ventilators, and defibrillators - often carry more risk because a malfunction can affect care in immediate ways.

Risk also depends on a mix of other factors, including:

• patient safety impact
• the sensitivity of PHI accessed
• network exposure
• vulnerability history
• operating system age
• patchability
• compensating controls

Related Blog Posts

• Best Practices for IoT Device Inventory in Healthcare
• Best Practices for Securing IoMT Devices in Healthcare
• Best Practices for IoT Device Security
• 5 Steps to Build an IoMT Security Program