In most cases, information security compliance is a notoriously difficult area for smaller companies to get started with. Generally, when a company is large enough to have compliance needs, that company has already established a lot of its operating processes and configured the infrastructure.
In GitLab's case, we started our formalized compliance program towards the end of our Series C funding round, which is actually earlier than a lot of companies our size. This timing afforded GitLab a terrific opportunity to build out our compliance program. We were able to take a step back and consider the most efficient use of our personnel without an immediate need for external compliance certifications.
Defining security controls: Independent or aggregate?
When it was time to identify security controls that would match up with processes and structure, we were faced with the decision a lot of small companies encounter: Do we treat each information security framework we have an interest in – or need for – independently, or do we try and aggregate these controls in a way that gives us natural alignment to underlying frameworks?
By interacting with industry frameworks (e.g. ISO, SOC, PCI, etc.) individually we would have clarity with each individual control in terms of scope and applicability. But we would have been reaching out to our internal teams with hundreds of individual controls, many of which overlap. An example of this overlap is that PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 all require business continuity plans. With an individualized approach to security frameworks, we would be treating each business continuity plan separately and would run the risk of making multiple requests to GitLab teams in order to satisfy all requirements.
By adopting an “umbrella framework” approach and leveraging an open source option (i.e. Adobe’s CCF), we’ve been able to build in efficiency and ensure that when we interact with our internal teams, we are not requesting the same information in multiple formats. In the above PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 example, choosing an umbrella framework means evaluating all the individual requirements collectively and creating a control statement that fulfills the needs of each of the controls simultaneously. This creates an overarching security control that allows us to make a single request for business continuity information to each GitLab team and eliminates having to collect slightly different information depending on the framework we are working with at any given time. By being thoughtful about what is asked for, the compliance group gains internal credibility. The more agile and efficient we can enable our teams to be, the more productive GitLab becomes.
The GitLab approach
We’ve already begun adapting Adobe's framework to satisfy our own needs. This unified framework approach has allowed us to quickly create security controls and start building out the supporting guidance and policy information. And we’ve been able to stand up a comprehensive compliance program – in months, not years.
As we spend more time customizing the Adobe CCF open source framework and aligning the compliance process to the GitLab product workflow, we plan to share what we’ve created and what we’ve learned along the way through a series of blog posts. We’ll also make some of these resources available to our customers in the hopes that it can help other organizations jump start their own compliance journeys.
Do you have thoughts on the approach GitLab is taking with our compliance framework adoption? Or maybe you have feedback on particular compliance needs you’d like to see GitLab address going forward? Share your thoughts with us below; we’d love to hear from you!
Cover image by Erik Witsoe on Unsplash
