The Technology Due Diligence Checklist

Step Zero: What to Demand in the LOI

Every experienced seller's counsel advises the same sequence. Give the buyer financials and commercial material early. Hold the technical and security material until the buyer is committed. By the time the LOI is signed, the buyer's leverage has peaked and begun to decline, which means the access terms you get are the access terms you negotiated at the moment you had the most leverage.

Six access provisions belong in the LOI or in the accompanying diligence protocol. None of them are unreasonable, and a seller who refuses all six is telling you something.

1. Read-only source code access, not a prepared demo

This is the single most contested item and the one most worth fighting for. Sellers offer a managed alternative: a curated code walkthrough, a screen-shared tour of the repository led by the CTO, or a vendor-run static analysis with the report shared but not the underlying access.

The difference is not subtle. A prepared demo shows you the code the CTO chose to show you, in the order the CTO chose. Read-only repository access, even time-boxed and supervised, lets your reviewer pull the commit history, look at the dependency manifests, examine the parts of the codebase nobody volunteers, and check whether the test coverage claim survives contact with the test directory.

Workable middle grounds exist. A clean-room arrangement where a named third-party reviewer bound by a confidentiality agreement gets read-only access for a fixed window, delivers findings to the buyer, and does not retain a copy, resolves most legitimate seller concerns. Insist on the substance: history, dependencies, and the ability to look where you choose.

2. Prior penetration test and security assessment reports, unredacted

Specify unredacted, and specify all reports from the trailing thirty-six months rather than the most recent one. A seller producing only the latest report is producing the one after remediation. The prior report is where you find out what the findings were before somebody cleaned up for the process.

3. Incident history with a defined lookback

Ask for a written incident log covering the trailing thirty-six to sixty months, including incidents that did not meet a regulatory notification threshold. The near-misses are the interesting ones. A company that reports zero incidents over five years is either extraordinarily well run, very small, or not detecting anything. The third explanation is the most common.

4. Security telemetry access or export

To answer whether an adversary is present, an assessor needs identity provider logs, endpoint telemetry, and where available SIEM data. Sellers resist this hardest because it feels invasive and because production log access carries its own risk. Negotiate for an export covering a defined window delivered to a named assessor, or read-only access scoped to a specific analyst. Without it, the compromise question cannot be answered and should be recorded in the memo as unanswered rather than quietly assumed.

5. Cloud console read-only access

A read-only role in the production cloud accounts (and in the identity provider) is the highest-information access grant in technology diligence per unit of seller risk. It is non-destructive, fully auditable by the seller, and it replaces a dozen interview questions with observation. Request it for the main production organization and ask explicitly whether accounts exist outside that organization.

6. Direct access to named technical staff without management present

One hour with the lead platform engineer, without the CTO in the room, will tell you more about operational reality than four hours of management presentation. Sellers often permit this late in the process. Ask for it in the LOI and schedule it early.

The Principle That Makes the Checklist Work

For every artifact below, three questions apply in order.

• Does it exist? If not, that is the finding. Record it and move on rather than accepting a promise to produce it later.
• Is it current? An asset inventory last updated nineteen months ago describes a company that no longer exists. Check the modification date and the most recent entry, not just the file name.
• Is it evidence or is it an assertion? A policy stating that backups are tested quarterly is an assertion. A restore test log with dates, durations, and the name of the engineer who ran it is evidence. Most data rooms are full of the first kind and thin on the second.

The third question is the one that separates real diligence from document review. Sort every artifact you receive into assertion or evidence. Then look at the ratio. A data room that is ninety percent assertion is describing a company that has invested in documentation and not in practice, which is the exact profile that produces post-close surprises.

The Checklist by Workstream

Each table gives the artifact, what it genuinely proves, and what its absence tells you. Request everything in one consolidated list rather than in waves, so the seller's response time becomes its own data point.

Workstream 1: Asset and environment

