30 September 202611 min read

7 Technical Due Diligence Domains Investors and Founders Must Verify

An opened typewriter on a felt mat beside a neat row of small trays holding its parts, the first tray holding a jeweller's loupe.

A rigorous technical due diligence checklist must verify seven technical domains: code and architecture, infrastructure and scalability, security and compliance, data and AI systems, team and processes, intellectual property, and integrations. The output is never a pass or fail label. It is a risk register, a remediation roadmap, and a confidence rating tied to the deal. Start by requesting repo access, an architecture diagram, recent incident logs, and any data protection impact assessment on file.

TL;DR:

A thorough review of code quality requires access to repositories, test coverage reports, deployment logs, and current architecture diagrams, not summaries.

Infrastructure assessment should focus on scalability, backup testing, disaster recovery plans, and incident history, with evidence of tested procedures.

Security due diligence demands penetration test results, encryption practices, access policies, and evidence of active patching, plus data privacy impact assessments when applicable.

Evaluating AI systems involves verifying data inventories, model documentation, monitoring for drift, and human oversight processes, not just claimed capabilities.

Understanding team maturity includes analyzing key-person dependencies, retention trends, release frequency, incident response plans, and technical debt management.

Assessing code quality and system architecture

Good architecture leaves evidence. Look for modular design, meaningful test coverage, automated build and deployment pipelines, clean dependency management, and a habit of code review rather than a policy that exists only on paper. Documentation that actually matches the running system is rarer than it should be, and its absence is itself a signal.

Ask for direct access rather than a slide deck summarizing the codebase. The right artifacts tell you more in an hour than a founder’s narrative tells you in a day.

Repository access with commit history, not just a snapshot export.
Unit and integration test reports showing coverage trends over time.
CI/CD logs demonstrating build frequency and failure rates.
Architecture diagrams that reflect the current system, not the original pitch deck version.
Dependency manifests such as package-lock.json or go.sum for supply chain visibility.
Recent pull requests and release notes showing how changes actually ship.

A codebase with no automated tests, a single monolithic deployment, or dependencies frozen for years is not disqualifying, but it does change the cost and timeline of any post-acquisition roadmap. Budget remediation time accordingly rather than assuming a quick patch will close the gap.

Infrastructure, hosting and scalability under real load

Operational resilience is where paper promises meet reality fastest. Review the hosting architecture, whether the system spans multiple availability zones or regions, how autoscaling is configured, and how dependent the company is on a single cloud vendor or a single engineer who understands the setup. Vendor lock-in is not automatically bad, but it should be a known and priced-in risk rather than a surprise.

Backup and disaster recovery deserve specific scrutiny because they are the domain most often described rather than demonstrated.

Recovery time objective and recovery point objective figures, with evidence they have been tested.
A disaster recovery plan and written runbooks, not just an assumption that someone will know what to do.
A documented incident history, including what broke and how it was resolved.
Monitoring dashboards and defined service level objectives.
Recent postmortems showing whether the team learns from failures or repeats them.

If a team cannot produce a tested backup restoration or a recent postmortem, treat that gap as a near-term cost item, not a footnote. Our case studies page includes examples of multi-site hosting and operational runbooks built to survive exactly this kind of scrutiny.

Security posture and data protection compliance

Security evidence should be concrete: penetration test reports, vulnerability scan results, identity and access management policies, encryption practices, and a patching cadence that is actually followed rather than aspirational. A team that cannot produce a pentest report from the last year, or that treats “we haven’t been breached” as proof of security, is telling you something important.

Privacy compliance runs alongside security. The EDÖB confirms that Swiss data protection law is technology-neutral and applies fully to AI systems, meaning controllers must build in privacy by design and privacy by default, and may need a formal impact assessment for high-risk processing. Check for a completed assessment where personal data volume or sensitivity warrants one, and review processor contracts for data transfer clauses and residency terms.

Recent penetration test or vulnerability scan reports with remediation status.
Identity and access management policies covering who can reach production systems.
Proof of encryption at rest and in transit.
A documented patching cadence and evidence it is followed.
A data protection impact assessment where high-risk processing applies.
Processor and sub-processor contracts covering cross-border data transfer.

