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).
SOC2 is becoming an industry standard for validating that a baseline of security program maturity is in place within an organization.
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.
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.
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.
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.
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.
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 make a potential attack against GitLab easier) 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 prospective 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.
We invite you to contact our Sales Team to kick off the process. The easiest way to do this is through their form here: Contact Sales. They can discuss pricing and plans that suit your needs before processing the NDA. We also have our Customer Assurance Package which includes publicly-available security questionnaire responses and a collection of the information our customers frequently request.
The GitLab MNDA template can be found here, and once completed the document should be uploaded as an Attachment by the GitLab Account Owner to Salesforce. General information about the process can be found on the order processing handbook page. The Account Owner may email firstname.lastname@example.org on behalf of the prospective customer. Please include the prospect recipient's name, job title and email address in the request.
Please send an email to email@example.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.
To request a SOC2 report on behalf of a customer, please message the Field Security team in slack #sec-fieldsecurity. Please include the following information:
Customer under terms- include SFDC link OR
NDA- include link to NDA
Information Security Analyst, etc…
NOTE: Due to internal system issues, we have experienced issues with GitLab team members emailing firstname.lastname@example.org. If you have emailed email@example.com and have not heard back please ping us in the #sec-fieldsecurity slack channel. If you've requsted a SOC2 report and have not heard back in a reasonable time, please reach out for clarification. Please note we currently group requests for SOC2 reports and strive to send reports out 2x a week.
If you are a GitLab team member please reach out to Field Security via #sec-fieldsecurity and request status, if you are a customer or prospect, please send a reply to the auto-generated email that was sent to you via Zendesk.
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.
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.
Please add a comment to this feedback issue.
You can also contact the security compliance team if there's any way we can help.