The technical section of the data room, from the reviewer's desk

A technical reviewer gets the data room link and a few weeks to tell a buyer what the software is really like to own. Before reading a line of code, they open the technical folders. What they find in the first hour sets the tone of the whole review: a calm read with a short list of questions, or a request list that eats the founder's calendar for a month.

Most sellers build this section last. Finance and legal have advisors who know what a room needs. The technical side is often left to the CTO in the evenings, who uploads what already exists: an old diagram, a security policy template, a spreadsheet of servers. Each of those files makes a claim, and the reviewer's job is to test every claim. A file that cannot be tested costs more time than an empty folder with a dated note.

This article reads the technical section from the reviewer's side of the desk: what gets opened first, what each document has to prove, what earns trust, what sets off follow-up questions, and when each part should become visible. It covers one section of the room. Our engineering partner PERETZ covers the whole room, every folder from corporate records to disputes, in How to Prepare a Data Room When Selling a Company or Raising Money: What Goes In, in What Order, What Goes Wrong.

The order a reviewer reads in

Reviewers rarely read folders in index order. They read in the order that risk to the deal appears. Questions that can stop a deal come first, questions that move the price come next, and questions about the cost of owning the product come last. A typical first pass looks like this:

1. The index. Is the technical section numbered, dated and complete, or a pile of uploads?
2. System overview and architecture diagram. The frame for everything that follows.
3. Ownership register. Who holds the domains, cloud accounts, repositories and store listings.
4. IP assignments and license scan. Whether the company owns its code, and what open source asks of it.
5. Infrastructure and cost. What runs where, and what it costs each month.
6. Backups and recovery evidence. Whether the business survives a bad day.
7. Security policies and incident history. Who can get in, and whether anyone would know.
8. Data map and privacy. Where personal data sits, and what was promised about it.
9. Team and knowledge. How much depends on one or two people.
10. Roadmap and known issues register. What the seller already knows is wrong, and what is planned.

The middle of that list follows the six layers we use in every review: ownership and IP, infrastructure and cost, data and privacy, code and architecture, security and access, team and knowledge. The overview and the known issues register sit around them as the frame and the summary. Organize the section along the same lines and the reviewer does not have to rebuild it.

What each document has to prove

Every document in the technical section exists to prove one thing.

System overview and architecture diagram

It proves that a stranger can understand the system. Two to four pages are enough: what the product does, its main components, languages and frameworks with versions, the outside services it depends on, and how a change travels from a developer's laptop to production. The diagram must match what the reviewer later sees in the cloud console and on the invoices. A diagram with three services next to a bill that lists eleven is the first crack. Date it and name who drew it.

Ownership register

It proves that the company controls what it runs on. One table: every domain, DNS provider, cloud account, code repository, app store developer account, payment processor, email service and key SaaS tool. For each, the legal holder, the admin users, the card that pays and the monthly cost. The usual finding is an asset in a person's name: a domain registered by a founder, a store account under a former contractor, a cloud account on a personal card. Each is fixable, and far cheaper to fix before it becomes a closing condition.

IP assignments and license scan

Together they prove that the company owns its code and knows what open source requires of it. The first part is signed assignments or work-for-hire terms from every employee, contractor and agency that wrote code, checked against the contributor list of the repositories, not against payroll. The second is a software bill of materials or license scan, with copyleft licenses such as GPL and AGPL flagged and a note on how each flagged component is used: linked, modified, distributed or served over a network. The gaps reviewers meet most often are the founder's code from before the company existed and the first freelancer. Counsel drafts the assignments; the reviewer checks that they cover everyone in the history.

Infrastructure and cost

It proves that the running cost is known and explainable. Twelve months of hosting and service invoices, grouped by provider, with the main cost drivers named. A list of environments (production, staging, development) and what each costs. Reviewers set this beside the revenue model: a cost line growing faster than the customer base is a question about margins, not only about engineering. Cloud credits that run out after closing belong here too, with their end date.

Backups and recovery evidence

It proves that the business can recover from a failure, and shows how much data it would lose. A backup policy is not the proof. The proof is the record of the last restore test: the date, what was restored, how long it took, who did it and what broke. Add the recovery runbook and any availability or recovery promises made to customers in contracts or on a status page. A backup that has never been restored is one of the most common findings in any review, and one of the easiest to fix.

Security policies and incident history

Together they prove that access is controlled and that the company would notice a problem. Policies matter less than evidence that they run: the production access list with roles and the date of its last review, multi-factor authentication status, offboarding records for people who left, patch history, the summary of the last penetration test with the status of each finding, and an incident log. If there were no incidents, write that, and say how you would know: what is logged, for how long, and who looks. A SOC 2 report, if you have one, goes here with its scope and period. Representations and warranties insurers ask about cybersecurity too.

Data map and privacy

It proves that the seller knows where personal data lives and that its use matches what was promised. A table of the systems that hold personal data: which categories, where they are hosted, who can reach them, how long they are kept, and which subprocessors touch them. The privacy policy versions with their dates, and the data processing agreements with key vendors and customers. Privacy promises usually stay with the product after a sale, so a policy that says data is never shared, next to an analytics setup that sends events to several vendors, is a finding. None of this needs real personal data in the room.

