# IT Due Diligence: Infrastructure, Security and Systems

- url: https://www.tryplox.com/blog/it-due-diligence
- date: 2026-07-01
- tags: Due Diligence, Data Rooms
- excerpt: The first time I sat in on an IT due diligence call, I expected a tidy conversation about servers and software licenses. Instead we spent two hours untangling who actually owned the source code, why p

The first time I sat in on an IT due diligence call, I expected a tidy conversation about servers and software licenses. Instead we spent two hours untangling who actually owned the source code, why production credentials lived in a shared spreadsheet, and whether the company had ever patched a database that had been public for three years. IT due diligence, I learned, is rarely about the technology being impressive. It is about whether the systems can survive scrutiny, scale with the business, and not blow a hole in the deal after it closes.

This guide covers what IT due diligence reviews, who runs it and when, the step-by-step process I follow, a checklist you can lift directly, the red flags that make me slow down, and how a well-run data room takes the friction out of the whole thing. For wider context, IT diligence is one workstream inside the broader [due diligence](/blog/due-diligence-guide) effort that buyers and investors run before they commit capital.

## What IT due diligence actually is

IT due diligence is the structured review of a target company's technology infrastructure, security posture, software, data practices, and the people who keep it all running. The point is to answer a few blunt questions: Does the technology do what management claims? Can it support the growth case the deal is priced on? What will it cost to maintain, fix, or replace? And what hidden liabilities, legal, security, or operational, are buried in the stack?

It is worth being precise about scope, because the term gets used loosely. IT due diligence overlaps with but is not identical to [technical due diligence](/blog/technical-due-diligence). I tend to treat technical diligence as the deeper assessment of a product's codebase, architecture, and engineering practices, while IT diligence is broader and more operational: it covers the corporate systems, infrastructure, security, vendor contracts, and IT organization that keep the whole company functioning, not just the flagship product. On a software deal the two blur together. On an industrial or services deal they are clearly distinct, and you need both.

It also sits next to, and feeds into, [financial due diligence](/blog/financial-due-diligence). The IT cost base, capitalized development spend, license obligations, and any deferred infrastructure investment all land on the numbers your finance team is modeling. A finding in IT diligence ("they will need to migrate off an unsupported platform within 18 months") often becomes a line item in the financial model and, sometimes, an adjustment to the price.

## Who runs it, and when

IT due diligence is usually commissioned by the buy side: a private equity firm, a corporate acquirer, or an investor leading a later-stage round. The actual work is done by a mix of people. Smaller deals might rely on a single experienced CTO-for-hire or a boutique advisory. Larger deals bring in a specialist diligence firm, sometimes a Big Four technology team, alongside the acquirer's own internal IT and security leaders.

On the sell side, founders and management get pulled in to answer questions, surface documents, and grant access to systems. If you are on that side, the smartest thing you can do is run your own internal review before the buyer's team arrives. I have watched sellers lose negotiating leverage simply because they were caught flat-footed by questions they should have anticipated.

Timing-wise, IT diligence typically kicks off after a letter of intent is signed and the deal moves into the confirmatory phase. In an M&A process it runs in parallel with the other workstreams covered in [M&A due diligence](/blog/ma-due-diligence), feeding findings back into the wider deal team. The window is usually tight, often two to six weeks, which is exactly why preparation and a well-organized data room matter so much. Every day spent chasing a missing architecture diagram is a day not spent on actual analysis.

## The IT due diligence process, step by step

Here is the sequence I follow. It is not rigid, deals differ, but the logic holds across most situations.

### 1. Scope and plan

Before requesting a single document, agree on what matters for this specific deal. A SaaS company priced on its product needs deep architecture and scalability work. A manufacturer needs more focus on operational systems, ERP, and aging hardware. Define the scope, the team, the timeline, and the criteria for what counts as a material finding. Write a request list that maps to the scope rather than firing off a generic 200-item template.

### 2. Request and collect documentation

Send the document request list and get materials into a single, access-controlled location. This is where most of the avoidable pain lives. When documents trickle in over email, get versioned three times, and sit in four different folders, the review slows to a crawl. A [virtual data room](/blog/virtual-data-room-due-diligence) solves this cleanly, and I will come back to why.

### 3. Review infrastructure and architecture

Map the actual environment: cloud accounts, on-premise hardware, network topology, environments (development, staging, production), and how it all hangs together. I want to understand single points of failure, capacity headroom, and whether the architecture matches what management described in the pitch.

### 4. Assess security and compliance

This is increasingly the heart of the review. Look at access controls, identity management, encryption, vulnerability management, incident history, and any compliance obligations (SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS, depending on the business). One unpatched, internet-facing system or one breach that was quietly never disclosed can change the entire risk profile of a deal.

### 5. Examine software, licenses, and IP

Confirm that the company actually owns or properly licenses the software it depends on. Check open-source usage and license compatibility, third-party license compliance, and whether any critical code was written by contractors without a proper IP assignment. Code ownership gaps are more common than people expect, and they are expensive to fix after the fact.

### 6. Evaluate the IT organization and vendors

Technology runs on people and contracts. Assess team structure, key-person dependencies, the use of outsourcers, and the major vendor relationships. A platform that only one departing engineer fully understands is a risk even if the code is excellent. Review vendor contracts for lock-in, auto-renewals, change-of-control clauses, and concentration risk.

### 7. Quantify costs and synthesize findings

Pull the threads together. Estimate the cost to remediate gaps, the integration cost if the buyer plans to merge systems, and the run-rate IT spend going forward. Then write it up plainly: what is fine, what needs investment, what is a genuine deal risk, and what (if anything) should change the price or the terms. The output should be readable by deal partners, not just engineers.

## IT due diligence checklist

This is the working checklist I hand to teams. Treat the priority column as a starting point and adjust for the deal.

