---
title: "Technical due diligence in 2026: the open-source licence that can taint the codebase"
lang: en
canonical_url: https://www.papermark.com/blog/technical-due-diligence
last_updated: 2026-08-15
published: 2026-07-29
category: [mergers-and-acquisitions]
author: "Marc Seitz"
summary: "Technical due diligence in 2026: a 9-area checklist, the 4-week process, real costs, the copyleft trap, and the data room for technical due diligence."
---

# Technical due diligence in 2026: the open-source licence that can taint the codebase

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?

## Quick recap

- Technical due diligence assesses the product and engineering side of a target: architecture, code quality, scalability, security, intellectual property ownership, and the team that maintains it.
- It is distinct from IT due diligence, which covers the internal systems a company runs on rather than the product it sells.
- A typical review covers 9 areas: architecture, code quality, security, infrastructure, delivery practice, data, IP and licensing, the engineering team, and the roadmap.
- The copyleft trap is the finding most likely to require legal remediation: a GPL or AGPL component compiled into a proprietary product can carry source disclosure obligations.
- Delivery health is usually measured with the DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service.
- Technical reviews typically run 2 to 4 weeks and cost $35,000 to $95,000 with a specialist firm, or $50,000 to $150,000 with a Big Four technology advisory practice.
- Findings usually land as a technical debt remediation estimate that adjusts price, funds a post-close budget, or becomes a closing condition.
- Buyers request source code access, architecture diagrams, security reports, and license inventories through a data room for technical due diligence rather than direct repository access.
- Repository access, when granted at all, is usually read-only for 5 to 10 business days after the reviewer is named and under NDA.
- Papermark hosts a data room for technical due diligence with granular permissions, dynamic watermarking, and per-visitor audit logs from €99/month.

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.

## 1. What is technical due diligence?

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](/blog/it-due-diligence.md), and they are not judging whether the market wants the product, which belongs to [commercial due diligence](/blog/commercial-due-diligence.md).

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.

## 2. Technical due diligence versus IT due diligence

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.

## 3. The 9 areas a technical review covers

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.

### What each area asks the seller to produce

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.

## 4. How the process runs over four weeks

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 1:** document request, architecture orientation, scoping call with the CTO.
- **Week 2:** code review in a controlled environment, dependency and license analysis, infrastructure walkthrough.
- **Week 3:** interviews with engineering leadership and individual contributors, security and incident review.
- **Week 4:** remediation estimates in engineer-months, integration assessment, and the final report.

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.

![Separate scoped links issued per technical reviewer in a diligence data room](https://assets.papermark.io/upload/file_HKCLjWCkdTzc6qAFV2it65-all-links.png)

_One link per named reviewer, issued in week one, is what makes the rest of the four-week process controllable._

## 5. Red flags that change the price

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 |

![Screenshot protection applied to penetration test findings in a technical due diligence data room](https://assets.papermark.io/upload/file_Jd6mEvqdytkqTP7BJhRyn7-screenshot-protection-cover-papermark-.png)

_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._

## 6. What technical due diligence costs

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](/blog/due-diligence-cost.md) 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.

## 7. Worked scenario: reviewing Feldstrom Analytics

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.

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.

## 8. Data room for your technical due diligence

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](/data-room.md) 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).

![Papermark data room for technical due diligence with folders per review area](https://img.papermarkassets.com/upload/file_35DtVER7SdS1G6unRE8unv-papermark-data-room.png)

_A technical due diligence data room with one folder per review area, so the security folder can carry different permissions from the roadmap._

### Why you need a data room for technical due diligence

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](/blog/best-virtual-data-rooms.md) 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.

### Step 1: build the room by review area, not by team

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.

### Step 2: issue one scoped link per reviewer

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 controlling access to technical due diligence documents](https://assets.papermark.io/upload/file_2Ne6hZvpaoh2CwpxRxfThZ-papermark-link-permissions.png)

_Per-link permissions keep architecture and penetration test documents scoped to named technical reviewers._

### Step 3: watermark and lock the security and licensing folders

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 watermark showing viewer email, IP address and timestamp on a technical diligence document](https://assets.papermark.io/upload/file_Ks2dtpU7UXaoreiAAtXr54-watermarked-document.png)

_Dynamic watermarking renders viewer identity onto every page, which is what makes a leaked architecture diagram traceable._

### Step 4: route technical questions to the CTO through Q&A

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.

### Step 5: read the analytics, then freeze the room

**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 across technical due diligence documents in a Papermark data room](https://assets.papermark.io/upload/file_YVZLbYwELYa8SxfjBg3mGe-virtual-data-room-analytics-.png)

_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](/blog/data-room-api.md) guide covers. After closing, **data room freeze** makes the room immutable and exports it as an archived ZIP with a certificate.

