Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab SOC2 Security Compliance

What is SOC2?

SOC2 is a security control report developed by the American Institute of Certified Public Accountants (AICPA) based on the Statement on Standards for Attestation Engagements no. 18 (SSAE 18).

What are the different types of SOC reports?

Why is GitLab pursuing SOC2 certification?

SOC2 is becoming an industry standard for validating that a baseline of security program maturity is in place within an organization.

Customer benefits:

GitLab benefits:

Is GitLab SOC2 compliant?

Yes! GitLab completed the SOC2 Type 1 process in March 2020. For information on how to request a copy of that report, please refer to the requesting the GitLab SOC2 report section of this page.

Scope of the above SOC2 Type 1 report

The SOC2 Type 1 report available for customer and potential customers upon request is scoped to GitLab.com. There are elements of the report that cover organizational-level security considerations (e.g. Business Continuity Planning, Risk Assessments, etc.) which go beyond the scope of GitLab.com as a SaaS product and speak to the mature state of GitLab's information security program.

What are we doing to become SOC2 Type 2 compliant?

With GitLab's security control design already validated through the SOC2 Type 1 audit, the next step is to solidify those controls to ensure they are operating in the manner we would expect for all in-scope systems. If you're wondering why it would take another 9-12 months for this process, check out the why is it going to take that long section below.

What's the difference between SOC2 controls and the GCF?

The GitLab Control Framework (GCF) is an overarching set of security controls that satisfy many underlying compliance requirements (e.g. SOC2, PCI, SOX, etc.).

SOC2 is a subset of the requirements that the GCF satisfies.

What will be the scope of our SOC2 examination?

GitLab's SOC2 report will cover the people, process, and technology that make up GitLab.com. The exact inventory of systems that comprise this scope are still being developed but any system that is connected to systems/services that operate GitLab.com is likely to be included in the scope of this audit.

When are we going to be compliant?

Requesting a copy of the GitLab SOC2 Type 1 report

The nature of SOC2 reports is such that these reports cannot be made publicly available. Not only do these reports contain very candid information about how our systems operate (which could increase the attack surface of the organization) but these reports also contain proprietary information about how these audit firms conduct their testing. For these reasons we can only share SOC2 reports with potential customers that are under an NDA with GitLab or with current customers bound by the confidentiality of our customer agreements. These reports can not be distributed to anyone other than the individuals receiving these reports.

If you are not yet a GitLab customer and would like to request a copy of our SOC2 report:

Please send an email to security@gitlab.com with the subject line Requesting GitLab's SOC2 Type 1 report. The message body must contain contact information for the intended recipient including name, email address and job title. We can only send the report to prospects with a valid NDA on file with GitLab. Once we receive your email and verify that we have an NDA on file for your organization, we will email you a copy of this report.

If you are an existing GitLab customer and would like to request a copy of our SOC2 report:

Please send an email to security@gitlab.com with the subject line Requesting GitLab's SOC2 Type 1 report. The message body must contain contact information for the intended recipient including name, email address and job title. Once we receive your email and verify you are an existing customer, we will email you a copy of this report.

Why is GitLab offering me a SOC2 report instead of filling out my company's security questionnaire?

GitLab is in the very fortunate position of having a lot of new customers sign up for our GitLab.com SaaS service every month. With our focus on efficiency we have decided to invest the time and money into pursuing this SOC2 certification in part so that our customers will have an assessment on the maturity and design of our information security program. With the security team we have, we want to spend as much of that team's time as possible securing the GitLab product and providing as much protection to customer data as possible. Responding to each individual customer security questionnaire doesn't scale very well.

The SOC2 Type 1 report we offer to our potential and existing customers uses an industry baseline for the topics it evaluates; this report should offer a lot of the same information customers would be looking to collect through their individual questionnaires. If you find you still have questions after reviewing our SOC2 report we're very happy to answer those questions but we just ask that you target those questions to the information missing from that SOC2 report instead of having us respond to the same information that already exists in the report.

Why is it going to take that long?

  1. We don't want to roll out controls specific to SOC2 only to go back to our teams next year with controls specific to ISO. Instead we are taking a longer-term view of our compliance needs and created a comprehensive security control framework that will allow us to gather security control evidence and work with teams in a more efficient manner.
  2. SOC2 Type 2 reports require 6 months worth of operating security controls in order to validate the effectiveness of the controls. If we want to be audited for a SOC2 Type 2 report on 2020-07-01 we need to have all controls designed, remediated, tested, and producing audit-ready evidence as of 2020-01-01.

How will this SOC2 project impact other teams at GitLab?

Creating security controls from scratch is a difficult process. Each GitLab team-member is iterating on processes, developing new features, reconfiguring systems, etc. every day. Security controls require a certain amount of stability in order to generate effective evidence we can present to external auditors. Combine this with the collaborative approach the security compliance team is trying to take and it makes this process especially challenging. The security compliance team doesn't want to go out to GitLab teams with archaic requirements that have been around for 10 years just because auditors are used to those requirements and the evidence to expect from each. Instead, we want collaborate with GitLab teams and innovate ways to gather evidence and be flexible in the requirements we are establishing in order to create an industry-leading security compliance program. Since GitLab creates new and innovative software, this process is really challenging since the security compliance team don't have deep technical expertise in all areas of the company. Instead we have to parter with GitLab teams to come up with the best way to approach each security control and generate meaningful evidence we can use in an audit.

TL;DR: There's just no way to establish a security program that is external-audit-ready without adding a certain amount of friction for our teams. Please know that we take this extra friction seriously and work hard to minimize that friction as much as possible.

Who is responsible for the SOC2 project?

Where can I submit feedback for this SOC2 project?

Please add a comment to this feedback issue.

You can also contact the security compliance team if there's any way we can help.