IT Due Diligence for Private Equity Acquisitions

PRIVATE EQUITY IT

IT due diligence should find the work hiding behind the deal

Private equity IT due diligence gives the buyer a practical view of the systems, people and contracts that will need attention after completion. It should answer more than whether the target has laptops and Microsoft 365. The useful questions are about ownership, access, resilience, support and the effort needed to separate or integrate the environment.

A target can look stable during management meetings while relying on one administrator, an undocumented firewall, old line-of-business software or backups that nobody has restored. Those gaps often become urgent on Day one. They can also change the integration budget and sequence.

Milnsbridge supports private equity firms and portfolio companies with technical discovery, transition planning, security controls and ongoing IT support. The legal, financial and tax parts of a transaction remain with the buyer's appointed advisers. This article focuses on the technology workstream.

The Australian Signals Directorate warns that a compromise inside one organisation can spread to both organisations when data is exchanged or systems are connected.[1] That makes the connection decision part of diligence, not an automatic Day one task.

The review also needs boundaries. A buyer may need enough evidence to price and sequence the technology work without giving a broad group access to sensitive systems before completion. Start with an agreed request list, a secure evidence room and named reviewers. Escalate gaps that affect control, continuity or the integration budget. Leave lower impact tidy-up work for the post-close roadmap. Give every request a decision purpose so the target knows why the evidence matters. An application list supports separation planning. Privileged account records show whether control can transfer at completion. Restore evidence tests whether a recovery promise has substance. Mark records that can be viewed before signing, records that need supervised access and checks that must wait until completion. Keep a decision log beside the request list. It should record what was supplied, who reviewed it, what remains uncertain and whether the gap changes price, timing or the conditions for connection.

BEFORE CLOSE

Four questions that shape the integration plan

EVIDENCE OVER ASSUMPTIONS

Start with records that show how the environment behaves

TECHNICAL WORKSTREAMS

What private equity IT due diligence should cover

These workstreams should meet in one dependency map. An identity change may affect access to payroll, finance applications or a customer portal. A carrier contract may delay a site move. A legacy server may hold data that the buyer assumed was already in Microsoft 365. Connecting the findings prevents one team from scheduling work that another team is not ready to support. Build the map around business services rather than device counts. For each service, record the application owner, administrator, identity source, hosting location, network dependency, support contract and recovery path. Then mark which items transfer with the deal and which require a new agreement. This exposes awkward handoffs early. A finance system may be licensed to the seller, while its database sits on hardware owned by the target. A branch may rely on a shared internet circuit that cannot be separated on the planned completion date. Those details turn a technical inventory into an integration schedule.

DAY ONE CONTROL

Turn findings into a sequence the operating team can use

The diligence report should end with an action plan, not a risk register that nobody owns. Day one work usually protects control of identities, business communication and support escalation. It should identify who can approve changes and what the team must avoid connecting until further checks are complete.

The first 30 days can address visibility and urgent remediation. That may include replacing shared administrator accounts, closing unsupported remote access, confirming backups, documenting the network and establishing regular patch and security reporting. Longer projects such as tenant consolidation, server replacement or application migration belong in a funded roadmap.

Data movement needs its own plan. ASD recommends secure transfer infrastructure, two trusted staff overseeing online transfers, checks before and after transfer, and protection for temporary staging locations.[1] These are concrete controls that can be assigned to named people.

The plan should separate decisions from tasks. A decision might be whether to retain the target's Microsoft 365 tenant. The tasks then cover access, licensing, data movement, user communication and rollback. Each task needs an owner, due date, dependency and proof of completion. This keeps technical work tied to the transaction plan instead of becoming an open-ended list.

Cost estimates should use the same sequence. Separate immediate control work from planned upgrades and optional improvements. State the assumptions behind each estimate, including staff numbers, sites, licences, contract exit dates and access to the target environment. If an estimate depends on evidence that has not been supplied, show a range and name the missing input. The investment team can then decide whether to seek more evidence, negotiate a condition or accept the uncertainty. Keep one-off transition work separate from recurring operating costs. Record whether figures include hardware replacement, project labour, licence overlap, data transfer and contract termination charges. Test the estimate against the dependency map rather than applying a flat amount per employee. A small team with several sites and an old line-of-business system can require more transition work than a larger cloud-based business. Put timing beside the cost. Spending needed before systems connect is different from an upgrade that can wait until the next budget cycle. This gives the deal team a usable cash requirement and gives the operating team a sequence it can defend. It also makes later budget changes easier to trace back to the evidence available before close.

The buyer should also decide what ongoing support looks like after the initial transition. A managed IT support plan can take ownership of agreed monitoring, patching, user support and reporting. Backup, project and security add-ons should remain separately scoped where they are not part of the chosen plan.

FOUR DECISION CHECKS

Evidence the investment team should expect

COMMON QUESTIONS

Private equity IT due diligence FAQ

SOURCE NOTES

Official guidance used in this article

[1] Australian Signals Directorate guidance for mergers and acquisitions

[2] OAIC guidance for preparing a data breach response plan

EXPLORE MORE

Related Milnsbridge resources