Technology Due Diligence in M&A: Scope, Evidence, and Deal Impact

Technology due diligence in M&A tests whether a target’s technology can support your deal thesis, operate safely from the day you close, and reach your post-close plan at a cost and risk you know before you sign. It covers the product and code, the IT that runs the business, cybersecurity, data and privacy, open source and software licenses, key technical people, critical vendors, and what it will take to integrate or separate the business.

It isn’t a generic checklist, or a scan that “passes” the company. The useful version works in five steps, in the order you’ll use them:

1. Scope the review to your thesis and to how much the business depends on its technology.
2. Gather evidence and grade how much weight each piece can bear.
3. Prioritize findings by likelihood and business impact.
4. Estimate remediation, with a stated method.
5. Assign deal and Day 1 actions: price, escrow, conditions, covenants, and who fixes what after closing.

Three neighboring topics get a pointer, not a section. For a content site or online store where the question is traffic, SEO, monetization or domain transfer, see The Ultimate Guide to Website Due Diligence. Legal conclusions about contracts, IP ownership and liability belong to counsel; see The Essentials of Legal Due Diligence. For how technology fits with the financial, legal and operational workstreams, see M&A Due Diligence: Process, Checklist & Workstreams.

What technology due diligence covers: five different jobs

“Tech diligence” is used for at least five kinds of work. They need different skills, evidence and often providers, so separate them from the start:

• Operational IT: the systems that run the business, such as email, user accounts, laptops, networks, accounting and ERP software, backups, and often a managed service provider (MSP) that runs them.
• Software, product and engineering: for companies that build technology, the architecture, code, development process, reliability, scalability and roadmap.
• Cybersecurity: how the company governs, protects, detects, responds to and recovers from attacks, and what incidents it has had.
• Data, privacy and AI: what data it holds, what it promised the people it came from, which rules apply, and whether AI features rest on data and models it has the right to use.
• Integration or separation: what it takes to connect the target to your systems or pull it out of a parent, and what must work on Day 1.

A traditional services business may need only the first and third in any depth. A software company needs all five. Lumping them into one “IT review” is how buyers end up with a network assessment of a company whose real value, and risk, sits in its code.

Step 1: How to scope technology due diligence in M&A

Start with the investment thesis, not a checklist, and ask two questions:

1. What does the thesis need the technology to do? Keep running as is? Scale to three times the customers? Integrate into your platform? Stand alone after a carve-out?
2. How dependent is the business on its technology? A technology-dependent target sells technology or can’t deliver without proprietary systems: software, data products, many ecommerce businesses. A technology-enabled target uses mostly off-the-shelf tools to deliver a non-technology service, like an accounting firm or distributor.

The more dependent the business, and the more the thesis asks of its technology, the deeper the review and the more it needs independent testing rather than documents.

From DueDilio’s experience matching buyers with providers: on our calls, buyers of software and tech-enabled businesses often say they don’t know what to ask for or how to scope a technology review, which is why this guide starts with a router rather than a single list.

Scope router

Pick the row that matches the target, then add any overlay. A healthcare SaaS company takes the software row plus the regulated row.

Depth means evidence, not page count: a short review that reads the actual cloud configuration beats a long one built from questionnaires. And if early evidence turns up something serious, like an undisclosed incident, widen the scope.

Sequence the work to what you can actually get

Sellers release technology information in stages, for rational reasons: source code and security weaknesses are among a company’s most sensitive information, the buyer might be a competitor, and every finding becomes a negotiating point. Plan around what you’ll realistically see:

1. Before the letter of intent (LOI): a management presentation, an architecture overview, a systems list and screening answers. Use them to pick your router row and flag deal-breakers.
2. In the LOI: write in the access you’ll need, including read-only access to key systems, interviews with technical leads (not only the CEO), permission for independent testing, and enough exclusivity time to do it. These rights are much harder to win later.
3. After the LOI, before signing: the main window for documents, interviews, read-only access, scans and code review. For very sensitive code, a common compromise is an independent third-party reviewer who reports findings without handing over the code.
4. Between signing and closing: confirm nothing material changed, consents are in hand and pre-closing fixes were done.
5. Day 1 and after: move remaining findings into an owned, costed plan.

