Software Technical Due Diligence Before an Acquisition
Score software ownership, architecture, security, dependencies, data, releases, incidents, and operations before an acquisition becomes a build commitment.
Aug 29, 2026
Software technical due diligence should test 9 evidence areas before an acquisition: ownership, architecture, security, dependencies, data, releases, incidents, operations, and remediation.
The goal is not to grade code style. The goal is to identify what the buyer will own, what can interrupt revenue, which obligations follow the transaction, and which fixes must change valuation, deal terms, or the first post-close milestone.
This checklist is for founders, operators, investors, and finance leaders buying a software-enabled business without a full internal technology team. It creates a common evidence request for the seller, an independent technical specialist, legal counsel, and the future operating owner.
The acquisition decision in one table
| Finding | Deal implication | Required evidence | Immediate action |
|---|---|---|---|
| Ownership is clear and systems are supportable | Risk may fit the current terms | Repositories, contracts, access, runbooks, release history | Confirm the post-close owner and first 90-day plan |
| Important gaps have bounded fixes | Adjust holdback, warranty, covenant, or remediation budget | Reproduction, impact, fix path, effort range, acceptance test | Put the fix and evidence into the transaction plan |
| Revenue depends on one person or hidden access | Continuity risk may affect timing or terms | Access map, handover, credentials, vendor contacts, incident history | Require handover and tested access before close |
| IP, security, data, or platform risk is unresolved | Do not average it into a score | Contracts, provenance, security evidence, data map, platform terms | Resolve, ring-fence, or pause the decision |
A long report without deal implications is weak due diligence. Every material finding should name the affected business process, likely consequence, evidence quality, decision owner, and next action.
Nine evidence areas to inspect
1. Ownership and access
Identify who owns the source code, designs, domains, cloud accounts, app-store accounts, data, certificates, third-party integrations, and deployment credentials. Confirm employee and contractor assignment terms with legal counsel.
Test access rather than accepting a spreadsheet. A named buyer representative should be able to reach the repositories, build system, production accounts, monitoring, backups, and vendor portals through approved credentials. Record dependencies on a founder, agency, former employee, or personal account.
If ownership is unclear, the buyer may acquire revenue without the practical ability to maintain the product. That is a transaction issue, not an item for a later engineering backlog.
2. Architecture and failure boundaries
Ask for a current system map showing applications, services, databases, queues, storage, identity, integrations, external vendors, and data flows. Then compare it with production configuration and recent incidents.
The useful question is not whether the architecture is modern. It is whether the system's boundaries are understood, failures are contained, capacity is visible, and the new owner can make changes without guessing.
Look for shared databases, undocumented scheduled jobs, direct production edits, unowned services, brittle integrations, and environments that cannot be reproduced. Mark which issues threaten revenue, compliance, recovery, or future delivery.
3. Security and secure development
Request the security model, privileged-role list, recent assessments, vulnerability handling, secrets process, logging coverage, incident records, and evidence of security work inside the delivery process.
The NIST Secure Software Development Framework organizes secure software practices across preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. CISA Secure by Design emphasizes ownership of customer security outcomes and secure product defaults. Use them as evidence prompts, not as a claim that a document proves the system is safe.
Select representative high-risk flows for hands-on verification. Include authentication, authorization, privileged actions, payments, file handling, personal data, and administrative recovery.
4. Dependencies and supply-chain exposure
Create an inventory of libraries, frameworks, containers, services, APIs, licenses, and unsupported versions. Record who monitors changes and how urgent updates reach production.
GitHub's dependency graph documentation explains how manifests and lock files can expose direct and transitive dependencies. That evidence is useful only when repositories and build artifacts reflect what production actually runs.
Check license obligations and commercial restrictions with counsel. Identify dependencies that are abandoned, pinned to vulnerable versions, tied to one vendor, or impossible to rebuild from the available source.
5. Data ownership and recovery
Map customer, employee, transaction, analytics, operational, and derived data. Record where it enters, where it is stored, who can access it, how it is retained, and how it leaves the system.
Test a backup restoration into a controlled environment. A successful backup job is not recovery proof. Record recovery time, data loss window, missing dependencies, manual steps, and the person who can perform the restore.
Include data exports and deletion. The buyer needs to know whether records can be migrated, corrected, retained, and removed under the business's contracts and legal obligations.
6. Release and change control
Ask the team to demonstrate how one production change moves from request through code, review, test, deployment, observation, and rollback. Review recent releases rather than an ideal process diagram.
Look for repeatable builds, environment separation, test coverage on critical journeys, migration controls, feature flags, release approvals, and rollback evidence. Manual work is not automatically bad, but hidden manual work creates continuity and scale risk.
The software development milestone checklist can turn post-close fixes into inspectable acceptance evidence instead of vague backlog items.
7. Incident history and observability
Review production incidents, customer complaints, support escalations, security events, outages, data corrections, and emergency changes for at least the period relevant to the transaction. Link each incident to detection, response, root cause, correction, and prevention.
A lack of recorded incidents can mean stability, but it can also mean weak detection. Compare the record with monitoring, support tickets, cloud logs, status reports, and customer communications.
The software maintenance cost guide separates corrective, adaptive, preventive, and improvement work. Apply that structure to the acquired product's real workload.
8. Operating ownership and key-person risk
List who owns product decisions, architecture, releases, cloud, security, data, support, customer escalations, and vendor relationships. Identify where the same person is the only approver, operator, and source of context.
Ask a second person to follow the runbook for a representative release, recovery, or support action. The test exposes missing access, tacit knowledge, and instructions that only make sense to the author.
If an external agency or freelancer is essential, review the contract, notice period, source access, documentation, open work, and handover obligations. The AI vendor exit and handover checklist provides an adjacent evidence pattern for systems with external delivery dependencies.
9. Remediation and cost of delay
Convert findings into decision-ready work. Separate close blockers, pre-close conditions, day-one controls, first-30-day fixes, and longer product improvements. Do not mix a security exposure with a design preference in one severity bucket.
For each material item, record the affected journey, evidence, likely consequence, dependency, owner, acceptance test, and timing. Use ranges for effort and cost. State uncertainty where evidence is incomplete.
The custom software ROI guide helps compare remediation cost, operating value, and cost of delay without turning assumptions into promises.
Copyable evidence request checklist
| Evidence package | What to request | What to verify |
|---|---|---|
| Ownership | Repository, domain, cloud, app-store, vendor, IP, and contractor records | Legal ownership and practical administrator access agree |
| Architecture | Current diagrams, production inventory, data flows, integrations | Diagrams match deployed systems and failure boundaries |
| Security | Roles, assessments, vulnerabilities, secrets, logs, incidents | Critical flows and privileged actions have current evidence |
| Dependencies | Manifests, lock files, images, licenses, service contracts | Production versions, transitive exposure, support status, obligations |
| Data | Data map, retention, export, deletion, backup, restore records | Representative export and restoration work in a controlled test |
| Delivery | Build, test, deployment, migration, rollback, release history | A recent change can be reproduced and explained |
| Operations | Monitoring, support, incidents, runbooks, on-call, vendors | A second operator can perform a critical procedure |
| Remediation | Risk register, effort ranges, owner, acceptance tests | Deal action and first milestone are explicit |
Send the request before the main interview. Missing evidence becomes a finding with uncertainty, not an invitation to fill the report with assumptions.
Sample the system instead of reading everything
Due diligence time is limited. Choose samples tied to value and risk: the main revenue journey, a privileged action, one complex integration, one data migration, one release, one incident, one restore, and one customer escalation.
Use the OWASP Application Security Verification Standard to structure technical security requirements at an appropriate level. Use the UK NCSC developers collection for secure development and deployment prompts. Neither source replaces testing the acquired system.
A useful sample links code and configuration to a real business outcome. For example, trace one order from customer action through payment, database writes, notifications, support visibility, refund, analytics, and reconciliation.
Turn findings into deal actions
| Severity | Decision test | Deal action | Acceptance evidence |
|---|---|---|---|
| Blocker | Ownership, legality, security, recovery, or continuity cannot be resolved | Pause, exclude, or require resolution before close | Independent verification of the resolved condition |
| Material | Fix is feasible but changes risk, cost, timing, or value | Adjust terms, holdback, warranty, covenant, or budget | Bounded milestone with named owner and evidence |
| Operating | Risk needs a day-one control or near-term procedure | Add transition action and accountable operator | Access, monitoring, runbook, or support test passes |
| Improvement | Product can operate, but the change improves maintainability or value | Prioritize after continuity work | Product measure and release acceptance are defined |
Do not let a total score hide a blocker. A product with many strong practices can still be unbuyable if IP ownership is unresolved or recovery cannot be demonstrated.
KUMO offers a free Kumo Build Readiness Review for acquirers and operators who need to turn findings into one safe remediation milestone. Map my first milestone to define the critical journey, evidence, dependencies, and acceptance boundary.
Relevant delivery proof
KUMO built Equipp for Ralco Group as a B2B and B2C equipment-rental marketplace. The Equipp case study documents pricing, payments, order workflows, inventory reservations, dashboards, distribution integration, and reverse logistics. It shows relevant delivery across commercial flows and operating systems. It does not prove the condition of an acquisition target.
The software partner selection checklist helps buyers test a remediation partner's evidence and ownership model after the transaction decision.
Questions acquisition teams ask
When should technical due diligence begin?
Start before final deal terms are fixed and early enough to request access, resolve missing evidence, and reflect material findings in valuation, warranties, conditions, transition work, or remediation budget.
Does a code review cover technical due diligence?
No. Code review is one input. Technical due diligence also covers ownership, deployed architecture, security, dependencies, data, releases, incidents, operations, key-person risk, and the cost of necessary work.
How much of the system should be sampled?
Sample enough to test the main value journey and the risks that could change the deal. Include critical code and configuration, a release, an incident, a restore, a privileged action, and a complex integration.
What makes a finding material?
A finding is material when it can affect ownership, revenue, customers, security, compliance, recovery, deal timing, transition, or the cost and feasibility of operating the product.
What should happen after the report?
Convert each material finding into a deal action or a dated remediation milestone with an owner, dependencies, acceptance evidence, and stop condition. Verify critical access and continuity before close.
Map findings to the first remediation milestone
KUMO's custom software development team can help turn verified findings into a bounded remediation or modernization milestone with explicit acceptance and handover. The free Kumo Build Readiness Review is designed for buyers and operators who need a practical next step after diligence. Map my first milestone with the system map, evidence gaps, critical journey, and highest-consequence finding.
Sources
The NIST Secure Software Development Framework, CISA Secure by Design, OWASP Application Security Verification Standard, UK NCSC developers collection, and GitHub dependency graph documentation were checked on 24 August 2026. Legal, security, and transaction advice should come from qualified professionals with access to the specific target and deal.
