Zoo is now SOC 2 compliant

At Zoo, we are passionate about security. Zoo Design Studio is built on secure design choices—while our core product is cloud-based, the main storage location for CAD files is the user's local machine. We also perform regular source code audits, review the source code of dependencies, and report issues through coordinated vulnerability disclosure programs. If a bug is found in our software, we have a security policy in place to address it.

TL;DR: On top of that, we are excited to share that we have successfully completed our SOC 2 Type II audit!

Grab the report at trust.zoo.dev! We decided to make the report publicly available because opening support tickets or emailing sales to get access is painful. (Yes, we experienced that ourselves when evaluating our vendors.) Also, checkout our policy ruleset-policy-bot which helped us to complete our SOC 2 review.

What does this mean? I'm a customer.

SOC 2 is a compliance framework, and essentially it validates that we have implemented our security controls. When reading any SOC 2 Type II report, you want to go through the stated controls and also see if the auditors noted any exceptions. If they don't note any exceptions, it means that they verified that the controls are implemented appropriately.

The bottom line is that a SOC 2 report is a weak positive indicator of how well a company is doing security-wise. However, we still believe that any SOC 2 report delivered has a net-positive effect on any company's security. Security is a complex and huge field. It ranges from background checks, on and offboarding, access controls to memory safety and heap feng shui. It is a collaborative practice between HR, IT, engineers, and everything else that pops into your mind when you hear the word "company".

Start to repeat: How to do SOC 2

1. Decide on an auditor.
2. Go through the readiness assessment. For each proposed control, decide if you already fulfill it or if you need to implement something new. You can also decide that the proposed control is inadequate, like we did with email phishing tests, and adapt it.
3. Implement or adjust processes, technical controls, and policies.
4. Deliver evidence in the form of populations and samples (typically CSV files, screenshots, or documents) to the auditor. Auditors will create a selection of population items and will request evidence for those.
5. Receive the report and repeat! SOC 2 Type II covers a certain time frame. So once you have done it, you need to keep up following policies and processes. This is also why technical controls are great—they are harder to forget about.

Which changes did we make?

Zoo is a very fast-moving company. From the very beginning Zoo has a proactive security-first mindset. With roughly 35 employees now, we are still small enough that implementing changes is relatively easy. We started planning for SOC 2 in February 2025 and had the audit in our hands by the end of October 2025. The audit window started on June 1st. That means we were able to implement all changes in just 4 months. We think this was possible due to three main reasons: 1) we are small, 2) we already had processes around performance reviews, org charts, and background checks in place, and 3) we were already following best practices in engineering like IaC, testing, linting, and fully automated deployment (we deploy multiple times a day). You may wonder why performance reviews matter for a security report: A SOC 2 report is supposed to measure security-related risk, which also includes HR topics like training requirements, an internal whistleblowing form, contract requirements, onboarding, termination, performance reviews, and background check requirements.

User access and vendor review. This initial review was one of the most important parts during the SOC 2 implementation. It unlocked the possibility to deploy SSO for many SaaS services, perform vendor reviews, and focus on the relevant services and systems. We created a vendors.toml file that was born out of a previous Markdown vendor list. However, we went further this time, listing all vendors we use (and no longer use) and which employee accounts exist. We also listed which authentication methods are supported (SAML, OIDC, etc.) and which compliance certifications exist. Today, this handwritten TOML file has 4200 lines of text. Here is an example of a file entry for AWS:

[[vendors]]
name = "AWS"
description = "Amazon Web Services - Cloud provider"
owner = "Adam"
url = "https://aws.some.url.com"
how = "Ask the infrastructure team"
cio = false
auth = ["saml"]
level = "Production"
2fa = true
audited = "2025-09-10"
soc2-subservice = true

[vendors.certification-review]
last_reviewed = "2025-09-10"
soc_2_report = "https://console.aws.amazon.com/artifact/v2/reports/details/report-9RNhIQWolrSBhJxz"
noted_non_compliance = "None"

[[vendors.accounts]]
id = "user1"

[[vendors.accounts]]
id = "user2"

This file is updated and reviewed during every user access review (where we validate if the listing is accurate), vendor review (checking SOC 2 reports and other certifications), and onboarding/offboarding. We also parse this file using internal tools to generate overviews. The audited flag and Git commits serve as signoffs we present as evidence. The goal is to automate generating this file for as many services as possible in the future. So far, this method scales well, and we can complete a full user review within hours.

SSO. Leaning further into SSO is a huge win for IT and security teams. It's clear that managing employee access in a centralized place is easier than going through each service and revoking access. However, reality strikes: not all SaaS vendors support SSO. Our solution is an internal tool that can provision and revoke user access for SaaS services that provide an API. This is a kind of poor man's SCIM. One problem we encountered is the infamous SSO tax. We noticed a recent push to make SSO available on non-enterprise tiers. In our opinion, there is a difference between offering SSO only on expensive enterprise tiers and providing it as a few hundred dollar add-on, as Vercel does. Still not ideal, but better than not having any option for SSO. Cloudflare just recently made SSO available on free tiers! Thanks for that!