Artifact to request	What it proves	What absence means
Current asset inventory (servers, endpoints, cloud resources, SaaS applications) with owner and data classification	The company knows what it runs and who is accountable for each item	Nothing downstream can be trusted: not patching coverage, not monitoring coverage, not the attack surface estimate
Network and data flow diagrams dated within twelve months	Where regulated or sensitive data actually moves, and which systems touch it	Data classification claims are unverified; segmentation claims cannot be checked
Cloud account and subscription list including non-production and any accounts outside the main organization	The real cloud footprint, including shadow environments	Expect orphaned accounts. Ask who pays the bills and reconcile against the general ledger
Domain and DNS inventory including expiry dates and registrar	Control of the external namespace	Common and consequential. Forgotten subdomains are a standard initial access path
External attack surface report produced by the buyer, not the seller	What an attacker sees today, independent of what the target believes it exposes	Not applicable: you run this yourself. Compare it against the seller's inventory and treat the delta as the finding

The delta between the seller's asset inventory and your own external enumeration is one of the most reliable diagnostic signals in the entire engagement. A small delta indicates a company that knows its estate. A large one indicates that every subsequent claim about coverage is aspirational.

Workstream 2: Identity and access

Artifact to request	What it proves	What absence means
Identity provider configuration export and full list of privileged and administrative accounts	Who can do what, and how many accounts hold standing privilege	Privileged access is uncounted, which means it is unmanaged
Multi-factor authentication coverage report by application and by user population, including service accounts and remote access	Whether MFA is actually enforced or merely available	Assume gaps. Ask specifically about remote access gateways, VPN, and legacy authentication protocols
Joiner, mover, leaver evidence: the last twenty terminations with deprovisioning timestamps	Whether access is actually removed when people leave	Orphaned accounts. Check the identity provider directly against the HR termination list
Named holders of root, domain administrator, code signing certificates, cloud organization owner, and domain registrar credentials	Key person concentration at the point where it is most dangerous	If one name appears on all five, that is a retention package input, not an IT observation
Third-party and vendor access list with scope and review date	Standing external access into the environment	Vendor access is typically the least reviewed and longest lived access in any estate

Identity is where most modern intrusions begin and end. A target with strong perimeter documentation and weak identity hygiene is more exposed than the reverse. Background on the discipline is in What Is Identity and Access Management and What Is Privileged Access Management.

Workstream 3: Security operations and incident history

Artifact to request	What it proves	What absence means
Incident log for the trailing thirty-six to sixty months including sub-threshold events	What has actually happened and how the company responded	A zero-incident claim over five years usually means no detection capability, not no incidents
All penetration test and security assessment reports from the trailing thirty-six months, unredacted, with remediation evidence and retest results	Whether findings were fixed or merely received	Open high-severity findings with no retest is a governance finding, not a technical one
Vulnerability scan output plus patch compliance rates by asset class	Time from disclosure to remediation, which is the number that matters	No measured patch cycle means no accountability for one
Log source inventory and retention periods for the SIEM or logging platform	Whether an investigation is even possible, and how far back	Short retention is the constraint that quietly makes a compromise assessment inconclusive
Detection and response arrangement: in-house team, MDR provider contract, or nothing, with coverage hours	Who is watching, and when	Business-hours-only coverage against adversaries who work weekends is a specific, quantifiable gap
Evidence of current or historical compromise from an independent assessment	Whether you are buying an environment that is already breached	This is the item most often assumed and least often purchased. See What Is a Compromise Assessment

Workstream 4: Product engineering and code

