Technology Due Diligence Checklist: What to Check Before You Invest or Acquire

A technology due diligence checklist should cover eight areas of the target's technology function: policies and procedures, data security and privacy, risk management, innovation and strategy, cloud and network, staff and training, technology performance, and vendor management. For each area, ask what is actually in place, request evidence that proves it rather than a description of it, and look for the red flags that turn into cost after the deal closes. The checklist below sets out the questions, the documents and the warning signs for each one.

We wrote about why traditional diligence struggles to keep pace with deals in Why Big 4 Tech Diligence Is Too Slow for Modern Deal Cycles. This is the practical companion: what to check, area by area.

How to use this technology due diligence checklist

Three principles separate diligence that finds things from diligence that confirms what management already said.

Evidence beats assertion. "We have backups" and "we restored from backup last quarter" sound alike in a meeting. Only one of them is a control. For every answer you get, ask what document, log or record would prove it.

Ask the person closest to the work. The CEO's view of technology is usually second-hand. Put the questions to whoever actually runs it.

Scale the depth to the deal. A minority stake in an early-stage company needs a lighter pass than a control acquisition where you will own the platform, the people and the problems. The areas stay the same; the evidence you request changes.

Start with context: what are you actually buying?

Before scoring anything, understand the shape of the business. These questions have no right answers, but they change how you read everything after them.

• Is technology the product, or does it support a product or service delivered some other way?
• How big is the technology function, how is it structured, and who leads it?
• What sensitive data does the business hold, and in which jurisdictions?
• Which regulations, customer contracts or certifications already shape how technology is run?

Evidence to request: an organisation chart for the technology function, a systems inventory, a current architecture diagram and a simple map of where customer data flows.

1. Policies and procedures: are controls written down and followed?

What to ask:

• Which technology policies exist (access, change management, acceptable use, incident response, data retention), and when was each last reviewed?
• How do you know they are followed? What happens when someone joins, changes role or leaves?
• How are changes to production approved and recorded?

Evidence to request: the policy list with owners and review dates, a sample of recent change records, and onboarding and offboarding checklists for the last few people who joined or left.

Red flags:

• Policies dated the week the data room opened.
• Template policies that still name another company or describe tools the business does not use.
• No record of changes to production, or approvals that happen only in chat messages.

2. Data security and privacy: who can reach what?

What to ask:

• Is multi-factor authentication enforced on email, cloud consoles, code repositories and admin tools?
• How often is access reviewed, and is it removed promptly when people leave?
• What security incidents or data breaches have occurred in the last three years, and what was done about them?
• Which breach notification obligations apply? For example, the GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a reportable breach, and Australia has the Notifiable Data Breaches scheme.
• Does the business hold SOC 2, ISO 27001 or similar, and what exactly does it cover?

Evidence to request: the most recent penetration test with the status of each finding, access review records, the incident register, and any SOC 2 report or ISO 27001 certificate together with its scope statement.

Red flags:

• A certification whose scope excludes the product you are buying. Certification shows a standard was met for a defined scope, not that the whole function is healthy.
• Shared admin accounts, or MFA that is optional for administrators.
• Critical penetration test findings that have been open for months.
• A claim of "no incidents, ever". More often that means nothing is being recorded.

3. Risk management: what happens when something breaks?

What to ask:

• Is there a technology risk register, who owns it, and when was it last updated?
• What are the recovery point and recovery time objectives for the critical systems, and who agreed them?
• When was disaster recovery last tested end to end, and what went wrong?
• Are backups held separately from production, so one compromised account cannot delete both?

Evidence to request: the risk register, the business continuity and disaster recovery plans, and the results of the most recent restore or failover test.

Red flags:

• A recovery plan that has never been tested.
• Backups stored in the same cloud account, with the same credentials, as production.
• A risk register that lists generic risks with no owners, dates or actions.
• An incident response plan nobody has rehearsed. A tabletop exercise is a quick way to find out whether the plan works.

4. Innovation and strategy: is technology pulling in the right direction?

What to ask:

• Is there a technology roadmap, and does it connect to the business plan your investment case relies on?
• Where is technical debt concentrated, and what would it cost to address?
• Where is AI used in the product and in operations, what data is sent to which models, and are AI capabilities claimed in sales material actually live?

Evidence to request: the current roadmap, the last two quarters of delivered work against what was planned, and a list of AI tools and models in use with the data each one touches.

Red flags:

• A roadmap that exists only as a slide prepared for the raise or the sale.
• Growth assumptions in the model that need a platform rebuild nobody has costed.
• AI features described to customers or investors that are manual processes behind the scenes.

If AI is central to the investment case, the AI Maturity Assessment covers this area in more depth.