Reviews and GitHub rulesets. Our SOC 2 controls require us to have a formal review process in place for code changes. We already had branch protection rules in place, but those are not flexible or centralized. We also wanted a way to supervise changes performed by administrators. Organization or repository admins can edit branch protection rules and bypass protections. This might even be necessary in emergency situations. We were looking for a technical solution to supervise merges and bypasses.

Since 2023, GitHub has provided rulesets and has been adding features since then. Rulesets allow you to define organization- or enterprise-wide rules for repositories, branches, tags, or pushes. The neat thing is that you can define who can bypass the rulesets, and GitHub also provides an API to fetch rule violations.

We use the API to alert the security team in case someone performs an emergency merge, so we can follow up with reviews. Not everybody on the team can do rule bypasses, but enough can that we and our auditors saw the need for a technical control.

You probably know the "Merging is blocked" message on GitHub. With our setup, you may bypass rules and deal with the consequences. If you are only bypassing due to a failed test, then the security team is alerted, but no further action is required. If you bypass without a review, with our configuration, you are expected to explain yourself, raise an incident ticket, and document the reason for the bypass.

We open-sourced the implementation of our ruleset policy bot. If you find yourself in the same need, feel free to grab it! Originally, were inspired by Tailscale's ToBeReviewedBot which is also open-source! So feel free to check out their approach as well.

Endpoint security & MDM Endpoint security can be a difficult topic, as security teams cross privacy boundaries of employees. Deploying a firewall won't cause as much skepticism as installing a piece of software on employees' laptops. That is why transparency is the most important part when it comes to endpoint security. Without honesty, you won't have the trust of your employees. For that reason, we decided to deploy FleetDM and provide the complete endpoint configuration as a Git repository. Any employee can read the documentation of that repository or actually read the configuration and suggest changes. This was the key to getting buy-in from the team.

Getting that buy-in from employees was also straightforward because we deploy two tiers of endpoint configuration. The heavyweight tier is FleetDM and is required for higher privilege production access. The lightweight one is Google Chrome Endpoint Verification. Not every employee is required to enroll in FleetDM. The casual developer, who occasionally needs to access logs of production systems, is only required to prove a secure system configuration (patched OS, full-disk encryption) through Endpoint Verification. The managed Google Chrome browser is considered a secure endpoint if it passes endpoint verification. By using SSO, we can enforce that only devices that pass endpoint verification can access production data. Once we reach a certain size, we will likely revisit endpoint security. However, for the current phase of the company and while implementing SOC 2, this was ideal.

Vendor reviews. For us, the key was to categorize vendors into those that are relevant for production systems and those that are not. For instance, Figma does not have access to any production data, so we treat them differently than AWS or Cloudflare. Makes sense, right? It is a case-by-case discussion you should have with your auditors, but for the most part you get to decide what systems are audited and which are not. The front matter of any SOC 2 report will list which services and systems are being audited. Services like GitHub, CockroachDB, AWS, Cloudflare and others might come into contact with production data, so we review vendor documentation, including their SOC 2 report. We still perform a lightweight vendor review of vendors that serve as tools in our development process, but we do not verify their security controls in depth. We think this could be what a lot of companies or auditors get wrong—they try to review every single vendor in depth, which is not feasible and also not advised. Focus on the ones that can have a negative impact on YOUR company, product, employees, or service.

Establishing a policy framework. One of the most daunting tasks when preparing for SOC 2 is creating the internal policies and making sure they align with the SOC 2 controls. Among others, we created a reasonable password policy, an acceptable use policy, a change management policy, and a vendor review policy. Generally, we try to make sure violations of our policies are not possible by enabling technical controls. For instance, we set up password complexity requirements in our IDP provider. Furthermore, if services use SSO, then there is ideally only a single password employees need to remember, which allows us to use our WebAuthN hardware tokens with any SSO-enabled services we use.

Security awareness training. Our security partner NewHarbor, checked this one off the list for us. They did a great job delivering the important messages without boring the team.

Incident response plan. Another shout out to NewHarbor. We started with a template and moved that over to Markdown. Documenting processes and policies in Git makes it much easier to explain changes, have a version history, and perform signoffs. We also decided to have separate processes for operational and security incidents. Any security incident has major implications, while service outages can be less significant and can go with less process overhead.

Risk assessment process. Enumerating risks can be very useful, especially when dealing with security-related risks. In some sense, any risk assessment practice is similar to threat modeling. By just enumerating risks, you don't eliminate risks, but it can kickstart discussions about threat modeling. We value threat models a lot. It is the basis for any sane security research. When doing formal analysis, code review, or even fuzzing, you need to decide on the juiciest targets. Sometimes it's obvious what to target, but more often you just think you know.