Artifact to request	What it proves	What absence means
Read-only repository access including full commit history	Who wrote the product, over what period, and how concentrated the authorship is	A repository with a shallow history or a single initial commit hides the provenance question entirely
Commit concentration analysis by author over the trailing twenty-four months	Bus factor, measured rather than asserted	Management will describe the team as deep. The commit graph will tell you whether that is true
Dependency manifests for every deployable artifact, plus a generated software bill of materials	What third-party code is actually shipping, including transitive dependencies	A hand-written open source list is a first-level list. The risk lives three levels down. See What Is an SBOM
CI/CD pipeline configuration and deployment frequency data	Engineering velocity and whether deployment is repeatable or heroic	Manual deployment by one person is both a velocity constraint and a key person risk
Contractor and contingent worker agreements covering anyone who committed code, with assignment clauses	Whether the company owns the code the contractors wrote	The single most common source of a broken IP chain in founder-led software companies
Test coverage reports and the actual test suite	Whether the coverage number corresponds to meaningful tests	A stated coverage percentage with no accessible suite is an assertion

Workstream 5: Resilience and recovery

Artifact to request	What it proves	What absence means
Documented recovery point and recovery time objectives by system, approved by the business	What the business has actually committed to	If only IT has seen these numbers, they are IT's aspiration rather than a business commitment. See RPO vs RTO
Restore test records with dates, systems, durations, and the engineer who ran the test	That backups actually restore, at a measured speed	The highest-value absence in the entire checklist. Untested backups fail at the moment of use
Backup immutability and isolation configuration	Whether backups survive an attacker who reaches the backup system	Ransomware operators target backups first. Non-isolated backups are functionally no backups
Most recent tabletop or incident response exercise record with participants and findings	That decision-makers have rehearsed, not just that a plan exists	A plan nobody has exercised is a document, not a capability. See What Is Incident Response
Incident response retainer or named external IR provider	How fast qualified responders can be engaged	No retainer means competing for responders during a widespread event, at surge pricing

Workstream 6: Third party, compliance and contractual

Artifact to request	What it proves	What absence means
Vendor inventory with spend, contract terms, renewal dates, data access scope and integration type	The real third-party surface, on both cost and risk axes	Build this once and use it for both IT and cyber workstreams
SOC 2 Type II or ISO 27001 reports for the target and its material subprocessors, including the full system description	What was in scope, what was carved out, and what exceptions the auditor noted	Read the carve-outs and exceptions, not the cover letter. See What Is SOC 2 Compliance
Customer contracts containing security obligations, audit rights, breach notification windows and uncapped data liability	Contractual exposure that survives close and may be triggered by a pre-close event	Uncapped data liability in a top-ten customer contract is a deal term, not a footnote
Cyber insurance policy, application and any attestations made to the insurer	Coverage limits, exclusions, and whether the attestations are accurate	An inaccurate attestation can void coverage at the moment it is needed. See What Is a Cyber Insurance Attestation
Regulatory correspondence including any open regulator inquiries, consent orders or state attorney general matters	Live regulatory exposure	An open matter the seller did not volunteer changes the reps, the escrow, and sometimes the deal
Open source license inventory resolved to transitive level with copyleft obligations identified	Whether distributed code carries source disclosure obligations	Counsel reviewing agreements is not the same as a scanner walking the dependency tree

How to Score What You Get

Run every response through a four-way classification and report the distribution, not just the findings.

• Produced, current, evidentiary. The healthy case.
• Produced, but assertion only. A policy where you asked for a test record. Downgrade the underlying control to unverified.
• Produced, but stale. Note the age. An artifact more than twelve months old for an operational control is usually not describing current state.
• Not produced. Distinguish refused from does not exist. Press once, then record which one it was. Both are findings, but they are different findings with different remedies.

Present the distribution to the investment committee as a single chart. A target where sixty percent of requested artifacts are assertion-only or absent is not a target with a documentation problem. It is a target whose management has not been measuring the thing you are about to underwrite.

Platform Versus Bolt-On: The Checklist Diverges

Running the same checklist on a $400 million platform and a $12 million tuck-in is a waste of money in one direction and negligence in the other. The questions differ because what you are buying differs.

Platform acquisition

