We got our SOC 2 Type II report (and you can, too)

At OtterTune, building a trusted and secure platform has been a top priority from the beginning. But as a company that deals with customer data in the cloud, we recognize how important it is for us to go the extra step and demonstrate our dedication to security to our customers.

This led us to pursue a SOC 2 Type II report that would provide evidence of our compliance with industry-standard best practices when handling customer data. We’re excited to announce that we have completed our first SOC 2 Type II audit process with zero exceptions! 🎉

In this blog post, we walk through what it means to be SOC 2 Type II compliant and explain why and how we did it. We hope to add to the reading material we found most helpful: articles from other early-stage SaaS companies sharing their experiences and insights from completing the SOC 2 audit.

What is SOC 2?

SOC 2 means Service Organizational Control 2, and it’s pronounced “sock two.” SOC 2 is a compliance standard developed by the American Institute of CPAs (AICPA), and it dictates controls  on security, availability, processing integrity, confidentiality, and privacy.

Certified CPA firms use the standard to perform SOC 2 audits and verify which parts of the standard an organization meets. Security is the only category that is mandatory for the SOC2 report. (OtterTune, however, met the standard in all areas, not just security.)

SOC 2 Type I vs. SOC 2 Type II

There are two types of SOC 2 reports: Type I and Type II. For both reports, the auditor checks that the relevant controls are in place and meet the criteria. The key difference is that the SOC 2 Type I report looks at a snapshot of controls at a specific moment in time, whereas the SOC 2 Type II report observes the controls over a period of time, typically 3 to 12 months.

The Type II report provides a higher level of rigor since it not only checks that the controls are in place but also that they are effective. Given this, a Type II report takes longer to complete – generally between 6-18 months – compared to a Type I report, which takes less than 6 months.

Zero Exceptions

If an auditor finds controls that are not designed or implemented correctly or that do not meet the criteria, these instances get recorded as audit exceptions in the SOC 2 report. When we announced at the beginning of this post that our report was delivered with zero exceptions, that means the auditors did not find any issues with our controls during their assessment, in security or any of the other areas checked: availability, processing integrity, confidentiality, and privacy.

Why we did this (and why now)

Since our initial product launch in October 2020, we’ve found data security to be a leading concern among our customers. We routinely receive requests from our prospective customers for proof of our strong security posture; the SOC 2 Type II report is the document that gets requested the most, by a large margin.

Interestingly, of the dozens of customers that have requested security documents from us over the years, not having a SOC 2 Type II report has only been a dealbreaker for two of them. We’ve found that in lieu of, or in addition to, SOC 2 and other standardized reports, many of our potential customers require their vendors to complete detailed questionnaires for their security teams to review. The issue with these security questionnaires is that they are verbose and hard to reuse, since companies typically tailor them to the specific security controls that they care about the most.

We quickly realized after filling out a couple of security questionnaires that it was a tedious, manual process and would not scale with our growing number of customers. As a result, the security review process would often take weeks or even months to complete. We lost a handful of business deals since a lot could change during these long processing times – for example, due to company priorities shifting or our “champion” leaving the company.

Our decision to pursue a SOC 2 Type II report was largely motivated by our need to streamline the security reviews required by our prospective customers to eliminate a key friction point in our deal cycles. Another reason is that it shows our customers that we care about security. A SOC 2 Type II report gives our customers a greater level of assurance than self-attested security questionnaires.

Lastly, one of the unforeseen benefits was that it helped with another project that was also underway – selling our product on AWS Marketplace. Many of the best practices and controls required by the Foundational Technical Review overlapped with those we had already put in place for the SOC 2 audit.

Why we went directly for a SOC 2 Type II report

The resources we came across when choosing between SOC 2 Type I and SOC 2 Type II offered similar guidance: if you’ve found that a non-negligible number of your potential customers will not accept a Type I report, then chances are you’ll need a Type II report relatively soon. If so, then going straight for a Type II report can save time and money overall.

We also determined which of the SOC 2 policies and controls we had already implemented at OtterTune to help assess how much extra work Type II would be compared to Type I. Some controls take longer to implement than others, and finding that we’d instituted some of the more time-consuming ones, like annual performance reviews, also helped us decide that a SOC 2 Type II audit was the right choice for our company.

How it went

This was our first time going through a SOC 2 Type II audit and the experience was pretty painless. The end-to-end process took around five months, including the time we time spent learning about SOC 2 and choosing our vendors. The timeline below shows how long it took and what we had to do during the planning, audit, and reporting stages. It also highlights when key events with our vendors took place.

What we did right

We made it through our SOC 2 Type II audit relatively fast and didn’t hit any major snags along the way. There were three things we did that simplified our audit process.

The first is that we had already implemented some of the controls and policies prior to SOC 2. This essentially gave us a “head start” when preparing for the audit. Our policies and processes included:

• Encrypting data at rest and in transit

• Enabling branch protection and requiring reviews for pull requests (PRs) in GitHub

• Using Terraform to deploy and manage our infrastructure

We also had policies and documents related to addressing potential risk in the company, such as the annual performance reviews we mentioned earlier. Our company documents included:

• Job descriptions

• An org chart

• Board meeting minutes

The second thing was that we used a compliance automation platform. This was a no-brainer for us, since a platform greatly reduces the effort needed to achieve compliance for companies with common tech stacks (like OtterTune). Also, as a company that offers tools to automate complex processes, saving the customer time and money, it seemed like something we “otter” do.

We went with Vanta because they supported integrations for our stack and were recommended by a colleague. After plugging them into our stack, the platform provided real-time visibility into our compliance status, gave actionable instructions to fix any issues detected, and assisted with evidence collection. They also had resources readily available at each step, from security policy templates to security training for employees.

The third thing we did was we followed the advice from companies that did their SOC 2 audit before us. For example, a recommendation we came across more than once was to confirm the audit date early on in the process. We took note of this and as you can see in the timeline, we started this discussion with our auditors less that a week after signing our contract with Vanta.

What was challenging

We put in a lot of effort to make sure that the processes and policies we created were not only SOC 2-compliant, but also suitable for our company. Here are some examples:

• We are 100% remote. To ensure workstations are secure, our employees must install an agent that checks for device vulnerabilities on each of their workstations.

• To ensure best practices in our daily operations, new employees must go through security training. We also have a strict change management process where all changes requires a security review.

• We store a lot of data in our system (> 2TB). We need a robust and flexible infrastructure to deal with security.

• Our company is fast-growing and we deliver a lot of new features over time. To ensure that our system is always secure and compliant, when we find a security bug, we fix it immediately. We also require a security review for each change.

What’s next

Completing our SOC 2 Type II audit is a major milestone for us, but our security efforts are ongoing. We’re committed to improving and maintaining our security controls and participating in these audits on an annual basis.