Picture this: You're on a sales call, everything's going great, and then they ask: 'What's your security certification status?' Your heart sinks a little. Sound familiar?
At Zoios we heard this question from day one—and it's why we pursued SOC-2 certification earlier than most startups our size.
The SOC-2 attestation aims to provide a way to show that a service organization has effective controls in place related to security, availability, processing integrity, confidentiality, and privacy of customer data. It covers both technical controls but also general company policies. Think of SOC-2 as a trust badge that tells other companies: "Hey, we take your data seriously and have our act together." It's not just about security—it's about proving you run a professional operation.
For context we are a small company (less than 10 employees) working in the HR space, helping companies understand the wellbeing, stress and performance of their organizations.
Working with individuals’ data led to questions about our processes very early. These questions usually come in the form of “do you have x and y certification?”, “can you fill this form?”, “what is your process for x?”.
These questions are a good sign that the org can benefit from using something like a SOC-2 attestation to help set in place all the processes that will position the company to be able to fulfill these kinds of expectations.
When we started our research, we noticed two patterns:
To address the first issue we decided that we wanted to get help to do this. To use a system/service that could help us understand what needed to be done and help us keep track of it.
To address the second point, we needed to figure out point #1 first.
That was when we started talking to possible vendors. At the end of the research we met with two specific vendors for proper sales calls. These were Vanta and Oneleet.
To cut the story short we went with Oneleet and we are very happy with the decision up to now.
At that point in time they were starting to expand their offering from being a penetration test specialized company into helping with the full security and compliance stack.
The support and knowledge we got from Oneleet on the first year was excellent and I can’t recommend them enough.
It was only after talking with the Oneleet team about our specific situation that we started to understand the work needed we were able to make a plan to tackle it.
There are two processes; one for a SOC-2 type 1 and a different one for SOC-2 type 2. We decided to go for the Type 2 attestation and that is what we talk about here today.
The main idea of such attestation is to show that the company have robust processes in place, is able to describe these processes and follow these processes as described.
The attestation flow consists of roughly three phases:
Our process was kickstarted with a meeting with our contact at Oneleet. At this meeting we provided him with all the relevant information on what we do, our tech stack, the company, the team, etc. The goal of this meeting was for them to get a picture of our situation.
This phase took around a week, but didn’t require a lot from us. After we provided the insights, the Oneleet team went to work and came back with their suggestions.
After that we had a follow up to go through the controls they suggested as applicable for us. At this stage it is important to be critical on whether each control makes sense for the reality of your company and product. Smaller companies can skip a few controls which are designed for larger companies.
For example we did have a long debate on the need for a specific requirement that would lead us to get a Cybersecurity insurance. Upon researching it, our insurance provider in Europe had not even heard of it. We also discovered it to be something more applicable to the American market, which is at this point less relevant to us.
These controls will be the basis on which you are going to work towards building/documenting your processes.It will also be the basis for preparing for the upcoming audit.
Once you have decided on the list of requirements applicable for your business, the next step is to figure out what are the specific expectations of each requirement.
In this step your vendor might be very helpful. In our case the Oneleet platform breaks down each requirements into many specific controls. For each control you’ll be expected to provide documentation as to how your company lives up to that.
Some controls involve implementing specific processes, E.g Employee onboarding, Physical access control, Access management, while others will require simply documenting that you do it.
Here’s the biggest time sink: You need to document your processes. That means writing them down and making sure to document that people went through them. This step can take lots of time if you are starting from scratch but, and again, here your vendor can help you out with templates to get you started.
For example; having to describe in details your disaster recovery process when you are just a 10 people start up can feel a bit overwhelming, but it is not too bad once you go through it.
On top of that, your vendor will probably provide automations that will keep the evidences in place automatically based on your systems. This is useful for requirements which involve Github settings, cloud vendor settings, etc.
My advice here is to avoid the temptation to promise too much. Think through what the requirement is aiming at and make sure that you fulfill that.
Go beyond the basic requirement when that makes sense for your case, but remember that if you promise, you are expected to prove you live by it.
A penetration test is not strictly required for the attestation, however, it is very much recommended. Especially if you’ve never done it and don’t have a dedicated security team.
My main advice is:
Remember, the test results are mainly for your business improvement. Learn, dig in, discuss the solutions and make sure that you get out of it better.
In theory the audit should be a mere formality assuming the other steps went on smoothly.
Most vendors will take care of selecting the auditor and dealing with them during the whole period.
As the auditee you must be available and ready to provide further documentation if needed. If the evidence gathering stage was thorough the needs will be minimal here. Your mileage may vary.
Here's something nobody tells you: every tool you add multiplies your compliance work. Using AWS, GitHub, Slack, and Google Workspace? That's four systems to monitor, document, and secure.
Everything need to be monitored and controlled. All your service accounts needs to be documented and properly disabled when not in use. All services mapped, admins appointed, inventories kept.
The more complicated, the more monitoring you’ll need to do, evidence to gather, surface for attacks to document, processes to create etc.
Defining your processes will impact your operation directly. In practice that means that you are always expected to operate in the way you have described on your workflows, and expected to document whenever you deviate.
Looking back, getting SOC-2 certified as an early-stage startup felt like a mix of a bad idea, an impossible hurdle and a sign of professionalizing. But here's the thing: it forced us to build better systems that actually made us more efficient.
If you're on the fence about starting your SOC-2 journey, my advice is simple: start before you think you're ready. The process will make you better, and your future self (and sales team) will thank you.
Here’s how I would start:
Getting these 5 steps rolling will put you in a good place for when you start the process.
Got questions about the process? Drop me a line at jorgelopes@hey.com. I'm happy to share the nitty-gritty details that didn't make it into this post.