Technical due diligence is the review a buyer runs on a target's product, codebase, architecture, and engineering organization to judge whether the technology can support the deal thesis. It answers one commercial question: how much will it cost, in money and time, to keep this product running and growing after we own it?
Software companies are bought on revenue multiples, but the multiple is only defensible if the product can keep delivering that revenue. A technical review is how a buyer finds out whether the platform behind an attractive ARR figure is a well-built system or a decade of accumulated shortcuts held together by two engineers. This guide covers what the review examines, how it runs week by week, what it costs, and which findings actually move a price.
The material that review runs on is the most attacker-useful content in the whole deal: architecture diagrams, penetration test findings, and incident histories. A data room for technical due diligence is what lets a seller hand that to a named reviewer without handing it to everyone on the distribution list. Section 8 covers the setup step by step.
Technical due diligence is a structured assessment of a target company's technology assets and engineering capability, performed by technical reviewers on behalf of an acquirer or investor. It typically happens after a letter of intent, alongside financial and commercial diligence, and produces a report that a non-technical investment committee can act on.
The scope is the product and the organization that builds it. Reviewers read architecture documentation, examine representative source code, interview engineers, inspect the deployment pipeline, review security posture and incident history, and check who legally owns the code. They are not auditing the company's laptops or its finance system, which belongs to IT due diligence, and they are not judging whether the market wants the product, which belongs to commercial due diligence.
The output is deliberately commercial. A good technical report does not say the code is messy. It says that supporting the current architecture at three times the present load will require roughly 18 engineer-months of work, that two of the four services have no automated tests, and that the single database instance is an availability risk with a specific mitigation cost. Those are numbers a deal team can put into a model.
Who orders it varies. Private equity firms commission it on every platform acquisition. Strategic acquirers often run it with their own engineering leadership plus an outside reviewer for independence. Venture investors run a lighter version at Series B and above, focused on scalability and security rather than a full code review.
The two terms get used interchangeably and they are not the same thing. Technical due diligence looks outward at the product the company sells. IT due diligence looks inward at the systems the company runs on: the ERP, the identity provider, the endpoints, the licenses, the disaster recovery plan. A software company needs both; a manufacturer buying a distributor mostly needs the second.
The confusion is understandable because the two overlap in cloud infrastructure and security. A target's AWS account may host both the customer-facing product and the internal data warehouse, and a single penetration test may cover both. Deal teams handle it by scoping explicitly: the technical reviewer owns anything a customer touches, and the IT reviewer owns anything an employee touches.
Where the distinction really matters is in integration planning. Technical findings determine whether two products can be merged or must stay separate. IT findings determine how quickly employees can be moved onto one email system, one identity provider, and one finance platform. Both feed the integration budget, but they are executed by different teams on different timelines. In the data room for technical due diligence, they are also different folders with different reviewers on them, which is the practical reason the scoping conversation should happen before the first document is uploaded.
The nine areas below make up the standard scope of a technical review for a software or technology-enabled business. Each produces findings that are either informational, a cost to quantify, or a genuine deal issue.
The first four concern the system itself. Architecture asks whether the design supports the growth the deal thesis assumes, and whether it is documented well enough that a new team could take it over. Code quality asks about test coverage, complexity, duplication, and consistency, sampled across representative modules rather than read line by line. Security covers vulnerability management, dependency hygiene, secrets handling, penetration test history, and past incidents. Infrastructure covers hosting, scaling behavior, redundancy, cost per unit of revenue, and single points of failure.
The next three concern how work gets done and what the company legally owns. Delivery practice is measured through deployment frequency, lead time for changes, change failure rate, and time to restore service, the four DORA metrics that describe whether a team can ship safely. Data covers the model, quality, retention, and privacy compliance under GDPR and equivalent regimes. Intellectual property and licensing covers contributor agreements, contractor assignments, and the open-source bill of materials.
| # | Area | Core question | Common finding |
|---|---|---|---|
| 1 | Architecture | Will the design hold at 3x scale? | Monolith with one shared database |
| 2 | Code quality | Can a new team maintain this? | Low test coverage in core modules |
| 3 | Security | What is the current exposure? | Unpatched dependencies, no pen test in 2 years |
| 4 | Infrastructure | What does it cost to run and scale? | Hosting cost rising faster than revenue |
| 5 | Delivery practice | Can the team ship safely? | Manual releases, monthly cadence |
| 6 | Data | Is data handled lawfully and well? | No retention policy, PII in logs |
| 7 | IP and licensing | Does the company own its code? | Copyleft dependency in the shipped product |
| 8 | Engineering team | Who actually holds the knowledge? | One engineer owns the payments service |
| 9 | Roadmap | Is the plan credible and costed? | Roadmap assumes headcount not yet hired |
The last two are about people and plans. The engineering team review looks at seniority mix, attrition, contractor dependence, and concentration of knowledge, because a codebase with one irreplaceable maintainer is a risk no amount of documentation fixes quickly. The roadmap review tests whether the growth plan the seller is being paid for is technically achievable with the team and budget on the table.
Knowing the nine areas is one thing; knowing what lands in the room is another. The table below maps each area to the documents a reviewer will request, which is also the folder structure a sell-side team should build before the room opens.
| Area | Documents requested | Typical count | Sensitivity |
|---|---|---|---|
| Architecture | System diagrams, service map, data flow, scaling assumptions | 8 to 20 | High |
| Code quality | Static analysis output, coverage reports, repository metrics | 5 to 15 | Medium |
| Security | Penetration tests, SOC 2 or ISO 27001 reports, incident log, policies | 10 to 30 | Very high |
| Infrastructure | Cloud account inventory, cost breakdown, availability design | 8 to 20 | High |
| Delivery practice | Pipeline documentation, DORA metrics, release calendar | 5 to 12 | Low |
| Data | Data model, retention policy, ROPA, processor agreements | 6 to 18 | High |
| IP and licensing | SBOM, licence inventory, contributor and contractor assignments | 10 to 25 | Very high |
| Engineering team | Org chart, seniority mix, attrition data, key person map | 4 to 10 | Medium |
| Roadmap | Product roadmap, engineering plan, hiring plan and budget | 4 to 10 | Medium |
The sensitivity column is what drives how the room is configured. Penetration test findings and the open-source bill of materials sit at opposite ends of the deal for different reasons: the first is a list of unfixed ways into the product, the second is the document most likely to end a negotiation. Neither belongs in the same folder as the release calendar.
Most technical reviews compress into three to four weeks, and the sequence matters because early access requests have the longest lead times. Repository access, in particular, is often the last thing a seller agrees to and the first thing the reviewer needs.
Week one is document collection and orientation. The reviewer receives architecture diagrams, the infrastructure inventory, security reports, the dependency and license inventory, incident history, and the engineering org chart, then holds a scoping call with the CTO. Sellers who have prepared this material in advance shorten the whole engagement, which is one reason sell-side technical preparation has become common.
Week two is the deep review. Reviewers examine code in a controlled environment, walk the deployment pipeline, and analyze the dependency tree for known vulnerabilities and license obligations. Week three is interviews: the CTO, the engineering leads, and usually one or two individual contributors, because senior leadership and the people who actually maintain the code often describe the same system very differently.
Week four is quantification and reporting. Findings get grouped into what must be fixed before or immediately after closing, what should be fixed within the first year, and what is acceptable. Each item carries an estimate in engineer-months and money, and the report closes with an integration view: what it would take to merge this product with the buyer's, or to run it separately.
Week one is also when the access model gets decided, and it decides everything after it. A seller who issues one link to a distribution list has lost control of the architecture pack for the rest of the process. A seller who issues one link per named reviewer, each scoped to the folders that reviewer needs, can watch the review happen and still switch it off the day exclusivity lapses.
One link per named reviewer, issued in week one, is what makes the rest of the four-week process controllable.
Not every finding matters commercially. Reviewers see untidy code in nearly every target, and untidy is not the same as dangerous. The findings that move a price are the ones with a bounded cost, a legal consequence, or a dependency on a single person.
Open-source license exposure is the most consequential legal finding, and it is the copyleft trap this guide is named for. If a shipped product incorporates a component under a strong copyleft license such as GPL or AGPL, the obligations can extend to disclosing the source of the surrounding work, which for a proprietary SaaS business is a serious problem. Remediation means replacing the component or re-architecting around it, and the cost is real but knowable, which makes it a price conversation rather than a deal breaker.
Key person concentration is the most common finding that survives negotiation. When one engineer is the only person who understands the billing service, the buyer is exposed from the day the deal closes. It is usually handled with retention agreements rather than price, but a buyer who does not find it during diligence has no chance to negotiate one.
Security history is the finding most likely to escalate. An undisclosed breach, personal data in application logs, or long-unpatched critical vulnerabilities suggest a control environment that will not survive the buyer's own compliance obligations. Where the buyer holds SOC 2 Type II or ISO 27001 certification, the remediation timeline becomes a closing condition rather than a budget line.
How each of those lands commercially follows a fairly consistent pattern, and knowing the pattern in advance is what stops a finding turning into a reflexive price cut.
| Finding | How it surfaces | Commercial remedy |
|---|---|---|
| Copyleft component in the shipped product | Dependency tree scanned against the licence inventory | Closing condition to replace, costed in engineer-months |
| Capacity ceiling within 12 to 18 months | Load profile compared with the growth in the deal thesis | First-year engineering budget funded in the model |
| Key person owns a critical service | Commit history plus individual contributor interviews | Retention agreement, rarely a price adjustment |
| Undisclosed security incident | Incident log compared with customer notifications | Specific indemnity, remediation as a closing condition |
| Personal data in application logs | Data flow review against the retention policy | Remediation plan with a dated milestone under GDPR |
| Contractor code with no assignment | Contributor agreements checked against commit authors | Seller obtains assignments pre-closing, or escrow |
Penetration test findings are a list of unfixed ways into the product, which is why they sit in a view-only, watermarked folder of their own.
Technical review pricing tracks the seniority of the reviewers and the size of the codebase. Specialist technology diligence firms typically charge $300 to $600 per hour and deliver a full review for $35,000 to $95,000. Big Four technology advisory practices charge $400 to $700 per hour and typically land between $50,000 and $150,000 for comparable scope, with more process and more partners on the cover page.
For a venture round or a small tuck-in, a lighter review focused on scalability, security, and IP ownership can be done for $15,000 to $30,000 in about two weeks. For a platform acquisition where the buyer intends to build on the target's technology for a decade, the full engagement is worth every hour, because the remediation estimate directly sets the post-close engineering budget. Our due diligence cost guide puts these figures in the context of a complete diligence budget.
Set against those numbers, the document infrastructure is a rounding error. A data room for technical due diligence at €99/month costs roughly €200 across a four-week review, against a $35,000 floor for the review itself, and it is the only part of the budget that also produces a disclosure record you can still read in five years.
A mid-market private equity fund signs an LOI to acquire Feldstrom Analytics, a B2B reporting platform with $11.5M ARR, 38 employees, and 14 engineers, at 5.4x revenue. The thesis assumes 40 percent annual growth for four years and a bolt-on acquisition in year two, both of which depend on the platform absorbing more customers and more data without a rebuild.
The reviewer starts with the dependency inventory and finds 1,840 third-party packages, of which four are under AGPL. One of them, a charting library, is compiled into the customer-facing product. Legal review concludes the exposure is real, and the engineering estimate to replace it is 3 engineer-months, roughly $65,000.
The architecture review finds a bigger issue. All 620 customer tenants share a single Postgres instance with no read replicas, and the largest tenant already generates 31 percent of query load. At the growth the thesis assumes, the reviewer projects a hard capacity ceiling within 14 months. Splitting the largest tenants onto dedicated instances and adding replication is estimated at 11 engineer-months plus $18,000 a month in additional hosting.
Interviews surface the third finding. Deployment happens manually on Thursday evenings, change failure rate is roughly one in five releases, and one engineer performs every deployment. The remediation plan is a CI/CD pipeline and automated testing for the two core services, estimated at 6 engineer-months.
Worked scenario. The 3 engineer-months of AGPL replacement is the smallest line and the only one that became a closing condition, because it is a legal obligation rather than a capacity problem.
Total quantified remediation is 20 engineer-months and $216,000 of incremental annual hosting. The fund does not cut the price. It funds a $1.4M first-year technology budget in the model, makes the AGPL replacement a closing condition, and puts retention agreements in place for the two engineers who hold the deployment and billing knowledge. All 96 technical documents, including the architecture pack, the two penetration test reports, and the license inventory, are shared through a view-only data room folder with watermarking, and repository access is granted read-only for 10 business days.
A data room for technical due diligence holds the most attacker-useful material in the whole transaction. A financial model tells a competitor what you earn. An architecture diagram plus a penetration test report tells anyone who reads them exactly where the product breaks and how to get in, and unlike a price, that stays true whether or not the deal closes.
Papermark is a secure, fully customizable, and developer-friendly data room built for modern dealmakers, with page-by-page analytics, dynamic watermarking, and transparent pricing (open-source and self-hosting available).
A technical due diligence data room with one folder per review area, so the security folder can carry different permissions from the roadmap.
Engineering teams default to whatever they already use, which usually means a shared drive link or a Notion page. Both are the wrong tool here, for four concrete reasons. If you are still choosing a platform, our comparison of the best virtual data rooms covers pricing model, bidder management and compliance across the main providers.
The documents describe how to break the product. A penetration test report is a list of unfixed vulnerabilities. An architecture diagram shows which service to target and which one has no rate limiting. An incident history tells an attacker what has already worked. Sending those to a buy-side distribution list means a document with a five-year shelf life is now in an unknown number of inboxes, including at a company that may walk away next month.
The bill of materials is the document that ends negotiations. The open-source licence inventory is the single file most likely to change the price, which is exactly why it should be released to named reviewers under a specific NDA rather than sitting in the same folder as the release calendar. Staged disclosure is a permissions feature, not a policy.
Three or four reviewers need three or four different views. The technical reviewer needs everything. Buyer's counsel needs the licence inventory and the contributor assignments, and nothing else. The buyer's own security lead needs the penetration tests. The investment committee needs the summary. A data room for technical due diligence issues one link per reviewer over one document set; a shared drive issues one permission level to everyone.
Repository access should be the exception, not the default. Most sellers should share architecture documents, dependency inventories, and code metrics first, and grant read-only repository access for 5 to 10 business days only after the reviewer is named and under NDA. That sequencing only works if the document layer is controlled well enough to make it credible.
The rest of this section is the practical setup: five steps to build a room that handles all four.
Create one folder per area from the table in section 3: architecture, code quality, security, infrastructure, delivery practice, data, IP and licensing, engineering team, and roadmap. That structure is what makes staged disclosure possible later, because the two folders you will want to release last, security and IP and licensing, are already separate from everything else.
Drag the folder tree in and upload in bulk. Automatic file indexing on the Data Rooms Plus plan builds and maintains the index as documents arrive, which matters in a four-week review where week two produces a second wave of requests off the back of week one.
Each reviewer gets its own link carrying its own folder scope, email allowlist or domain restriction, and download rule. On a technical review the asymmetry is unusually sharp, because the person who most needs the penetration tests is not the person who needs the roadmap.
| Reviewer | Folders granted | Rights |
|---|---|---|
| Technical diligence firm | All nine areas | View and download, except security |
| Buyer's security lead | Security, infrastructure, data | View only, watermarked |
| Buyer's counsel | IP and licensing only | View and download |
| Investment committee | Architecture summary, roadmap | View only |
| Buyer's CTO | Architecture, delivery practice, engineering team | View only |
Granular file-level permissions are set per link rather than per user, so no reviewer creates an account and access is scoped to named people rather than to whoever receives a forwarded URL. NDA gating on the security and licensing links requires acceptance before any file opens, which is what makes staged disclosure enforceable rather than aspirational.
Per-link permissions keep architecture and penetration test documents scoped to named technical reviewers.
Switch the security folder and the IP and licensing folder to view-only and turn on dynamic watermarking, which stamps every page with the viewer's email, IP address, and timestamp as it renders. Screenshot protection adds a further deterrent on penetration test findings specifically.
State the limit honestly: a downloaded file cannot be recalled by any platform. That is why download is switched off on those two folders rather than merely discouraged, and why watermarking exists, so a leaked page traces to a named viewer instead of to nobody.
Dynamic watermarking renders viewer identity onto every page, which is what makes a leaked architecture diagram traceable.
Technical questions arrive tied to a specific diagram or a specific line in a dependency report, and they need answering by an engineer rather than by the deal team. Run over email, they get relayed twice and lose precision on the way.
The Q&A module attaches each question to the document that prompted it, with permissions controlling who sees which threads, so the CTO answers once and the answer sits next to the artefact it refers to. The log exports for the closing file, which matters when a representation about open-source usage is later tested.
Page-level analytics show which reviewer opened which document, when, and for how long. In a technical review this is genuine early warning: a reviewer who has spent forty minutes in the licence inventory has found the copyleft component, and you have roughly a week to prepare the remediation estimate before it appears in their report.
Per-visitor analytics show which technical documents each reviewer opened and for how long, which is where the next question comes from.
Because Papermark is developer-friendly, teams running several deals can create rooms, upload document sets, and issue links through the public API or the MCP server rather than clicking through the interface, which our data room API guide covers. After closing, data room freeze makes the room immutable and exports it as an archived ZIP with a certificate.
Papermark is our #1 VDR provider for M&A transactions right now. In two deals we used custom branding, dynamic watermarking, and granular permissions.
Tyler
The Data Rooms plan is €99/month with a 7-day free trial and includes 3 team members, unlimited data rooms, unlimited documents with no file size limit, a custom domain, dynamic watermarking, NDA agreements, and granular file-level permissions. Data Rooms Plus at €249/month adds 5 team members, the Q&A module, the audit log, automatic file indexing, and SOC 2 Type II. Premium at €549/month adds 10 members, the public API, SSO, and whitelabeling. Against a technical review that starts at $35,000, the room is a rounding error, and unlimited data rooms under one subscription means a sell-side team running a competitive process can give each bidder its own room.
No credit card required.
IT due diligence in 2026: the 8-domain checklist, the licence trap that costs buyers most, TSA timelines, and how to run it in a data room for IT due diligence.
Financial due diligence in 2026: 3 pillars, a 6-week timeline, the working capital peg that costs more than EBITDA, and the data room for financial due diligence.
How the M&A due diligence process works in 2026. Seven phases, a citable checklist, red flags, document categories, and the data room setup buyers expect.
