Technical Due Diligence Questions to Ask in 2026: Code, AI, Security and Team

Technical due diligence questions are the questions a buyer or investor asks a target's technology leaders to test whether its software, infrastructure, team and processes can carry the deal thesis. The useful ones ask for evidence, not opinions: a metric, a document, a log or a live demo. In 2026 the list also has to cover how much of the code was written with AI tools and how that code was reviewed.

We first published this list in 2023 as eight questions for IT company leaders. This version is rebuilt for deal teams, operating partners and CTOs on either side of a transaction: the questions grouped by area, the evidence that should back each answer, and the red flags that should change the price or the plan. They are the same questions Sphere's technical due diligence team works through in an assessment of four weeks or less.

What Is Technical Due Diligence?

Technical due diligence is an independent assessment of a company's software, architecture, infrastructure, security, engineering organization and product, carried out before an acquisition, investment or major operating decision. Its job is to turn technology risk into numbers the deal model can use: remediation cost, time to scale, key-person exposure and the run-rate cost of operating the platform. For the full scope, see what technology due diligence covers and what investors check.

The questions below assume a software or tech-enabled target. If the company runs on technology rather than selling it, such as a manufacturer or a services firm, pair them with our IT due diligence checklist, which goes deeper on enterprise systems, licences and separation.

How Should You Use Technical Due Diligence Questions?

Send the questions as a written questionnaire with the first data room request, so management can prepare evidence instead of improvising. Use the interviews to probe answers that were vague or that contradict the documents. Then verify the answers that matter most to the deal thesis directly against code, configuration and logs.

Not every question deserves equal depth. A growth investment that depends on scaling puts architecture first. A carve-out puts infrastructure and separation first. An AI-first company puts model provenance and AI-built code first. Agree the weighting with the deal team before the questions go out.

Which Technical Due Diligence Questions Should You Ask in 2026?

The nine groups below cover a full assessment of a software or tech-enabled company. Each group lists the questions to ask; the table after them shows which answers need hard evidence.

1. Architecture and scalability

• What does the architecture look like today, and when was the diagram last checked against what is actually deployed?
• What happens at two, five and ten times current load, and which component fails first?
• Which parts of the system would need a rewrite, not just more infrastructure, to support the growth plan?
• Where are the single points of failure in the core transaction path?

A good answer comes with a load test or production metrics that show headroom, and names the bottleneck along with a plan for it. "The cloud scales automatically" is not an answer.

2. Code quality and technical debt

• How is technical debt tracked, and how much engineering capacity goes to it each quarter?
• What is automated test coverage on the code paths that generate revenue, and how long does the test suite take to run?
• Which modules does the team avoid changing, and why?
• Which frameworks, languages or databases are past the end of vendor or community support?

A team that cannot name its worst debt usually carries more of it than a team that can. Our guide to assessing and pricing technical debt explains how to turn these answers into a costed register.

3. AI-generated code

This is the group most questionnaires written before 2024 lack. Many engineering teams now produce a significant part of their new code with coding assistants and agents. That code can look clean while hiding weak tests, snippets with licence obligations, or logic nobody on the team fully understands.

• Which AI coding tools and agents are in use, and roughly what share of recent changes did they produce?
• What review is required before AI-generated code is merged, and is it enforced in the pipeline or only written in a policy?
• How is generated code scanned for licence provenance, exposed secrets and known-vulnerable dependencies?
• Do the tests on AI-written modules check real behaviour, or were they generated by the same tool that wrote the code?
• Who on the team can explain the generated modules in revenue-critical systems without re-reading them first?

These questions tell you what the team believes about its process. To see what actually entered the codebase, read our guide to diligence on AI-generated code, or commission a focused code audit of the AI-built modules before signing.

4. AI in the product

• Which features depend on third-party models, and what happens to margins if inference prices or model behaviour change?
• Does the company hold the rights to the data it trains, fine-tunes or grounds its models on?
• How are model outputs evaluated before release, and how are failures monitored in production?

If AI is central to the valuation, these questions need their own workstream. See how to evaluate an AI company or AI product before you invest.

5. Security and data protection

• When were the last penetration test and code-level security review, and which findings are still open?
• How are secrets, privileged access and third-party integrations controlled and reviewed?
• Which personal or regulated data is stored, where, and under which regimes?
• What security incidents occurred in the past three years, and what changed afterward?

In regulated targets, this group can decide the deal. In the cybersecurity-first diligence Sphere ran for Marble Financial's acquisition of Inverite, the team reviewed more than 15 security domains in three weeks, which gave the buyer's legal and technical teams a specific list of security and compliance gaps to take into closing negotiations.

6. Infrastructure, cloud cost and resilience

• What do the last twelve months of cloud bills show, and how much of that spend is idle or oversized?
• Is the infrastructure defined as code, and could the environment be rebuilt from scratch?
• When was a full restore from backup last tested, and how long did it take?
• What are the recovery time and recovery point objectives for each critical system, and were they met in the last real incident?

7. Engineering team and key people

• Who holds knowledge that is not written down, and what happens if they leave after close?
• What did attrition and open roles look like over the past two years?
• How is work split between employees, contractors and outsourced teams, and who owns the code each of them writes?
• Has the technology leadership run a platform at the scale the business plan assumes?

8. Delivery process

• How often does the team deploy to production, and how often does a deployment cause an incident?
• How long does a change take from commit to production?
• How is the roadmap prioritized, and how many committed dates were met last year?

9. IP, open source and third-party dependencies

• Does the company own all of its code, including work by former contractors and agencies?
• Which open-source licences are in the dependency tree, and do any copyleft licences apply to distributed code?
• Which third-party APIs or vendors could stop the product if they failed, changed terms or raised prices?

Which Answers Need Evidence?

Some answers can be taken on trust in a first pass. The ones below cannot, because they move price, terms or the post-close plan. Request the evidence alongside the questionnaire.

What If You Are the Company Being Asked?

Founders and CTOs preparing for a sale should expect every question above, and should answer them before a buyer's team does. Running the same questions internally a few months before going to market leaves time to close the cheap gaps, such as missing IP assignments, untested restores or review rules nobody enforces, and to document the rest honestly. Our guide to sell-side technical due diligence covers how to prepare the evidence.

What Happens to the Answers After Diligence?

Answers become findings. Each finding should be rated by severity, given a remediation cost and timeline, and tied to a deal consequence: a price adjustment, a specific warranty, a closing condition or a task in the first 100 days. Our sample technical due diligence report structure shows how those findings are written up so a deal team can act on them.

For the full methodology, including when a standalone code audit is enough and when you need complete diligence, see our technical due diligence and code audit guide.