On a platform, the technology is the thesis. It will carry five years of organic growth and a series of bolt-ons layered onto it. The controlling question is not whether the technology works today. It is whether it can absorb what you are about to do to it.

Platform-specific additions to the checklist:

• Multi-tenancy and data isolation architecture. If you will be onboarding acquired customer bases onto this platform, the tenancy model determines whether that is configuration work or a rewrite. Ask for the tenant isolation design and how a single-tenant customer would be migrated.
• Integration capability and API surface. A platform that cannot ingest an acquired company's data or expose its own functionality through documented, versioned APIs will make every bolt-on a manual project.
• Engineering organization scalability. Not just current capability. Can this team absorb thirty engineers in eighteen months? Is there an engineering management layer, or does every decision route through the founder-CTO?
• Cost curve at 3x and 5x volume. Model hosting, licensing and support cost against the growth case explicitly. Per-seat third-party licensing embedded in the product is a margin problem that only appears at scale.
• Security program maturity, not just posture. A platform will be the acquirer of record for security across the portfolio. It needs a program that can extend, which means named ownership, a budget line, and a governance cadence.
• Technical debt quantified with a remediation sequence. Not a list of complaints from the engineering team. A costed, sequenced program tied to the growth milestones it blocks, as described in Quantifying Technical Debt in M&A.

Bolt-on acquisition

On a bolt-on, the technology is usually not the thesis. The customer base, the geography, the product line or the team is. The technology question is narrower and more urgent: what does it cost to integrate this, how long will it take, and what risk does it import into the platform on day one.

Bolt-on specific additions:

• Integration cost and timeline to a named end state. Systems consolidated, systems retired, systems run in parallel and for how long. Parallel running is the cost line that consistently gets underestimated.
• What connects to the platform on day one. The moment you join two networks or federate two identity providers, the weaker environment's risk becomes the stronger environment's risk. Insist on knowing what will be connected, when, and what compensating controls will exist in the interim.
• Contract assignability and change of control. Software licenses, cloud commitments and managed service contracts frequently contain change of control provisions. An assignment consent that requires a renegotiation at list price is a real cost.
• Key person exposure during integration. On a bolt-on the target's technical staff often depart within twelve months. Identify who holds the knowledge required to complete the migration and price their retention specifically.
• Data migration feasibility with a sample. Ask for a sample export in the actual format. Discovering at integration that customer records live in a proprietary schema with no documented export is a six-figure surprise.
• Pre-connection security baseline. A short, non-negotiable list of conditions the bolt-on must meet before any network or identity connection: MFA on remote access and administrative accounts, endpoint detection deployed, no unsupported operating systems on connected segments, and a completed compromise assessment.

That last item is the one sponsors regret skipping. The integration plan and its failure modes are covered in Post-Close Technology Integration, and the mirror-image problem when the target is being separated from a parent is in Carve-Out Technology Separation.

Side by side

Question	Platform	Bolt-on
Primary concern	Can it carry the thesis for five years?	What does integration cost and what risk arrives with it?
Code review depth	Deep. Architecture, quality, ownership, dependencies	Targeted. Ownership and licensing only, unless the product survives
Engineering org	Can it scale and is there a management layer?	Who must be retained through migration, and at what price?
Security requirement	Program maturity that can extend across a portfolio	A pre-connection baseline that must be met before day one
Cost modeling	Run rate at 3x and 5x volume	One-time integration plus parallel running duration
Typical budget share	Largest technology diligence line in the deal	Proportionate, with spend shifted toward integration planning

Sequencing: What to Do in Which Week

On a typical four-week technology diligence window following LOI:

