Technology due diligence: a checklist and when to bring in an outside expert

Technology due diligence checks whether a company's software, infrastructure, security and engineering team can support the plan behind an acquisition or investment. The questions are practical. Does the product work the way the sales deck says? What will it cost to keep running and to scale? What security, licensing or staffing problems come with it? And how much of the knowledge sits in one or two people's heads?

You can cover a lot of it with a structured request list and a few hours of conversations with the engineering team. You need an outside technical expert when the technology is the main reason for the deal, when nobody on your side has built something similar, or when the findings will change the price.

A worked example: a small B2B software company

Suppose you are investing in a company that sells scheduling software to clinics, with 12 engineers and a product that has run on the same codebase for six years. The company and details are hypothetical. The seller says the platform can handle five times today's customers without a rebuild, that security is "SOC 2 compliant" and that the team is stable. Each claim maps to a section below.

The technology due diligence checklist

Architecture and scale

• A current diagram of the system: services, databases, third-party dependencies and where each runs
• Hosting costs by month for the last year, and what drives them
• Load today versus the claimed headroom, and what broke the last time traffic spiked
• Single points of failure, and any core technology near end of life. U.S. banking regulators' vendor guidance lists "end of life issues with the software programming language, computer platform, or data storage technologies" as a resilience risk worth checking. Interagency Guidance on Third-Party Relationships

Code and delivery

• Read access to the main repositories, or a supervised walkthrough if the seller will not grant access before signing
• How changes get from a laptop to production: tests, reviews, deployment and rollback
• A list of known technical debt, and the team's own estimate of what it would cost to fix
• Which parts of the code only one person understands

Security

• Results of recent penetration tests and vulnerability scans, and what was fixed afterward
• Access controls: multi-factor authentication, encryption and how source code access is managed. The same regulators' guidance names these as items to check. Interagency guidance
• How the team finds and responds to vulnerabilities after release. NIST's Secure Software Development Framework groups secure development practices into four areas: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities. It is useful vocabulary for your questions, and NIST says it is not meant to be a checklist to follow. NIST SSDF
• Any SOC report, read in full. SOC 2 reports cover controls relevant to security, availability, processing integrity, confidentiality or privacy, and they are issued by CPAs. AICPA SOC suite Check which systems and time period the report covers and what exceptions it lists. The AICPA's page currently carries a notice that it is looking into allegations about the practices of one SOC compliance vendor, which is one more reason to read the report rather than rely on a badge.

Open source and licenses

• A software bill of materials (SBOM). CISA describes an SBOM as a nested inventory, "a list of ingredients that make up software components." CISA SBOM
• The licenses of those components. The SPDX License List gives standard short identifiers for common open-source licenses, which makes an inventory easier to scan. SPDX License List Ask your attorney to review any licenses that place obligations on how you distribute the software.

Data

• What personal or sensitive data the product stores, where and for how long
• Backups, and when a restore was last tested

Team

• Who the key engineers are, how long they have been there and what would happen if one left
• Hiring plans that the growth case assumes, and whether they are realistic

When to bring in an outside technical expert

Bring in outside help when any of these is true:

• The technology is the thesis. If you are paying for a proprietary system, the value depends on it being as good and as defensible as claimed.
• Nobody on your side has built something similar. A deal team can read a diagram, but judging whether a six-year-old scheduling engine can scale five times over takes someone who has done that work.
• The domain is specialized. Payments, healthcare data, machine learning systems and embedded hardware each have failure modes a generalist may miss.
• A finding would change the price. If a rebuild might be needed, get an estimate from someone independent of the seller.

There are two common ways to get that help:

1. A full review. A specialist firm or senior engineer reviews the code and systems under a confidentiality agreement with the seller's permission. This is the thorough option and takes the most time.
2. Short calls with practitioners. Before or alongside a full review, talk to engineers and IT leaders who have run similar systems. Ask them what usually goes wrong at this scale, how long a migration like the one proposed tends to take and which questions to put to the seller's team. Do not share the seller's confidential materials on these calls unless the seller has agreed.

For the second option, how to choose the right expert covers matching someone's experience to your question. If you need someone to stay involved after the deal, a fractional CIO is another route.

Record findings the deal team can use

Summarize each area as a short list: what you checked, what you found, what it would cost to fix, and what you could not check. "Two services run on a database version past vendor support; upgrade estimated at six to eight engineer-weeks by the team, not yet reviewed independently" is useful. "Some technical debt" is not.

Technology findings feed into the wider due diligence checklist, and vendors the product depends on belong in vendor due diligence.

Your next step

Send the seller the request list above, trimmed to the claims your price depends on. Write down which of those claims you are not qualified to judge.

For short calls, Instant Expert finds people who match a description, such as "engineering leads who have scaled a B2B scheduling product." You review who it finds, it sends your invitations, and you pay only for calls that get booked. The directory pages for engineering professionals in enterprise SaaS and IT professionals in cybersecurity are a place to start.