If the budget is small: the floor

A traditional small business may not justify a specialist review, but “less depth” still has a floor. After the LOI and before closing, get at least these, shown to you on a screen share rather than described, so you’re looking at the live settings instead of taking someone’s word:

• MFA: whether it’s enforced on email, admin and remote access.
• Backups: where they’re kept, whether a copy sits off the main network, and the date and result of the last test restore.
• Control of accounts: who holds admin rights, the domain registration and the backups (more on this under cloud and IT below).
• Updates: whether systems, and especially internet-facing devices, are patched.

CISA’s Cross-Sector Cybersecurity Performance Goals (see cybersecurity below) make a sensible question list for the rest. If you can pay for a few hours of an independent IT or security generalist, spend them on these items, not a broad questionnaire. Anything you can’t verify goes into the Step 5 triage like any other finding.

Step 2: Gather evidence, and grade how much it proves

Weak technology reviews usually fail here: they treat a policy document, a CTO’s reassurance and a test result as equal. They aren’t.

A finding that will change price or terms should rest on grade 3 or 4 evidence. Grades 1 and 2 are fine for items you’ll only monitor.

The grading matters because of incentives. Management isn’t necessarily hiding anything, but the people answering often have earnouts, rollover equity or job offers riding on the deal. Diagrams tend to show the system as designed, not as it runs, and questionnaires are self-assessments. That doesn’t make the evidence useless; it limits the weight it can carry.

What certifications and reports actually prove

Certifications are strong grade 2 evidence, but only within their stated scope:

• ISO/IEC 27001 certifies an organization’s information security management system (ISMS), and a certificate covers a stated scope. Read the scope statement to confirm it includes the product and systems you’re buying, not just a head office or one team.
• SOC 2 is a CPA firm’s attestation against the AICPA’s Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. Check the report type, whether the auditor tested how controls operated over a period or only looked at their design as of one date, which criteria and systems were covered, and any exceptions noted.
• Penetration tests and scans are point-in-time results for a stated scope. Last year’s clean external scan says nothing about the internal network or code shipped since.

Sellers lead with certifications because customers already required them. Use them to narrow your questions, not skip them.

First request list

After the LOI, a request like this covers most router rows. Trim it to your scope.

☐ Systems and application inventory, with owners and hosting location

☐ Current architecture and data-flow diagrams, noting what’s out of date

☐ Read-only access to the cloud console, identity provider, code repositories and ticketing

☐ Last 12 months of cloud and software bills

☐ Security policies, incident log and reports, and cyber insurance policy and claims history

☐ Certifications and test reports (with scope) and their remediation status

☐ Disaster recovery plan, stated recovery objectives and the last restore test

☐ Data inventory, privacy notices and customer data-processing terms

☐ Open-source inventory or software bill of materials (SBOM), if one exists

☐ Critical vendor, MSP and customer contracts with technical commitments

☐ Engineering and IT org chart, including contractors, plus the roadmap and features promised to customers

The list isn’t proof. What comes back, and how fast, is the evidence.

For regulated targets, sort out access first. If the target is a HIPAA covered entity or business associate, HIPAA’s definition of “health care operations” expressly includes due diligence related to a sale, transfer or merger, and a Business Associate Agreement is required before protected health information is shared with a provider acting as a business associate.

What to examine in each technology workstream

Use step 2’s evidence here, and go only as deep as your router row calls for.

Product, architecture and roadmap

Software due diligence in M&A starts with whether the product can do what the thesis needs: how it’s built, where it breaks under load, how reliable it has been, and what scaling would take.

Technical debt means shortcuts in code or architecture that make future change slower or riskier. Every product has some; what matters is whether it blocks the roadmap and what fixing it costs. There’s no standard score for it, so be wary of reports that give one.

