Most medical device companies bringing in outside hardware or firmware help ask the wrong first question. They ask “are you ISO 13485 certified,” when the question that actually predicts whether the engagement works is “how do your records plug into our design history file.”
Certification tells you a company has a quality system. It doesn’t tell you whether that system produces records your quality team can drop into a DHF without a rewrite. Those are different problems, and conflating them is how companies end up with a certified vendor whose deliverables still need three weeks of internal rework before they’re audit-ready.
Two Different Things Called “Compliance”
Having a quality system means the engineering team follows a documented process: design reviews happen, changes go through change control, records get retained. This is what certification audits.
Producing design-control-ready output means the specific documents that come out of that process (design inputs, design outputs, verification protocols, risk control records) are structured the way your DHF needs them, cite the right predicate requirements, and trace cleanly from requirement to implementation to test result.
A firm can have the first without the second. A well-run process that produces internally-consistent but idiosyncratically-formatted records still forces your quality team to translate everything before it’s usable. The translation work is where schedules actually slip, not in the engineering itself.
What Should Cross the Line
Regardless of who does the engineering, these records need to exist in a form your quality system can consume directly:
- Design inputs traceable to requirements. Not “we built what you asked for,” but a document mapping each engineering decision to the requirement that drove it, in language your traceability matrix can reference.
- Risk control implementation evidence. If your ISO 14971 file identifies a hazard and specifies a control, the engineering record needs to state where that control lives in the design and how it was verified. A schematic alone doesn’t answer “how do we know this mitigation works.”
- Verification and validation protocols and results, written before the test runs, with pass/fail criteria stated in advance rather than reverse-engineered from whatever the test happened to show.
- Design review records with dates, participants, and what was actually decided. Not meeting notes. A record that shows the review happened and what changed because of it.
- Change history for every design revision, with rationale. “Changed R14 from 10k to 4.7k” is not a change record. “Changed R14 to 4.7k to bring pull-up rise time within the I2C spec’s 300ns limit at the increased bus capacitance from the added sensor” is.
None of this requires the outside team to be certified. It requires them to already know what a DHF-ready record looks like, because retrofitting these five things into six months of undocumented engineering work is far more expensive than producing them as you go.
What Should Not Cross the Line
The reverse mistake is just as common: companies that hand over things an outside engineering team has no business owning.
Intended use, clinical claims, the regulatory pathway and predicate selection, product-level risk acceptance, and the actual FDA submission are yours. An external hardware or firmware partner should coordinate with your regulatory and quality functions and hand over evidence that feeds those decisions. They should not be making them, and you should be skeptical of anyone offering to.
This isn’t a legal nicety. It’s the difference between “we implemented the risk control and here’s the verification evidence” and “we decided this risk was acceptable,” and only your organization is positioned to make the second call, because only your organization holds the regulatory relationship and the liability that comes with it.
The Question That Actually Screens for This
Skip “are you certified.” Ask instead: “Walk me through what a design review record looks like when you hand it to a client’s quality team.” A firm that’s done this before will describe a specific document structure without hesitating. A firm that hasn’t will describe their internal process and never get to the handoff format, because they’ve never had to think about the seam.
The seam is the whole problem. Good engineering that never has to interface with someone else’s quality system doesn’t need to think about traceability format. Good engineering that has to plug into your DHF does, and that’s a different (and narrower) skill than most hardware and firmware engineers develop on their own.
If you’re evaluating outside help for a regulated program, see how we split this ownership before you scope the engagement, not after the first design review record shows up in the wrong format.