Technology due diligence checklist (UK)

How to use this checklist

This is a working checklist, not a compliance form. You will rarely get clean answers to every point, and missing answers are themselves a finding. Treat each area as a line of questioning: what you are told, what you can verify, and what the gap between the two implies for risk and cost. The aim is not a pass or fail. It is a clear picture of what you are buying, what it will take to run it safely after completion, and which of those numbers belong in the deal model rather than in a nasty surprise during the first 100 days.

1. The estate and who owns it

Before anything else, establish what technology exists and whether the target genuinely controls it. Ownership gaps are common in owner-managed businesses and they become the buyer's problem on day one.

• Full inventory of infrastructure: servers, cloud accounts, hosting, networking, and where each is physically located.
• Who holds the root and admin credentials for every cloud account (AWS, Azure, Microsoft 365, Google) and whether they transfer with the deal.
• Domain names and DNS: registered to the company, not to a founder's personal account or a former agency.
• Software licences: what is owned, what is subscribed, what is per-seat, and whether licences are assignable on a change of control.
• Owned vs leased vs personal: hardware, mobile devices, and any system running on an individual's personal account or kit.
• Shadow IT: tools bought on expenses or personal cards that the business depends on but nobody formally manages.
• Third-party dependencies: SaaS platforms, APIs, and hosting the product cannot function without, and the commercial terms behind them.

2. People and key-person risk

Technology is only as transferable as the knowledge that runs it. The single most common finding in owner-managed targets is that critical systems live in one person's head.

• Who actually understands each core system, and whether that knowledge is documented anywhere.
• Bus-factor on custom or business-critical systems: how many people could keep it running if the key person left the week after completion.
• Reliance on named individuals: founders, a single senior developer, or one long-serving engineer holding undocumented context.
• Reliance on a single external contractor or agency, especially one with no formal contract or handover materials.
• State of documentation: architecture notes, runbooks, credentials records, and onboarding materials, versus tribal knowledge.
• Retention risk: which of these people are staying, on what terms, and what happens to the technology if they do not.

3. Security and certification posture

Security due diligence is not a tick-box exercise on certificates. It is an assessment of whether the target is currently exposed and whether it has ever been breached.

• Certifications held and genuinely maintained: Cyber Essentials, Cyber Essentials Plus, ISO 27001, and whether they are current or lapsed.
• Multi-factor authentication: enforced across all cloud services and admin accounts, or optional and patchy.
• Patching and supported software: whether critical updates are applied promptly and whether any end-of-life operating systems or applications are still in use.
• Backups: what is backed up, how often, whether restores have ever been tested, and whether backups are isolated from ransomware.
• Breach and incident history: any past compromises, data loss, or near-misses, and how they were handled.
• Externally exposed services: open ports, exposed admin interfaces, and anything internet-facing that should not be.
• Incident response: whether there is a plan, who would run it, and whether anyone would notice an intrusion in the first place.

4. AI and data exposure

Data and AI exposure has become a distinct area of diligence, and it is one where owner-managed businesses have often accumulated risk without realising it.

• Where personal and commercial data physically lives, and whether that matches what customers and contracts have been told.
• UK GDPR and Data Protection Act posture: ICO registration, lawful basis, retention, and any subject-access or breach history.
• Use of AI tools across the business, and whether staff are pasting customer data, code, or IP into third-party models.
• Whether company or customer data is flowing into external AI services under terms that allow it to be retained or used for training.
• IP ownership of AI-generated assets: code, content, and designs produced with AI tools, and whether the business can clearly own and defend them.
• Data-sharing arrangements with third parties, sub-processors, and any offshore processing.

5. The delivery record

For any target that builds its own software or ships a digital product, how it delivers is as important as what it has delivered. This is where technical debt hides.

• How software is built and released: version control, code review, and whether there is a repeatable deployment process or manual heroics.
• Test coverage: whether automated tests exist, what they cover, and whether the team can change the system with confidence.
• Deployment maturity: how long a release takes, how often it fails, and how quickly a broken release can be rolled back.
• Technical debt: known shortcuts, ageing frameworks, and areas of the codebase the team is afraid to touch.
• Documentation of the codebase itself, versus code that only its author understands.
• Whether parts of the system are effectively undocumented or "vibe-coded": assembled quickly, including with AI assistance, without a maintainable structure behind them.

