Technical due diligence for software acquisitions: Evidence, risk, and remediation

Last substantive review: August 2026.

When an established company buys a software business, invests in one, or asks the board to approve a technology-heavy transaction, the useful question is not whether the code looks modern. It is whether the asset can keep serving customers, whether the buyer will control what it is paying for, and which technical liabilities change the price, timing, integration plan, or operating budget.

Horizon Labs approaches that question as a bounded evidence and remediation engagement. We agree on the transaction thesis, systems, access, decision date, and exclusions; build a defensible evidence record; test the highest-consequence claims; and turn findings into work that an owner can accept or reject. When a buyer needs senior architecture, security, platform, AI, embedded, IoT, or integration judgment, that specialist lane is typically $150–200 per hour. The rate buys accountable expert time, not a promised deal outcome or a substitute for legal, accounting, compliance, or valuation advice.

This article is for corporate development leaders, buyers, investors, board advisers, CTOs, and engineering executives assessing a production software asset. It covers software-acquisition diligence and the engineering work that follows. It does not tell a deal team whether to sign or supply a universal checklist that makes every target comparable.

Start with the decision, not the repository

A review becomes useful when its scope follows the decision. A buyer acquiring a product and its engineering team needs different evidence from an investor taking a minority position, a lender testing business continuity, or a strategic acquirer planning to merge platforms. Write a short mandate before opening the data room:

• the transaction thesis and the capabilities believed to create value;
• the legal entities, products, repositories, environments, data stores, devices, models, and third parties in scope;
• the customer, revenue, security, continuity, ownership, and integration assumptions that must be tested;
• the decisions and dates the report must support;
• the level of technical access permitted before signing or closing;
• work owned by counsel, accountants, privacy specialists, penetration testers, compliance assessors, or other advisers;
• known exclusions, evidence that will not be available, and how those limitations will appear in the report.

Turn the thesis into questions that can be answered with evidence. Can the buyer build and deploy the product from controlled source? Which services and people are required to operate it? Does a promised integration exist in production or only on a roadmap? Who owns commissioned code, training data, firmware, designs, domains, and cloud accounts? What happens if a critical vendor or senior engineer leaves? What investment is required before the system can enter the buyer’s operating model?

Do not widen the review merely because a tool can scan another repository. A comprehensive-looking report with no link to a transaction decision creates noise. Record out-of-scope observations separately and escalate only when they plausibly affect an in-scope asset or assumption.

Build an evidence room that can answer follow-up questions

A folder full of policies is not an evidence room. The room should connect assertions to artifacts, owners, and dates. Use an index that states what each item supports, who supplied it, its period of coverage, whether it is complete, and which reviewer has access. Provide controlled, read-only access where practical; redact customer secrets and personal data; never distribute production credentials in a document folder.

The SPDX specification provides a current, standardized way to represent software-component and supply-chain information. An SBOM is useful inventory evidence, but it is not proof that every component is reachable, correctly licensed, supported, patched, or safe. Pair it with build manifests, lockfiles, runtime inventories, vulnerability decisions, license review by counsel, and a reproducible method for refreshing the record.

Ownership deserves the same discipline. Match repositories and deliverables to the entities and people that created them, then let counsel determine the legal effect of assignments and licenses. Horizon Labs’ code ownership and IP assignment guide explains the operational evidence an engineering team should preserve; it is not a legal opinion.

Test the operating truth behind the documents

Documents express intent. Diligence must also examine operation. Select representative paths based on consequence and uncertainty, then trace them from source through production. A reviewer might observe a clean build from a controlled repository, inspect how an approved change becomes a release, follow one customer request across dependencies, review a recent incident and its corrective action, or examine whether a backup restoration reached a usable state.

Use a graded evidence model. Direct observation, reproducible artifacts, system-generated records, and corroborated interviews carry different confidence from a policy with no execution record. Record the date, environment, sample, and limitations for each test. A passing sample does not prove that every repository or period behaves the same way.

Architecture review should begin with runtime boundaries and failure paths, not a diagram’s shapes. Identify entry points, trust boundaries, synchronous dependency chains, queues, data stores, privileged paths, regional or device constraints, and manual interventions. Compare the map with telemetry, configuration, infrastructure definitions, and the people who operate it. Note where the diagram is stale; do not silently redraw the target into a more flattering system.

Reliability evidence needs both prevention and recovery. Review customer-facing indicators, alert quality, incident frequency and consequence, unresolved post-incident actions, capacity constraints, backup coverage, restoration evidence, and third-party failure behavior. The disaster recovery planning guide covers recovery objectives and restore testing in more depth. A backup job marked successful is not the same as a restored service that meets the business need.

Assess security as risk evidence, not badge collection

The security workstream should start with the product’s assets, users, data, deployment model, threat boundaries, and contractual or regulatory context. A certification can be relevant evidence, but its system boundary, period, exceptions, and complementary controls matter. Do not infer that a report about one environment covers an acquired product, a mobile app, model pipeline, device fleet, or newly added service unless the stated scope does.

NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes across govern, identify, protect, detect, respond, and recover. It can help reviewers see whether governance and recovery are missing from a control-heavy review. It is a flexible risk framework, not a transaction-specific scoring model and not evidence that any outcome is achieved.

For software-development practice, the current NIST Secure Software Development Framework groups practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. NIST describes the practices as outcome-based and intended for risk-based tailoring, not a checklist whose completion establishes safety. Map relevant outcomes to the target’s evidence and record where the transaction needs more assurance.

For a web application, OWASP ASVS 5.0 provides testable application-security requirements and levels of rigor. State the ASVS version and selected requirements in the work plan. A partial review should not be described as ASVS conformance, and ASVS does not replace infrastructure, cloud, device, personnel, privacy, or business-continuity analysis.