Team and knowledge

It proves that the product survives if one person leaves. A chart of the technical team with roles and employment type (employee, contractor, agency), the areas each person knows, and where that knowledge is written down. The strongest evidence is a handover test: someone other than the usual person deployed, restored or fixed something from the documentation alone, and it worked.

Roadmap and known issues register

It proves that the seller knows the weak points and has a plan. Sellers fear this document most, and reviewers trust it most. List the known problems: end-of-life frameworks, manual steps in deployment, parts of the code nobody wants to touch, open findings from past tests. For each, the impact, a rough fix plan and the status. A reviewer who meets an issue the seller already listed writes a finding with a plan behind it. A reviewer who discovers an issue the seller left out starts to wonder what else is missing. How a known issue is also reflected in the disclosure schedule is a question for your deal counsel.

Document, proof and common gap

What earns a reviewer's trust

Trust in a data room is built from small signals that repeat. Seen in the first few files, they make the rest of the questions narrower. A quick check before the section opens:

• Every document is dated and names an owner on the seller's side.
• Numbers agree: users, uptime, monthly cost and team size are the same in the deck, the memorandum and the technical files.
• Every policy has evidence beside it: an export, a log extract or a dated screenshot with secrets removed.
• Registers are tables a reviewer can check line by line against the systems, not paragraphs of prose.
• Negatives are dated and explained: "no incidents recorded as of this date", with the logging that would have caught one.
• Known issues are listed by the seller before anyone finds them.
• Only final versions are in the room, with file names that say what each file is.
• One technical contact answers technical questions, so the founder is not the answer to everything.
• Nothing in any file contains a password, API key, private key or connection string.

None of this requires a perfect system. A product with real technical debt can still have a room that reads as honest and under control, and a well-built product can lose credibility to a careless one.

What sets off a flood of questions

One weak file rarely produces one question. It makes the reviewer doubt the files around it, and the request list grows across layers. The patterns are predictable.

A policy with no trace. An access policy that requires quarterly reviews, with no record of any review, leads to questions about every other policy in the folder.

A diagram that disagrees with the bill. If the invoices show services the diagram does not, the reviewer has to map the system alone, and asks about each unexplained line.

Assignments that do not cover the history. When the contributor list shows names with no matching agreement, counsel on the buyer's side gets involved, and the question moves from engineering to the deal terms.

"Available on request." It means the reviewer must ask, wait and wonder why the file was not there.

Empty folders without a note. An empty folder is a question. A dated note that says there is nothing to hold, and why, is an answer.

Secrets in files. An API key in a screenshot or a configuration file says more about security habits than any policy. It is also a live exposure: rotate the key, then remove the file.

Missing evidence also changes how findings are rated. A reviewer cannot call a risk low without something to show it is low, so the finding is written on what can be shown. Under our severity scale, a backup nobody has restored, or code with no assignment behind it, can rate High or Critical simply because the better case cannot be confirmed.

Staging the section: before LOI and after

A bidder who does not buy has still read what you showed. The technical section should open in steps that follow the seriousness of the reader. Your M&A advisor and counsel set the real stages; this is the technical side of them.

Before the letter of intent

Bidders need enough to price the deal and to see that nothing is hidden, not enough to rebuild the product. At this stage the section usually holds:

• The system overview and a high-level diagram, without internal hostnames or network detail.
• A summary of the ownership position: what the company holds, and any item being moved into its name.
• A cost summary by category rather than by invoice.
• A summary of certifications and the last security test, without its findings in detail.
• A short version of the known issues register, at the level of themes.

During exclusivity

Once a buyer has signed a letter of intent and its reviewers start work, the full documents open: the registers, the invoices, the access lists, the restore records, the full known issues register. Source code does not go into the room. The buyer's reviewer reads it in place, with read-only, named and time-limited access, as in our access protocol. The same applies to production systems. The full penetration test report, with steps to reproduce each finding, goes only to the named technical experts, because it is a map of your weak points. Real personal data stays out at every stage: the reviewer works from the schema, row counts and masked samples.

When the bidder is a competitor

Some technical material is commercially sensitive in the hands of a rival: pricing logic, customer-specific configurations, the product roadmap, cost per customer. When a competitor is bidding, those files can go to a clean team, a small group of people with no role in pricing or strategy, often outside advisors, who report back in aggregated form. Who sits on it and what it may see is a question for competition counsel, not for the engineers. The technical work is to know in advance which files fall into that group.

What to do next

If a sale is six to eighteen months away, there is time to fix what the section would expose, not only to describe it. Our exit readiness program builds the technical section of the data room as the fixes land, and ends with a mock review read the way a buyer's reviewer would read it.

If your advisor is preparing to go to market now, vendor due diligence produces a buyer report for the data room from one review of all six layers, plus support with technical questions while bidders work through it. If a buyer has already called and you want a fast read first, a sell-side red-flag memo shows the gaps that matter most within days of access.

To see how findings are written and rated, read what our report contains. Questions about scope, confidentiality and fees are answered in the FAQ.

Questions