I recently read a great quote from the CIO at Dell: “There is no business without IT right now. We don’t support the business – we are part of the business.” While most due diligence efforts won’t focus on companies the size of Dell, the fact remains that technology now plays a key role in almost all businesses.

If you accept this premise, then you should consider how much attention technology receives when you’re evaluating an investment. If it’s not any less important that customer contracts or financial projections, then don’t treat it as an afterthought.

Too often I’ve seen that technology due diligence consists of a brief period at the end of the overall due diligence process that focuses on things like documenting the existence of IT assets like servers and laptops, and maybe a quick review of the data center.

While acknowledging the need to get a deal done as quickly as possible and to start the process of integration, below are some additional IT due diligence steps that I think should be required in specific IT-related acquisitions.

Source Code Review

If there is proprietary technology involved in the operations or products of the target company, it’s critical to have a source code review performed by an expert in the particular programming language used to develop the target’s technology.

The best IT consultants are truly fluent in only a handful of languages, so it’s worth the added expense to be sure a real expert is reviewing the code, even if that person isn’t involved in the overall IT due diligence process. You want to know that good development practices were used, that the design is scalable and that there are no obvious security concerns.

A source code review can also identify any third party and open source components that are used in the target’s software. It’s very important to ensure that any open source components are used within the terms of their license.

Penetration Testing

If the systems or websites of the target store any sensitive data, it’s worthwhile to have a penetration test performed. This means hiring a resource to evaluate the security of the website and associated network infrastructure. In some cases, the testing firm will attempt to breach the network defenses and to access systems and data. You want to know about any vulnerabilities, and the potential cost to correct them, before you’re the owner. Penetration testing is a highly specialized service not typically part of standard IT due diligence efforts.

Industry-specific Requirements

Industries such as healthcare and finance are subject to various government regulations when it comes to secure storage and transmission of data, retention requirements and encryption. If the target accepts and processes credit cards on their own, a separate set of security requirements must be in place and verified.
Unless your IT due diligence expert is familiar with the relevant requirements, you’ll probably want an additional resource who is a specialist in these industry-specific issues to review them.

Staff Interviews

Having someone meet with the IT staff of the target company who can speak their language can be the most valuable part of an IT due diligence effort. These employees tend to be more open with fellow technicians, and can provide a wealth of information around the target technology’s strengths and weaknesses. In addition, familiarity with key IT staff skills sets can assist in integration planning.

Conclusion

With just a little extra effort, IT due diligence can come closer to reflecting the importance that IT plays in most businesses today. The relatively small incremental cost is well worth the investment.

In recent years, open source software has gone from something used mainly by startups and hobbyists to a resource that at this point is very much mainstream.  This article examines open source software and how it impacts IT due diligence.

What is Open Source?

Generally speaking, “open source software” refers to programs and projects that are developed by a company or an organized group of online programmers, and are made available with source code for free.  The software may be modified or redistributed by those who download it, subject to various open source license terms.

There is nothing inherently wrong with open source or its use in commercial environments.  In fact, many commercial software programs and services include open source components.

Well-known examples or open source software include:

• Apache (web server)
• Linux (Unix-like operating system)
• MySQL (database software)
• PHP (website scripting language)
• WordPress (blogging software)

Today, open source software is used by companies of all sizes.  While it’s often favored by startups due to its low cost, companies like Google and Amazon run significant portions of their operations with open source software.

While open source tools are available at no cost, they are not always “free.”  There are often optional packaging and support costs.  Still, in many cases, very capable and less expensive open source alternatives to popular commercial software tools are available.

Open Source Security

Traditionally, one major concern regarding open source has been security.  There are some valid points on each side of the argument.

Those who believe open source software to be less secure focus on the fact that, since the source code is available for anyone to see, a skilled hacker might be able to identify a vulnerability and exploit it.

Those who feel open source is more secure than commercial products also point to the availability of source code, but their argument is that since many eyes are viewing the code, any security weaknesses introduced should be quickly identified. Large, well organized open source efforts can sometimes issue security updates more quickly than a commercial software company.

Open Source Licensing

Open source software is made available under many standard licenses.   A list of common open source licenses and their terms can be found here:

http://opensource.org/licenses

Some licenses are very liberal, allowing the open source tool to be used in any way desired by an end user, including modification, redistribution and even resale.  At the other end of the spectrum, some licenses require that any redistribution includes the release of any supplemental or modified source code.

Occasionally, a company has acquired another only to later find that certain software assets just purchased were based on open source projects with a very restrictive license.  In that case, the options are to release the source code, redesign it to eliminate the open source component or to pull the product from the market.  Obviously, none of these are good options.

Practical Due Diligence for Open Source

Given the concerns around security and licensing, there are a number of areas to explore during IT due diligence.

First, a list of open source projects utilized by the target company should be requested.  This should include the name and version of the open source project, the license under which the project is distributed and whether the open source component is used for internal or external purposes.

If open source is utilized only for an internal development or administrative utility, there is usually little if any concern, as it’s normally the external distribution of any enhancements that may trigger some of the more restrictive license terms.

The target’s response to this request should be examined to understand the requirements of the relevant licenses in conjunction with a detailed review of how the open source component is used.  This will allow the acquiring company to begin to understand whether there are any concerns.

Due diligence should determine the target’s process for deciding whether to use an open source component.  Is a formal review of the open source license performed before a component is accepted for use?  Who makes the final decision?  Is this a senior staff member, with a thorough understanding of the relevant issues, or can an individual programmer make the decision and potentially put the company at risk?

The security concerns outlined earlier can be mitigated by the size of the open source community for a component and how active it is.  Large open source developer communities ensure that a project continues to be enhanced and supported.

Due diligence should examine, for key open source components used by the target, the process used by that open source project for reporting and responding to bug reports, especially when related to security issues.  Some of the largest open source projects have dedicated security response teams and a specific infrastructure related to security issues, but not all do.

Does the target closely track the updates to any open source components utilized?  Too often, companies bundle an open source component with a proprietary product, but don’t update the open source portion as that component is enhanced.  This can lead to the inclusion of outdated and potentially insecure open source software in the target’s own product.

Audits

The terms and requirements in some restrictive open source licenses cascade to downstream use.  For example, it’s possible that the acquisition target uses a commercial software component in its product or service that in turn utilizes an open source component.  The target may not have any idea that the open source component in indirectly included in its own software.

Audit tools and services exist to identify open source components and their related dependencies in software.  Audit firms track the source code from thousands of projects and versions and can automatically identify this code in the target’s own source code or object code.

Reference

Everything you’d ever want to know about the history of the open source movement, license terms, etc. can be found here:

http://opensource.org/

Conclusion

There is nothing fundamentally wrong with the use of open source software by startups and other commercial enterprises.  However, during IT due diligence it’s important to determine whether the target is using any open source components intelligently and responsibly.

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.