Technical diligence rarely sinks a deal because the technology is imperfect. It goes badly when nobody can explain how things work, who owns what, or what the plan is for known risks. These four steps get the facts written down, the obvious issues fixed and the remaining risks owned before the questions arrive.

Step 1 — Inventory what you have

Goal: Write down how the business runs on technology.

  1. List every system, where it is hosted and who has admin access.
  2. Record who wrote and owns the code, including contractors and agencies.
  3. List vendors, open-source licences, subscriptions and contracts.
  4. Draw a simple map of where customer and company data flows and is stored.

You finish with: A system, ownership and data inventory in one place.

Step 2 — Review against common questions

Goal: Find the gaps before someone else does.

  1. Check that code, cloud accounts and domains are owned by the company.
  2. Review security basics: access, backups, multi-factor sign-in and incident history.
  3. Review the delivery process: how changes are tested, released and rolled back.
  4. Note costs, single points of failure and anything that depends on one person.

You finish with: A ranked list of risks with an owner for each.

Step 3 — Fix the quick wins

Goal: Close what can be closed before the deadline.

  1. Move any accounts or code held personally into company ownership.
  2. Remove old access and turn on multi-factor sign-in everywhere.
  3. Test a backup restore and write down the result.
  4. Write a dated plan for larger items that cannot be fixed in time.

You finish with: Quick wins closed and a dated plan for the rest.

Step 4 — Prepare the story and evidence

Goal: Answer questions quickly and consistently.

  1. Write a short technical overview: architecture, team, process and roadmap.
  2. Collect evidence in one document room, organized by topic.
  3. Check every claim in the overview against the evidence.
  4. Agree with leadership what is disclosed and who answers which questions.

You finish with: A technical overview and an organized evidence folder.

Common pitfalls

  • Waiting until questions arrive to find out who owns the code.
  • Making claims in the overview that the evidence does not support.
  • Hiding known risks instead of showing a dated plan.
  • Letting one engineer answer everything from memory.

See it as a workflow

Leadership

Technical due diligence preparation

Get the technology, code and security story in order before investors or an acquirer ask, so diligence confirms the plan instead of derailing it.

See the workflow

More guides like this

Related answers

Read as Markdown Fractional CTO