Compare the roadmap with engineering capacity and with customer commitments: features, integrations or uptime promised in contracts or sales conversations. Sales teams promise things to close deals, and those promises become your obligations. Product analytics, showing which features customers actually use, can confirm or undercut the growth story.

Code and engineering

Technical due diligence in an acquisition usually includes a repository review, through read-only access or an independent reviewer. Look at:

• who wrote and maintains each part, including contractors
• the software development life cycle (SDLC): code review, testing and release, including automated build and deployment (CI/CD)
• test coverage and how often releases break things
• documentation a new team could use
• third-party dependencies and how out of date they are
• application security

The OWASP Top 10 (2025 edition) is a widely used reference for web application risks such as broken access control, security misconfiguration, software supply chain failures and injection. Checking those categories tells you more than line or commit counts, which say little about quality or productivity and are easy to game.

Cloud, infrastructure and IT operations

An IT due diligence checklist typically covers identity and access (who has admin rights, whether MFA is enforced), endpoints, networks, backups, monitoring, service levels and cost. The checklist tells you where to look; configuration evidence tells you what’s there.

For disaster recovery, ask for stated objectives per critical system. NIST defines the recovery time objective (RTO) as how long a system can be in recovery before it harms the organization’s mission or business processes, and the recovery point objective (RPO) as the point in time to which data must be recovered after an outage. Compare those with the last restore test.

For cloud-hosted businesses, reconcile the cloud bill with the financials. Ask what drives cost, whether it grows faster than revenue, and whether committed-spend contracts run past closing. Hosting cost that scales badly is a margin problem, not just a technical one.

In smaller companies, check who holds the keys: whether an MSP, a former employee, a contractor or the owner’s personal email controls admin accounts, domain registration or backups. If so, that’s a Day 1 risk however good the rest looks.

Cybersecurity

Cybersecurity due diligence in M&A is one workstream within technology diligence, but often the one with the most immediate downside. The NIST Cybersecurity Framework (CSF) 2.0 is a useful frame: the framework document (NIST CSWP 29) groups outcomes into six functions (Govern, Identify, Protect, Detect, Respond and Recover), which pushes the review past tools to who owns cyber risk and whether the company can recover. For smaller targets, CISA’s Cross-Sector Cybersecurity Performance Goals give a practical baseline mapped to the same six functions.

Cover at least:

• Governance and identity: who owns security, a current inventory of systems and accounts, and MFA on email, admin and remote access.
• Vulnerabilities: how fast patches go in, and whether internet-facing systems have unpatched vulnerabilities that appear in CISA’s Known Exploited Vulnerabilities (KEV) catalog of flaws known to be exploited in the wild.
• Ransomware resilience: CISA’s #StopRansomware guidance recommends regular vulnerability scanning (especially of internet-facing systems), patch management, offline encrypted backups tested regularly, and a defined incident response and reporting path.
• Incidents and response: past incidents, how they were handled, who was notified, what’s still open, and whether logs and a tested response plan exist. Ask directly and get answers in writing.
• Third parties and insurance: which vendors can reach systems or data, and the cyber policy’s coverage, exclusions and claims history.
• Testing scope: exactly what past or planned tests covered, and what they didn’t.

Some regimes apply only to certain targets. Non-bank “financial institutions” such as mortgage brokers, finance companies, collection agencies and tax preparers fall under the FTC Safeguards Rule, which added a breach-reporting requirement effective May 2024. If the seller or parent is a public company, SEC rules require it to determine without unreasonable delay whether a cybersecurity incident is material and, if so, disclose it within four business days of that determination. How these apply to your deal is a question for counsel.

Data, privacy and AI

Start with a data map: what personal and business data the company collects, where it’s stored, who it’s shared with, how long it’s kept and how reliable it is. Then check what the company promised, because privacy promises can follow the data. In the FTC’s Toysmart case, customer data sold as an asset in bankruptcy stayed subject to the seller’s original privacy promises. A list collected under “we’ll never share your data” may not be usable the way your thesis assumes.

