What due diligence finds first

We have sat on both sides of this table for 13 years: building the systems that get audited, and looking at systems before money changes hands. The pattern is stable. Due diligence does not fail a deal on the interesting questions — it fails it on four boring ones that surface in the first week, long before any architect draws anything.

1. The bus factor question

The first question is not “is the code good?” It is: can production be rebuilt from the repository alone — proven, not assumed? If the honest answer involves one person, one laptop, or one unproven intuition, the finding writes itself. Teams discover this question was coming the moment the letter of intent is signed; by then the only lever left is the price.

2. The restore that was never rehearsed

Backups that have never been restored are a belief system, not a control. The first week of diligence asks for the restore proof — the log, the timestamp, the duration. Teams that rehearse restores can produce it in an hour. Teams that do not produce a quiet admission, and that admission becomes the discount line.

3. Evidence that lives in someone's head

NIS2 and ISO 27001 changed what “we have it under control” has to mean: evidence, not assurances. Where is the inventory? Who owned the last incident, and where is the writeup? When the answers are names instead of documents, the buyer does not hear “small team” — they hear “keyperson risk”, and they price it.

4. The repair-or-reprice moment

None of these four is expensive to fix when there is no deal on the table. All four are expensive to fake when there is one. That asymmetry is the whole argument for preparing before a buyer appears: the same work costs an order of magnitude less without a deadline attached to it.

• Rebuildable from the repository: yes or no, with proof.
• Restore rehearsed: when, how long, by whom.
• Ownership named per system: a person, not a team.
• Incidents written up where a stranger could read them.

What preparing actually looks like

It is not a six-month audit program. It is a short, honest pass over the four questions above, fixing what a stranger would stumble over, and writing down what already works. We run this as a 30-minute diagnosis call: you describe the system and the deal or decision you face, and we look at the first concrete risk together — no pitch, no obligation. If you want the full set of questions we ask, the IT due-diligence checklist on this page is the same one we work through.