### What it costs

The [Data Rooms plan](https://www.papermark.com/pricing.md?view=datarooms) is **€99/month** with a 7-day free trial and includes 3 team members, unlimited data room visitors, 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, AI redaction, the public API, SSO, and whitelabeling. **Data Rooms Unlimited at €999/month** removes per-seat charges entirely, so teams that add reviewers mid-deal pay one number regardless of headcount, and it carries every Premium capability including AI redaction. 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._

## FAQ

### What is technical due diligence?

It is a review of a target's product, architecture, code, security, and engineering team to judge whether the technology supports the deal thesis. A standard review covers 9 areas and produces remediation estimates in engineer-months, typically over 2 to 4 weeks.

### How much does technical due diligence cost?

Specialist technology diligence firms 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. A lighter scalability and IP review runs $15,000 to $30,000.

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

Technical due diligence covers the product a company sells: architecture, code, and the engineering team. IT due diligence covers the systems a company runs on: ERP, identity, endpoints, licensing, and disaster recovery. A software acquisition needs both, and the two reports usually overlap only in cloud infrastructure and security.

### How long does technical due diligence take?

Three to four weeks is standard once the document set is available: week 1 collection and orientation, week 2 code and dependency review, week 3 interviews, week 4 quantification and reporting. The constraint is almost always document readiness rather than reviewer capacity, which is why sell-side technical preparation shortens the whole engagement.

### Who performs technical due diligence?

Usually a specialist technology diligence firm engaged by the buyer after the letter of intent, often alongside the buyer's own CTO for the architecture and integration view. On deals with meaningful security exposure a separate security lead reviews the penetration tests and incident history, which is why that folder normally needs its own scoped access rather than sitting in the general technical folder.

### What does a technical due diligence report include?

An architecture assessment against the growth thesis, code quality and test coverage findings, a security and dependency review, DORA delivery metrics, an open-source licence position, a key person map, and a remediation plan priced in engineer-months. In the worked scenario in this guide the report quantified 20 engineer-months and $216,000 of incremental annual hosting.

### Does the buyer get access to the source code?

Usually a limited, read-only review in a controlled environment, often for 5 to 10 business days rather than open access. Most sellers share architecture documents, dependency inventories, and code metrics through a data room for technical due diligence first, and grant repository access only after the technical reviewer is named and under NDA.

### What technical red flags kill a deal?

Rarely a single one. The findings that most often become closing conditions are copyleft open-source components compiled into a proprietary product, an undisclosed security breach, and personal data handled outside GDPR requirements. A capacity ceiling projected within 12 to 18 months usually adjusts the model rather than ending the deal.

### Why does an AGPL or GPL dependency matter so much?

Because strong copyleft licences can extend source disclosure obligations to the surrounding work, which for a proprietary SaaS product is a genuine legal problem rather than a hygiene issue. The remedy is replacement or re-architecture, and it is knowable: in the worked scenario above, replacing 1 AGPL charting library out of 1,840 packages was estimated at 3 engineer-months, roughly $65,000, and became a closing condition.

### Do I need a data room for technical due diligence, or is a shared drive enough?

A shared drive gives you one permission level, and a technical review needs at least four: the diligence firm sees everything, the buyer's security lead sees the penetration tests, counsel sees the licence inventory, and the investment committee sees the summary. A data room for technical due diligence sets permissions per link over one document set, watermarks the security folder, and produces the per-visitor record that supports an open-source representation later.

### How do I stop a penetration test report from leaking during diligence?

Set the document to view-only, restrict the link to a named email allowlist, gate it behind an NDA, and enable dynamic watermarking so every page carries the viewer's email, IP, and timestamp. Papermark's page-level analytics then record which reviewer opened which page and for how long. Granular file-level permissions and watermarking are included in the €99/month Data Rooms plan with 3 team members; the audit log sits on Data Rooms Plus at €249/month.

## Related resources

- [Best virtual data rooms in 2026](/blog/best-virtual-data-rooms.md)
- [IT due diligence](/blog/it-due-diligence.md)
- [Commercial due diligence](/blog/commercial-due-diligence.md)
- [M&A due diligence checklist](/blog/m-and-a-due-diligence-checklist.md)
- [Due diligence cost](/blog/due-diligence-cost.md)
- [Startup due diligence](/blog/startup-due-diligence.md)

---

_Markdown version of [this article](https://www.papermark.com/blog/technical-due-diligence) for AI agents and LLMs._
_More Papermark content: [llms.txt](https://www.papermark.com/llms.txt) · [full index](https://www.papermark.com/llms-full.txt)._