GitLab Security Compliance Controls

What Are Security Controls?

Security controls are safeguards and countermeasures implemented to reduce or mitigate risks to organizational assets and data.

Control Description:

A control description is a clear, concise statement defining a specific security requirement or activity. Well-written control descriptions in the GCF:

• Use active, professional language
• State what must be done or what security measure is in place
• Are written generically without vendor-specific terminology (to remain reusable and vendor-neutral)
• Are actionable and testable by auditors
• Clearly communicate the objective

Examples:

• EPM-12: Laptops are configured by default to prevent the use of portable storage devices to mitigate data exfiltration with exceptions documented and approved by management.
• PSM-6: Security awareness training is required to be completed upon hire and on an annual basis thereafter for team members. The training covers topics including organizational security policies, industry security best practices, and relevant threat landscapes applicable to job responsibilities.
• AIM-6: AI systems are verified and validated using defined criteria and testing methodologies to ensure accuracy, performance, and quality standards are met.

Control Ownership

For controls to operate effectively, clear ownership and accountability must be established. Two key roles are responsible for control design, operation, and evidence collection:

Control Owner

• Accountable for the overall control and the risk it mitigates
• Responsible for remediation of control deficiencies and audit findings to bring the control into a state of audit-readiness
• May delegate control execution to stewards or responsible parties, but retains ultimate accountability
• Approves control design changes and major operational adjustments

Process Owner

• Subject matter expert who understands how the control operates in practice
• Works with the compliance team to provide evidence and explain control implementation
• May provide technical details, system access, or operational context for testing
• Often the person who actually performs or oversees the control activity

Note: The control owner and process owner may be the same individual.

GitLab Control Framework (GCF)

We take a comprehensive approach to our immediate and future security compliance needs. Older and larger companies tend to treat each security compliance requirement individually which results in independent security compliance teams going out to internal teams with multiple overlapping requests. For example, at such a company you might have one database engineer that is asked to provide evidence of how a particular database is encrypted based on SOC2 requirements, then again for ISO requirements, then again for PCI requirements.

To address this, we developed a common controls framework called the GitLab Control Framework (GCF). This approach can be visualized as follows:

graph TD;
    SOC2_Requirement1-->Team1;
    SOC2_Requirement1-->Team2;
    SOC2_Requirement2-->Team1;
    SOC2_Requirement2-->Team2;
    PCI_Requirement1-->Team1;
    ISO_Requirement1-->Team2;

Given our efficiency value here at GitLab we created a set of security and AI controls that would address multiple underlying requirements with a single control allowing the Security Compliance team to make fewer requests to control owners and efficiently collect all evidence we would need for a variety of audits at once. This approach can be visualized as follows:

graph TD;
    SOC2_Requirement1-->Control1;
    PCI_Requirement1-->Control1;
    SOC2_Requirement2-->Control2;
    ISO_Requirement1-->Control2;
    Control1-->GCF;
    Control2-->GCF;
    GCF-->Team1;
    GCF-->Team2;

GCF Methodology

As our security compliance goals and requirements have evolved, so have our requirements and constraints related to our security control framework. Our GCF is a proprietary set of controls developed specifically for GitLab’s unique infrastructure, business model, and security posture.

The GCF was developed through a comprehensive analysis process:

1. Analyzed compliance requirements from certifications and attestations we maintain and are pursuing (SOC 2, ISO 27001, ISO 42001, PCI DSS, FedRAMP, etc.)
2. Compared against industry frameworks such as NIST Cybersecurity Framework (CSF), NIST SP 800-53, and the Secure Controls Framework (SCF) to ensure alignment with industry best practices
3. Created custom control domains and controls tailored to GitLab’s all-remote, cloud-native, and AI-powered DevSecOps environment

This approach allows us to maintain mappings to all compliance requirements while eliminating irrelevant controls and adding GitLab-specific controls where needed. The framework is designed to be customizable and scalable, enabling us to create new domains or controls as we pursue additional certifications and as our business evolves.

GCF Scope and Assessment Approach

The GCF includes controls beyond what is in-scope for external certifications, covering both compliance-required and risk-driven controls. Each year, an assessment schedule is created to test and monitor controls, with assessments grouped by quarter and assigned to members of the Compliance team:

• Compliance controls: Required for external certifications; tested at least annually
• Risk-based controls: Driven by system criticality (Tier 1/2) or data sensitivity (RED/ORANGE); tested based on capacity and risk priority

GCF Structure and Data

Traditional control frameworks typically track minimal information such as a control ID, description, and owner. The GCF takes a more comprehensive approach, capturing extensive data that provides context around control implementation details, requirements the control is mapped to, scope of control (assets and processes included in the control), and other relevant details documented in the control fields below.

The GitLab Control Framework is maintained in our GRC solution, GAS (GitLab Assurance Solution). This centralized repository enables efficient control management, visibility into control relationship mappings, audit preparation, and continuous monitoring of GitLab’s security posture.

GCF Control Domains

Through our analysis of industry frameworks and compliance requirements, we created custom control domains that organize controls into logical families aligned with GitLab’s security program structure and operational model.

GCF Control Fields

The GCF tracks the following fields for each control to provide context, enable efficient management, and support audit activities:

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Visualization of control hierarchy - Admin Access Example
    accDescr: Flowchart showing how a Level 1 admin access control cascades to Level 2 product and entity-level processes, then to Level 3 asset-specific implementations.

  L1["Level 1: IAM-4<br/>Administrator access is granted based on<br/>job roles and responsibilities"];
  L2A["Level 2: IAM-4-GitLab.com<br/>Shared admin access process for systems supporting GitLab.com"];
  L2B["Level 2: IAM-4-Dedicated<br/>Shared admin access process for systems supporting Dedicated"];
  L2C["Level 2: IAM-4-Entity<br/>Shared admin access process for entity-level systems"];
  L3A1["Level 3: GCP Admin"];
  L3A2["Level 3: Google Workspace Admin"];
  L3B1["Level 3: AWS Accounts Admin"];
  L3B2["Level 3: Password Manager Admin"];
  L3C1["Level 3: Okta Admin"];
  L3C2["Level 3: SIEM Admin"];
  L3C3["Level 3: Antivirus Admin"];
  L3C4["Level 3: MDM Linux Devices Admin"];
  L3C5["Level 3: MDM macOS Devices Admin"];
  L1-->L2A;
  L1-->L2B;
  L1-->L2C;
  L2A-->L3A1;
  L2A-->L3A2;
  L2B-->L3B1;
  L2B-->L3B2;
  L2C-->L3C1;
  L2C-->L3C2;
  L2C-->L3C3;
  L2C-->L3C4;
  L2C-->L3C5;

3. Security Compliance Additional Procedures

Once the Security Compliance performs the assessment for inclusion in external certification scope, the team may elect to perform walkthroughs or testing of these controls.

Additionally, if the system poses a high risk to the environment (regardless of scoping), the team may also perform additional control testing. The Production Readiness Assessment Template (template being developed) may be used to document this testing.

4. Documentation

Security Compliance makes documentation updates as follows:

• GAS - results for any control testing performed are documented in GAS Assessments
• External Audit ‘Technical Scope’ - changes to the scope are reflected in this wiki page
• Continuous Control Monitoring (CCM) Testing Issues/Schedule - needed updates to the CCM based on scoping changes are made to ensure future testing is performed

References

Return to the Security Compliance Team page

View page source - Edit this page - please contribute.