The 'Dirty Dozen': 12 IT Due Diligence Documents That Reveal the Truth Behind the Deal

The Data Room is Lying to You

You’ve seen the CIM. You’ve sat through the management presentation where the CTO promised their platform is "AI-ready," "cloud-native," and "infinitely scalable." The financials look clean—EBITDA is climbing, and the ARR growth is respectable. But in the server room (or the AWS console), a different story is unfolding.

We have audited hundreds of technical estates for private equity sponsors. The pattern is painfully consistent: Financial engineering cannot fix technical insolvency. When you acquire a software-enabled business, you aren't just buying revenue; you are inheriting every shortcut, every hacked-together integration, and every ignored security patch the previous management team left behind.

The cost of this ignorance is staggering. McKinsey data reveals that CIOs estimate technical debt amounts to 20-40% of the entire value of their technology estate. In a $100M acquisition, that is $20M to $40M of hidden liability that doesn't show up on the balance sheet until you try to integrate it or scale it.

Most General Partners (GPs) treat IT due diligence as a check-the-box exercise. They ask for a "technology overview" and get a PowerPoint. To protect your multiple, you need raw data. You need the documents that reveal where the bodies are buried.

The 12 Documents You Must Demand

When we run a technical diligence process, we don't ask nicely. We require these 12 documents to be uploaded to the data room before we even schedule the code audit. If a target refuses to provide them, it’s not a red flag—it’s a siren.

Category 1: The Code & Architecture Reality

• 1. The Software Bill of Materials (SBOM)
  Don't tell me you use open source; show me exactly what libraries you are running. With the rise of supply chain attacks, an outdated SBOM is a ticking time bomb of security liability and IP risk. If they can't produce this instantly, they don't know what's in their own product.
• 2. Static Code Analysis Report (Unredacted)
  We don't want the summary; we want the raw output from tools like SonarQube or Veracode. We are looking for "Cyclomatic Complexity" scores. High complexity means high maintenance costs and slow feature velocity post-close.
• 3. The "Spaghetti Map" (Logical Network Diagram)
  Sales decks show clean, layered architecture. Reality is often a mess of point-to-point integrations. If the diagram looks like a bowl of spaghetti, your integration costs just tripled.

Category 2: Infrastructure & Spend

• 4. Raw Cloud Billing Exports (Last 12 Months)
  Not the Finance summary. The raw AWS/Azure/GCP CSV export. We use this to identify bloated infrastructure spend. Often, 30% of the "COGS" line is waste—orphaned instances and unoptimized databases that go straight to EBITDA once fixed.
• 5. The "Key Person" Commit Log
  Who wrote the code? If 80% of the critical commits in the last year came from one engineer who isn't on the retention list, you are buying a platform you can't maintain. This is key-person risk quantified.
• 6. Downtime & Incident Logs
  SLA reports are marketing documents. Incident logs are legal evidence. Look for recurring outages on Friday nights or during peak load. It tells you if the system is truly "scalable" or just holding on by a thread.

Category 3: Security & Compliance

• 7. Third-Party Pentest Results (The "Fail" Report)
  Targets love to share the "remediation verification" letter. Demand the initial finding report. It shows you their security posture before they cleaned it up for the sale.
• 8. Data Privacy Map (PII Inventory)
  Where does customer data actually live? If they claim GDPR/CCPA compliance but can't show you a data flow map, you are buying a regulatory fine waiting to happen.

Category 4: Process & Future

• 9. The Real Product Roadmap vs. Engineering Backlog
  Compare the "Innovation" slides in the management deck with the actual Jira backlog. If the roadmap says "AI Features Q3" but the backlog is 90% "Bug Fix" and "Refactor," you are buying a maintenance project, not a growth platform.
• 10. Technical Debt Register
  Mature engineering teams track debt. Immature ones ignore it. If this document doesn't exist, you must assume the debt is infinite.
• 11. Open Source License Audit
  Are they using GPL libraries in a proprietary product? If yes, you might be legally required to open-source your entire acquisition. This kills deals instantly.
• 12. QA & Test Coverage Reports
  High test coverage (80%+) implies a system that can be updated safely. Low coverage (<20%) means every new feature you ask for will break three existing ones.

How to Use These Findings

Gathering the documents is step one. Weaponizing them for value creation is step two. You are not looking for perfection; you are looking for pricing leverage and integration planning.

The "Price Chip" Conversation

When you find that 30% of the code is effectively dead or that the cloud bill is 2x what it should be, you don't necessarily walk away. You chip the price. We call this "Capex-ing the Fix." Calculate the cost to remediate the critical technical debt over the first 12 months and deduct it from the enterprise value. If it costs $2M to fix the security holes, that’s not OpEx—that’s a purchase price adjustment.

The 100-Day Plan

Your 12 documents form the basis of your 100-day plan. If the "Key Person" log showed dependency on one founder, your Day 1 priority is knowledge transfer, not new features. If the Cloud Bill showed waste, your Day 1 priority is FinOps optimization to boost near-term EBITDA.

Conclusion: Trust, but Verify (with Root Access)

In 2026, "Tech DD" is no longer about checking if the servers work. It is about assessing the maintainability of the revenue stream. Harvard Business Review estimates that 70-90% of M&A deals fail to achieve their goals, largely due to integration failures. Don't let hidden technical debt be the reason your thesis fails.

Demand the dirty dozen. If they hesitate, dig deeper.