IT due diligence: the risks that are not in the codebase

A code review answers whether the software is any good. It answers almost nothing about whether the company can be bought, integrated, or operated by somebody else.

The findings that hold up transactions are usually not in the repository at all. They are in contracts, account ownership, licence terms and where the data physically sits — and none of them requires reading a line of code to find.

This is the half of a technical due diligence engagement that runs in parallel with the code work, and in smaller transactions it is frequently the half that matters more.

Account and asset ownership

Establish who legally controls each of these: domain registrations, DNS, cloud accounts, app store listings, code signing certificates, CI systems, the password manager, and the analytics properties.

The pattern to look for is anything owned by an individual rather than the company — a founder’s personal account, a contractor’s registrar login, an app store listing under someone’s Apple ID. This is common, it is rarely malicious, and it can genuinely block a completion until it is untangled.

Certificates deserve their own check. An expiring code signing certificate controlled by someone who left is a small problem that becomes an urgent one on a schedule you do not control.

Licence exposure

Two directions, and both matter.

Inbound: what the software depends on and under what terms. Copyleft components inside a proprietary product are the classic finding. Also worth checking: dependencies whose licence changed after adoption, which has happened to several widely used projects and which nobody notices because the version in use predates the change.

Outbound: what the company promised its own customers. Perpetual licences, source escrow agreements, most-favoured-nation pricing clauses, uptime commitments with financial penalties. These live in sales contracts and they transfer with the business.

Vendor concentration and contract terms

List the vendors the product cannot run without, then read the contracts for three things: notice period, price escalation, and what happens on change of control.

Change-of-control clauses are the ones that surprise people. A critical vendor entitled to renegotiate or terminate when the company is acquired is holding an option, and the value of that option comes out of the deal.

Also worth quantifying: what a forced migration from each critical vendor would cost in months. That number is the real measure of the dependency.

Data location and lawful basis

Where the personal data is stored, which jurisdictions it moves through, what the retention policy says, and whether the system can actually honour a deletion request.

That last one is a technical question dressed as a policy question. Plenty of systems can hide a record and very few can genuinely remove it from every copy, including backups and the analytics tool nobody remembered.

Continuity

Not the disaster recovery document — the evidence. When was a restore last tested, and by whom. Who is on call, and what happens if that person is unavailable. Which single supplier failure would stop the business.

The useful framing is not whether a plan exists but when it was last exercised. Plans that have never been exercised are hypotheses.

Why this gets skipped

Because it is unglamorous and because it needs access to legal and finance as well as engineering, which means more people and more scheduling. It is also harder to demonstrate expertise in, so it attracts less attention than a code review does.

That is a poor reason to skip the half of the work most likely to produce a finding that changes the terms.

Who needs to be in the room

This is the half of the work that stalls, and it stalls for a predictable reason: the answers live with people who are not engineers.

Account ownership is usually finance or operations. Customer contract terms sit with sales or legal. Data residency needs whoever owns the privacy programme, which at smaller companies is often nobody in particular.

If you are commissioning the review, name those people at the start and get them scheduled in the first week. If you are being reviewed, assemble the licence inventory, the vendor contract list and the account ownership map before anyone asks. Those three artifacts remove most of the delay, and producing them frequently surfaces the finding yourself — which is a much better position than having it surfaced for you.

What this does not cover

It does not assess the software. A company can pass every item above and still have a codebase nobody can safely change, which is why the two halves run together rather than as alternatives.

I would also flag that licence analysis at scale needs tooling and legal review. I can identify the exposure and read the obvious cases; the determination of whether a particular copyleft term applies to a particular linkage is a lawyer’s call, not mine.

Related reading: the diligence process covers how this fits the wider sequence, the checklist covers the code-side items, and what a report contains covers how these findings get written so they survive a negotiation.