How SaMD teams ship an expedited patch without breaking change control

Most change control guidance assumes you have time. The standard playbook, laid out in our guide to change management for medical devices, moves through impact assessment, review, and approval before anything reaches production. That works when a change is planned. It falls apart the moment a critical bug or a security vulnerability lands in a shipped product and the fix cannot wait for a two-week review cycle.

Software as a medical device (SaMD) teams run into this more than hardware teams do. Their software ships continuously, and the vulnerabilities that force an urgent patch tend to get disclosed on a timeline the team does not control. A serious defect in a diagnostic or monitoring product can put patients at risk while the documentation catches up. The real question is how to move fast and still produce a record that holds up when an auditor or an incident reviewer asks what happened.

BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool

Why the standard process breaks under pressure

A planned change control process is built around sequence. Assess the impact, document the rationale, run verification, collect approvals, then release. Every step assumes the clock is on your side.

An emergency patch inverts that order. A zero-day disclosure or a safety-critical defect forces the release decision to the front, and the documentation that normally precedes it now trails behind. That often results in two problems. Teams either freeze, leaving a known vulnerability live while they work through the full process, or they ship the fix and promise to backfill the record later, which in the middle of the next sprint almost never happens.

Neither outcome survives scrutiny. IEC 62304, the standard governing medical device software life cycle processes, does not exempt urgent changes from risk evaluation, verification, or traceability. FDA's post-market cybersecurity expectations treat a patch as a change that still has to be assessed for its effect on safety and effectiveness. A fast fix that introduces a new hazard, or that breaks a validated function, becomes its own compliance event. What you want is a path that compresses the timeline without dropping the parts that actually matter.

What a defensible expedited path looks like

The big mistake here is treating an emergency as a reason to abandon process. The better move is to design a second, faster process before you need it, so the expedited case is a known route rather than an improvisation under fire.

1. Start by defining the trigger. Write down, in advance, what qualifies a change as expedited: a confirmed security vulnerability above a set severity, a defect with a direct patient-safety impact, a regulatory or field-action deadline. Anything below that threshold takes the standard path. A predetermined change control plan (PCCP) is the natural home for this logic, since it already asks you to describe the changes you anticipate and how you will handle them.

2. Pre-authorize the compressed path. Decide now who can approve an expedited release, so you aren't chasing signatures during an incident. Then draw a clear line between the record you always capture, covered in the next section, and the routine work that can wait until the incident is closed.

3. Capture the record where the work already happens. Here SaMD teams have an advantage most hardware teams lack. The evidence of a well-controlled change already exists in the development toolchain, in the pull request, the code review, the test run, and the ticket describing the defect and its severity. When change control lives inside the Jira and GitHub workflow your engineers already use, the approval, the risk note, and the test evidence attach to the same ticket as the fix. The trail gets created in real time, rather than reconstructed from memory a month later.

4. Finally, reconcile once the fire is out. An expedited change is not finished when the patch ships. After the immediate risk is contained, fold the change back into your formal design and development file, confirm the deferred items got completed, and record the whole event as a closed loop. A security patch handled this way often leaves a cleaner trail than a planned change does, because the urgency forces the team to write down decisions as they make them.

The minimum record an expedited change still needs

Compressing the timeline works only when everyone agrees ahead of time on what still gets written down. The set below is short on purpose. Each item is something an auditor or an incident reviewer will expect to find, and each one is created during the fix rather than after it.

• What changed and why, plus the defect or vulnerability that triggered it and the severity you assigned.
• The risk assessment for the change itself, covering any new hazard it introduces, its effect on your existing risk controls, and the reasoning behind releasing before the full process has finished running.
• Verification that the fix does what it claims, tied to the specific defect.
• A regression check confirming the patch has not broken another validated function, with traceability back to the requirements it touches.
• For a security fix, the vulnerability reference and its severity, and what the change does to the device's security posture.
• The approval, showing who signed off on the release under the authority you set in advance.
• A short note on anything deferred, with the date it will be closed.
• The released version and where it went, so post-market traceability stays intact.

None of this requires a separate quality project. Every item is a byproduct of doing the work carefully, as long as the place you record it is the place the work already lives.

BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool

Simplify your change control process with Greenlight Guru

Speed and defensibility only fight each other when the compliance record lives somewhere other than the code. If your quality system is a separate pile of documents that someone updates after the fact, every urgent fix opens a gap between what shipped and what got recorded. Close that gap and the tradeoff mostly disappears.

Greenlight Guru's eQMS is built for this case. It puts change control, risk management, and design controls in the same environment where SaMD teams write and ship software, with native connections to the tools engineers already work in. An expedited patch moves through a defined approval path, the risk assessment and verification evidence attach to the change, and the record is complete the moment the fix goes out. No second documentation exercise waits to be forgotten, and no audit surprise shows up six months later.

Emergency changes will happen. A team that has decided in advance how to handle them, and that captures the evidence where the work occurs, can move at software speed and still walk into any audit or incident review with the record already written.

See how Greenlight Guru handles change control for SaMD teams.