Tous les articles

What belongs in a technical data room, and what its absence says

Ask what belongs in a technical due diligence data room and you get two different answers depending on who you ask. Lawyers produce a request list with two hundred items. We produce a shorter one, because after enough audits you learn which documents change findings and which exist to be counted.

There is a second question hiding inside the first, and it is the more interesting one: what does it mean when the documents are not there. A thin technical data room slows the audit down, and it is also a finding about how the company operates, often the first one we write down.

What the technical data room should contain

The working list, in rough order of how often each changes our conclusions:

  • An architecture overview that matches reality: one or two diagrams with the main components, data stores, and external dependencies, dated within the last year
  • Access to the code, or failing that, repository statistics: contributor distribution, commit activity over time, the shape of the review process
  • The engineering org chart with tenure and location, and who owns which part of the system
  • Incident history: the postmortem folder, or at minimum a list of significant outages with dates and causes
  • Security posture: how secrets and access are managed, the latest pentest report with its remediation status, certifications if any exist
  • Infrastructure costs for the last twelve months, ideally broken down enough to see the cost per customer or per unit of usage
  • The dependency picture: third-party services the product cannot run without, and the license inventory for open source components
  • For AI products: eval results over time, model and provider dependencies, and cost per request, the items we detail in the AI due diligence checklist we use on live deals

Notice what the list is optimized for. Every item is evidence of how the system and the team behave, rather than a policy describing how they should. One page of real incident history outweighs fifty pages of incident management procedure.

A thin data room is itself a finding

Behind the list sits an uncomfortable fact: well-run companies do not prepare most of these documents for the deal. They already have them, because the documents are the exhaust of operating properly. The architecture diagram exists because new engineers needed it. The postmortems exist because the team learns from failure. The cost breakdown exists because someone watches margins.

So when the data room is empty of them, the absence speaks. No incident history almost always means no incident process rather than a flawless system. No architecture documentation on a system of real size means onboarding happens by oral tradition, which is a key-person statement. No eval results from a company selling AI means quality is being assessed by vibes. Each gap converts into a question about the underlying practice, and the audit proceeds by interview and code reading instead, more slowly and with wider error bars.

The tell is freshness. Documents created in a hurry the week diligence started have a look: no history, no revisions, suspiciously consistent formatting, nobody’s coffee stains on them. We do not treat that as deception, founders are told to assemble a data room and they assemble one. But a document written for the deal describes the company as it wishes to be seen, and we weight it accordingly.

What nobody needs

A word on the opposite failure, because over-stuffed data rooms slow deals too. We do not need every policy binder, every historical contract with a hosting provider, or a hundred pages of ISO procedure exported from a compliance tool. Volume buys no credibility, and burying the three documents that matter under three hundred that do not costs everyone a day. Certification reports are the exception: we want the actual SOC 2 report rather than the logo, for reasons set out in what SOC 2 and ISO 27001 prove in due diligence.

We would also rather see candid gaps than cosmetic completeness. A one-line note saying "we have no formal disaster recovery plan; here is what we actually do" is more useful, and frankly more reassuring, than a template plan that has never been tested. Sellers can do a great deal in the weeks before a process starts, and we wrote the founder’s side of that preparation separately.

The data room sets the clock

There is a direct commercial reason to care, on both sides of the table. The state of the data room is the single biggest variable in how long the technical read takes, a relationship we describe in how long technical due diligence takes. With a solid data room, a focused read fits in 3 to 4 days and conclusions arrive while the deal still has room to move. With a thin one, the same questions get answered through scheduled calls at interview pace, the audit stretches by a week or more, and in a competitive process that week has a price.

The state of the data room also shapes where we point the effort. Gaps tell us where to dig, and the digging is where findings live: the practices a company documents are rarely the ones that hurt it, a pattern consistent with the red flags that matter.

For investors, the practical move is simple: send the target a focused request list early, and read the response pattern as data, not only the contents. For founders, the list above is the standard to build toward before a process starts rather than during one. And when the room is open and the clock is running, a technical and AI audit is how the contents get converted into a scorecard, a risk register, and a conclusion an investment committee can act on.