• Before LOI. External attack surface enumeration and credential exposure checks. Both are passive, require no seller cooperation, and can reframe the LOI access negotiation if they surface something.
• Week one. Issue the consolidated artifact request. Begin cloud console and identity provider observation. Book the technical staff interviews.
• Week two. Code access and dependency analysis. Incident and pen test history review. Start the compromise assessment, because telemetry collection and analysis has the longest lead time of anything in the program.
• Week three. Interviews without management present. Chase the gaps. Begin costing findings.
• Week four. Convert findings to deal language and deliver. Every material finding carries a cost, a timeline, an owner, and a recommended instrument.

The common sequencing error is starting the compromise assessment last because it is the hardest access to negotiate. Start it first for exactly that reason.

Related Reading

• Technology Due Diligence: The Complete Guide
• Tech DD vs IT DD vs Cyber DD: Where the Boundaries Sit
• Technology Due Diligence Red Flags That Kill Deals
• The Technology Due Diligence Report
• What Is M&A Cyber Due Diligence
• What Is Third-Party Risk Management

Frequently Asked Questions

What should a technology due diligence checklist actually contain?

Named artifacts, not categories. For each item it should state the specific document or data export to request, what that artifact genuinely proves (usually narrower than its title suggests), and what it means if the target cannot produce it. Organize by workstream: asset and environment, identity and access, security operations and incident history, product engineering and code, resilience and recovery, and third-party and contractual. A checklist that says review cybersecurity produces a vague data room request and a report that grades whatever the seller chose to provide. A checklist that says produce an MFA coverage report by application and user population forces an enumeration, and enumerations produce exception lists.

Why does the absence of a document count as a finding?

Because operational artifacts are byproducts of the operations themselves. A company running a real backup program generates restore test records without trying. A company managing its estate maintains an asset inventory because it needs one to patch. When those artifacts do not exist, the underlying activity generally does not either. Treat absence as a substantive finding with a remediation cost and a timeline attached, not as an open item to clean up after signing. Distinguish refused from does not exist, press once, and record which it was. They are different findings with different remedies and different implications for management quality.

What technology access should I negotiate into the LOI?

Six provisions: read-only source code access rather than a prepared walkthrough, all penetration test and security assessment reports from the trailing thirty-six months unredacted, a written incident log covering thirty-six to sixty months including sub-threshold events, security telemetry access or a defined export for compromise assessment, read-only cloud console and identity provider access, and direct interviews with named technical staff without management present. Sellers withhold these until an LOI is signed, which is why the LOI is a diligence instrument and not only a price instrument. Access you did not negotiate at peak leverage is access you will spend half your diligence window fighting for.

How is a platform checklist different from a bolt-on checklist?

On a platform the technology is the thesis, so the question is whether it can carry five years of growth and a series of bolt-ons. That adds multi-tenancy and data isolation architecture, API and integration capability, engineering organization scalability, cost curve modeling at 3x and 5x volume, and a costed technical debt remediation sequence. On a bolt-on the technology is usually not the thesis, so the question is integration cost, timeline, and imported risk. That adds contract assignability and change of control review, data migration feasibility tested with an actual sample export, key person retention through migration, and a pre-connection security baseline the target must meet before any network or identity link.

Should I accept a code walkthrough instead of repository access?

Only as a fallback, and record the limitation in the report. A prepared walkthrough shows the code the CTO selected, in the order chosen. Read-only repository access lets your reviewer pull commit history to measure authorship concentration, examine dependency manifests for transitive open source and licensing obligations, inspect the parts of the codebase nobody volunteers, and verify that a stated test coverage figure corresponds to a real test suite. A clean-room arrangement resolves most legitimate seller concerns: a named third-party reviewer under confidentiality gets read-only access for a fixed window, reports findings to the buyer, and retains no copy.

Which single artifact reveals the most?

The restore test record, narrowly ahead of the MFA coverage report. A restore test log with dates, systems, durations and the name of the engineer who ran it proves that backups actually restore and at what speed, which converts a stated recovery time objective from a policy number into a measured one. Its absence is the highest-value gap in the checklist because untested backups fail at the exact moment they are needed, and ransomware operators target backup systems first. Close behind it, the delta between the seller's asset inventory and your own external enumeration is the most reliable single diagnostic of whether the company knows what it runs.