Logging and monitoring. Meeting the SOC 2 goals for logging and monitoring our systems was pretty easy for us. We already have centralized tracing across all our backend services. The same is true for logging. For performance metrics and alerting, we use Prometheus. During the readiness phase of SOC 2, we focused primarily on adding security-related monitoring and alerting. Using existing tools, we built ourselves a basic SIEM. Luckily, the logging platform we use already calls itself a SIEM, which makes the compliance people happy.

Automated security testing. Recently, we have been integrating more automated security testing. All containers are scanned using Trivy. Source code changes are audited using Semgrep. SBOMs and potential vulnerability exposure are collected centrally in Dependency-Track and DefectDojo. For now, the value of using GitHub Advanced Security was not that great, so we decided to connect the open-source tools ourselves. In the long run this will provide us more flexibility, and we are still using GitHub's regular security features like Dependabot alongside that.

Independent security reviews and penetration tests. In 2024, we did an in-depth secure code review and threat model with Trail of Bits. Fourteen findings were reported, and all of them have been fixed. The report will go public in the next few weeks, so once available, I'll link it here. If you want to get notified once it's released, subscribe to our trust center. For 2025, we decided to do a more classic penetration test. For 2026, we have already scheduled another secure code review with Trail of Bits -- this time focusing on the new AI capabilities of Zoo.

Firewalls. Firewalls can be part of a secure system design. However, if you only open the ports you need, there is no need for a firewall. WAFs (Web Application Firewalls) can be useful to block common web attacks, and we enabled that through Cloudflare. However, this is likely be a case where terminology was created to sell products. A WAF is not a firewall in the classical sense. In network security, firewalls are primarily used to separate trust zones and segment the network. Typically, they do routing and manage the traffic. A WAF, on the other hand, is more closely related to a reverse proxy than a firewall application. The silver lining here is: If you have a WAF and your auditors want a firewall, they will likely be happy with that.

Trust center. The mentioned trust center is also an outcome of our SOC 2, as we need a place to publish the SOC 2 report, security reviews, and system diagrams.

Schedule. Did we already mention that SOC 2 is not a one-time thing? You need to keep up with it. For that reason we created a schedule that lists all recurring tasks we need to do. For that, we set up Slack workflows to keep us on track.

What we avoided

• MDM managing all endpoints. We found a security model that checks our controls without forcing every employee to enroll in MDM. At the same time, we can focus on a small group of employees with sensitive production access.
• Focusing exclusively on penetration tests. We conduct yearly security reviews. Some years it might be a classical penetration test, other years a secure code review and threat model. We don't want to box ourselves into a single type of review.
• Fixing every alert from Dependabot or other automated tools. We decided to triage those alerts on a regular basis, but not every alert needs to be followed up.
• Overwhelming IT-related teams with a full-blown EDR. We deploy lightweight ClamAV antivirus to our sensitive endpoints. While we do want to have EDR in place eventually, for now, fine-tuning EDRs for developers is not something we want to invest time in. Once Zoo reaches a certain size, we will revisit that decision.
• Running antivirus on server infrastructure. We don't know why this is still a common thing wanted by some auditors. It does not make sense, and our auditors agreed. Servers are not typical endpoints.

If you have good auditors, there is no need to bend over backwards to implement controls that do not make sense for your company. Go through the controls and align them with what you already do in your company. The auditors will be grateful to gain a better understanding of your company and product. Yes, there are some compliance elements you need to accept; however, many of them are more flexible than you might think!

Beyond SOC 2

We do a lot more to keep Zoo secure beyond SOC 2 requirements. We wish those were actually part of a SOC 2 review, but so far they are not.

However, legislation is also catching up, like with the Cyber Resilience Act, which will address SBOMs and vulnerability disclosure in the EU.

Coordinated vulnerability disclosure. We have a security.txt in place that describes how security researchers can report security vulnerabilities to us. We are using GitHub security advisories to track and disclose vulnerabilities.

SBOMs. We generate SBOMs for all our services and store them in a central location. This makes it easier to track dependencies and their vulnerabilities.

Use of hardware two-factor authentication. While SOC 2 requires two-factor authentication, it does not mandate WebAuthN hardware tokens. We decided to enforce hardware 2FA for all employees anyways, which eliminates phishing attacks.

Fuzzing. We are fuzzing critical components of our system. A blog post with details about our fuzzing setup and our findings is coming soon!

What's next?

Prepare for the next SOC 2 Type II audit. We have everything in place; now the goal is to maintain documentation, policies, and processes. Also, we are cleaning up and creating new internal documentation about which processes are in place and how to follow them.

Apart from that, the current tools we put in place need to grow with the company. As we hire more employees, we will have a bigger IT team. Work that is currently done by the security team will be shifted to IT. Likely, we will also invest in more rigorous alerting and integrate systems into a proper SIEM.

Overall, I'm happy with the outcome of our SOC 2 journey. As expected, preparing for SOC 2 had a net-positive security outcome. But I'm also happy to get back to focusing on other security initiatives beyond SOC 2, such as our fuzzing efforts and improving our secure development lifecycle.