Home - Thaumatec

Can you prove your documentation matches your software?

This is the question that ends conversations fastest, because it’s rarely about whether the

documentation exists — it’s about whether it’s current.

Most engineering teams write a Software Development Plan once, early on, and never revisit it as the

product evolves. Six releases later, the plan no longer reflects how the software is actually built, tested,

or maintained. The SOUP list is missing two dependencies that were added in a sprint nobody

documented. Verification records exist for an old release, not the current one.

None of this is intentional negligence. It’s what happens when documentation is treated as a one-time

compliance exercise instead of a living artifact tied to IEC 62304’s software lifecycle requirements. But to

a reviewer running a gap analysis against the standard, the distinction doesn’t matter — a stale

document fails the same way a missing one does.

The fix isn’t writing more documentation. It’s a structured review against the standard itself — class-

appropriate Software Development Plans, current SOUP risk assessments, and verification and validation

records that actually correspond to what’s shipping today.

Is the codebase an asset, or a liability you haven’t priced in yet?

A working product and a sound codebase are not the same thing, and due diligence is where that gap

gets expensive.

Test coverage that looked adequate at seed stage often hasn’t kept pace with the product.

Dependencies accumulate unpatched CVEs quietly, because nobody owns the monitoring process.

Architecture decisions made under deadline pressure — a tightly coupled module here, a workaround

there — become technical debt that nobody flagged because the product still worked fine in production.

The investor or acquirer isn’t trying to catch the team out. They’re trying to answer a much simpler

question: if we fund or acquire this, what are we actually inheriting? A codebase with a clear technical

debt inventory, ranked by remediation effort, answers that question. A codebase nobody has audited

just raises more questions — and questions slow deals down.

This is also where architecture matters as much as code quality. Scalability assumptions that were

reasonable for a pilot don’t always hold at the next stage, and the cloud/device boundary in connected

medical devices carries its own security and latency risk that a generic code review won’t catch.

Would this survive a regulator’s first question?

The third question is the one founders are least prepared for, because it sits at the intersection of

engineering and regulatory strategy — two functions that, in early-stage companies, often don’t talk to

each other enough.

FDA’s 2023 and 2026 Cybersecurity Guidance and MDCG 2019-16 now expect structured, documented security

evidence: a Software Bill of Materials, a threat model built on a recognized framework like STRIDE, and a

defined process for monitoring and remediating vulnerabilities. Infrastructure questions follow close

behind — where is data hosted, how is it segregated, what does the CI/CD pipeline’s release control

actually look like, and can the team demonstrate data residency compliance under GDPR or MDR Article

83.

Companies that have engineering and regulatory working in sync from early on tend to have most of this

in place already. Companies where compliance was bolted on later usually discover the gaps only when

someone outside the company — an auditor, a notified body, or now, an investor’s technical reviewer

— asks to see the evidence.

Why this matters before the data room opens

Each of these questions maps to a real, fundable risk: regulatory delay, unplanned engineering spend, or

a stalled submission. None of them are unanswerable. But they take time to answer properly, and that

time is exactly what a live due diligence process doesn’t allow.

The companies that move through diligence fastest aren’t the ones with zero gaps — they’re the ones

who already know where their gaps are, with a remediation plan attached, before anyone asks.

That’s the difference between a technical review that confirms what you already knew, and one that

derails a term sheet.

Thaumatec’s Technology Due Diligence service combines a structured IEC 62304 and IEC 81001-5-1

documentation review with hands-on codebase, architecture, and infrastructure investigation —

delivered as a single risk-graded report, built for investors, acquirers, and the founders preparing for

them.

Learn more about Technology Due Diligence →

Schedule a call with our expert and see if you are ready