From day one, our mission has been to deliver a secure and reliable platform, and this commitment has only deepened as we’ve grown.
Despite being a young startup, we’re proud to have onboarded prominent customers like OpenAI, Notion, and Figma. For us, safeguarding our customers’ data is as vital as the powerful insights they gain from using Statsig.
As our infrastructure has evolved to serve a diverse range of customers—whether small or large, B2B or B2C—we’ve significantly expanded our security and privacy program. We now have a dedicated team proactively addressing both internal and external security needs.
In this blog, we’ll walk you through the key pillars of our security and privacy program and the practices we’ve put in place to achieve them.
From the very first line of code, security and privacy have been at the heart of every feature we release. Depending on the specific scenarios, Statsig offers multiple security options that can be baked into your design. Our customers frequently utilize features like:
Client vs Server SDKs: Choose the right SDKs based on your needs while ensuring different levels of privacy needs. It is worth noting that, in our client SDKs, all evaluations are precomputed on Statsig servers and sent down to you client applications. Experiment and gate names are hashed to mitigate the possibility of end-users spoofing into a test or feature.
Private attributes: Leverage feature flags and experiments without sending PII to Statsig.
User request deletion API: Handle on-demand user data deletion requests with ease.
Access management: Manage user access in line with your organization’s specific requirements.
Beyond these product features, we ensure that our applications run securely in all environments, from production to non-production. Key measures include:
Active workload monitoring to ensure our services remain healthy and free from anomalous activities.
Encryption of internal requests and communications between our services using TLS v1.2 and v1.3.
Regular scanning of our application binaries for vulnerabilities, with immediate action taken when necessary.
We also conduct regular white-box and black-box penetration tests, carried out by third-party security experts, to identify and address potential vulnerabilities in our systems.
While black-box testing probes our security using common practices without prior knowledge of the system, white-box testing provides testers with complete access to our applications and systems.
This approach allows them to uncover vulnerabilities that black-box tests might miss. If you’d like a copy of our latest security assessments, please contact our Sales team.
Data is the lifeblood of Statsig, and we treat it with the utmost care. All customer data is secured, regardless of its nature or whether it contains PII.
Here are some of the measures we take to protect your data:
Each customer’s data is logically segregated, with robust programmatic and access controls in place to isolate it from other customers’ data.
Within our internal systems, access to customer data is restricted to team members who require it for troubleshooting and diagnostics.
Data at Statsig is encrypted both at rest and in transit, using storage providers that meet the highest security standards. All data transfers, whether internal or external, are always encrypted.
Last year, we launched Warehouse Native Experimentation, which allows you to leverage Statsig’s powerful experimentation capabilities without your data ever leaving your warehouse. This solution has enabled many security-conscious customers to run experiments confidently, addressing their concerns about data security and privacy.
For more information about the security of our warehouse native product, we describe the Statsig Warehouse Native privacy and data storage policy in our documentation.
The majority of our services are currently run on Google Cloud Platform, which offers robust security features out of the box, such as DDoS protection and Deny by Default network policies. However, we’ve developed additional procedures and guardrails to further protect against network attacks and data breaches:
Access to our cloud services is strictly controlled, with Role-Based Access Control (RBAC) applied at various resource levels (e.g., organization, project, group) depending on the provider.
We actively monitor system activities and audit logs, triggering alerts if any unexpected access is detected.
In addition to the network policies enforced by cloud providers, we manage our own network policies to further protect our endpoints and resources from unintended behaviors.
Cloud resources are managed with policies that are enforced by automated processes, reducing the risk of human error in resource management.
Our selection of cloud service providers is meticulous and need to go through multiple stakeholders’ decisions and checklists. And if you're interested, we document our subprocessors.
At Statsig, access to our systems is tightly controlled. Team members are provisioned identities on an as-needed basis, with authentication requiring single sign-on, strong passwords, and two-factor authentication. Human identities work in tandem with our corporate network firewalls to prevent unauthorized access to our systems.
Each service within our systems also has its own identity. Service-to-service communication is secured by peer authentication, following strict authentication and authorization policies for each service. This ensures that unintended cross-service access is impossible.
All employee-owned devices that require access to our systems are centrally managed through an MDM (Mobile Device Management) software. This software controls the lifecycle of devices and their access to our systems.
Statsig is used by customers across a wide range of industries, each with its own compliance requirements. We work closely with our customers to meet their specific needs. Statsig has been SOC 2 Type 2 compliant since 2022.
(If you’d like a copy of our SOC 2 report, please contact us.)
We are also actively working on more compliance certifications. So stay tuned and/or talk to us if you are interested in knowing more.
We’ve had a bug bounty program in place since the very beginning of the company.
This program has been instrumental in helping us strengthen our platform, especially during our early stages. While we’ve since built a robust internal security and privacy team and program to detect vulnerabilities and protect our system, we continue to believe in the value of the bug bounty program.
The Statsig platform is better because of contributions from the entire Statsig community—not just our team. If you’re interested in participating in the program, please refer to the bug bounty page.
As we continue to enrich our security and privacy program, we’d love to hear from you. If you have questions or feedback about how we approach security and privacy at Statsig, please don’t hesitate to contact us or ask a question in our Slack community. Happy experimenting—securely!
Understand the difference between one-tailed and two-tailed tests. This guide will help you choose between using a one-tailed or two-tailed hypothesis! Read More ⇾
This guide explains why the allocation point may differ from the exposure point, how it happens, and what you to do about it. Read More ⇾
From continuous integration and deployment to a scrappy, results-driven mindset, learn how we prioritize speed and precision to deliver results quickly and safely Read More ⇾
The Statsig <> Azure AI Integration is a powerful solution for configuring, measuring, and optimizing AI applications. Read More ⇾
Take an inside look at how we built Statsig, and why we handle assignment the way we do. Read More ⇾
Learn the takeaways from Ron Kohavi's presentation at Significance Summit wherein he discussed the challenges of experimentation and how to overcome them. Read More ⇾