Similar to the compliance space, security is an area of a system or product that is not prioritized appropriately. It is also an area that may require an expert that doesn’t currently exist on the development team. Some questions to ask are:
- Who has access to the production environment and why?
- How is both physical and digital access managed?
- Is data encrypted at rest?
- Is data encrypted in flight?
- What strategies are used to ensure there aren’t internal holes in our infrastructure and its access?
- What tools are used to ensure that malware is guarded against on team members’ machines?
- What level of security tooling is in place to keep people from getting into the software product or its supporting infrastructure?
- How is the infrastructure configured from a security perspective?
- What sort of monitoring is in place to validate network traffic?
- If attacked, what tooling is in place to deal with it?
First, I’m not a lawyer and Inventive doesn't provide legal advice. I can only tell you stories from the trenches. Get a reasonable attorney that specializes in IP law. If you can afford it, get a team of lawyers so that you have at least two sets of eyes in the process. If the contract side is not perfect, you may find yourself tied to a vendor forever or never fully owning your software. Many of the questions above will ferret out any questionable areas of the product. But some critical things to have spelled out and understood include:
- What is the timeline for transition?
- At what point will I see and thoroughly inspect the software, team, and related processes?
- Will I get access to the software’s source control, including its history?
- Will I own the data as well as the software?
- Will I own the data schema and all related logic in the data storage system?
- Are there any dependencies in my system that I will not own the rights to?
- For how long will your team support ramp up my team?
- Who is responsible for getting the software running in my environments?
- Will I have a third party review the system and all required dependencies and systems before purchasing the software? (due diligence)
IMPORTANCE OF A THIRD-PARTY POINT OF VIEW
From our experience, be sure not to use the “smartest technologist in the room.” You might know someone that appears to be a technology expert. They may even have worked at Google for a time and are legitimately super smart. However, that doesn’t mean that they are an expert in auditing systems or in what you are acquiring. Don’t fall into this trap, as you may end up purchasing something you quickly regret. Some areas to look for in a non-emotional third party are as follows:
- Do they know the tech that is used in the product I am interested in purchasing?
- Have they audited complex systems before?
- Do they have an example report they can provide of past projects?
- Do they have references for the work they have performed before?
- Are they larger than one individual capable of leaning on many different team members for specific areas of an audit?
- Does the team come with a history of building large and small systems?
- Does this teamwork in my industry and understand what I am trying to achieve with this acquisition?
As you can tell from the above, looking at an existing system for acquisition purposes is no easy task. This post is a starting point for auditing a technology product — large or small. Be sure to use the sheet we have prepared for this article as a way of tracking what you find out about the product during your audit.
There are many different areas to consider, and they are not all purely technical. Each of these high-level areas can be dug into even deeper depending on your plans post-acquisition. If you tend to integrate the existing team into your company, there are many other areas to dig into. If you plan to migrate off the existing infrastructure to your infrastructure, there are many areas to consider as well.
Join our mailing list to find out more about auditing software systems, teams, and infrastructure. We have many great articles planned on this topic.