How long does technology due diligence take and when should each piece start?

A typical mid-market window is four weeks after LOI. External attack surface enumeration and credential exposure work should run before the LOI, since both are passive and need no seller cooperation. Week one is the consolidated artifact request plus cloud and identity observation. Week two is code and dependency analysis and, critically, the start of the compromise assessment, because telemetry collection and analysis has the longest lead time in the program. Week three is staff interviews without management present and gap chasing. Week four is conversion of findings into deal language. The usual sequencing error is starting the compromise assessment last because the access is hardest to obtain.

What if the seller refuses most of the checklist?

Refusal is data. Distinguish categories: some refusals are reasonable (live penetration testing during an active process, unrestricted production log access), and some are not (declining to confirm whether any regulator matter is open, or refusing any form of code access on a software acquisition). Respond by converting the unanswerable into deal terms. Unverified items become specific indemnities, escrow amounts sized to the plausible remediation cost, or closing conditions requiring the seller to produce evidence before funding. Record every unanswered item explicitly in the investment committee memo. A known unknown priced into the structure is a manageable position. An assumed answer is not.

Change Healthcare: One Missing Control, Sixteen Months After Close

UnitedHealth Group's Optum unit completed its acquisition of Change Healthcare in October 2022, after a Department of Justice antitrust challenge delayed the roughly $13 billion transaction by more than a year.

On February 21, 2024, roughly sixteen months after close, Change Healthcare was hit with ransomware attributed to the ALPHV/BlackCat group. The attack took down claims processing, eligibility checks and payment infrastructure that a large share of the United States healthcare system depends on. Providers went weeks without reimbursement. UnitedHealth extended billions of dollars in advance funding to keep practices operating.

In testimony to the Senate Finance Committee and the House Energy and Commerce Committee in May 2024, UnitedHealth Group CEO Andrew Witty described the initial access: attackers used compromised credentials to log into a Citrix remote access portal in the Change Healthcare environment that did not have multi-factor authentication enabled. Witty testified that the company was still working to determine why MFA was not enabled on that server. UnitedHealth confirmed it paid a ransom of approximately $22 million. The company subsequently reported total cyberattack impacts of roughly $3.1 billion for full-year 2024, and in January 2025 confirmed that approximately 190 million individuals were affected, making it the largest healthcare data breach ever reported in the United States.

Now read that against the checklist above. Workstream 2, row two: multi-factor authentication coverage report by application and by user population, including service accounts and remote access. The artifact is specific for a reason. A general question (do you have MFA?) gets a yes, because the company does have MFA, on most things. A coverage report by application and user population forces an enumeration, and an enumeration produces the exception list. The exception list is where a remote access server with no MFA appears.

Two points a sponsor should take from this, and one caution.

The first point: the highest-consequence findings in technology diligence are almost never architectural. They are single missing controls on specific systems, invisible to a policy review and visible only to an enumeration. A security policy stating that MFA is required is an assertion. A coverage report showing ninety-four percent enforcement and naming the remaining six percent is evidence, and the value is entirely in the six percent.

The second: integration timelines create the exposure window. A newly acquired environment that has not yet been brought onto the acquirer's identity architecture, endpoint tooling and monitoring runs on its own controls for as long as that takes. That is precisely the pre-connection baseline problem described in the bolt-on section. The question is not whether the acquirer's security program is strong. It is what the acquired environment is running on until the integration reaches it.

The caution: this is a published account of a single incident at one of the largest healthcare transactions on record, and no public reporting establishes what the original 2021 to 2022 diligence did or did not examine. The lesson is not that anyone was negligent. It is structural. A control gap of this kind is findable only by an artifact request specific enough to force an enumeration, and it remains findable for as long as the acquired environment runs separately.