Technical Due Diligence
What is actually there, against what the deck says. On either side of the transaction.
Technical due diligence on a regulated technology company is two assessments that have to be read together. One is the usual question of whether the architecture, the code and the team are what they appear to be. The other is whether the regulatory position is real, because in a regulated company the compliance surface is part of the asset and it is the part that is easiest to present well and hardest to verify quickly.
A clean codebase attached to a premarket cybersecurity package that does not exist is not a clean company. Neither is a strong security document set describing a system that does something else.
What this covers
Architecture and its ceiling
What is built, how it fits together, and what it will cost to do the next thing the thesis depends on. The question is rarely whether it works today. It is what the first genuinely new requirement costs.
The regulatory position, verified
Premarket and post-market obligations, HIPAA posture, vulnerability disclosure, and the evidence behind each. Claims are checked against the system rather than read back from the data room.
Security posture
Identity, authorization, tenant separation, secrets handling, dependency and supply chain exposure, and the test history including what was found and what was done about it.
Key person and team risk
What is understood by exactly one person, what is undocumented, and what walks out of the building if a specific individual resigns after close.
Cloud estate and run cost
What it costs now, what it costs at the modeled scale, and how much of the current bill is buying nothing. Unowned infrastructure is both a cost line and an exposure.
The integration question
For an acquirer, what it takes to connect this to what you already own, and which assumptions in that plan are the expensive ones.
I am not your legal or regulatory adviser and I do not give an opinion on deal terms. This is a technical and regulatory-engineering read that your counsel and your regulatory lead use as an input.
What usually brings people here
You are diligencing a medtech, digital health, legal or financial services technology company.
You are preparing to be diligenced and would rather find it first.
A deal is proceeding and the technical answers you are getting are confident but thin.
Post-close, and the thing you bought is not behaving the way diligence suggested it would.
How the engagement runs
Fixed-price, scoped to the deal and delivered inside the diligence window. The output is written for whoever is making the decision: findings separated into what is broken, what is unfamiliar but fine, and what is a price conversation.
On the sell side it runs the same way and produces a remediation sequence instead of a recommendation, because everything you close before the process starts is something nobody gets to discount you for.
This sits inside the fractional CTO side of the practice. If what you need is ongoing ownership rather than a defined piece of work, start there instead.
Questions I get asked first
How is this different from a generic technical due diligence?
In a regulated company the compliance surface is part of the asset. A clean codebase attached to a missing premarket cybersecurity package, an unexamined business associate agreement, or a security program that exists only as documents is not a clean company. I look at both, because the gap between them is where the value gets destroyed after close.
How long does it take?
A focused read of architecture, code, cloud estate, security posture and regulatory obligations fits inside a normal diligence window. It takes longer when the answers are not written down anywhere and have to be reconstructed from the running system, which is itself one of the findings.
Can you do this on the sell side?
Yes, and it is the cheaper time to do it. Everything a buyer will raise is findable in advance, and a finding you have already fixed is not a price adjustment. A finding you have documented and consciously accepted is usually not one either. The ones that hurt are the surprises.
What do we get?
A written assessment that separates what is broken from what is merely unfamiliar, sized by what it would cost to fix and by what happens if you do not. Written for whoever is making the decision, not for engineers.
Written on this
Start with a conversation
Tell me what’s going on. If this is the right piece of work I will scope it. If it is not, I will say what is.
Bring your architecture problem, stalled project, cloud bill, or diligence deadline.
Not ready for a call? Send a message instead.
For companies looking to engage BATO. Vendors, please email.