The European Cyber Resilience Act is expected to apply lifecycle cybersecurity obligations to products with digital elements sold into the EU starting around 2027. If the target’s product includes software, remote data processing, or is marketed commercially in the EU, add a quick CRA applicability check to the review: does the product contain digital elements, does it process data remotely, and is it intended for EU distribution.

Data governance, analytics and AI system controls

Data practices reveal how disciplined a team really is. Request a data inventory, retention policy, a data dictionary, and sample datasets that let you verify claims rather than take them at face value. A company that cannot produce a clear map of what data it holds and why is carrying hidden liability, regardless of what its pitch deck says.

AI features need their own layer of scrutiny; using tools like the AI Overview Checker can help optimize documentation for Google AI Overviews. Ask for documentation of training data sources, any model cards describing intended use and limitations, validation metrics, and monitoring in place to catch model drift after deployment. The EFK’s audit approach for AI systems recommends reviewing AI systems across three lifecycle stages: planning, development, and operation, with documentation and monitoring expected throughout rather than only at launch.

A data inventory listing what is collected, where it lives, and how long it is kept.
A data dictionary mapping fields to their business meaning.
Model documentation covering training data sources and known limitations.
Drift monitoring evidence and any human-in-the-loop review step for automated decisions.
Data lineage maps and access logs showing who touches sensitive data and when.

Human oversight of AI outputs is a practical control worth verifying directly, not just accepting as a stated policy: ask to see the validation workflow, not only the accuracy numbers behind it.

Evaluating the engineering team and technical debt

Technology is only as durable as the team maintaining it. Review the org chart for key-person dependencies, recent retention trends, and whether hiring plans match the roadmap the company is presenting to investors. A brilliant system maintained by one irreplaceable engineer is a single point of failure, not an asset.

Process maturity matters as much as headcount. Look at how code reviews happen, how often releases ship, who owns incident response, and whether runbooks exist for the scenarios that matter most.

Org chart review flagging any critical single points of failure.
Recent engineer retention and turnover figures compared against hiring plans.
Evidence of consistent code review practice, not an occasional exception.
Release frequency and rollback history over the past several months.
A documented incident response process with named owners.
A technical debt backlog with prioritization and time-to-fix tracking.

Technical debt itself is not a red flag: every mature system carries some. What matters is whether the team can name it, size it, and show a credible plan to pay it down over time.

Intellectual property ownership and licensing risk

An investor cannot rely on code that the company does not actually own. Verify that every engineer, whether employee or contractor, has signed an assignment agreement transferring intellectual property rights to the company. Missing assignments are one of the most common and most expensive surprises found late in a deal.

Open source usage needs its own pass. Run a license scan across all dependencies and flag anything with restrictive terms, such as copyleft requirements that could force disclosure of proprietary code.

Employment and contractor agreements with explicit IP assignment clauses.
Contributor license agreements for any external or community contributions.
A license scan report covering all open source dependencies in use.
Copyright notices consistent with claimed ownership.
Vendor and contractor agreements reviewed for assignability and exclusivity restrictions.
Any patent filings relevant to core technology.

Where reused documentation or code carries a share-alike license such as the Creative Commons BY-SA terms, confirm the company understands the attribution and reuse obligations that come with it.

Mapping integration complexity and third-party dependencies

Every external integration is a dependency the acquiring team inherits. Build a full inventory of connected services, from payment processors to analytics tools to internal APIs, along with the contractual terms and versioning guarantees attached to each one. A system that quietly relies on a deprecated API version is a migration cost waiting to surface.

Resilience under failure is just as telling as the integration list itself. Ask what happens when a third-party service goes down: does the system degrade gracefully, retry intelligently, or fail outright and take other features with it.

A full inventory of external integrations with contract terms and renewal dates.
API specifications and versioning commitments for each dependency.
Evidence of retry logic and fallback behavior under third-party outages.
Integration test suites demonstrating end-to-end flows, not just unit-level mocks.
Contractual exit terms in case a vendor relationship needs to end.

A company with a dozen undocumented integrations and no fallback logic is not necessarily a bad investment, but the migration and stabilization work should be priced into the deal, not discovered after close.

How to run the review from kickoff to final report

