Patch Smart
How QA keeps health tech safe at patch speed.
Health tech teams no longer get to decide whether to patch. What they decide is how well they do it: whether each fix closed the flaw, whether anything else broke, and whether the record exists when an auditor or a customer asks. This six-part series covers the QA work that makes high-volume patching safe. A new part publishes every Wednesday.
SQA² is QA-only. We do not find vulnerabilities or write patches. We verify that fixes work, that nothing else broke, and that the evidence exists.
- 1Patching is mandatory
- 2Every patch is a change
- 3A patch pipeline
- 4Regulated evidence
- 5Test the seams
- 6Ways to start
Before the next patch cycle
Six questions for health tech engineering, QA, security, and compliance leaders. Mark each one Yes, Partly, or No. Every answer that isn’t a Yes is a gap to close before the next advisory arrives. Check your team on this page in about two minutes, or download the one-page checklist to work through together. No email required.
Check your team in about two minutes
Answer for how the team works today, not how it’s planned. Your answers stay in your browser.
Which clinical and patient-data flows would hurt most if a fix broke them, and does automated regression cover them?
Good looks like a risk-tiered list of critical flows, each with an automated regression run on every patch.
Does every fixed flaw have a retest case in the permanent suite?
Good looks like a retest linked to each fix and kept in the suite, so a closed flaw stays closed.
How quickly does a smoke suite tell the team that a release broke something?
Good looks like results within minutes of every merge, while the author still remembers the change.
Which third-party components does the product depend on, and which tests run when one of them changes?
Good looks like a current component inventory, or SBOM, mapped to the test suites that protect each function.
Can the team produce, for any patch, the record of what changed, what was tested, and who approved it?
Good looks like one place that holds the finding, the fix, the tests, the results, and the approval.
If the people working on patches changed next month, what would remain in the system of record?
Good looks like runbooks, tests linked to fixes, and handoff notes written while the current person is still there.
The series
Six parts, one every Wednesday.
Patching is mandatory. How well you do it is the choice.
The number of disclosed vulnerabilities keeps rising, and the gap between disclosure and exploitation keeps shrinking. Every fix is also a change to working software. Part 1 sets out the numbers and why the real question is how well a team patches.
Read Part 1
Every patch is a change, and changes need proof.
Three questions need an answer after every fix: is the original flaw closed, did anything the fix touched stop working, and do the connected systems still behave? Part 2 covers the methods that keep those checks fast without making them shallow.
Read Part 2
Build a patch pipeline with QA in every stage.
A team that handles each fix as a one-off falls behind. Part 3 walks through six stages, from intake to learning, and shows how scoring each fix on exposure and on change risk gives a defensible order of work.
Read Part 3
In a regulated industry, a patch isn’t done until the evidence exists.
Section 524B of the FD&C Act, the FDA’s Quality Management System Regulation, IEC 62304, and the proposed HIPAA Security Rule update all ask for proof as well as speed. Part 4 covers what a good evidence package shows for every change, and why building it as you go turns an audit into a retrieval exercise.
Read Part 4
Test the seams where other people’s code meets yours.
Most health tech runs on code someone else wrote: open-source libraries, cloud services, device firmware, and EHR interfaces. Part 5 covers how to test those boundaries without source access, from a component inventory tied to your tests to contract tests for HL7 and FHIR connections.
Read Part 5
QA by your side, and practical ways to start.
No program removes all risk, and a security team is essential. Part 6 lays out ways to start, sized to the team: a 30-minute strategy call, a 3-month pilot, capacity that scales with patch volume, and a continuity check.
Read Part 6
Would your patch knowledge survive a staff change?
Question 6 is about continuity: what stays in the system of record when the people working on patches change. Our QA continuity scorecard is seven questions, about two minutes, with no email required.
Talk to us about your patch process
In a 30-minute strategy call we map how fixes move from advisory to release and identify where regression coverage, component inventory, or evidence is thin. You leave with a short list of gaps your team can act on, whether or not you ever work with us. The call is open to anyone who asks.