Subscribe
When a company buys another company, the due diligence process is analogous to a home inspection during a real estate transaction. A buyer sees only so much when they tour a home—enough to know they like it and to assess the value, but not enough identify hidden problems that might devalue the property. An in-depth assessment requires time and expertise.
Things to consider during software due diligence
Similarly, a company acquiring another starts with a fairly good idea about the target’s value and strategic fit before they agree on a price and a timeline for the deal. But when they sign a Letter of Intent, they reserve the right to dig deeper via a process called due diligence. The acquirer then has several weeks to request information, ask questions, and perform analyses to allow them to:
- Confirm their current understanding of the target’s business
- Plan for integration
- Uncover any surprises that could impact the deal or their desire to go ahead
(It’s a nice-looking house, but the foundation is crumbling and it’s about to collapse)
This kind of analysis covers all aspects of a business. Acquirers will dig into financials, HR records, legal documents, customer complaints, marketing plans—everything, including the software technology. This is particularly relevant for deals in which software is a substantial part of the value. Inquiries about the technology will range from a high-level look at product strategy and roadmap to the people and processes, and extend down to the code itself. The breadth of inquiry spans quality, security, and legal issues.
As with any aspect of due diligence, much information is gleaned through Q&As and documents as well as discussions. A meeting between respective CISOs might start with walk through of the target’s AppSec program at a high level. A disclosure request might include documented processes on open source use, handling vulnerabilities, building in security, and software architecture.
When do software audits come into play?
Where the rubber meets the road, though, is in the code. That’s where an audit comes in. It will delve deeply into all aspects of the code and focus on open source, application security, architecture, quality, and processes. This kind analysis is well-suited to a trusted third party because targets will not share their code with a potential acquirer. The exhaustive analysis Synopsys performs also requires skills that acquirers may not possess, much like a home buyer relies on the expertise of the inspector to spot issues that would escape a typical homeowner (and require willingness to crawl into the deepest corners of the attic). Applying such expertise is what distinguishes an audit from a mere automated scan.
Once alerted to security, quality, and legal issues in the code, a buyer can protect themselves in the deal and plan to address them going forward. Rarely, though occasionally, code issues can kill a deal. However, they certainly impact planning, and extreme issues can affect deal valuation, timing, or terms. Newly discovered vulnerabilities or open source license compliance issues may need to be remediated before close. A revealed architecture hairball may reduce the price to cover refactoring costs. Or buyers may hold back some money as insurance against a potential licensing lawsuit based on a discovered GPL-licensed component.
Tech acquirers rely on Black Duck® software audits to keep their technical houses in order, ensuring they are making wise M&A investments that pay off in the long run.
Continue Reading