| Area | What to review | Why it matters | Priority |
|---|---|---|---|
| Infrastructure | Cloud accounts, servers, network diagrams, environments, disaster recovery | Reveals scalability headroom and single points of failure | High |
| Security | Access controls, encryption, vulnerability scans, incident history, MFA coverage | Surfaces breach risk and undisclosed exposure | High |
| Compliance | SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS as applicable | Regulatory gaps create legal and financial liability | High |
| Software and IP | Code ownership, IP assignments, open-source licenses, third-party licenses | Confirms the company owns what it sells | High |
| Data | Data architecture, backups, retention policies, data quality | Affects integration, privacy, and analytics value | Medium |
| IT organization | Team structure, key-person risk, documentation, runbooks | Determines whether systems survive staff turnover | Medium |
| Vendors and contracts | Key supplier agreements, change-of-control terms, lock-in, concentration | Exposes hidden costs and renewal traps | Medium |
| Technical debt | Legacy systems, unsupported platforms, deferred upgrades | Predicts future investment needs | Medium |
| Costs | Current IT spend, capitalized dev, remediation and integration estimates | Feeds the financial model and valuation | High |
| Roadmap | Planned investments, migrations, end-of-life timelines | Tests whether the growth case is achievable | Low |

If you want a broader, deal-wide version of this that goes beyond IT, the [due diligence data room checklist](/blog/due-diligence-data-room-checklist) covers every workstream and the folder structure I use to organize them.

## Common red flags

Some findings make me pause and dig harder. None of these automatically kills a deal, but each one tends to mean the picture is messier than the pitch suggested.

- **No clear IP ownership.** Contractors wrote core code with no assignment agreement, or the founders cannot produce a clean chain of ownership. This is fixable but it takes time and legal work.
- **Undisclosed security incidents.** A breach, a ransomware event, or a near-miss that never made it into any document. The cover-up usually worries me more than the incident.
- **Heavy key-person dependency.** One engineer holds the entire system in their head, with no documentation and no second person who can deploy safely.
- **Unsupported or end-of-life technology.** A platform that the vendor stopped supporting, or a database version with known unpatched vulnerabilities, sitting in production.
- **Shadow IT and credential sprawl.** Production secrets in spreadsheets, shared admin logins, no central identity management, no audit trail of who accessed what.
- **Costs that do not reconcile.** IT spend in the financials that does not match the systems you can actually see, which often signals capitalized development that masks recurring expense.
- **Inflated architecture claims.** The pitch deck describes a modern, scalable platform; the codebase tells a different story. This is where IT and technical diligence have to talk to each other.

## How a data room streamlines IT due diligence

The single biggest determinant of how painful IT diligence feels is not the complexity of the technology. It is how the documents are organized and shared. I have run reviews where every artifact, architecture diagrams, security policies, license inventories, vendor contracts, sat in a structured, permissioned data room from day one. Those reviews move fast and stay calm. I have also run reviews where materials arrived as email attachments over three weeks, and those felt like archaeology.

A virtual data room helps in a few concrete ways. It gives every reviewer a single source of truth, so nobody works from a stale network diagram. It lets the seller control access at a granular level, so an external security advisor sees the security folder without getting the full commercial file. And it produces an audit trail of who viewed what, which matters for the seller's peace of mind and for showing sensitive material was handled properly. The activity analytics also tell the seller something useful: if a buyer's team spends hours in the security folder, that is where the negotiation is heading.

This is the problem [Plox](/data-rooms) is built for. I use it to set up a clean folder structure, grant scoped access to each advisor, share documents without leaking them into inboxes, and watch engagement so I know where attention is landing. For IT diligence specifically, the value is in keeping a high-pressure, time-boxed review organized: sensitive architecture and security documents stay controlled, every reviewer works from the current version, and the seller never loses track of who has seen what. If you are weighing options, our guide to the [best data room for due diligence](/blog/best-data-room-for-due-diligence) walks through what to look for. The tool matters less than the discipline, but the right tool makes the discipline almost automatic.

## Frequently asked questions

### How long does IT due diligence take?

For most mid-market deals, the IT workstream runs two to six weeks, starting after a letter of intent and ending before close. The biggest variable is preparation. A seller with an organized data room and clear documentation can compress the timeline dramatically, while chasing missing or disorganized materials can stretch it well past the planned window.

### What is the difference between IT and technical due diligence?

IT due diligence is broader and more operational. It covers the company's whole technology footprint: infrastructure, security, corporate systems, vendors, and the IT organization. Technical due diligence digs deeper into the specific product, its codebase, architecture, and engineering practices. On a software deal they overlap heavily, and serious buyers usually do both.

### Who pays for IT due diligence?

The buy side almost always commissions and pays for it, since they carry the risk of the acquisition. Sellers often run their own internal review beforehand at their own cost, which is money well spent because it surfaces problems while there is still time to fix them and protects negotiating leverage.

### What are the biggest IT due diligence red flags?

Unclear intellectual property ownership, undisclosed security incidents, heavy dependence on a single engineer, unsupported or end-of-life systems still in production, and IT costs that do not reconcile with the financials. Any one of these is a signal to slow down and investigate before relying on management's account.

### Do I need a data room for IT due diligence?

You can run a review over email and shared drives, but it is slower, less secure, and harder to control. A virtual data room gives you a single source of truth, granular access control, version discipline, and an audit trail. For a time-boxed review involving sensitive security and architecture documents, it removes most of the avoidable friction.

### How does IT due diligence affect the deal price?

Findings flow straight into valuation. Remediation costs, required platform migrations, license shortfalls, and integration spend all become line items in the financial model. A material IT risk can reduce the price, shift it into an earn-out, or add specific warranties and indemnities to the purchase agreement.