A structured process keeps technical due diligence from turning into an open-ended fishing expedition. The workflow below scales from a two-week sprint to a longer engagement depending on deal size.

Sign an NDA and hold a kickoff call to confirm scope, timeline, and who on the target’s side will answer questions.
Send a prioritized artifact request in week one: repo access, architecture diagram, incident logs, and any data protection impact assessment on file.
Follow up in week two with deeper artifacts: license scans, test reports, vendor contracts, and org chart details.
Conduct hands-on technical review alongside structured interviews with the CTO, lead engineers, and anyone owning security or compliance.
Score each domain using a simple three-axis rubric: whether evidence exists, how strong that evidence is, and how much business impact a gap would carry.
Compile a risk register and remediation roadmap, ranked by severity and estimated cost to fix.
Deliver a one-page executive risk summary backed by a technical annex, plus a remediation timeline and, where leadership gaps surfaced, the option of interim technical leadership.

Pro Tip: Ask the same three questions of every engineer you interview, not just the CTO: what breaks most often, what would you fix first with more time, and what are you most worried an outside reviewer will find.

The final deliverable should let a non-technical investor understand the risk level in five minutes, while giving a technical reader enough evidence in the annex to verify every conclusion independently.

How Ampersand approaches audits and technical ownership

A specialized software studio runs software audits and technical due diligence from Zurich, with senior engineers leading the review from first contact through the final report rather than handing it to junior staff. That continuity matters because the person asking the interview questions is the same one who has to defend the findings.

Two engagements illustrate the range of this work: Habitects AG, where Ampersand owned the technical side of a bathroom-renovation platform through a full merger, and Repa Immobiliare, where a property portfolio moved off paper onto software built to stay offline by design. Both required the same discipline a technical due diligence review demands: verifying what exists, documenting what is missing, and building a credible plan forward.

Davide Morotti

Getting a technical due diligence review done right

Running this checklist internally takes real engineering time that most founders and investors do not have spare, and a rushed review misses exactly the issues that turn expensive after close. Ampersand Labs handles software audits and technical due diligence as a standing service, with senior engineers doing the actual review work instead of delegating it down.

The engagement fits founders preparing for a raise who want to know what a buyer will find before they find it, and investors who need an independent technical read on a target within a tight deal timeline. Where a review surfaces leadership or delivery gaps, Ampersand also offers interim CTO support to carry the remediation plan through rather than leaving it as a document nobody executes.

Details on the audit and technical due diligence service, along with engagement scope, are on the engineering consultancy page, and current plan and pricing information is on the pricing page. Reach out to scope a review against your deal timeline.

Sources

Three references anchor the regulatory side of this checklist. The NCSC’s P042 ISDS concept provides a template for documenting security measures and residual risk. EDÖB’s outsourcing guidance clarifies that a controller stays responsible for data even after delegating processing to a vendor. The CRA overview cited earlier helps determine EU lifecycle obligations for products with digital elements.

FAQ

What should be included in a due diligence checklist?

A complete technical due diligence checklist covers code and architecture quality, infrastructure and scalability, security and regulatory compliance, data and AI governance, team and process maturity, intellectual property ownership, and third-party integration risk. Each domain should produce concrete evidence rather than a verbal assurance, feeding into a consolidated risk register and remediation roadmap.

What is technical due diligence?

Technical due diligence is a structured review of a company’s software, infrastructure, security, and engineering team, conducted before an investment or acquisition to verify claims and surface risk. It typically results in a risk assessment, a prioritized remediation plan, and a confidence rating that informs deal terms or valuation.

What is a CDD checklist?

Customer due diligence, often shortened to CDD, is a compliance process financial institutions use to verify customer identity and assess risk, and it is distinct from the technical due diligence covered in this checklist. If you encountered the term expecting technology review guidance, the code, infrastructure, security, and team checks above are the relevant equivalent for software and technology deals.

What are the “Four P’s” of due diligence?

Definitions of the “Four P’s” vary across industries and no single authoritative version applies specifically to technical due diligence. For a software or technology deal, the seven-domain structure in this checklist, covering code, infrastructure, security, data, team, IP, and integrations, gives a more reliable framework than a generic four-part model.

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading