Be open about as many things as possible. By making information public we can reduce the barriers to contribution and make collaboration easier. Use public issue trackers, projects, and repositories when possible. – The GitLab Handbook
Transparency is one of our core values and a fundamental part of what makes GitLab unique. But openness and System and Organization Controls 2 (SOC 2) audits often don't go hand in hand.
A quick history of the traditional audit
At traditional organizations, seeing a high level of transparency with documented procedures and processes publicly available, is not typical. And when the time comes for these organizations to undergo an audit, the process is time-consuming and can be burdensome for many employees who have to balance audit requests on top of their day-to-day work responsibilities.
For these same employees, a lot of time is spent digging through process documentation, policy documents, and even workflow documents, which is only the starting point for an audit. Eventually, this trickles down to the auditors having to meet with these employees to understand how the processes, policies, and workflows are executed, which means more time is sacrificed bringing an auditor up to speed on internal processes and procedures.
What does our approach to compliance look like?
At GitLab, we value transparency so much so that everything we do as a company is public by default. If the need arises for information to be kept private, we have a policy in place which requires GitLab team members to provide justification within our (public) handbook as to why specific information can not be made public.
Specific to compliance, handbook pages detail the implemented controls that exist in our environment, including the scope that each control covers, the groups and/or process owners for each control, and even how we’ve mapped these controls to various industry standard compliance frameworks (e.g. ISO, PCI, SOC 2, etc.). Our handbook is the central repository for how we run the company. The change history for any update made to the handbook is available publicly. This means that the wider GitLab community is able to hold us accountable for what we say we do, and how we do it. Our handbook is geared for self-serve consumption: readers gain visibility into and understanding of how processes are executed and any nuances that should be considered.
This same self-serve approach applies to compliance and undergoing an audit, where we aim to enable an auditor to self-serve as much information about our processes and procedures as possible. In this case, we save the time control and process owners would have spent walking an auditor through how these processes are executed internally.
Beyond decreasing the audit workload of control and process owners, transparency earns more frequent feedback and contributions from people outside the company.
This enables us to collaborate with our valued customers and partners and deepens the industry and community understanding of our business, culture and values. Furthermore, we experience the added benefit of recruiting people who share our values.
How did our transparent culture impact our first SOC 2 Type 1 audit?
Almost all information about GitLab and the work that we perform day-to-day is available publicly (with the exception of any data that is considered not public by default). This opens a door that allows external auditors to do more digging and potentially ask questions that we might not be prepared for.
Knowing this helped us know where and when to push back on our auditor to understand how their questions related back to a specific audit requirement.
We’re happy to say our transparent culture had an overall positive impact on our very first SOC 2 audit. As someone who has operated in an external audit capacity, I would have loved to have been able to perform an external audit over a company that had as much publicly facing documentation as GitLab! Being transparent about everything we do as a company provided a lot of value during our SOC 2 audit in multiple ways:
- Time savings: In a traditional audit, an auditor schedules meetings with various process owners to walk through how internal processes relevant for an audit (such as change management) are executed. Here at GitLab, these procedures are documented publicly, so our auditor was able to read about these processes and provide more specific follow-up questions which ultimately resulted in team members being able to spend more time performing their day-to-day responsibilities instead of spending time interacting with our auditor.
- Understanding documentation gaps: Based on the deeper follow-up questions asked by our auditor, we were able to identify gaps in our documentation around processes being executed, but without sufficient documentation in the handbook. This gave us an opportunity to improve our documentation and potentially gain time savings in future audit cycles.
- Reduced scope creep: Given the amount of information that is available in our handbook, this may seem counterintuitive. However, because the GitLab architecture is published in our handbook, it helped to clearly define the scope of our SOC 2 audit and helped take the guesswork out of which technology should be subject to audit procedures.
While there were many valuable takeaways stemming from our transparency, we also quickly learned that the documentation in our handbook could lead an auditor to preliminary conclusions because processes weren’t fully documented. We didn’t see this as a negative impact, but more as an area for improvement and iteration to further refine our handbook documentation. So, again, the outcome of a deeper understanding of the documentation gaps that existed in our handbook is truly valuable and one we’re already working to address. Here are some merge requests that have been opened as a result of our first SOC 2 Type 1 audit:
- Revising our Data Classification Policies for more clarity
- GitLab Control Framework (“GCF”) revisions to align controls to SOC 2 Criteria and clean-up control language for clarity
How do you find the middle ground between transparency and compliance?
To put it plainly, there is no middle ground.
Compliance is a key function of all organizations. These efforts ensure that the organization and its personnel are adhering to various regulatory obligations by working cross-functionally to implement policies and procedures to meet these requirements. Transparency is actually a powerful compliance driver because it means the wider GitLab community can hold the company accountable for the processes that we put into place and how we carry them out.
Being transparent inherently helps minimize the scope of an audit because it allows us to be specific and detailed about how we operate as a company. We have moved away from a traditional audit model where process owners sit in a meeting with an auditor and spend hours talking. Instead, through our handbook, the documentation exists in a state that allows someone to pick it up and understand how to execute specific processes and procedures so that there is no guesswork involved. Processes and procedures aren’t left open to interpretation because that would reduce the ability for GitLab team members to "self-serve" information. We believe these same benefits extend to deeper understanding and clearer scope definition on the part of an audit team.
What’s next?
As a result of our first audit cycle, we have identified areas where we can iterate on our documentation to make it clearer and more concise. We’ll be working to get our handbook up to snuff while continuing to ready ourselves for an SOC 2 Type 2 audit. We are excited to continue exercising our value of transparency to further improve audit efficiency from audit to audit!
Between revising our documentation to be more clear and concise and preparing for our SOC 2 Type 2 audit, we have also performed a Cloud Security Alliance (CSA) CAIQ v3.1 self-assessment. We chose to perform this self-assessment partly for transparency and partly to provide the broader GitLab community with additional assurance over the maturation of the Security Compliance Program at GitLab. The self-assessment is available directly on the CSA website.
- Interested in learning more about GitLab's Security Certifications and Attestations? Visit our Security Certifications and Attestations handbook page to learn more.
- Do you require a copy of GitLab’s SOC 2 report? See how potential and existing customers can request this report.
Cover image by Maarten van den Heuvel on Unsplash