CISA’s Software Acquisition Guide for Government Enterprise Consumers is useful for its emphasis on asking suppliers for security evidence and making expectations explicit. Its audience is government software procurement, not corporate M&A. Use its questions where they fit; do not present it as a private-transaction standard.

Review architecture, dependencies, and ownership together

A finding rarely stays inside one category. An unsupported library may be a security exposure, a license question, a release constraint, and a staffing problem. A production account owned by a founder’s personal identity is an access-control issue and a transfer risk. A customer-specific fork can affect reliability, roadmap capacity, contract performance, and integration cost.

Follow material dependencies through four layers:

1. Technical dependency: which code, API, model, device, data feed, certificate, or managed service is required?
2. Operational dependency: who monitors it, renews it, deploys it, rotates access, and responds when it fails?
3. Commercial dependency: what contract, quota, region, support level, pricing term, or change-of-control provision applies? Counsel and finance own the interpretation.
4. Exit dependency: can the buyer replace, transfer, reproduce, or temporarily contain it, and what must happen first?

Do the same for technical debt. “Old code” is not a useful finding. Describe the observable constraint: releases require a manual database edit; only one person can update firmware; a shared service has no isolation boundary; test fixtures cannot reproduce a regulated calculation; or a vendor SDK is past support. Estimate remediation only after identifying the affected path, prerequisites, verification method, and uncertainty. The technical debt cost guide provides a method for tying debt to delivery, reliability, and operating cost.

Write findings that a deal team and engineering team can use

A severity label without a failure path invites argument. Define the rubric for the engagement and apply it consistently. One practical structure combines consequence, credible likelihood, exposure or reachability, evidence confidence, time sensitivity, and relevance to the transaction thesis. Do not let a scanner’s numeric score decide transaction materiality.

Use calibrated language. “No evidence provided” is different from “control absent.” “Not reproduced in the review environment” is different from “does not work.” “One sampled repository” is different from “all source.” State contradictions and unresolved questions. Keep a findings register linked to the evidence index so later readers can trace the conclusion.

The report should open with the transaction thesis, scope, limitations, and decision-relevant findings. Detailed evidence, lower-priority maintenance, and tool output belong behind that. Include a system map, dependency and ownership concerns, an integration-readiness view, and a remediation register. Avoid a single proprietary score that hides judgment; decision-makers need the reasons and uncertainty.

Separate pre-close decisions from post-close engineering

Diligence identifies and characterizes risk. Counsel and the deal team decide how findings affect representations, conditions, covenants, economics, or the transaction itself. Engineering should not draft legal conclusions. It should explain the technical condition, credible consequence, containment options, remediation dependencies, and evidence still required.

Create two work queues. The first contains evidence or containment needed before the next transaction decision. The second is a funded operating plan for accepted post-close risk. Group the second queue into coherent tranches: secure account transfer, reproducible builds, critical vulnerability treatment, recovery verification, dependency stabilization, observability, ownership transfer, and integration seams. Assign an executive risk owner and an engineering owner to each tranche.

Do not schedule every low-priority cleanup for day one. Protect customer operation and preserve rollback while the buyer learns the system. Verify each remediation against an explicit test, then update the finding with the new evidence and residual risk. A closed ticket is not proof that the original failure path is controlled.

Horizon Labs can run the technical work as a bounded diligence review, a narrow confirmation test, or a remediation tranche alongside the buyer’s team and advisers. The $150–200 per hour specialist lane fits inherited systems and high-consequence areas that need senior judgment quickly, including architecture, platform reliability, security engineering, AI systems, embedded products, IoT fleets, and complex integrations. The engagement letter or statement of work should name the systems, access, deliverables, exclusions, reporting cadence, and acceptance evidence.

If you are preparing an acquisition, investment, or board review and need an evidence-led technical workstream, contact Horizon Labs. Bring the transaction thesis and the decisions you need to make; the first scope should be narrow enough to finish and important enough to change what happens next.

Frequently asked questions

What does technical due diligence cover in a software acquisition?

It tests whether the software asset, operating practices, team, dependencies, security controls, data handling, intellectual-property chain, and cost profile support the buyer’s transaction thesis. The exact scope should follow the deal, product, risk tolerance, access available, and decisions the report must inform.

What belongs in a technical evidence room?

A useful evidence room contains a current system and data-flow map; repository, build, test, deployment, and environment evidence; incident and reliability records; access and security-control evidence; dependency and license inventories; ownership documents; vendor and infrastructure obligations; operating costs; roadmaps; and named owners. Sensitive material should be redacted or provided through controlled, read-only access.

How are diligence findings prioritized?

Prioritization should combine consequence, credible likelihood, exposure or reachability, evidence confidence, time sensitivity, and transaction relevance. Each finding needs the observed evidence, affected asset, plausible failure path, interim containment, remediation owner, verification test, dependencies, and remaining uncertainty—not only a color or severity label.

Is technical due diligence a security audit?

No. Technical diligence can review security evidence and perform agreed technical checks, but it is broader than application security and usually narrower than a formal audit, penetration test, legal opinion, compliance examination, or financial valuation. Those workstreams should be commissioned separately when the transaction requires them.

What happens after the diligence report?

The deal team decides which issues affect the transaction, which become pre-close requests, and which enter a funded post-close plan with counsel and other advisers. Engineering then converts accepted findings into owned remediation tranches with prerequisites, acceptance tests, rollback or containment, and a record of residual risk after verification.

Sources

• https://csrc.nist.gov/projects/ssdf
• https://www.nist.gov/cyberframework
• https://owasp.org/www-project-application-security-verification-standard/
• https://spdx.dev/use/specifications/
• https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf