When buying a startup, investors focus on the product, the capital structure, competitors and the monetization strategy.  More and more, however, potential acquirers are adding IT due diligence to their due diligence efforts.

When considering the technology environment at a startup, savvy investors understand that they won’t see the same processes that Amazon or IBM have implemented.  And, given that they’re most likely buying the idea, the team, the intellectual property or the customers, they probably won’t concern themselves with things like an inventory of your laptops or a copy of your BYOD policy.  They’re going to be focused on the most important technology and product issues.

This article discusses some of the IT due diligence issues most likely to trip up a deal involving a startup.

Scalability and Performance Testing

If the buyer wants your product, they’ll almost certainly have a plan to significantly increase the user base.  Could your product handle ten or even a thousand times your current number of users without being re-architected?   Be ready to demonstrate that you’ve planned for scalability from the start, either through your design or better yet from the load testing you’ve performed.

Proper Software Licensing

Don’t take shortcuts on software licensing.

While it might be tempting to use unlicensed software, it will be identified during IT due diligence and this is a great way to have your deal price lowered.  The investor will have to determine how much it might cost to properly license whatever you might need going forward, and will probably add on some percentage as an “uncertainty factor,” since they’ll wonder what else might come up later that they don’t know about.  This assumes that the deal isn’t killed because the investor is worried about your decision-making or honesty.

Security Incidents

Investors will want to know about any security or hacking incidents you’ve experienced.  If you’ve had any, they’ll want to understand exactly what happened and what you’ve done to make sure it won’t happen again.  They need a comfort level that you understand the importance of security, especially if your startup is in an industry such as healthcare or finance.  In those fields, a huge fine or a fatal blow to your reputation can be only one security breach away.

Production Downtime

You’ll most likely be asked to document and describe any system downtime in the past six or twelve months.  What has been done to ensure that the problem won’t reoccur?   Downtime can be a result of any number of issues, such as lack of scalability, underpowered hardware, uncoordinated release management or poor testing.  Everyone has downtime – remember when Twitter was fairly new?  Be sure you can isolate the reason it happened, communicate what you learned and explain how you addressed the underlying cause.

Intellectual Property Ownership

It’s very common to find that companies don’t own all of what they consider to be “their” software.  This is often a result of utilizing non-employees to do some development.  If you used contractors or consultants to develop any part of your product, have an attorney review the agreement you had with the developer to determine who owns the rights to what they created.  You might be surprised to find that even though you paid them for the work, you don’t own it.  If you didn’t have an agreement, you should ask an attorney what that means about your ownership rights, and address the situation as needed.  Otherwise, you may find yourself in the midst of a deal, trying to fix the problem as your investor’s concern increases by the hour.

Team Dynamics

The team at your startup may well be your greatest asset.  In fact, sometimes the investor is buying the company to get the team.  Be sure that everyone the investor interviews is presentable, professional and gives the appearance of working well together.  This isn’t always easy at a technology startup, but if the investor feels like the founders can no longer stand working with each other, or you have too many employees on the wrong side of eccentric, they may think twice about writing that check.

Code Review

Expect a source code review.  You know your code and your product.  You know where the weak spots are.  If you were reviewing your company’s code, what would concern you?  Someone who’s an expert in your preferred development language will be doing the review, so address anything that you know you wouldn’t want to see if the roles were reversed.

Conclusion

If you make sure you have the issues listed above addressed in a solid way before trying to sell your company or attract investors, it should go a long way towards making sure your startup clears the IT due diligence process without incident.

While most IT due diligence efforts are related to mergers & acquisitions, IT due diligence can also be useful when considering whether or not to engage the services of a new vendor.

In this case, you most likely won’t have the same level of access to the vendor’s staff, services and confidential information that you would during due diligence for a company purchase. However, there are still IT due diligence questions that are reasonable to ask and there are other steps you can take independently to investigate the vendor.

Keep in mind that your success with many of the suggestions in this article depends heavily on the nature of the relationship with the vendor and how much your business means to them. If you’re a small company and the vendor is IBM, then you need to be realistic about the contract provisions to which IBM will agree. Many of the ideas, though, can be applied to any potential vendor relationship.

To protect your best interests when negotiating contract terms and provisions, always consult a qualified attorney.
IT due diligence on a vendor comes down to three main areas of focus:

• Is the vendor utilizing best practices and adhering to any requirements for your industry?
• What happens if there is a significant change related to the vendor or their services?
• What happens if the vendor goes away?

Let’s look at these three areas in detail.

Is the vendor utilizing best practices and adhering to any requirements for your industry?

There are definitely a number of IT due diligence questions that are valid when exploring a potential relationship with a new vendor.

If your industry has specific requirements related to security or privacy, then you should by all means delve into the technical details of the vendor’s offering.

Questions around data encryption and storage as well as network security facilities are certainly fair game. You’ll also want to develop a comfort level with the vendor’s redundancy approach, as well as business continuity and disaster recovery plans.

If the vendor offers a web-based product or service, and security is an area of concern, you’ll need to understand the nature of the vendor’s hosting facilities. Your security requirements may dictate that the vendor’s services are hosted in a data center audited under the SSAE 16 standard. In that case you can request SOC 3 (for public consumption) or SOC 2 (private and usually requiring a non-disclosure agreement) audit reports. You may want to request a facility visit to see the hosting environment with your own eyes.

Be sure to determine whether the vendor is providing all services on their own, or if they are to any extent simply a reseller or packager of other services. In the latter case, you are adding new layers of vendors to investigate. Sometimes you may be better off going directly to the underlying service provider.

Similarly, you may have security and longevity concerns about any open source or third party software components utilized by the vendor in providing their service, so it’s wise to ask about any such use.

A number of contract provisions can be helpful in protecting your interests as a client. If there are scheduled downtime or maintenance windows, it’s important that they be specified in the contract, with penalties for any significant unscheduled downtime. This is especially true if the vendor is offering a service that will be related to mission critical operations for your company. Generally speaking, a service level agreement within the contract, specifying things like response time, uptime and feature sets, is also a good practice.

Depending on your level of concern about security, you may also consider requiring the vendor to make representations about background checks or similar investigations of their employees.

What happens if there is a significant change related to the vendor or their services?

A number of things can change at your chosen vendor over the course of your relationship.

Employee departures, especially in a small vendor company, can have a big impact on the product and service quality. If you’re making a decision to go with a particular vendor because of specific vendor employee or team, you can include a provision in your contract that gives you the ability to terminate or renegotiate the agreement if the people servicing your account leave.

Strategic changes at the vendor may also impact you. The vendor may decide at some point that they no longer wish to provide the product or service you’re using. You may want to add a provision in your contract that requires a period of advance notice before a product can be sunset or placed in maintenance mode.

Many contracts contain a provision specifying that if the vendor is sold and the acquirer agrees to take over existing agreements, the customer’s contract automatically transfers to the new company. You may wish to attempt to add a clause that you must give your approval before your agreement is transferred to the new company. It’s not common that a vendor will agree to this provision, but again, it depends on how much your business means to that particular vendor.

What happens if the vendor goes away?

The worst case scenario is that the vendor goes out of business. In the case, you have two options: take over the product yourself, or find another vendor.

Taking over the product is really only feasible in the situation where the vendor is providing a software tool. In that case, your contingency plan requires you to have available on your staff or via a consultant the expertise required to understand and maintain the product. This also requires access to the product’s source code.

How do you get the source code if the company has gone out of business? The solution is to establish protection up-front by requiring the vendor to set up a source code escrow account. Source code escrow uses a third party company to maintain a copy of the vendor’s source code, which should be updated by the vendor on a regular basis. The source code escrow agreement will specify the reasons that the source code can be released to a vendor’s customer. Common reasons include filing for bankruptcy, cessation of operations or terminating support for a product.

The alternative is to find another vendor. It’s always a good idea to review your vendor options when entering into or renewing a contract. Hopefully there are other companies that provide the same or similar product or service as your chosen vendor. A regular survey of the competitive landscape will allow you to quickly pivot to another vendor if that becomes necessary.

Additional Steps to Take

In addition to the vendor’s cooperation and / or acceptance of contract provisions, you can take the following steps to investigate the vendor before making a commitment.

Search the web for product information and service reviews. Are the vendor’s customers saying good or bad things about the vendor and its products? Similarly, see if there is anything to be gleaned from the vendor’s Twitter account and Facebook page.

Do your own reference checks by reaching out to any customers you identified in the previous steps. The vendor will likely be willing to provide reference customers, but they will be prescreened and will almost certainly provide a positive recommendation.

Check out glassdoor.com company reviews to see if the vendor’s employees have provided any reviews. If the company is filled with unhappy employees, you may question the company’s long-term viability. Keep in mind that unhappy employees are more likely to post reviews than happy ones.

If applicable, check with the Better Business Bureau or the equivalent in your country to learn of any pattern of customer complaints.

Run a Dun & Bradstreet report to get an idea of the company’s financial viability. If the vendor doesn’t have a D-U-N-S number, it can be a sign that the company is very new or very small.

Your industry may have a regulatory body that posts details of security or privacy violations. For example, in the US, the Department of Health & Human Services
posts information about data breaches involving patient information for 500 or more individuals. If your potential vendor is included on such a list, at a minimum you’ll want to understand what caused the issue and what steps the vendor has taken to ensure that a similar problem won’t occur again.

Conclusion

The Internet has made investigating a potential vendor much easier. Between addressing upfront any problems that can be anticipated and the steps you can take without the involvement of the vendor, your IT due diligence effort can help to ensure a good selection and a positive relationship.

The recent credit card data breach at Target has, rightfully, received much media attention since it occurred.  While it’s unlikely that you’ll be performing IT due diligence on a Fortune 50 company, the Target data breach serves as a reminder that data security should be an important component of any IT due diligence effort.

Investigating the Past

It’s important to determine whether there have been any data breaches in the past.  Besides indicating a potential lack of expertise, a company may suffer long-term damage to its reputation with customers if it hasn’t been a good steward of their data.  Any previous data breaches should be noted in the due diligence report.

The first thing to do is simply to ask the staff at the target company if they’ve ever suffered a data breach.  You can also search Google for any online or newspaper mentions of the company in this context.  If an incident is revealed or discovered, be sure you receive a thorough explanation as to the root cause and details as to the measures that have been put in place to ensure that such a breach doesn’t happen again.

Best Practices

Even if there hasn’t been a credit card or other data breach, ask the staff at the company being acquired to explain in detail the features of their systems that protect sensitive data.  If they’re not ready with a thorough, confident response, this may be a sign that data security hasn’t been a cornerstone of system development.

There are a number best practices you should expect to hear as part of a comprehensive data security solution:

• Encryption.  Sensitive data should be encrypted while being transmitted to and among the company’s servers and systems and while stored.  Additional levels or methods of encryption should be considered for the most sensitive data such as credit card details and Social Security and similar identification numbers.  Backup tapes and disks should also be encrypted.

• Separation.  Credit card data should be stored away from online systems as much as possible.  Third parties who specialize in the storage and use of credit card billing data can provide options that don’t require a company to maintain or even have access to customer billing data.  This can reduce the security burden for a company while also increasing customer confidence.

• Physical Security.  It’s important that physical access to servers containing sensitive data be restricted, whether the servers are in-house or at a third party hosting company.  Backup media should be secured in a locked safe or offsite at a secure location such as a bank.

• Network Security.  The servers protecting sensitive data must be properly protected by the network infrastructure, likely including multiple levels of firewalls and thorough auditing and monitoring.

• Software Updates. Servers and firewalls should be running up-to-date antivirus software and operating system patches.

Social Engineering

The staff at the target company should be aware of the concept of “social engineering,” in which important data is obtained by deception.  For example, a technical support representative may be talked into providing or resetting a key password, which allows a hacker to gain access to systems and bypass every technology best practice that has been put in place.  This is a favorite approach of thieves and many large companies have suffered data breaches as a result.

Audits

Regardless of your confidence in the current data security standards and processes in place, you may also consider utilizing a third party company to perform a penetration test on the target company’s systems.  This test will probe common security vulnerabilities and will attempt to identify any system weaknesses.  Services exist that will perform penetration tests on a daily or even more frequent basis.

Larger transactions may warrant a thorough operational audit under SSAE 16 or ISAE 3402 guidelines.

Conclusion

Even the smallest company today likely works with credit card and other sensitive data.  During IT due diligence, it’s important to uncover the history of any past data breaches and to ensure that proper systems are in place to prevent data breaches from occurring in the future.

