We spend a lot of time doing due diligence audits for potential investors or companies that are considering an investment and need an external technology audit. Generally, we are brought on when a company's primary product is a web application. In these cases we dive deep and then provide recommendations based on areas where the organization has more risk.
Our Audit Components
When conducting a technical due diligence audit, we follow a standard checklist of questions that look at all areas of the technical product. The audit includes sections for architecture, performance, scalability, security, development process, and maintainability. Whether you’re preparing to get audited or looking for guidance on what an external auditor should look for, this post will walk you through the basic building blocks of our audit process so you know what to expect.
1. Code History & Architecture
In this section we want a general overview of how the code works, who built it, and what technologies it uses. The first step is to look at the overall architecture. We look specifically for code that’s clean, well-documented, and easily understood. It’s a good sign when code follows industry standards, including trusted open source components. If the code utilizes outside vendors, like AWS or Azure, we make sure those integrations are designed and used properly.
Another important consideration in our code overview is whether it was coded in-house or externally. While some degree of outsourcing is understandable, especially for fast-growing companies, it’s important that the in-house development team wrote all the core components of the software. This tells us they understand how it works and why it was built in a particular manner. We also look for parts of the code base that only one person understands. This is a vulnerability. The best companies have decentralized knowledge about the code so it doesn’t rely on one person.
2. Development Process
The strength of the development team is a critical indicator of whether a company will continue to be successful. We examine who is on the development team and how the team is organized. The team should have strong, experienced leaders and clear processes in place for communication and decision making. We’ve also found that the most successful teams are releasing regularly - at least once a month. However, continuous integration is the ideal system.
Another consideration is the type of revision control the team uses (Git, GitHub, Bitbucket, etc), and how they test new features before adding them to production. What is the process for testing, reviewing, and deploying a new release?
3. Monitoring & Scalability
We’ve found that it’s important to set up monitoring early on, and it’s a red flag if an organization doesn’t have any monitoring at all. It’s a good idea to have application performance, application security, infrastructure performance, website, and exception monitoring. While an organization may not need all of those in the early days, it makes sense to have decent coverage.
We also ask whether the system has been load tested and if the team knows the system’s max capacity. Every potential bottleneck will eventually need a remedy as the product grows, so thinking about capacity growth and the development environment from the outset is important. Load balancing also becomes important, as is identifying single points of failure in the system. The end goal is to make scaling as easy as possible. That means automating all possible processes, anticipating hurdles to scaling, and understanding the cost of scaling on new development and existing licenses.
4. Security
As a baseline, we expect organizations to have SSL, XSS mitigation, SQL using prepared statements or an ORM which protects against SQL injection, and other obvious security measures in place. Passwords and sensitive user data need to have a careful plan for storage, transmission, and backup. Ideally, the organization shouldn’t lose any user data in the event of a database server getting destroyed or otherwise lost.
The entire version control system for the organization should also be backed up in multiple locations. There should be clear upgrade and patching regimes for the core software and 3rd party software/services. It should be straightforward to recover in the event of a disaster, and it’s important for the organization to execute a disaster recovery test.
Technical Due Diligence, Explained
While there are many aspects to a technical audit and our audits get more detailed depending on the client, the above steps are a great starting point for what to expect when requesting or undergoing a due diligence audit. These steps are also useful for any growing company to consider, since they’re the best practices in architecture, development, scalability, and security. While a technical audit can be daunting, it doesn’t have to be as long as you have a few core components in place.