Product

Multitudes is now SOC 2 certified!

9 min read
Text on abstract background

We’re excited to share that Multitudes has been awarded SOC 2 Type II certification! This is an independent verification of the standards we use in our approach to security, privacy and managing customer data.

Now that it’s official, we wanted to share a little about why we prioritized getting certified, what we learned along the way and some tips for others who are heading down this route.

  1. Why SOC 2? 
  2. The process (including timeline and costs!)
  3. Our tips

Why SOC 2? 

SOC 2 is a voluntary compliance standard, and we’ve gotten pretty far without it by having good security practices and filling out security questionnaires where needed with potential customers. That said, we always knew that we would need to get it someday, but given that it takes a lot of time (not to mention money!) to get certified, the question was when. 

For us, the main tipping point was when it started coming up more with potential customers. Especially for companies that are already SOC 2 certified, it’s much easier and faster for them to work with vendors that have the same certifications. For all potential customers, it means a faster security review and less time spent answering questionnaires. 

The second reason is that it’s a good way to acknowledge the hard work we had already been putting into security. We’re lucky to have had engineers from the start that have always cared deeply about security (shout out to Emily in particular!), so this mindset was hardwired into how we built Multitudes. Getting certified means we’ve had third-party, independent verification that the way we process our customer data is secure, and our team has had formal recognition for all the hard work they’ve put in. 

A final note here is that we debated whether to do SOC 2 or ISO 27001 first. They’re both security compliance standards, and in many cases, having one is enough for potential customers. In the end, we decided to start with SOC 2 because it’s more expected in the US (it was developed in the US so this isn’t surprising!), and our non-US customers were happy to accept it rather than ISO 27001. 

Why we did it: 

  • Easier and faster onboarding for customers, especially ones that are SOC 2 compliant
  • Recognition for our already-great practices around security
  • A well-recognized standard for our US customers, and one that our non-US customers were also comfortable with

The Process: Timeline & Cost

Before we get in to the timeline, it’s good to understand where we were starting from: 

  • Our in-house security champion Emily (who listens to alllll the security podcasts*) had embedded security considerations into our team and engineering practices.
  • We had already thought deeply about our approach to security, including creating a Security and Privacy page on our website that outlines our policies on everything from encryption, to environment segregation, to device management.
  • We completed an AWS Well-Architected Review with an AWS Solutions Architect; these are free for AWS customers and we found it valuable to get feedback from an experience architect 
  • Our team was doing annual security training (👋 shout out SafeStack!) 
  • We had a CAIQ questionnaire that we updated annually. This was a tip from a security expert; it includes a lot of the questions you’d regularly have to answer in a security review with potential customers if you don’t have SOC 2 or ISO 27001.

With all this in mind, we hit the first milestone of getting Type I certified in February, and were audited for Type II from April to July of this year. We started preparing a couple months in advance, to choose the auditor and pen tester, a tool to manage the process, and to get it all set up.

The all up cost for getting certified, including Vanta, our auditor Johanson Group (more on that later), and penetration testing was $17K USD. That covered both Type I and II certification, so it will be a bit less in future years, since we’ll just need to do the recertification for Type II annually. 

*Since posting this, we’ve had lots of people ask for Emily’s favorite podcast. We asked her, and she recommends the Darknet Diaries podcast for “really interesting stories from pen testers, social engineering experts and everything in between”.

Our tips

Now that we’re on the other side of this journey, we wanted to share what we learned along the way, in the hope that it could help others.

  1. Put good habits in place

The focus we put on security from the start helped us sail through the audit process – and the SOC 2 process prompted us to add good new habits as well. 

💡A practice that we’ve had for a while is setting up smart automations – e.g., using tools like Dependabot and Renovate to find and fix open PRs that address vulnerabilities. That served us well through the SOC 2 process.

💡At the start of the SOC 2 process, we also decided to set aside weekly engineering time for security. We started doing a recurring Friday afternoon session to clear out security alerts; it worked so well that we’ve decided to continue this practice even now that the formal audit period is over. Carving out time for good security hygiene means that we stay on top of changes and we know who’s reviewing this regularly.

  1. It’s worth paying to work with the right people

We’re a startup, so we’re conscious of costs – and we knew heading into the SOC 2 process that it wouldn’t be cheap. That said, we wanted to make sure we were getting the right advice and support. In the end, we chose to work with Johanson Group as our auditor. They weren’t the cheapest, but they came highly recommended (thank you to the folks over at Runn!) and now that we’ve completed the process, we can say that it was worth paying a bit more to get better support.

💡Some tips for when you’re shopping around for suppliers: 

  • Set up a call with the potential vendors to ask some questions. From the start, the Johanson team was generous with their time in answering our questions and very responsive over email.  That was part of why we decided to work with them, and this stayed true throughout the audit – they were easy to work with and happy to answer our questions.
  • If you are using a tool to help you with compliance (e.g. Vanta), look for an auditor that’s familiar with it.

💡Once you have a great auditor, our next tip is to cover as much as you can with them in advance of the audit. We sent the Johanson team lots and lots of questions to make sure we were preparing correctly (thank you, Mark!), and we also gave them access to Vanta in advance to do some early checks. All of this meant that we felt much calmer and more prepared by the time the audit period started.

  1. It’s as much about people as engineering

Because it’s a security audit, we had expected that it would focus on our app security and engineering practices. So we were surprised by how deep the audit went into people and communication. Maybe it’s because we started out with good security practices, but the engineering changes required were minimal. Instead, there was much more documentation around on policies and people. 

The areas where it went deeper than we’d expected were things like: 

  • Employee performance reviews
  • Board minutes and policies
  • Communications to customers about key system changes
  • Checking employee agreement to a Code of Conduct and Confidentiality agreement

Reference checks: Note that, for fairness and equity reasons, we do thorough reference checks instead of background checks for new employees. That’s because background checks are subject to systemic bias (check out Lauren’s talk here for more information and resources).

We hope that helps other companies looking at SOC 2 certification! If you want to hear more, get in touch or join our Tech Leader Chats community.

Contributor
Nicole Jackson
Nicole Jackson
Content Contributor
Support your developers with ethical team analytics.

Start your free trial

Join our beta
Support your developers with ethical team analytics.