Announcing: Jam has achieved SOC 2 Type II compliance
If you’ve been a Jam customer, you know privacy and security are part of our ethos — with guardrails baked into every facet of product development at Jam. Today, we’ve officially achieved enterprise-grade privacy and security standards for every software team who wants to Jam!
In just under 18 months, our user-base has grown from 1 to 60K+, the use-cases for Jam have expanded, and our customers— from large enterprises, to early-stage startups— now rely on our platform as a core driver of engineering QA processes. As we enter this exciting stage, we remain committed to the responsibility that comes with that level of trust - and we don’t expect our customers to “take our word for it.”
So, we took our existing security and privacy policies, made them even more robust, and put them under microscopic scrutiny. Now, Jam is compliant with the strictest security framework. In this post, I will walk you through why we got SOC 2 compliance, how we accomplished it, and what we are doing to continue to maintain this standard.
What is SOC 2 and why we pursued it
SOC 2 is a compliance framework for auditing and reporting how a company handles customer data. There are two types of SOC 2 reports: Type I and Type II.
We pursued Type II because of its more rigorous standards. SOC 2 Type II audits include an additional requirement where a third-party auditor ensures that you are following all the security practices that you claim for a longer period of time. As I mentioned before, Jam already had a strong security policy internally, but we believed it was important for our customers to see that we do what we claim to do. On top of that, SOC 2 Type II compliance is a box many software buyers need to check before they can even try out your product. We want more and more companies to find it easy to report bugs and move fast. So it was a no-brainer!
Getting ready for the audit
“Failure to prepare is preparing to fail” - John Wooden
Contrary to popular belief, getting ready for the audit is 80% of the work and not the audit itself. How you prepare, determines what your audit will look like.
Looking back, I struggled the most when we were about to start preparing for our audit. There was not enough information out there about how a company of our size (and stage) achieved SOC2 Type II compliance. As a result, I am going to spend most of my time writing about how to prepare for the audit.
Step 1: Find an engineering partner
Find someone who you can rely on to set up the required developer practices to comply with SOC2. For example: someone who has the authority to and can set up the right permissions and practices (code review policies) in GitHub, logging & monitoring and firewalls for your cloud environment. At Jam, I closely worked with our engineering lead Tony Stuck (thank you, Tony!).
Step 2: Set up a Slack channel to keep everyone informed
We created a channel called “project-soc2-readiness”. We used this channel to share our progress with the rest of the team.
Step 3: Create a project in your preferred issue tracker and work backward
Set a deadline for when you will be audit-ready. The process took 6 months from start to finish, we aligned on prep time before we started our audit. Once we picked that date, we worked backward to identify what milestones we needed to hit. We created a project in Linear (our issue tracker) called “SOC2 Readiness” and created 171 tasks and sub-tasks. We weren’t shy about the number of tickets because we wanted to capture every single task (doesn’t matter how small) to ensure nothing fell through the cracks.
Step 4: Single place to manage documentation
Next, we created a Notion space called ‘Security’. This was our central hub to store documents related to our SOC 2 compliance process. This is what it looked like:
The idea was to have a one-stop shop to find relevant processes (or standard operating procedures), incident reports, tabletop scenarios and meeting notes related to our security efforts and SOC 2 process. The space is visible to everyone in the company.
Step 5: Weekly meetings to track audit readiness
Tony and I met every week to track our progress for SOC 2 audit readiness. We used this meeting as a forcing function to make progress.
In the beginning, we needed the full hour but as we started getting closer to our observation period, the meetings were closer to 5 - 20 mins.
Step 6: Start with the policies
Getting the policies created, reviewed, and approved took the longest time. You will be using these policies to codify (or create) security practices for the company. We started with templates from Drata that were very helpful. It may seem tempting to copy-paste everything from the templates, but be aware that you will have to abide by everything listed in your policies to get your SOC 2 compliance with zero exceptions. Not all of the specifications in templated policies will be relevant for your company, so make sure to only add things that make sense for your business. Once we drafted the policies, we got them approved by our primary stakeholders i.e. our engineering lead (Tony) and CEO (Dani).
Step 7: Watch out for common pitfalls and avoid them
A common pitfall? According to our auditor, businesses often get marked on exceptions around timeline-specific policies. For example; if you say you do quarterly vulnerability tests, you must perform vulnerability tests every quarter. For us, this simple tip made a big difference: “there’s no such thing as over-documenting.” As you review your policies, create a separate document, we use Notion, to note down the tests/tasks that should be done in a specific time-frame, as well as who’s involved in each one. If you don’t keep track of these requirements, they will come back to haunt you later.
Step 8: Set up a meeting with your auditor’s customer success team
We are not talking about Drata’s customer success team — before you start your audit, you can ask your auditor as many questions as you want. From our experience, we recommend you also set up at least one meeting with the auditor’s customer success managers. It might seem unnecessary, but we found this meeting to be super valuable. We learned about specific details we would’ve missed, if we hadn’t taken up on this free meeting from the auditors at Prescient.
For example, our auditor’s CS team flagged that some controls inside Drata would pass the initial screen just because of a corresponding policy. However, when it comes time for the audit, the auditor will ask for the policy and corresponding evidence for that control. Our customer success manager from the auditing team shared a spreadsheet that detailed all of the policies that are easy to miss and require manually preparing evidence.
Step 9: Prepare your simulation exercises (but don’t perform them yet)
Sure, you can perform them before the audit, but it will be redundant. This is how we went about it: First, we prepared all the documentation - and only when our audit window started, did we perform the business continuity exercise and the security incident exercise. You can do a dry run before the observation window, but if you do, just keep in mind that the auditors will want to see it again during the audit.
Step 10: Once you reach 100% readiness, set up meetings with your auditor and Drata customer success manager
Once Drata said we were 100% ready for an audit, we set up meetings with our auditor and our customer success manager at Drata. We did not have a specific agenda, we just wanted to do a sanity check to see if we were missing anything.
We worked closely with Drata to figure out what controls and policies we needed to put in place to be audit-ready. It started with codifying security practices into policies and getting everyone in the company to accept them. Then, we integrated Drata with our cloud environment to monitor if we are compliant or not. If Drata notices an anomaly, it immediately alerts us so that we can resolve the issue and continue to stay compliant.
The audit process
Once you’re ready - the auditing process is fairly simple.
Step 1: Slack integration
After we reached 100% readiness, we set up our Slack integration with Drata. The integration sends a Slack message when one or more controls are not ready. We waited to integrate Slack because we already knew exactly what controls were missing, so the Slack integration at that stage would’ve been noisy and not so valuable. However, once we were audit-ready, it became crucial to know if one or more controls were not ready for our audit instantly. A Slack message early in the morning was great for giving us a heads-up on anything that needed fixing quickly, without sacrificing our audit readiness.
Step 2: Set up regular check-ins and schedule maintenance tasks
We had bi-weekly check-ins with our auditor. This is usually a meeting where the auditor makes bulk requests for evidence you have to provide. We also scheduled our annual pen test, quarterly vulnerability test, business continuity tabletop exercise, and security incident exercise during our observation period.
Our ongoing privacy and security efforts
Jam’s data privacy and security practices will continue to adhere to enterprise standards. Our security policies are supported by quarterly vulnerability tests, and annual exercises as dictated by SOC 2 Type II requirements.
Need a copy? If you are a Jam customer or thinking about getting started with Jam, contact us at security@jam.dev to receive our SOC2 Type II report.