State rules vary; California’s are a common reference point. The California Consumer Privacy Act (CCPA) has an exception for personal information transferred as an asset in a merger or acquisition, as long as the buyer keeps using it consistently with the law (Cal. Civ. Code §1798.140(ad)(2)(C)). Treat that exception and the Toysmart point as flags for counsel: whether a given transfer qualifies, and what old promises allow, are legal determinations. Your technology team’s part is to document what the company promised the people its data came from and how the data is actually used. CCPA’s exemptions for business-to-business and employee data expired at the end of 2022, so those records are covered too. If the target sells data about people it has no direct relationship with, check whether it belongs on California’s data broker registry. Health data brings in HIPAA; NIST SP 800-66 Rev. 2 is NIST’s current implementation guide for the HIPAA Security Rule.

For AI features, ask which models are used and whose they are, what data trained or tuned them, whether customer contracts and privacy notices allowed that use, and whether AI output drives decisions about people. Rules here are changing and vary by jurisdiction, so treat anything material as a question for specialists and counsel.

IP, open source and licenses

The technology question is what’s in the code and under what terms. Whether the company owns or may use it is a legal conclusion, so coordinate with counsel.

Open-source components are normal; their license terms are what matter. The SPDX License List gives standard identifiers and official texts for open-source licenses, so a scan can say exactly what it found. Two distinctions come up constantly:

• GPL-3.0 requires anyone who distributes a covered program in object-code form to also convey the corresponding source code (license text).
• AGPL-3.0 goes further: if a modified program is offered to users over a network, as in a SaaS product, those users must be offered its source code, even though nothing is “distributed” in the traditional sense (license text, §13).

That’s why modified AGPL code in a hosted product is a specialist trigger in the router. A software bill of materials (SBOM), an inventory of the components in a piece of software, speeds this review up. NTIA published its minimum elements for an SBOM on July 12, 2021, under Executive Order 14028, and CISA now hosts SBOM resources. If the target doesn’t have one, an independent open-source scan can build the inventory.

Also check that contractors and former employees who wrote code signed IP assignments, which commercial software licenses restrict assignment or change of control, and whether customer contracts limit how the code or data can be used. Your attorney decides what those documents mean.

People and key-person risk

In many smaller technology companies, one or two people understand the system. Map who holds critical knowledge, who could back them up, reliance on contractors or offshore teams (and who holds those contracts), and open roles.

Then look at incentives. Key engineers who get nothing from the sale, or whose equity pays out at closing, have little reason to stay. Retention terms and documentation written before closing are usually cheaper than rebuilding knowledge after someone leaves. Treat productivity metrics with care: they’re easy to misread and rarely show who is essential.

Vendors, MSPs and concentration

NIST’s CSF 2.0 gives cybersecurity supply chain risk management its own category under Govern, a reminder that a target’s risk includes its vendors’. For each critical vendor, check term and renewal, SLAs, security terms, cost, whether the contract needs consent on a change of control, and how hard it would be to leave.

MSPs deserve special attention in smaller deals: an MSP often holds the keys described under cloud and IT above, and it naturally wants to keep the contract after closing. Make the handover a closing deliverable whether or not you keep it.

Integration, separation and transition services

Plan what must work on Day 1: identity and email, network access, customer-facing data, billing, and controls that stop the wrong people from having access.

In a carve-out, the business may run on the parent’s systems for a while under a transition services agreement (TSA), a contract in which the seller keeps providing specific services for a fee and a limited time. Check each service’s term, cost and exit plan, which licenses and contracts sit in the parent’s name, and stranded costs: costs left behind after separation with no business to support them. One-time integration or separation cost belongs in the deal model, not in the first-year budget as a surprise.

Step 3: Prioritize findings with an evidence-to-impact matrix

