MNA Tools
Playbook · Before signing

IT due diligence

Find out what technology you are buying, what it costs to run and to change, and what belongs in the price, the purchase agreement and the day-one plan.

IT due diligence is where you find out what technology the buyer is actually getting: the systems the business runs on, the people who keep them running, the contracts behind them and what they cost. You do it under time pressure, with information supplied by a seller who wants a good price.

Mistakes here surface late. An out-of-support platform, a licence that does not transfer, or a core system only one person understands rarely moves the headline price on its own. It moves the integration budget, the timeline and the first year's risk, and it shows up after the agreement is signed, when your leverage is gone.

When it happens

Mostly between the letter of intent and signing, once a non-disclosure agreement is in place and the data room opens. Before that, during screening, you only have what the target shows the internet.

In diligence you usually have the data room, a written question-and-answer process, one or more management sessions and perhaps a site visit. You rarely have system access, and you seldom speak to anyone below IT leadership. Questions are often rationed and routed through advisers, so each one has to count.

Who is involved

  • The deal team, who own the timeline, the question process and the valuation model your findings feed.
  • The IT diligence lead, who sets the scope, runs the request list and the sessions, and writes the report.
  • The security lead, running security due diligence in parallel.
  • Legal counsel, who turn findings into contract terms and review supplier contracts for change of control and assignment.
  • Finance, for run-rate costs, capital spend, one-off costs and synergies.
  • The target's IT leadership, who answer questions, usually through the seller's advisers.
  • The buyer's business owners, who will run the acquired business.

The steps

1. Set the scope and the materiality threshold

Start from the deal thesis. A business that will run on its own needs a different review from one that will be folded into the buyer's platforms within a year. Agree a materiality threshold with the deal team so effort goes to findings that could change the price, the terms or the plan.

  • The deal thesis and the integration it assumes
  • Entities, sites and countries in scope
  • The cost and risk threshold for a reportable finding
  • Whether the target depends on a parent's shared services (if so, read carve-outs and transition services)
  • Deadlines for questions, the report and the draft purchase agreement

2. Send a structured request list

Organise the list by area so you can track answers and see the gaps. Ask for documents first and explanations second.

  • Organisation and key people: IT organisation chart, headcount, contractors, outsourcers, tenure of key staff
  • Infrastructure and hosting: data centres, cloud subscriptions, network diagrams, hardware age and support status
  • Applications and data: application inventory with owner, version, hosting, degree of customisation and where the data lives
  • Security: policies, recent assessments, incident history
  • Contracts and licences: top suppliers by spend, entitlements against deployment, change-of-control and assignment clauses, termination terms
  • Run-rate costs and capital spend: operating costs over recent years, capital plans, charges from a parent or affiliate
  • Technical debt and projects in flight: deferred upgrades, project budgets, status and remaining spend
  • Compliance: certifications, regulatory obligations, open audit findings
  • Shared services: what the target receives from its group and on what terms

3. Run the management sessions and site visit

The sessions are where you learn what the documents leave out. Build your questions from the gaps in the data room, and ask for a demonstration rather than a description.

  • Ask what breaks in a normal month and who gets called
  • Ask who would be hardest to replace, and why
  • Ask what was deferred in the last year or two
  • On a site visit, look at the server room and the wiring closets: labelling, age, power, what is unmanaged

4. Test claims against evidence

Every important claim needs a document, a report or an outside observation behind it. Mark each one verified, partly verified or unverified, and say so in the report.

  • Licence counts against invoices and true-up reports
  • "We have disaster recovery" against the last test report and its results
  • Domain and hosting lists against the target's public footprint
  • Support status against the vendors' published end-of-life dates
  • Cost figures against ledger extracts, not budget slides

5. Estimate stand-alone and integration costs

Finance needs two numbers. The stand-alone cost is what it takes to run the target independently after closing, including whatever a seller or parent used to provide. The integration cost is the one-off spend to reach the planned end state. Give ranges and state the assumptions behind each.

  • One-off costs: separation, migration, replacement, re-papered licences, transition services
  • Recurring changes: new licences, support contracts, extra staff
  • Remediation that cannot wait, such as end-of-life platforms
  • Synergies, each with its assumption and expected timing
  • A confidence level for every line

6. Turn findings into deal terms with counsel

Some findings belong in the price, some in the purchase agreement, some only in the plan. Agree the treatment with counsel. Typical outcomes are representations and warranties about IT systems, licence compliance and data protection, specific indemnities for known issues such as a licence shortfall, and pre-closing undertakings to fix something specific. Give counsel the facts, the evidence and the exposure. Leave the drafting to them.

  • For each finding: description, evidence, impact, estimated cost, proposed treatment
  • Contracts that need consent to assign or that terminate on change of control
  • Services the seller must provide after closing

7. Write the report

Lead with the few findings that change the deal, in language the deal team can act on. Put the detail by area behind it, with the evidence status of each claim.

Red flags

  • Core business processes running on platforms that are out of vendor support, or about to be
  • One person who understands the core system, the network or the payroll interface, with no documentation and no deputy
  • Software deployed beyond its entitlement, licences held in the parent's or an individual's name, or licences that cannot be assigned
  • Disaster recovery that exists on paper and has never been tested end to end
  • A core system so heavily customised that upgrades stopped years ago
  • Customer or personal data held in a country nobody mentioned, or with a supplier that has no data-processing terms
  • A sharp drop in IT spend in the year before the sale
  • Critical services from a parent with no written terms
  • Large projects in flight with no budget left to finish them
  • Answers that keep arriving as summaries instead of documents

What you hand over

  • The IT due diligence report, with an executive summary and findings by area
  • A findings register, each finding with its treatment: price, purchase agreement, plan or accept
  • Cost estimates: stand-alone, one-off integration, recurring changes and synergies, with assumptions
  • A contract list showing change-of-control and assignment issues
  • Input to the purchase agreement, agreed with counsel
  • Day-one requirements and transition service needs, as the starting point for day-one readiness
  • Open questions to resolve before closing

Where MNA Tools helps

  • DeepReview builds an outside-in profile of the target from public information: domains, hosts, exposures and leaked credentials, with an A to F grade. Use it to test the data room's lists against what can be seen from outside. It is passive by default and available on request.
  • HouseGRC holds your findings as an owned, dated register, with the target as its own organisation, so diligence findings carry through into integration.
  • SubnetSleuth can inventory a site or range read-only, where the target grants access, to test its asset lists against the network itself.

See MNA Tools in a deal for how the three fit together across the stages.

A general guide to the technology side of a deal, not legal, tax or financial advice. Adapt it to the deal in front of you, and take advice where the stakes call for it.