5. Cloud and network: what does the estate consist of, and who controls it?

What to ask:

• Who legally owns the cloud accounts, domains and code repositories? The company, a founder personally, or a development agency?
• What has cloud spend been over the last twelve months, and how has it moved relative to revenue and usage?
• Is infrastructure defined as code, or built by hand in the console?
• Which systems are on software versions that are no longer supported by their vendors?

Evidence to request: twelve months of cloud invoices, the architecture diagram, a list of production environments and accounts with their owners, and a list of end-of-life software in use.

Red flags:

• Cloud accounts or domains registered to an individual or an agency rather than the company.
• One person who understands how production is put together.
• Cloud costs growing faster than revenue with no explanation.
• Unsupported operating systems or databases running customer-facing services.

6. Staff and training: can the team deliver the plan after the deal?

What to ask:

• Who are the people the platform depends on, and what happens if any one of them leaves?
• What is the mix of employees, contractors and outsourced providers, and where are they located?
• What has attrition looked like over the last two years, particularly among senior engineers?
• Is the technology leader the right person for the next stage, or the right person for the last one?

Evidence to request: an anonymised team list with role, tenure, employment type and location, attrition figures, and any retention arrangements for key people.

Red flags:

• Key-person dependency with no documentation or succession.
• A core product built and maintained entirely by an external agency, with no one in-house who understands it.
• A cluster of senior departures in the months before the process started.

7. Technology performance: is it measured, or just assumed?

What to ask:

• What uptime and response-time commitments does the business make to customers, and has it met them?
• How many significant incidents have there been in the last year, and is there a written review for each?
• How often does the team deploy, how often do deployments fail, and how long does recovery take? DORA's software delivery metrics are a useful common language here.

Evidence to request: availability history or status page records, incident post-mortems, any service credits paid under customer contracts, and deployment history from the last six months.

Red flags:

• Performance reported as the absence of complaints.
• Service credits paid to customers that do not appear in the management narrative.

8. Vendor management: what are you inheriting from suppliers?

What to ask:

• Who are the critical suppliers, what does the business spend with each, and when do the contracts renew?
• Do any critical contracts contain change-of-control clauses that let the supplier terminate or renegotiate after the deal?
• Have all contractors and agencies who wrote code assigned their intellectual property to the company?
• Which open source licences are in the codebase? Some copyleft licences carry source-sharing obligations; the AGPL, for example, can require a modified version offered over a network to make its source available to users.

Evidence to request: a supplier list with spend and renewal dates, copies of the critical contracts, IP assignment agreements for contributors, and a dependency licence report from the codebase.

Red flags:

• Change-of-control termination rights in a contract the business cannot operate without.
• Code written by contractors with no IP assignment on file.
• Copyleft-licensed components inside proprietary software with no review of the obligations.
• Heavy dependence on a single supplier with no exit terms.

What to do with the red flags

Not every finding is a deal breaker. Most fall into one of four buckets.

1. Price. Remediation with a known cost, such as replacing end-of-life systems or rebuilding infrastructure the company does not control.
2. Protection. Risks you cannot fully quantify, such as past breaches or open source exposure, which your legal advisers may want to address through warranties, indemnities or conditions.
3. Plan. Gaps that are normal for the company's stage and belong in the first 100 days, such as missing policies or untested recovery.
4. Walk away. Problems that undermine the investment case itself, such as a product that cannot scale to the plan or IP the company does not own.

How to run the checklist without slowing the deal

Most of this checklist does not need an expert in the room. Get a structured baseline from the technology leader first, request evidence only where the baseline shows risk, and bring specialist advisors in for the areas that need judgement. Advisory budget then goes on analysis instead of discovery.

Where StackUp fits

This is the job the StackUp Technology Assessment was built for. It is eighty-four questions across twelve categories of the technology function. Four categories set context, and the other eight are the same areas as the checklist above and carry the score. It is usually completed in one sitting by the person who runs technology, and it is scored by fixed rules, so the same answers always produce the same number out of 100.

For a deal team, that means a consistent baseline across every target and portfolio company, the eight areas opened up to show where the risk sits, and the four priorities worth acting on first.

A baseline is not the end of diligence. Use it to decide where to request evidence and where to point your advisors. The first assessment is free and gives you the score, the eight areas and the four priorities. Paid plans, set out on the pricing page, add the board and investor-ready report, portfolio visibility across companies and tracking between runs; because the scoring never changes, re-running it after the deal shows what actually improved. The For VCs and PE Firms page shows how investors use it.

Preparing a company for investment or sale? The same checklist finds the gaps before a buyer does. See Prepare for Investment or Acquisition.