Software technical due diligence is the structured review of a target company’s software, source code, and technology stack before an acquisition or investment round closes. Its purpose is to make the parties aware of actual or potential risks—ownership gaps, licensing obligations, code provenance questions, security exposure—while there is still time to negotiate price, remediate, or walk away. This article examines the categories that appear on most technical due diligence checklists and explains, for each one, why the information is requested, how it is analyzed, and what litigation risk it is meant to surface before, rather than after, closing.
The driving principle of software technical due diligence is: to build awareness; to establish trust; address issues before the event is final; and price accordingly. It is not necessarily intended to turn over every stone and identify every single issue, but instead helps make parties aware of significant issues that may need to be addressed at some point, or identify critical issues so important that they may impact the decision of whether to purchase the software or company at all.
Consider this premise: it is exceedingly rare that software or technology is free of issues, though all issues themselves are not always critical, provided the party responsible for them (or the party becoming responsible for them) is aware and able to act accordingly. They may be software bugs, integration issues, security risks, or ownership risks. But no matter the problems, awareness matters because it facilitates informed decision making.
Depending on the specific context of a technical due diligence project, the specific assessments can involve many different factors to consider. In fact, a quick Google search often shows numerous publicly available “technical due diligence checklists.” Many of these often contain similar overlapping categorical considerations like IP ownership, software architecture review, code quality, data privacy, and security.
Many of these checklists are authored by engineering firms focusing heavily on software architecture, technical scalability, and code quality. They may list various pieces of potentially relevant information to request when undertaking a technical due diligence project, and relate more to a business’s strategic decisions supporting an acquisition, sale, or investment round. Seemingly few of these checklists take an approach that seeks evaluation and understanding of potential litigation risks, or provides context as to why certain information is requested, how it will be used, or what specifically one hopes to gain from analyzing the information.
In this article, we examine categories common among these technical due diligence checklists and provide context regarding why certain information may be relevant, how that information may be used, and what one might hope to learn about the underlying technology regarding potential litigation risks that may arise after closing. While a strong checklist is a great starting point, understanding the “why” and “how” of a given checklist may aid in uncovering issues that could result in litigation long after the deal closes.
As we’ve seen in practice, even well-built software can be riddled with peculiarities regarding ownership, licensing, code provenance, functionality, and security, among others. A technical due diligence roadmap that focuses strictly on quality, architecture, or technical stability may overlook such issues presenting significant risks long after closing, and diligence that only skims the surface of summary level information without going deeper may miss important issues or fail to document findings well enough to support or refute later claims.
For example, consider Marriott’s acquisition of Starwood that closed in 2016 at an estimated value of $13.6 billion. Unknown to either party, Starwood’s network had been compromised two years prior, exposing sensitive personal information of nearly 500 million guests. The security breach, and its cause, were not discovered until two years after the acquisition when Marriott learned of suspicious activity via a security alert. This breach carried an estimated $30 million in recovery costs related to investigations and customer notifications, responsibility for which Marriott assumed when it acquired Starwood. While public findings don’t specifically detail the technical due diligence efforts, the fact that this risk was missed suggests that a wider scope could have potentially exposed the issue earlier.
Verizon’s acquisition of Yahoo in 2017 provides an example of how early detection of potential issues can be helpful. The acquisition closed at an estimated value of approximately $4.4 billion, but during the acquisition Yahoo disclosed two major data breaches occurring in years prior affecting upwards of 1 billion accounts. The breaches were not reported until 2016, which caused the parties to amend the acquisition deal to reduce the sale price by approximately $350 million, and accompanied by an agreement to share costs related to follow-on investigations and potential lawsuits that resulted from the breaches. Problems discovered before closing can have a significant impact not just on the price, but how the parties handle issues that arise post-closing.
Every technical due diligence project need not look the same, and in fact, some may not check all the boxes or drill deep looking to overturn every stone. Depending on the concerns parties may have in a merger, acquisition, or investment prospect, some categories that commonly appear in technical due diligence checklists may not be as relevant as they are in other contexts. The sections below provide a non-exhaustive list of some common categories in technical due diligence checklists, supplemented by an explanation of what information may be relevant, what types of analyses or review may aid in exposing potential issues at a later point, and what issues parties may be looking to avoid by focusing their attention on these categories.
IP Ownership and Chain of Title
Evaluating IP ownership and “chain of title” issues in software may entail analyzing key documentation like employee and contractor agreements, IP assignment agreements, interviews with key individuals, and a parallel analysis of certain individuals’ contributions to the software. Experts conducting technical due diligence in this context will look to these bodies of information to understand the evidence supporting ownership claims, and use source code review to verify the documentation provides seemingly adequate coverage or assess for gaps or other issues. The expert’s objective is to determine whether there is a risk that the software could be subjected to later claims of third-party ownership from former employees, cofounders, or independent contractors, which would not only be costly to defend, but if successful could restrict later use or licensing capabilities.
Licenses
Evaluating licensing issues in software may entail analyzing the source code, repository and relevant documentation to confirm that the software or technology is proprietary or whether it includes elements of licensed third-party software or open-source software, both of which may carry certain limitations or obligations. Experts conducting technical due diligence in this context conduct source code review and additional extrinsic research to identify indicia of third-party or open-source license language often appearing within the source code lines and files, and evaluate whether it implicates other source code files or has other impacts. The resulting output may take the form of a software bill of materials (“SBOM”) outlining a complete list of the components in the code and applicable licenses and potential implications. This can expose risks of license violations or third-party claims to ownership, and potentially hinder the ability to enforce acquired rights against others, and importantly, can impose significant costs to re-engineer or rebuild software that is free from these issues.
AI-Generated Code
Examining software to identify the presence of AI generated code is another compositional task that entails a thoughtful analysis of the source code, repository, and supporting technical documentation. It also may involve the application of certain forensic techniques to evaluate historical development of source code. Experts conducting technical due diligence in this context may conduct thorough evaluations of source code and certain functionality, as well as a careful evaluation of the repository metadata to look for indicia of AI-generated code, and seek to quantify how much was likely written using generative AI tools versus organically developed. Generative AI and AI-generated source code can present issues whether a party can properly claim ownership over the content, or whether the generated content infringes upon the training data it uses as a source. This can potentially restrict the scope of ownership, and impose an inability to successfully assert one’s rights.
Code Provenance
Analyzing the code’s provenance, or origin, entails evaluating the source code repository metadata and commit history at key points in time to trace the origins and evolution of the code within the repository. With this information, an expert can help build a historical timeline and assess whether contributions to the source code were organically created, or whether there are indicia of problematic files or lines resulting from large commits of source code with minimal or no prior history, or other suspicious activity that coincides with employment changes. This can help determine whether there are potential issues relating to third-party ownership claims as discussed above, or suggest other problematic concerns like potential trade secret misappropriation or copyright infringement.
Functionality
Evaluating the software’s functionality can entail a reasonably thorough source code review and functional mapping, which may be further supported by analysis of technical documentation (e.g., release notes, source code comments, testing plans and data, requirements) and marketing materials (e.g., pitch decks, customer contracts, trade show publications). Experts looking to evaluate the functionality of the software may look at this material to gain an understanding of precisely how the software works under the hood, and whether public representations and depictions of those capabilities are supported by the technology. They may also look at this material to assess things like code quality, technical capability, architectural composition. This can help expose factual information that may be useful in defending against potential legal claims for fraud, misrepresentation, breach of warranty, or other claims such patent infringement, trade secret misappropriation.
Trade Secret Protection or Contamination
Analyzing the protective posture of the target software’s trade secrets entails source code review and analysis of documented policies, procedures, and practices, as well as forensic analysis of certain data like access logs and other security mechanisms intended to restrict access and use of proprietary material. An expert analyzing this material may be able to assess whether claimed trade secrets have been adequately protected from disclosure, or whether the information is capable of meeting the burden of qualifying as a trade secret. Conversely, when combined with analysis focusing on code provenance, such analyses may be able to provide additional confidence that claimed trade secrets were developed appropriately or whether there are peculiarities that present risks of trade secret misappropriation or patent infringement claims later.
Data Privacy and Security Posture and Breach History
As illustrated by the examples of Marriott and Verizon above, assessing the privacy and security posture of software during mergers, acquisitions, or investment funding rounds can be of significant importance, and carries with it substantial post-closure implications. Technical due diligence that touches upon these categories may entail evaluating security policies, technical safeguarding practices and procedures, conducting forensic analysis of system logs, and other technical testing to identify and analyze system vulnerabilities. Additional information, such as issue reports, defects, customer complaints may be helpful to illuminate potential high-risk areas where issues may be more apparent as well. Experts may look for evidence of past or ongoing intrusions to ascertain whether or to what extent the software, systems, or data may already be compromised or remedied. Further, evaluating the ways in which the core software touches upon, uses, retains, or transmits customer data, and the policies, practices, and procedures in place that govern that interaction can be another key consideration that entails analyzing the technology, historical data, and other materials. For example, forensic analysis of systems and access logs may identify vulnerabilities that may not have been captured through routine data privacy impact assessments undertaken for certain functions or features of the software, which can leave an acquiring company exposed to the potential repercussions. A second review provided through technical due diligence can provide confidence that the software is in reasonable compliance with regulatory obligations, or uncover gaps that would present costly problems.
Like the Marriott-Starwood acquisition, breaches that occur prior to an acquisition, but not discovered until post-closing have carry-on effects that endure long periods of time, and impose significant cost. Technical due diligence focusing on security and privacy posture can potentially identify these types of risks early so that appropriate steps can be taken to remedy them, or plans developed for addressing the consequences like fines, penalties, and lawsuits that may come later.
Code Preservation
Perhaps the most practical activity that appears on numerous existing technical due diligence checklists considers preserving a snapshot of the source code at the time of closing. This entails forensically generating a verified copy of the codebase and data at the point in time they exited at closing. Experts equipped with proper forensic tools can extract and preserve the source code at this key point in time, which gives the parties the ability to later prove facts contemporaneous with the event that underscores the technical due diligence. As we’ve seen in practice, constructing a historical record of source code and metadata at a specific point in time can be time-consuming, costly, and imperfect when looking backward through the records, whereas records generated contemporaneously with key events are more often cheaper and more defensible.
Conclusion
A technical due diligence checklist is an important piece of documentation for mergers, acquisitions, and investment rounds, but what can have significant impact on later outcomes is what analyses were undertaken in satisfaction of the checklist, whether they provided an acceptable scope of coverage, and whether the effort fulfilled the purpose of making the parties aware of potential issues they may later have to address. Issues such as ownership, provenance, licensing, security posture, and representations as to the software’s functionality can be costly to address later in time, whether in litigation or typical engineering and improvement workflows, and more cost-effective to discover and remediate earlier in the process.
However, not every technical due diligence project will ultimately look the same; some may prefer breadth over depth, and vice versa. But having an understanding of what implementation of a given checklist looks like in practice can be important to the risk identification and mitigation strategy. Knowing what work it entails lets the parties understand where there may be gaps in their risk assessment efforts, whether the gaps present risk, and whether those risks are acceptable to the parties.
Contact DisputeSoft for a confidential consultation. With over 23 years of experience and more than 475 software and IT disputes, DisputeSoft brings a litigation perspective to technical due diligence.
Frequently Asked Questions
What should be included in a technical due diligence checklist?
What should be included in any technical due diligence checklists really comes down to what the parties consider are high risk and high-priority questions that require answers. For example, a software development company acquiring another may be less concerned about code quality and architecture because they have an internal plan to pivot its use case or leverage it for something entirely different, and will already be primed to deal with such issues on the fly, however unideal. But the same hypothetical may be significantly concerned with IP ownership and open-source licensing and seek to place increased emphasis on ownership certainty.
What are red flags in technical due diligence?
Red flags may be different depending on the particular facts and scenario. Where key information or data that supports one of the due diligence considerations is missing or compromised, it might signal issues, or at least fail to make a party aware of potential issues.
How long does technical due diligence take?
The time span for undertaking technical due diligence can vary in any particular scenario, and there’s no one-size-fits-all equation. For smaller, more limited due diligence efforts involving very specific inquiries, smaller code bases, and smaller volumes of information, technical due diligence can take a short amount of time on the order of weeks, but the time, effort, and cost increases nonlinearly where questions are broad and the volume of information increases and becomes more complex.
Why should source code be preserved at closing?
Preserving source code at the point of closing reduces the effort and puts a degree of certainty to the question of what the source code looked like at a specific point in time. Software disputes, and the investigations that are undertaken to support them, rarely, if ever, concern only a single moment in time, as the nature of software and software development is that it’s always evolving. Source code may look very different between two periods of time, however short, and when it isn’t preserved as of a specific time, understanding exactly the status of the code at any given historical time requires a dedicated effort.