The way your IT due diligence checklist is formatted can have a surprising impact on how smoothly the due diligence process proceeds. During due diligence, many documents are being traded back and forth, whether or not a data room is involved.

The due diligence checklist from the IT Due Diligence Guide has just been reformatted and expanded to align with the advice in this article.

In addition to the general categories and specific individual items you’re requesting, including a number of additional columns on the list can help things to be as efficient as possible.

The overall due diligence list, including other areas such as legal and financial, may have a numbering system, so you’ll need a place to identify the number or code assigned to each item on the list. This way, when the acquisition target is providing responses, they can let you know that they’re providing a document for "item 20" instead of "an inventory list of servers" that you’ll need to match up to the list.

Having a column on the list to simply track whether something has already been provided is a useful feature. Someone on the due diligence team should maintain the "gold copy" of the due diligence request list, and this allows everyone to see what information has been provided and what is still needed.

While it’s advisable to narrow down your IT due diligence requests to only the information that’s really required, some buyers prefer to use a standard list for all transactions. This can mean that many of the items won’t apply to a specific transaction, so having a column on the checklist indicating that the item isn’t applicable to the seller’s company can cut down on back and forth communication and let you know why something hasn’t yet been provided.

Many deals utilize a physical or virtual data room to store the documents for an M&A transaction. If this is the case for a particular acquisition, it’s helpful to track the data room location or file name for an item on the due diligence checklist. Again, someone usually has the "gold copy" of the list, and this is useful reference information.

Finally, tracking comments on the due diligence checklist, whether from the due diligence team or the party providing the responses, can be helpful. If an item hasn’t yet been provided, the comments can track when it is expected to arrive. If something needs follow up, or the due diligence team needs to consult an outside expert for further review of an item, the comments section is a great way to track it.

These tips can of course apply to the non-technology areas of due diligence as well. By tracking just a few more simple pieces of data, the efficiency and organization of a transaction can be significantly improved.

M&A due diligence has traditionally focused on financial and legal issues. IT due diligence was often an afterthought, even though many transactions would have benefited from its inclusion in the process.

A 2011 Ernst & Young study of C-level and private equity executives found that separate technology due diligence was performed in M&A transactions roughly 50% of the time. IT issues discovered in due diligence played into final negotiations in fewer than 20% of the transactions.

A recent IT due diligence survey on ITDueDiligenceGuide.com of almost 200 M&A professionals shows that the situation may be changing. Participation was solicited on various M&A message boards, websites and groups, the vast majority of which did not have an IT focus.

The survey indicated that IT due diligence is now a component of 88% of the transactions in which the survey respondents are involved. The consistent need for IT due diligence isn’t surprising when one considers the extent to which technology drives almost every business today.

Even though 95% feel that IT due diligence is a valuable component of M&A and facilitates post-transaction integration, 23% of the time IT due diligence is performed by someone who is NOT a technology expert. 61% of the survey respondents indicated that IT due diligence is normally performed by a member of the internal due diligence team instead of utilizing the services of an outside expert. Clearly there is an opportunity to provide additional resources to assist those due diligence teams without a dedicated IT professional available.

54% of those surveyed have experienced a transaction in which issues discovered during IT due diligence led to either a reduction of the purchase price or an outright cancellation of a planned acquisition. This demonstrates that IT due diligence can play a role in stopping a bad deal in its tracks, or at least in establishing a more rational transaction price.

Almost every M&A professional that responded indicated that IT due diligence is a valuable component of an overall due diligence effort.

Here are the relevant questions and responses from the IT due diligence survey:

Has IT due diligence been a component of any of the transactions in which you’ve been involved?

88% Yes

12% No

Generally speaking, has IT due diligence been handled by a technology expert?

77% Yes

23% No

Generally speaking, has the person leading IT due diligence been an outside consultant or part of the internal team?

39% Consultant

61% Member of the Team

Do you believe that IT due diligence facilitates the integration of acquired companies?

95% Yes

5% No

Has an IT due diligence finding ever been the reason for a reduction in the deal purchase price, or for cancelling a transaction entirely?

54% Yes

46% No

Overall, do you believe IT due diligence is a valuable component of the due diligence process?

99% Yes

1% No