Diligence rarely fails on the device.
The device works. The bench data is good. The clinical story holds up. Then a request list arrives, and somewhere between item fourteen and item twenty-two there are five or six lines about software documentation — and that is where a process that was moving in weeks starts moving in months.
So here is what actually gets pulled when there is regulated software in the product, what a weak answer looks like, and what a clean one looks like.
Why software is where diligence slows down
Software is the only part of your device whose entire history was recorded automatically. Every commit is timestamped. Every dependency version sits in a lockfile. Every ticket has an author and a close date.
That cuts both ways. If the process was disciplined, the evidence already exists and diligence moves fast. If it was not, the gaps are just as legible — and legible to anyone technical who spends an afternoon in the repository. You cannot tidy a commit history the way you can tidy a slide.
The deeper reason is about what is being valued. A reviewer looking at your mechanical design is evaluating a finished thing. A reviewer looking at your software is evaluating something that will keep changing for the entire life of the product, and asking what it will cost to keep changing it once you are no longer the only people who understand it.
The five artifacts they pull
1. Traceability from requirement to test
What gets asked: the traceability matrix linking software requirements to design, to test cases, to test results.
A weak answer: a spreadsheet assembled in the three weeks before submission, never updated since, whose requirement IDs no longer match anything in the repository.
A clean answer: a matrix generated from your tooling rather than by hand, current as of a known software version, where every requirement traces forward to a verification result and every gap is explicit and justified.
What it tells them: whether your requirements are real or reverse-engineered. Reverse-engineered requirements are easy to spot, because they read like descriptions of the implementation rather than statements of intent — which is exactly what they are. A reviewer who sees that concludes the software cannot be changed safely by anyone except the people who originally wrote it. That is a valuation problem, not a paperwork problem.
A useful test before anyone else runs it: pick three requirements at random and follow each one down to the tests that verify it, then pick a test and work back up to the requirement that motivated it. Matrices built after the fact almost always work in one direction only.
2. Your third-party software inventory
What gets asked: the list of third-party and open-source components, with versions, known vulnerabilities, licences, and the rationale for each one being acceptable in a medical device. Under IEC 62304 this is your SOUP inventory; under FDA's cybersecurity expectations it is your SBOM. Diligence will ask for both and will notice if they disagree.
A weak answer: a package manifest exported the week the request arrived. That tells the reviewer what you depend on today. It does not tell them what you shipped, which is the actual question.
A clean answer: an inventory generated from the build, tied to a released version, with a monitoring process behind it and a named owner.
What it tells them: your security exposure, your licence exposure, and whether anybody is actively watching either. This is the artifact that most often changes price rather than killing a deal. A stale inventory becomes a remediation line item, and remediation line items come out of your number.
3. Problem resolution and maintenance records
What gets asked: your open defect list, and a walk-through of how one recent safety-relevant problem was handled from report to closure.
A weak answer: two trackers, no field distinguishing safety relevance from severity, and closed tickets whose entire resolution history is the word "fixed."
A clean answer: a single intake queue, problems characterised by both severity and safety relevance, each linked to a change request, a verification result and a version — plus evidence that somebody looks across problems for patterns rather than only closing them one at a time.
What it tells them: what this software costs to own. An acquirer is not buying a codebase, they are buying an obligation to maintain regulated software for years. Your problem records are the most honest estimate available of what that obligation looks like in practice.
4. Whether you can rebuild the version you cleared
What gets asked: reproduce the exact software build that went to FDA.
A weak answer: a pause.
A clean answer: a tagged release, a documented toolchain with pinned versions, and a build that runs today and produces the same artifact.
This is the question that most reliably stops a call. The build is on a server. The server has not been rebuilt in two years. Nobody recorded the compiler version, and the engineer who set it up has left. The cleared device still exists; the ability to reconstruct it does not.
What it tells them: whether your cleared product is something you control or something that happened once. It is also the point where configuration management stops being an abstraction and becomes a question with a yes or no answer.
5. Whether the risk file moved after clearance
What gets asked: the revision history of the risk management file.
A weak answer: last revised on the date of submission.
A clean answer: revisions tied to specific software changes, each modification carrying a risk impact analysis, with traceability back to the change that prompted it.
What it tells them: whether you ran a post-market process or simply shipped. A risk file frozen at submission says the team treated risk management as a gate to pass rather than a process to run. Unlike the other four, this one carries consequences beyond the deal — a frozen risk file is a finding waiting for an auditor, and the buyer knows they are inheriting it.
What they are actually measuring
None of these five questions is really about compliance. Compliance is the vocabulary, not the subject.
What a technical reviewer is measuring is transferability: can a team that is not yours take this software over and keep it safe, current and shippable, without rediscovering everything your original engineers knew and never wrote down?
Which is why the answers matter more than the artifacts. A team with an imperfect traceability matrix who can say exactly where the gaps are and why is in a stronger position than a team with a complete-looking matrix that turns out to have been assembled retrospectively. The first team is describing a process they run. The second is describing documents they produced.
If you are six months out
Six months is enough to fix all five, and the order matters.
Start with the build, because it has a hard yes-or-no answer and takes the longest to unwind if it is broken. Tag a release, pin the toolchain, prove you can reproduce it, write down how.
Then the third-party inventory, because it is mostly mechanical and it is the one that costs real money if you leave it. Generate it from the build, get a licence review done once, and put a recurring calendar item against it.
Then problem resolution, because the fix is two fields and a named owner rather than a new system. Everything you add from today forward is evidence. You do not get to retrofit the past, but you can demonstrate the process is real and running now.
Traceability and the risk file take longest, because honest remediation there means revisiting decisions that were made informally. Start them early and expect them to be the two still open at the end.
If the request has already landed
Then you triage, and the single most important thing I can tell you is this: do not backfill.
The instinct to reconstruct a traceability matrix over a weekend, or to date an inventory as of eighteen months ago, is understandable and it is the one mistake that turns a repricing into a dead deal. The people reading these documents have seen a great many that were made in a hurry, and the tells are not subtle — uniform timestamps, no intermediate revisions, language that does not match the era of the code it describes.
The move is to produce what exists, name what does not, and bring a remediation plan with dates and an owner attached. That turns the conversation from "what else is missing" into "what does this cost and who is fixing it." The second conversation is one you can negotiate.
The part most founders miss
Every artifact on that list is an output of IEC 62304 run properly. Not an extra deliverable, not a diligence-specific exercise. Traceability comes out of Clause 5. Maintenance records out of Clause 6. Risk analysis out of Clause 7. Build reproducibility out of Clause 8. Problem records out of Clause 9.
If your team treated those clauses as a submission requirement — something you satisfy once, on the way to clearance — diligence is where you find out they were describing how the product gets operated for its whole life.
Which is the frustrating part. Nobody who did this work properly did it in order to pass diligence. They did it because it is how you build software you can keep changing safely. Passing diligence is just what that looks like from the outside.
Preparing for diligence, or already in the middle of it? Hattrick builds and maintains FDA-regulated device software, including getting the documentation story straight before somebody else reads it. Get in touch at [email protected].