Every material finding should answer the same questions: how sure are we, how likely is it to bite, what would it cost the business, what does fixing it take, and what do we do in the deal? The matrix shows the format.

Illustrative only. Findings and methods show the format; they aren’t typical findings or benchmarks.

Confidence and likelihood are separate columns on purpose. You can be sure a problem exists and still think it’s unlikely to cause harm soon. Folding both into one “severity” color hides that, and it’s how arbitrary maturity scores creep into reports.

Step 4: Estimate remediation, with the method on the page

A remediation estimate without a method is an opinion. The method is usually simple: hours by role × an hourly rate, plus one-time purchases, plus any change in recurring cost, with a low and a high case. Keep one-time and recurring costs apart, because they hit the deal differently.

An illustrative example

Illustrative only. The hours, rates and license costs are assumptions chosen to show the arithmetic, not market rates. Real estimates depend on the target, the team and the scope.

A buyer is acquiring a small SaaS company priced as a multiple of EBITDA. Diligence finds the first three issues in the matrix.

How that translates into the deal:

• One-time cost is a cash need. Ask the seller to fix it before closing, negotiate a price reduction of about that amount, or fund it yourself and budget for it.
• Recurring cost changes the earnings you’re paying a multiple for. If the price assumes EBITDA without it, then at an illustrative 5x multiple, $11,760–$15,760 a year is worth $58,800–$78,800 of price ($11,760 × 5 and $15,760 × 5).
• Uncertain cost, like the AGPL issue before counsel weighs in, often fits a specific indemnity or escrow sized to the high end of the estimate ($90,000 here) better than a price cut sized to a guess.

Add timing and dependencies: the MFA rollout takes days and blocks nothing, while the component replacement could take a quarter and delay a feature a customer was promised, which may cost more than the engineering.

Step 5: Triage red flags and assign deal and Day 1 actions

A red flag without evidence, impact and an owner is just a worry. Sort each material finding into one of six tiers, and let the tier drive the response.

The deal levers are the same across tiers: confirm or revise the thesis, adjust the model, require a fix or consent, change the price, add an escrow or indemnity, add a condition or covenant, look at insurance, negotiate a TSA, or walk away. Which lever fits, and how the purchase agreement words it, is for your attorney. The technology team’s job is to hand counsel precise, evidenced findings with cost ranges, so the legal terms rest on facts.

Expect sellers to push findings toward “post-close.” Anything fixed after closing is paid for by you; anything fixed before closing, or priced, is paid for by them. That’s a fair negotiating position, and it’s why the tier should follow the evidence, not whoever argues hardest.

The technology due diligence report and first-100-day handoff

A useful technology due diligence report is short at the front and specific underneath:

• Scope and limitations: what was reviewed, how, with what access, on what dates, and what wasn’t. This is the most important section and the one most often buried.
• Deal-team summary: thesis-relevant findings, tier, cost range and recommended response.
• Evidence-to-impact matrix, with each finding’s evidence grade.
• Remediation roadmap: one-time and recurring costs, sequencing and dependencies.
• Day 1 and first-100-day plan, with named owners.

A report is a point-in-time view based on the access provided, not a guarantee that systems are secure or that nothing was missed. A provider who says otherwise is overselling.

Hand the findings and roadmap directly to the people who will run the business; without a named owner, findings stall once the deal team moves on. For the rest of your pre- and post-closing list, see the buying an existing business checklist.

Who should do the work

Depending on your router row, you may need a technology diligence lead, a software and architecture specialist, a cybersecurity practitioner, privacy and IP counsel, a cloud cost specialist, and someone who has run integrations or separations. Providers tend to scope around what they do best (a penetration-testing firm proposes a penetration test), so check each proposal against your router row. Ask each provider what access they need, what they won’t cover, and how they’ll turn findings into cost ranges and deal responses. For more, see how to choose a due diligence firm.

When you’re ready to staff the review, you can compare vetted independent technology, cybersecurity, privacy and other diligence providers on DueDilio.