How GitLab built a security control framework from scratch (opens in new tab)

GitLab created its own security control framework after finding that existing frameworks were too broad, rigid, or insufficiently granular for its multi-product, cloud-native environment. The GitLab Control Framework (GCF) combines industry best practices with product-specific implementations and extensive operational metadata. This lets GitLab manage multiple certifications and internal risks through one scalable framework rather than maintaining separate frameworks for each product.

Why Existing Frameworks Were Insufficient

• GitLab initially used the Secure Controls Framework, then adopted NIST SP 800-53 in preparation for FedRAMP.
• NIST’s more than 1,000 controls were comprehensive but included requirements that did not apply to GitLab.
• Broad controls often combined several distinct activities:
  • NIST AC-2, “Account Management,” covers account creation, modification, disabling, termination, shared accounts, and monitoring.
  • GitLab treated these as separate controls because they have different owners, risks, testing methods, and evidence requirements.
• Repeatedly customizing NIST controls effectively meant GitLab was building its own framework, leading to the decision to formalize one.

Establishing the GitLab Control Framework

GitLab developed the GCF through five major steps:

Assessing Requirements

• The team mapped requirements from existing and planned certifications, including:
  • SOC 2 Type II
  • ISO 27001, ISO 27017, ISO 27018, and ISO 42001
  • PCI DSS
  • TISAX
  • Cyber Essentials
  • FedRAMP
• Internal requirements covered mission-critical systems outside certification scopes and systems handling sensitive data.
• This analysis established the minimum controls GitLab needed to meet compliance and risk-management obligations.

Learning from Industry Frameworks

• GitLab compared its requirements with:
  • NIST SP 800-53
  • NIST Cybersecurity Framework
  • Secure Controls Framework
  • Adobe and Cisco Common Controls Framework
• The goal was to reuse proven structures and ensure important security domains and practices were not omitted.

Creating Custom Domains

• The team organized the framework into 18 custom control domains.
• Each domain groups related controls according to how GitLab’s security program is managed.
• The structure supports adding, changing, or retiring controls as the business evolves.

Separating Framework Requirements from Implementations

GitLab operates several products with different infrastructure and compliance scopes:

• GitLab.com is a multi-tenant SaaS platform hosted on GCP.
• GitLab Dedicated is single-tenant SaaS hosted on AWS.
• GitLab Dedicated for Government is a FedRAMP offering hosted on AWS.

To avoid duplicating the framework, the GCF uses two control levels:

• Level 1: Defines what must be implemented at the organizational framework level.
• Level 2: Describes how each product fulfills the requirement.
• Entity-level controls apply across the organization and are inherited by all product offerings.
• This model supports product-specific audits while preserving a single source of control requirements.

Adding Operational Metadata

Rather than tracking only a control ID, description, and owner, the GCF records detailed context for each control:

• Responsible owner and risk accountability
• Applicable environment or product
• Covered assets and systems
• Performance or testing frequency
• Manual, semi-automated, or automated nature
• External certification or internal-risk classification
• Testing procedures and required evidence

This turns the framework into an operational control inventory. Teams can filter it to identify controls for a particular audit, determine ownership, or find manual controls that may be candidates for automation.

Designing for Growth

• The GCF is intended to evolve with GitLab’s products, risks, and certification goals.
• Its structured metadata helps GitLab assess scope and identify gaps when pursuing additional certifications such as ISMAP, IRAP, or C5.
• The framework’s modular design makes it easier to extend compliance coverage without creating entirely new control systems.

GitLab’s experience suggests that organizations should consider a custom framework when standard frameworks require extensive modification. The most effective approach is to retain useful industry guidance while tailoring control granularity, product implementations, ownership, testing, and metadata to the organization’s actual operating environment.