A technical due diligence checklist is the list of checks an investor or acquirer runs on a target company’s software before signing. This one has 55 checks in 7 risk areas: 43 code-level checks across security exposure, dependency and license risk, technical debt, architecture and scalability, engineering practices, and team and knowledge risk, plus 12 checks beyond the code covering infrastructure, compliance, IP ownership and the roadmap. Each check says what to look at and what a red flag looks like, so a failed check turns straight into a finding you can price.
The 55 checks at a glance
| Risk area | Domains | Checks |
|---|---|---|
| Security exposure | Application security, Secrets & credentials, Configuration & environment | 14 |
| Dependency & license risk | Dependency vulnerabilities, License compliance | 6 |
| Technical debt | Code correctness, Complexity & maintainability, Duplication & dead code | 8 |
| Architecture & scalability | Architecture consistency, Modularity & coupling, Performance | 6 |
| Engineering practices | Test coverage, CI & delivery | 4 |
| Team & knowledge | Knowledge concentration, Development continuity | 5 |
| Beyond the code | Infrastructure & scalability, Compliance & data privacy, IP ownership, Build vs buy & vendors, Product & roadmap | 12 |
Free technical due diligence checklist template
Prefer a spreadsheet? The tech due diligence template below has every check as a row, ready to fill in during the review and share with the deal team.
One row per check with what to look at, the red flag, severity, and empty columns for status, evidence and engineer-days to fix. Opens in Excel, Google Sheets or Numbers.
How to use this tech due diligence checklist
- Get read-only access first. The code-level checks are answered from the code, the git history or the build, not from a questionnaire the target fills in about itself.
- Mark each check Pass, Fail or N/A. A check you couldn’t assess is N/A, never a pass. Say so in the report, so nobody reads silence as a clean result.
- Record the evidence. For every failure, write down the file, package or person it comes from. Findings without evidence get argued away in negotiation.
- Price the failures. Estimate engineer-days to fix each one and multiply by a blended day rate. That number is what belongs in the valuation conversation.
- Split by timing. Decide what must be fixed before close (live secrets, exploitable vulnerabilities, license problems, missing IP assignments) and what goes into the 30- and 90-day plan.
1. Security exposure checklist
What an attacker could exploit today, and what would trigger a breach notification.
Application security
- No critical security vulnerabilitiescritical
What to look at: Run static analysis and review auth, payment and data-export paths for exploitable flaws.
Red flag: Any critical finding on an internet-facing endpoint with no fix date.
- No high-severity security vulnerabilitieshigh
What to look at: Count high-severity findings and check whether the same class repeats across endpoints.
Red flag: The same vulnerability pattern in many places, which points to a process gap, not one bug.
- No code or command injectionhigh
What to look at: Search for eval/exec, shell commands built from user input and template injection.
Red flag: User input reaching a shell, eval() or a template engine without validation.
- No SQL injection riskshigh
What to look at: Look for queries built with string formatting instead of parameters or an ORM.
Red flag: f-strings or string concatenation inside SQL, especially in DELETE/UPDATE.
- No unsafe deserializationhigh
What to look at: Check pickle, unsafe YAML loading and similar on data that crosses a trust boundary.
Red flag: pickle.loads or yaml.load on request bodies, files or queue messages.
- Authentication and access control hold uphigh
What to look at: Review session handling, role checks and tenant isolation on multi-tenant data.
Red flag: Endpoints that change data without an auth check, or IDs that let one customer read another's records.
- Static security rules passmedium
What to look at: Run a rule-based scanner (e.g. Semgrep) against the codebase and triage the results.
Red flag: Hundreds of open scanner findings nobody has looked at.
Secrets & credentials
- No hardcoded secrets in the repositorycritical
What to look at: Scan the code and the full git history for keys, tokens and passwords.
Red flag: Live credentials in the repo; past staff and contractors still have them.
- No private keys committedcritical
What to look at: Look for service-account JSON, TLS and signing keys in the tree.
Red flag: A *.json or *.pem key file in source control.
- No cloud or payment provider tokenscritical
What to look at: Check specifically for AWS, Stripe, GitHub and Slack tokens.
Red flag: A live Stripe or AWS key: direct access to money or infrastructure.
- No credentials assigned in codehigh
What to look at: Look for passwords and API keys set as string literals or defaults.
Red flag: os.getenv('KEY', 'real-secret-value') style fallbacks.
Configuration & environment
- No environment files committedhigh
What to look at: Check for .env, .env.prod and similar files in the repository.
Red flag: .env files with production database URLs or keys in git.
- Debug and auto-reload disabled in productionmedium
What to look at: Confirm debug flags and dev servers are off in production config.
Red flag: Stack traces or debug pages reachable on the live site.
- Database connection configured safelymedium
What to look at: Review ORM/engine settings: SQL echo, SSL, pool limits.
Red flag: SQL logging of real customer data, or unencrypted connections.
2. Dependency & license risk checklist
Open-source risk the buyer inherits on day one.
Dependency vulnerabilities
- No critical vulnerable dependenciescritical
What to look at: Run npm audit / pip-audit (or an SBOM scan) against the lockfiles.
Red flag: Critical advisories in packages that are directly reachable from the internet.
- No high-severity vulnerable dependencieshigh
What to look at: List high advisories by package and whether a patched version exists.
Red flag: Many high advisories with available fixes that were never applied.
- Moderate advisories under controlmedium
What to look at: Count moderate advisories and the age of the oldest unpatched one.
Red flag: A long backlog of old advisories: dependencies aren't being maintained.
License compliance
- No strong-copyleft dependencieshigh
What to look at: Find GPL/AGPL packages in a proprietary product, including transitive ones.
Red flag: AGPL code in a SaaS product: may oblige publishing your own source.
- No weak-copyleft dependencies without reviewmedium
What to look at: Flag LGPL/MPL packages and how they are linked or modified.
Red flag: Modified LGPL/MPL code shipped without meeting its obligations.
- Every dependency license identifiedlow
What to look at: List packages with missing or non-standard licenses.
Red flag: Unknown licenses on core packages: unpriced legal risk.
3. Technical debt checklist
How expensive the codebase will be to change after close.
Code correctness
- The code compiles and type-checkshigh
What to look at: Build the project and run the type checker from a clean checkout.
Red flag: The main branch doesn't build, or type errors are suppressed wholesale.
- No lint errorsmedium
What to look at: Run the project's linters with its own config.
Red flag: Linting disabled in CI, or thousands of errors left in place.
- No high-severity logic defectshigh
What to look at: Review money, permissions and data-integrity code paths for wrong results.
Red flag: Billing, refund or quota logic with unhandled edge cases.
Complexity & maintainability
- No extremely complex functionsmedium
What to look at: Measure cyclomatic complexity; list functions above 20.
Red flag: Core business logic in a handful of 500-line functions.
- Under 10% of functions above complexity 10low
What to look at: Check what share of functions are moderately complex.
Red flag: Complexity spread everywhere: every change is slow and risky.
- No high-severity maintainability issuesmedium
What to look at: Look for global state, hidden coupling and copy-pasted rules.
Red flag: Global mutable state shared across requests.
Duplication & dead code
- Little duplicated codelow
What to look at: Detect duplicated blocks across the repository.
Red flag: The same business rule implemented differently in several places.
- Little unreferenced codelow
What to look at: Find files nothing imports and that aren't entry points.
Red flag: Large amounts of dead code that inflate the codebase you are paying for.
4. Architecture & scalability checklist
Whether the system can support the growth plan in the deal thesis.
Architecture consistency
- Consistent architecture across the codebasemedium
What to look at: Check that layering, data access and error handling follow one pattern.
Red flag: Three different ways to call the database, each with its own bugs.
- Few cross-cutting inconsistencieslow
What to look at: List competing conventions (config, logging, auth checks).
Red flag: Every service or module invented its own conventions.
Modularity & coupling
- No circular importsmedium
What to look at: Build the import graph and look for cycles.
Red flag: Modules that can't be changed or extracted independently.
- No module depends on everythinglow
What to look at: Find modules that import many internal modules.
Red flag: A 'utils' or 'core' module every change has to touch.
- No high-severity design flawsmedium
What to look at: Review service boundaries, schema design and single points of failure.
Red flag: A design that needs a rewrite to reach the projected scale.
Performance
- No high-severity performance problemsmedium
What to look at: Look for N+1 queries, blocking I/O in async code and unbounded queries.
Red flag: Costs or latency that grow faster than usage.
5. Engineering practices checklist
Whether the team can ship changes safely.
Test coverage
- At least one test file per five source fileshigh
What to look at: Compare test files to source files, and look at what the tests cover.
Red flag: Almost no tests around payments, auth or data integrity.
- Coverage is measuredlow
What to look at: Check for coverage tooling and reports.
Red flag: Nobody knows which parts of the product are unprotected.
- Every major area has testsmedium
What to look at: List top-level modules with no tests at all.
Red flag: Whole services or apps with zero tests.
CI & delivery
- CI runs the tests on every changemedium
What to look at: Check the pipeline runs tests and blocks merges on failure.
Red flag: CI exists but doesn't run tests, or failures are ignored.
6. Team & knowledge checklist
Key-person risk that has to be handled in the deal terms.
Knowledge concentration
- No one wrote half or more of the codehigh
What to look at: Look at the commit share per contributor over the repo's history.
Red flag: One engineer authored most of the commits: a bus factor of one.
- At least three significant contributorsmedium
What to look at: Count contributors with 10% or more of commits.
Red flag: Only one or two people understand the core systems.
Development continuity
- Recent commitsmedium
What to look at: Check when the codebase was last changed.
Red flag: No commits for months: nobody may be left who can maintain it.
- The main author is still activehigh
What to look at: Check the top contributor's most recent commit.
Red flag: The person who wrote most of the code has stopped committing.
- Two or more people actively committingmedium
What to look at: Count contributors active in the last 90 days.
Red flag: A single active maintainer for every post-close fix.
7. Beyond the code checklist
What a code scan can’t tell you: whether the system scales, whether the company is compliant, and whether it owns what it sells. Answer these from the cloud account, contracts and interviews.
Infrastructure & scalability
- Scaling headroom is knownhigh
What to look at: Ask for current peak load against capacity, any load-test results, and which component saturates first.
Red flag: Nobody can say how much more traffic the system handles, or the database is already near its limits.
- No single points of failurehigh
What to look at: Look for a single database without failover, a single region or server, and deploys only one person can run.
Red flag: One machine or one person whose loss takes the product down.
- Backups and disaster recovery are testedhigh
What to look at: Ask when a backup was last restored end to end, and what the recovery point and recovery time targets are.
Red flag: Backups exist but have never been restored.
- Cloud cost scales with revenuemedium
What to look at: Compare the monthly cloud bill over the last 12 months with customer and revenue growth.
Red flag: Infrastructure cost growing faster than revenue, or large line items nobody can explain.
Compliance & data privacy
- Personal data is mappedhigh
What to look at: Ask for a data map: what personal data is stored, where, for how long, and who can access it.
Red flag: Nobody can list where customer data lives, or production data is copied to laptops and test systems.
- Regulatory obligations are methigh
What to look at: Check GDPR/CCPA basics, plus PCI DSS or HIPAA if the product touches card or health data, and vendor DPAs.
Red flag: Card or health data handled with no compliance program in place.
- Security certifications and pen tests are currentmedium
What to look at: Review SOC 2 or ISO 27001 status, the last penetration test, and whether its findings were closed.
Red flag: SOC 2 promised to enterprise customers but not started, or pen-test findings still open.
IP ownership
- The company owns its codecritical
What to look at: Confirm signed IP assignment agreements for every founder, employee, contractor and agency that wrote code.
Red flag: Core code written by contractors or an agency with no IP assignment.
- No borrowed or disputed codemedium
What to look at: Ask where the first version came from and whether any code was reused from a previous employer or client.
Red flag: Code carried over from a founder’s previous company or a client project.
Build vs buy & vendors
- Commodity pieces are bought, not builtmedium
What to look at: Look for homegrown authentication, billing, queues or search where a standard service would do.
Red flag: In-house versions of commodity infrastructure maintained by a single engineer.
- Critical vendors have an exitmedium
What to look at: List the vendors the product can’t run without, their contract terms and who owns the accounts.
Red flag: A critical service on a personal account, a free tier, or a vendor with no realistic replacement.
Product & roadmap
- The roadmap fits the architecturemedium
What to look at: Walk through the next 12–18 months of roadmap with the tech lead and ask what would need rebuilding.
Red flag: The deal thesis assumes features the current architecture can’t support without a rewrite.
What to request from the target before you start
- Read-only access to every source repository, including infrastructure and mobile apps.
- An architecture diagram, or a one-hour walkthrough with the tech lead if none exists.
- The list of third-party services, what each is used for, and the monthly cost.
- Incident and outage history for the last 12 months, with postmortems if they exist.
- The engineering org chart, tenure, and who owns which systems.
- Previous penetration tests, security audits or SOC 2 reports.
For the interview side, use our list of 60 technical due diligence questions to ask the target.
How to score and price what you find
Give each failed check the severity shown above, then estimate the engineer-days to fix it. A single exposed secret is a few hours of rotation; missing tests across the product can be weeks. Multiply the total by a blended rate (for example $600 to $1,000 per engineer-day) to get a range you can put in front of the investment committee.
- Before close: live secrets, critical or high vulnerabilities, strong-copyleft licenses, missing IP assignments.
- First 30 days: vulnerable dependencies, debug settings, missing CI tests.
- First 90 days: test coverage, duplication, architecture clean-up.
- Deal terms, not engineering: key-person risk is handled with retention and handover periods, not engineer-days.
See which findings actually change deals in technical due diligence red flags that kill deals, and how sellers can get ready in how to prepare for technical due diligence.
Common mistakes
- Trusting a questionnaire. The target’s own answers about its code are a starting point, not evidence.
- Counting “not checked” as “fine”. If a check couldn’t run (no git history, no lockfile), the report should say so.
- Reporting severity without cost. “High risk” doesn’t move a price; “18 engineer-days, $11K–$18K” does.
- Ignoring the team. A clean codebase that one person understands is still a risky acquisition.
One row per check with what to look at, the red flag, severity, and empty columns for status, evidence and engineer-days to fix. Opens in Excel, Google Sheets or Numbers.
Technical due diligence checklist FAQ
What is a technical due diligence checklist?
A list of the checks an investor or acquirer runs on a target company’s software before a deal: security exposure, dependency and license risk, technical debt, architecture and scalability, engineering practices, team risk, and the questions beyond the code such as infrastructure, compliance and IP ownership. Each failed check becomes a finding with a severity and a cost to fix.
How long does technical due diligence take?
A traditional manual review takes two to six weeks. With automated scanning of the codebase, a screening-level review takes three to five business days, and a full review with interviews one to two weeks. Most of the calendar time is getting access and scheduling interviews, not analysis.
Who should do technical due diligence?
Someone independent of the target who can read code and judge architecture: an external technical due diligence firm, an operating partner with an engineering background, or an automated review tool combined with a short expert interview. The target’s own team should not grade itself.
What documents should I request from the target company?
Read-only access to all source repositories, an architecture overview, the list of third-party services and their costs, the incident history for the last year, the org chart for engineering, and any previous penetration test or security audit reports.
What are the biggest red flags in technical due diligence?
Live secrets in the code, strong-copyleft (GPL/AGPL) code inside a proprietary product, almost no automated tests around payments or authentication, and one engineer who wrote most of the code and is not committed to stay after the deal.
Is technology due diligence the same as technical due diligence?
Yes. Technical, technology, tech and engineering due diligence all describe the same review of a target’s software, infrastructure, security and engineering team. Some firms use “technology due diligence” for a wider scope that includes IT systems and vendors, which the beyond-the-code checks in this list cover.
Is there a free technical due diligence template?
Yes. The spreadsheet linked on this page has every check in this checklist as one row, with what to look at, the red flag, the severity, and empty columns for status, evidence and engineer-days to fix. It opens in Excel, Google Sheets or Numbers.
Can technical due diligence be automated?
Most of the code-level checks can: secrets, vulnerable dependencies, licenses, complexity, duplication, test coverage and commit history. Questions about the roadmap, hiring and the deal thesis still need a conversation with the team.