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 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: software as a service (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. Check whether critical systems depend on knowledge held by one person, and what happens if that person leaves.

• Who 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 examines current exposure and the incident history that can be evidenced. A bounded diligence exercise cannot establish that a business has never been breached.

• Certifications held and maintained: Cyber Essentials, Cyber Essentials Plus, ISO 27001, and whether they are current or lapsed. The NCSC publishes what Cyber Essentials covers (opens in new tab), and UKAS (opens in new tab) explains what accredited certification means.
• 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.

Data protection and intellectual property conclusions need the deal’s legal advisers as well as technical evidence. The ICO data protection fee guidance (opens in new tab) helps establish the fee position; it is not a general certificate of data protection compliance.

• Where personal and commercial data physically lives, and whether that matches what customers and contracts have been told.
• UK GDPR and Data Protection Act 2018 (opens in new tab) posture: whether the Information Commissioner’s Office (ICO) data protection fee is payable or an exemption applies, 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 intellectual property (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 the team ships software is as important as what it has shipped. 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. Each finding may require remediation, contractual protection, further investigation or acceptance by the buyer, 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.
• A prioritised remediation range for the deal model, with each estimate tied to a finding, assumptions, dependencies and a confidence level.

The custom-software question

Custom software deserves a specific engineering review. A product demo or a broad “needs review” flag does not tell a buyer whether the software is maintainable or what transition will cost. Review code, architecture, dependencies and release practices, and distinguish verified findings from areas where access or evidence was limited.

There are three things to establish, in order.

• What the software is. The architecture, the technology stack, the 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.

Undocumented custom software is not automatically a deal-breaker. Its maintainability, ownership, dependencies and the availability of the people who understand it determine the risk. Provide a cost range with assumptions and confidence levels; some gaps need further investigation before they can be priced reliably.

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 low bus factor, meaning dependence on too few people, that can be improved 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 custom 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, then agree any fuller exercise and whether the first fee can be credited before commissioning it. If you would rather have this run for you, that is our technology due diligence service.