Software Due Diligence for Acquisition

Whether you are thinking of acquiring software or performing assessment for somebody else there are a couple of main questions you need to have answered.

Section 1


Was the environment properly maintained and documented?

A. Is there an active disaster recovery plan in place? i.e. Offsite backups; GIO redundancy; Contingency Plan?

B. How well software application is documented? Are there ongoing revisions for documentation? Is there a clear application requirements and environment specifications? Are there logs of past outages with known resolutions?

You will always find something that is not right. The key question is how critical are those things for your acquisition? If you plan to use software as it is and sell it to more users, the one "make it or break it" question should be, "Can application architecture scale?" If you are acquiring software for its great workflow and user experience and not planning to expend into the market, it may be OK not to look into the scale and load testing. You have to understand the inherent bottlenecks, however.

C. Last but not least is infrastructure that is currently used for the software application.

Section 2

Development and Management Team

Do not underestimate the value of the team that develops and managed the software today. You should meet people face to face and get a feel on what their values are and how they approach issues and challenges. Junior developer on the team is as important as CTO. Their values will be directly correlated to how software was build. After initial phone screening it helps to schedule on on-site visit. There should be at least two people for a technical evaluation: one subject matter expert (SME) (You do not want a .Net person doing a Ruby on Rails evaluation) and one business minded architect.

Section 3

Intellectual Property Handling

It is also important to check if software used any open source code or Right to Use code. You will need to consult IP attorney to evaluate full scope of Intellectual Property writes with your perches. If software has integration with other, evaluate how this connection is performed and what written agreements there are in place to keep using it after write of ownership have been transferred.


Section 4


My background is in Information Security and I can't stress enough how much we all at risk because most of the software on the market has been written by development teams that cares mostly for the functionality of it and not so much security. The high level questions I would ask are

A. Is RBAC (Role Based Access Control) implemented and properly documented?

B. How communication stream between application tears have been secured?

C. Is there any communication that is happening over a Public network that carry privet data? If yes, you not only need to ask for a copy of a firewall policy, but possibly hire penetration expert to scan and assess all vulnerabilities.

D. What operating system application was written for? Is host OS property and regularly maintained? Were there any known issues that host OS security causing to the application?

E. Is database security maintained properly? What about administrator role accounts, how often those passwords are changed?

Section 5

Regulatory Compliance Issues

Are you purchasing software in the industry that has some regulatory compliance? Health Care, Pharmasuticals,  AirForce, Gambling, Financial and Banking those are top industries that heavily regulated. Check relevant compliance regulations: PCI DSS , FISMA, GLBA, SOX, ISO 27001 and HIPAA.

Section 6

Business Claims

If existing business is selling software and claims it to be better because it already have a lot of users or it is very user friendly, it helps to validate those claims by a simple research.


No Comments Yet.

Leave a comment

You must be Logged in to post a comment.