Incident response · Digital health & life sciences
Incident Response Planning for Medical Device Makers
An incident response plan for a device maker has to choreograph three separate processes that often get triggered by the same event: coordinated vulnerability disclosure, the recall procedure your quality system requires, and privacy breach notification under PIPEDA, PHIPA or a BAA. Work usually starts after a hospital customer's own incident, an audit finding, or the uncomfortable realization mid-scramble that nobody had agreed who calls Health Canada first. We build the plan and the runbook so that decision is made in advance.
Reviewed by the Privacy Horizon team · Last reviewed
What you're protecting
What the plan has to choreograph, not just document
A written plan only works if it tells people, in order, what to decide and who to call.
The disclosure-versus-recall decision
A clear framework for deciding, within hours, whether a discovered vulnerability is a routine fix, a coordinated disclosure event, or a trigger for the section 58 recall procedure.
The problem-reporting clock determination
A fast, defensible process for deciding whether an incident meets the 10-day death or serious-deterioration threshold or the 30-day threshold for other reportable incidents.
Multi-audience notification
A sequenced runbook covering Health Canada, hospital customers under their network-connection agreements, patients, and any US covered entity owed notice under a BAA.
PSIRT and privacy escalation working together
A single incident structure that routes a finding to both the coordinated vulnerability disclosure track and the privacy breach track when the same event triggers both.
Regulatory map
The separate clocks a device incident can start at once
A single security event can start several regulatory clocks simultaneously, each with its own deadline and its own audience.
The Medical Devices Regulations' reporting and recall duties
The Medical Devices Regulations set 10- and 30-day problem-reporting windows depending on severity, plus documented recall procedures, entirely separate from any privacy notification obligation the same incident carries.
PIPEDA's breach reporting duty
Where personal information is compromised, PIPEDA requires reporting to the Privacy Commissioner and notice to affected individuals where there is a real risk of significant harm.
PHIPA breach duties as an electronic service provider
A breach touching an Ontario custodian's personal health information triggers duties under your electronic-service-provider role, coordinated with, but distinct from, the custodian's own obligations.
HIPAA's 60-day business associate notice
Where the RPM cloud serves a US covered entity, a breach of unsecured PHI has to be reported to the covered entity inside the window your Business Associate Agreement sets.
What goes wrong
What an unrehearsed response actually looks like
The plan exists because the failure mode without one is predictable and costly.
A missed problem-reporting deadline
Without a fast, agreed process for classifying severity, the 10-day clock can pass before anyone has formally decided whether it applies, turning a manageable incident into a compliance failure.
A hospital customer surprised instead of informed
A network-connection agreement typically expects proactive notice, and a hospital learning about an incident from a news report rather than from you damages the relationship well beyond the incident itself.
Conflicting timelines across regimes
Without a single incident owner tracking every applicable clock, a team can satisfy one notification duty while missing another running in parallel on a different schedule.
Ransomware halting firmware signing
An attack against internal build and signing infrastructure needs a response plan of its own, since it threatens the integrity of every future update pushed to devices already in the field.
Our incident response for medical device makers
What our incident response plan covers for a device maker
A classification framework, a decision tree, and audience-specific runbooks built around your actual product and customer base.
Incident classification playbook
A structured way to determine, quickly, whether an event is primarily a security incident, a safety incident, a privacy breach, or some combination of the three.
Problem-reporting and recall decision tree
Clear criteria and an accountable decision-maker for whether an incident crosses the 10- or 30-day threshold or requires invoking your recall procedure.
Notification runbook by audience
Sequenced templates and contact paths for Health Canada, affected hospital customers, patients, and any US covered entity under a BAA, so nobody is improvising language mid-incident.
PSIRT integration
A documented handoff between your coordinated vulnerability disclosure process and the incident response plan, so a researcher-reported flaw and an active exploit both route through the same structure.
Tabletop exercise
A rehearsal that walks RA/QA, engineering and leadership through a realistic scenario, testing whether the plan's decision points actually work under time pressure.
How the engagement runs
How we build the plan with your team
The plan is built around your actual product architecture and customer contracts, not a generic template.
Step 1
Map current gaps against the clocks
We review your existing recall procedure and any incident documentation against the problem-reporting deadlines and applicable privacy notification duties.
Step 2
Build the classification and escalation playbook
We define who decides severity, how fast, and what triggers each downstream track, disclosure, recall, or privacy notification.
Step 3
Draft the notification runbook
Audience-specific templates and contact procedures are written for Health Canada, hospital customers, patients and any US covered entity relationships.
Step 4
Run a tabletop rehearsal
RA/QA, engineering and leadership work through a realistic scenario together, surfacing gaps before a real incident does.
What it costs
What determines incident response planning cost
Cost depends on how many regulatory regimes apply, whether your customer base spans Canadian hospitals, US covered entities, or both, and whether a tabletop exercise and staff rehearsal are included alongside the written plan.
Incident response planning is also delivered as part of a Virtual Privacy Office retainer for device makers who want the plan maintained as their product and customer base change, rather than built once and left to age. Share your customer and jurisdiction footprint and we will scope a tailored quote.
Medical Device Makers: Incident response questions, answered
They can run in parallel from the same event. A vulnerability might trigger coordinated disclosure to researchers, a recall decision under section 58 if it affects deployed devices, and a privacy breach notice if patient data was exposed, each governed by different rules and often different owners inside the company.
Typically RA/QA leads contact with Health Canada given the regulatory relationship, while a designated incident owner notifies hospital customers under their network-connection agreements in parallel, and patient notice follows once scope and risk are confirmed. The plan assigns these roles in advance so nobody is deciding under pressure.
No. Only findings meeting the regulatory threshold, generally a plausible path to death or serious deterioration for the 10-day report, or another reportable incident for the 30-day report, trigger mandatory reporting. Most findings are remediated through normal patch and disclosure processes without crossing that line.
Your existing recall procedure covers the mechanics of removing or correcting a device in the field. An incident response plan sits above that, deciding whether a given event should trigger a recall, a privacy notification, coordinated disclosure, or several of these at once, and in what sequence.
Not necessarily separate plans, but the plan needs distinct playbooks for each, since a cloud breach primarily triggers privacy notification duties while a device-level flaw primarily triggers problem-reporting and recall considerations. A single plan can hold both if it is structured clearly enough.
More for medical device makers
Other services for this niche
About this service
Answers & guides
What's Protecting Your Business from the Next Threat?
Don't wait for a breach to expose your vulnerabilities. Let Privacy Horizon secure your data, ensure compliance, and build lasting trust.