Who is digital health technical due diligence for?
Seed-to-Series-B investors, acquirers, and health systems or pharma groups evaluating a vendor. We also run sell-side diligence for founders who want to find the issues before their investors do. The reviewer has built and shipped regulated clinical software, so the findings are grounded in what it takes to fix them.
What does digital health technical due diligence include?
- Architecture and scalability — whether the system can grow with the business case, and what it will cost to get there.
- Codebase and engineering practices — code quality, testing, CI/CD, dependencies, and the bus factor.
- Security and HIPAA posture — technical safeguards, vendor and BAA coverage, and incident history.
- Regulatory position — whether claims and product are consistent with the SaMD position the company states.
- Data assets and rights — what data the company holds, whether it may use it as planned, and how clean it is.
- Team and key-person risk — who holds the knowledge and what happens if they leave.
- Remediation estimate — what the findings will cost to fix, so they can be priced into the deal.
How does a digital health technical due diligence engagement run?
- ScopeConfirm the questions the deal needs answered and the access available.
- ReviewDocumentation, repository and infrastructure access, and interviews with the technical team.
- ReportRisk-rated findings with evidence and remediation estimates.
- CallA readout with the investment or deal team, and follow-up questions for two weeks.
Digital health technical diligence scorecard
We score each target across seven areas. Each one has evidence we request up front and clear red and green flags, so investment committees get a consistent read across deals. (Founders preparing for diligence should start with our digital health readiness checklist.)
| Area | What we check | Evidence we request | Red flag | Green flag |
|---|---|---|---|---|
| Architecture and scalability | Service boundaries, data model, hosting, load and cost curve, single points of failure | Architecture diagram, cloud bill, incident log, load-test results | A demo stack that has never carried production load | Documented architecture that already runs at several times current volume |
| Security and HIPAA posture | Risk analysis, BAAs, access control, encryption, logging, breach history | HIPAA risk analysis, BAA list, pen-test report, SOC 2 or HITRUST report if any | No written risk analysis, or PHI with vendors that have no BAA | A current risk analysis, a clean pen test with fixes closed, and BAAs in place |
| Regulatory and FDA status | Whether the product is a device, which features are cleared, whether marketing matches the clearance | Regulatory strategy memo, 510(k) or De Novo numbers, FDA correspondence, claims in sales material | Diagnostic or treatment claims with no clearance or wellness rationale | Claims that match a listed clearance or a documented wellness or CDS position |
| Data rights and interoperability | Who owns the data, what consents allow, EHR integrations, export formats | Data-use agreements, consent forms, integration list, API docs | Training data the company has no clear right to use | Consents and contracts that cover the planned uses, with standard FHIR or HL7 integrations |
| Clinical evidence | Whether the evidence supports the claims buyers are paying for | Validation studies, publications, real-world performance data | Accuracy numbers from internal data only, with no external validation | Prospective or external validation in the intended population |
| AI/ML validation | Training and test separation, reference standards, subgroup performance, monitoring and change control | Model cards, evaluation reports, data lineage, retraining plan | Test sets drawn from the training data, or no monitoring after launch | Independent test sets, subgroup results and a written plan for model changes |
| Team and delivery | Who holds the critical knowledge, release process, technical debt | Org chart, release history, backlog, key-person list | One engineer who alone can deploy or understands the core system | Documented processes, code review and more than one owner per critical system |
Top 10 red flags in digital health technical diligence
- Marketing claims that outrun the FDA status. Check every diagnostic or treatment claim against FDA's 510(k) and De Novo databases and the company's establishment registration and device listing.
- No written HIPAA risk analysis, or one that predates the current architecture.
- PHI flowing to vendors without a BAA, including analytics, logging and AI model providers.
- A breach history not disclosed in the data room. Large breaches are public on HHS's breach portal.
- Claimed EHR certification that does not appear in ONC's Certified Health IT Product List, or integrations that are one-off scripts.
- Data practices that may raise information blocking questions for a company that is a certified health IT developer or health information network.
- No software bill of materials or cybersecurity documentation for a connected device. FDA's premarket cybersecurity guidance expects them for cyber devices.
- AI accuracy reported only on data the model was trained on, with no independent test set or subgroup results.
- Unclear rights to the training data, such as clinical data licensed for care but not for product development.
- Key-person risk: one engineer or contractor who alone can deploy, or who owns the code and infrastructure accounts.
Data-room request list
What we ask for in the first week. Having it ready shortens diligence and signals maturity.
- Architecture diagram, data-flow diagram showing where PHI lives, and hosting accounts
- HIPAA risk analysis, policies, BAA inventory and the most recent penetration test
- SOC 2 or HITRUST report, if the company has one
- Regulatory strategy memo, FDA submission numbers and any FDA correspondence
- Data-use agreements, consent forms and data licenses
- Validation studies, publications and AI model evaluation reports
- Incident and outage log for the last 24 months
- Read-only repository access, release history and a list of open-source licenses in use
- Org chart with owners of each critical system
Frequently asked questions about digital health technical due diligence
Do you do sell-side diligence?
Yes. Founders often engage us before a raise to find and fix issues on their own terms. The deliverable is the same report, addressed to you.
How much access do you need?
Read-only access to repositories and cloud consoles, existing documentation, and two to four interviews. We never need production patient data and work under NDA.
How is this different from your Initial Audit?
The Initial Audit is for the company itself and ends in a remediation roadmap the team executes. Due diligence is for a third party and ends in a risk-rated opinion for a decision. The review is similar; the audience and the deliverable differ.
What do you look at in technical due diligence for a digital health company?
We score seven areas: architecture and scalability, security and HIPAA posture, regulatory and FDA status, data rights and interoperability, clinical evidence, AI/ML validation, and team and delivery. Each has evidence we request and defined red and green flags.
How do you verify a target's FDA status?
We check every product claim against FDA's public 510(k), De Novo and establishment registration and listing databases, then compare the cleared indications with what the company actually markets. Mismatches between claims and clearances are one of the most common findings.
What should a digital health company put in its data room for tech diligence?
An architecture and PHI data-flow diagram, HIPAA risk analysis and BAA list, recent penetration test, any SOC 2 or HITRUST report, FDA submission numbers and correspondence, data-use agreements and consents, validation and AI evaluation reports, an incident log, and read-only code access.
Related services
Scope it in 30 minutes
Book a scoping call and we'll name the smallest engagement that moves you forward. Most teams start with the fixed-scope Initial Audit.
Book a 30-min scoping callPrefer to write? Send a short note.