6. The cost runway

Finally, translate the findings into money. Every real risk above is either a remediation line item or a reason to reprice, and the buyer needs the numbers before completion, not after.

• End-of-life software and hardware that must be replaced on a known timeline.
• Licensing non-compliance exposure: under-licensed software or per-seat overuse that a vendor audit could turn into a bill.
• Integration cost: what it takes to fold the target into the buyer's environment, or to stand it up independently from the seller's.
• Immediate remediation: the security, backup, and access fixes that cannot wait past the first weeks of ownership.
• Ongoing run cost: the realistic annual cost of keeping the estate supported, secure, and licensed.
• The single remediation estimate that belongs in the deal model, with each number attached to a specific finding so it can be defended in the investment committee.

The custom-software question

This is the hardest part of technology due diligence and the one most reports get wrong. A target with significant bespoke software often gets waved through with a vague "custom platform, needs review" or, worse, flagged as an unquantified red flag that spooks the deal. Neither is useful. Custom software is a measurable, priceable question, and answering it properly is what turns a target that looks unacquirable into one you can confidently buy.

There are three things to establish, in order.

• What the software actually is. The architecture, the technology stack, the real state of code quality, and how much of it is documented. You cannot judge risk on a demo. You have to look at what is under it.
• Whether it is maintainable. Is it built on mainstream, supported frameworks that other engineers can pick up, or on something exotic that only the original author understands? How deep is the key-person dependency, and is a supported takeover feasible, whether by the buyer's team, an in-house hire, or a managed partner?
• What it costs to keep, wrap, or replace. Every custom system has three futures: keep it and support it as-is, wrap it in a supportable framework and documentation so it can be maintained safely, or plan to replace it over a defined period. Each has a number. Putting those numbers on the table is the entire job.

The message deal teams need to hear is this: undocumented custom software is not automatically a red flag. Plenty of good businesses run on software their founder built and never wrote down. That is a known, bounded problem with a known cost to fix. What kills deals is leaving it unquantified. Quantify it, and you often find the "risky" target is perfectly acquirable at a price that reflects the remediation.

Red flags vs deal-breakers

Not every finding threatens the deal. The skill in technology due diligence is separating what is a remediation line item from what is a genuine reason to walk or seriously reprice.

Usually remediation line items (cost, not catastrophe):

• Missing MFA, weak patching, or untested backups.
• End-of-life software on a replaceable timeline.
• Undocumented custom software with a maintainable stack.
• A high bus-factor that can be reduced with hiring and documentation.
• Licensing tidy-ups.

Potential deal-breakers (repricing or walk-away territory):

• An unresolved or undisclosed breach, especially involving personal data.
• Core IP or a critical domain the company does not actually own.
• A product built on an unmaintainable stack with a single departing author and no feasible takeover.
• Data or AI practices that create material regulatory liability.
• A technical debt and re-platform cost that exceeds the deal thesis.

The point of the checklist is to make sure a genuine deal-breaker is found before completion, and that everything else is priced rather than feared.

When to run a Deal Scan vs a full Technical DD

You do not always need a full technology due diligence exercise. The right depth depends on deal size, timing, and how much of the risk sits in technology.

• A Deal Scan is a fast red-flag screen, run in a few days. Use it early, when you want to know whether the technology holds any deal-threatening surprises before you commit real diligence budget, or on smaller deals where a full exercise is not proportionate. It answers "is there anything here that should stop us?"
• A full Technical DD is the complete exercise across all six areas, including a proper look at any custom software. Use it once a deal is progressing, when technology is central to the thesis, when there is meaningful bespoke software, or when the investment committee needs a defensible report. It answers "exactly what are we buying, and what will it cost to run?"

A sensible pattern is to start with a Deal Scan and let it credit against the fuller exercise if the deal proceeds, so early screening is never wasted spend. If you would rather have this run for you, that is our technology due diligence service.