The Security Compliance Team safeguards GitLab’s position as the industry’s most trusted DevSecOps platform through rigorous certification management and risks & controls monitoring. We protect our customers by turning compliance requirements into competitive advantages, using our own product to demonstrate security excellence.
Value Proposition
Security Compliance maintains GitLab’s position as the most trusted DevSecOps platform by providing assurance to our customers and enabling sales through certification maintenance and expansion.
Identify control weaknesses and gaps (observations)
Provide remediation recommendations and guidance
Track remediation to completion
Industry and Regulatory Monitoring and Insights
Monitoring drafts and changes to relevant laws, executive orders, directives, regulations, policies, standards, and guidelines.
Collaborating on responses to relevant RFIs, RFQs, RFPs, and requests for public comment.
Monitoring changes to government contractual language that could impact public sector security and compliance posture.
Dogfooding
We use the GitLab product to perform our core competencies
We recommend GitLab feature solutions to remediate observations and reduce risk
We provide feedback to the product by exemplifying the compliance persona.
Operating Model
We use agile program management and project management best practices to organize our work with the goal of being as efficient as possible while continuously iterating towards our objectives. Security Compliance team members are encouraged to regularly bring up feedback on how we can improve the way we work and this is a standing topic in our weekly team meeting agenda.
Core Processes
The single source of truth for all of in-progress work is the Security Compliance team top-level epic, which has detailed status updates, along with the team epic board which we use to visualize workflow status and compare to our roadmap. All work that is directly associated with our roadmap should take place via these and issues should be opened in the Security Compliance Team Issue Tracker project. This is important for two reasons: It allows us to work efficiently by centralizing and organizing our work in a single place using a robust labeling scheme and it allows us to report on various operational metrics (performance indicators).
Much of our work related to the FedRAMP Authorization Program is unfortunately not visible to the rest of GitLab due to regulatory mandates outside of our control. In order to bring as much transparency and visibility into our work, and to continue to track basic metrics, it is critical that we continue to use our epic board and issue tracker as much as possible, even if used to track high-level tasks with links to detailed issues within the authorization boundary.
How We Work
Epic hierarchy
The our team top-level epic is simply a SSOT for status updates for epic assignees / directly responsible individuals (DRIs). The immediate child epics get a seccomp-roadmap label to appear in our epic board and effectively constitute our roadmap.
Sub-epics group tasks required to deliver an item mentioned
Sub-epics represent an item from the roadmap and are delivered in a specific phase
Sub-epics can span multiple months, but their end date should match the ‘anticipated completion date’ of the roadmap phase they are added to.
The diagram below shows an example of traversing the complete hierarchy:
Epic assignee responsibilities
Each epic has a single DRI who is ultimately responsible for delivering the project. This does not mean they are doing all of the work, rather they are ensuring the work is progressing, blockers are quickly addressed or escalated if needed, and reporting on the status each week.
The DRI needs to:
Work with others to move issues through the boards (e.g. from triage to in progress to complete)
Ensure epic and any nested child epics and issues are using the appropriate labels
Ensure the epic meets criteria outlined in epic structure (next section)
Provide status updates on the epic each week including accomplishments, what’s next, overall health status, and any blockers
Epic structure
Each immediate child epic under our top-level team epic must include the following (adjust quick actions as necessary):
The bottom status note comments at the bottom are important as this is what is used to automatically post status updates to these epics and the team epic.
Epic meta data to include
Assignee is the DRI which should be populated whenever an epic moves to seccomp workflow::in progress
Start date is set to the expected start date, and updated to be the actual start date when the project begins
Due date is set to be the expected end date
The due date is set based on the Roadmap
The date that a project actually ended is taken from the date that the epic was closed
Health status should be kept updated (on track, needs attention, at risk)
All epics and issues are set with due dates according to the official roadmap.
Process to update epic due dates / roadmap items:
After the end of each month Security Compliance management reviews the epic (expected) due dates and works with epic assignees / DRIs to determine any roadmap changes if an epic extends beyond the epic’s planned phase.
Management then determines roadmap adjustments so that planned work in future phases remains realistic after shifting open work.
Roadmap changes are shared in the next weekly sync.
Status updates
We leverage automation to ensure team members only need to provide a status update once and management only ever has to go to one place to review it. This has historically been a big problem at GitLab with epics and issues spread across various subgroups and projects.
The status for all work relating to the Security Compliance roadmap is maintained in the description of the top-level team epic so that it is visible at a glance.
Weekly status update process
DRIs should provide weekly updates for the DRI’s epics according to following process:
Every Thursday afternoon the epic assignee / DRI of active epics (anything that is not seccomp workflow::triage) will get @mentioned in a comment on the epic asking them to reply with a status update.
By 17:00 UTC / 12:00 PM ET on Fridays DRIs of active epics (or the person covering if DRI is OOO) provide an update in the status section of the description of the epic regarding status of the epic including any relevant details of child epics and issues.
If the DRI for a child-epic is different than the epic DRI, the epic DRI is responsible for getting updates from the child-epic DRI.
Format for weekly update should be a brief update (~sentence or couple bullets) for each of these three items:
Progress since last update - Changes deployed to production, unblocked blockers, any other progress achieved.
Risk and Confidence - Any new blockers identified or existing blockers that persist? Any other challenges now or in the near future? How do these blockers and/or challenges affect our confidence of completing by scheduled due date per the roadmap?
Mitigations - What is required to overcome challenges or blockers identified? Should this be escalated to other team members, teams, executives, or domain experts?
Update Workflow and Health label - After each status update, the workflow label and health status should be updated. See the SecComp Team Issue Tracker Readme for details on label structure.
Top-Level Epic Status Updateautomation periodically synthesizes updates from the DRI’s status update reply comment to automatically populate their epic with the status and the top-level team epic.
In order to ensure efficiency we will use these same status updates across any other department, division, or OKR status updates, to include broadcasts in Slack.
Backlog refinement
Prior to the start of a new quarter, the team will spend time refining the epic backlog. This process will be led by the team Manager, who will go through the epics targeted for the upcoming quarter according to the roadmap and ensure each epic contains the following information (pulling in different stakeholders to help fill in the details as necessary):
Background (e.g. provide context and the purpose of this work, what is it and why is it relevant?)
Exit criteria (break down the work into smaller, logical chunks and highlight dependencies and predecessors)
When the above information is being added, the Epic will move from Triage to Ready status. The goal is to start each quarter with our planned roadmap items for that quarter in the Ready list.
Engagement Model
Slack
Feel free to tag @sec-compliance-team to reach the entire Security Compliance team
The #sec-assurance slack channel is the best place for questions relating to our team
- Achieve Agency ATO Achieve - FedRAMP Authorized on FedRAMP Marketplace
Ongoing in FY26
2
Certification Expansion
- Perform Gap Assessments for ISO 42001 and ISMAP - Prepare and share audit report on our posture and readiness for the certifications - Support remediatation of identified gaps
Assessment and report - End of Q1FY26 Remediation - Ongoing in FY26
3
Control Framework Refinement
- Streamline GitLab’s control framework implementation by expanding compliance coverage, automating control management, and enhancing documentation to support future scalability.
Ongoing in FY26
Review and Updates
This charter will be reviewed and updated quarterly to ensure alignment with:
GitLab’s user access review is an important control activity required for internal and external IT audits, helping to minimize threats, and provide assurance that the right people have the right access to critical systems and infrastructure. This procedure details process steps and provides control owner guidance for access reviews.
Benefits to the organization
Reduces security risk
Identifies dormant and/or disabled accounts
Ensures only required team members have access to a system
Validates users who have changed roles have not retained access no longer relevant
Ensures terminated team members no longer can access company systems
Supports GitLab compliance and regulatory requirements which maintains customer trust
Scope
In-Scope Systems
Security Compliance performs Access Reviews for in-scope systems based on a subset of factors. Including:
The Security Compliance team is instrumental in supporting external audits, certifications, and attestations, with benefits that extend across the organization. Our responsibilities include:
Preparation and Coordination: The team prepares for external audits by gathering necessary evidence, documentation, and ensuring the organization is ready to demonstrate compliance with standards such as SOC 2, ISO 27001, or other industry-specific regulations. We coordinate with internal stakeholders to ensure that the right processes and controls are in place and maintained.
Liaison with Auditors: The Security Compliance team acts as the primary point of contact between auditors and the company. We facilitate audit activities, such as walkthroughs and interviews, thereby minimizing disruption to operational teams and helping ensure that the audit is conducted smoothly.
Continuous Monitoring: We implement mechanisms for ongoing monitoring of controls to ensure compliance is maintained between audit cycles, enabling the organization to stay audit-ready at all times.
Remediation and Follow-up: When findings or deficiencies are identified during audits, the team works to develop remediation plans, tracks the progress of these plans, and ensures that actions are taken to close gaps before the next audit.
Benefits to Customers
Trust and Assurance: External certifications and attestations serve as independent verification that the organization meets established security standards. This builds trust with customers, reassuring them that their data is handled securely and that the company has taken appropriate measures to protect it.
Risk Mitigation: Customers can feel confident that risks associated with data breaches or security incidents are mitigated through well-documented, tested, and externally verified controls. This reduces concerns around vendor risk when choosing to work with the company.
Compliance with Industry Standards: For customers operating in highly regulated industries, it’s crucial to work with partners who comply with relevant regulations. The Security Compliance team’s work in obtaining certifications helps customers meet their own compliance requirements by demonstrating that their partners follow the necessary standards.
Benefits to GitLab
Enabling Sales and Market Expansion: External certifications and attestations act as competitive differentiators in the marketplace. We enable the sales team to address customer concerns related to security and compliance more effectively, leading to increased sales opportunities. Additionally, some certifications are prerequisites for entering certain markets or working with specific clients, enabling market expansion.
Supporting the First Line of Defense: The Security Compliance team limits the need for the first line of defense (such as engineering, product, or IT teams) to interact directly with auditors. This allows these teams to focus on their core responsibilities, such as building and delivering products, without the added burden of preparing evidence or explaining controls to auditors. The Compliance team takes on this responsibility, facilitating the audit process and ensuring subject matter experts are only involved when absolutely necessary.
Current certifications and attestations
Refer to the GitLab Trust Center for the latest information on all of the certifications and attestations we maintain, including 3rd party reports, commonly request security documentation, and answers to commonly asked questions about our security and compliance posture. There is a dropdown list to view content for GitLab.com and GitLab Dedicated SaaS offerings. Some of the content is applicable to both SaaS platforms and/or GitLab Inc.
Team members working with security vulnerabilities should read this procedure in its entirety and reach out to @sec-compliance-team in the #sec-assurance Slack channel if you have any questions.
Purpose
In accordance with expectations set by the FedRAMP Authorization Act and FedRAMP Program Management Office (PMO), GitLab must follow a formal process to track and request approval (risk acceptance) from our sponsoring Agency Authorizing Official (AO) for any vulnerabilities that cannot be remediated within SLAs due to scenarios described in the Scope section below. These are called vulnerability Deviation Requests (DRs) and are formally reported to our AO every month using GitLab’s Plan of Action & Milestones (POA&M) (internal only). Deviation requests for risk adjustments (severity downgrades), false positives, and operational requirements require Authorizing Official (AO) approval.
A gap analysis as it relates to security compliance refers to an in-depth review that helps organizations determine the difference between the current state of their information security and a given security standard (SOC 2 Type 2 Availability Criteria, ISO 27018, BSIMM, etc.) they might want to adopt or align against. The outcome of completing gap analysis procedures is a report to management:
What, if any, gaps exist between GitLab’s current state and that new standard
A recommendation for whether or not to pursue that new standard
The impact of not pursuing that new standard
The impact if that new standard is pursued
Scope
The scope of gap analysis procedures performed by the Security Compliance team are limited to information security and compliance related regulatory standards and frameworks.
As new GitLab security controls are identified that need to be implemented by the Security Compliance Teams for compliance or regulatory reasons, these controls follow an established process in order to make that implementation successful.
These lifecycle phases are managed via GitLab’s governance, risk and compliance (GRC) application.
Scope
This document applies to GitLab’s security controls being assessed by the Security Compliance Team(s).
The Federal Risk and Authorization Management Program (FedRAMP) is a United States government-wide program that standardizes security requirements for the authorization and ongoing cybersecurity of cloud services in accordance with the FedRAMP Authorization Act, FISMA, and OMB Circular A-130. In short, Federal Agencies are required to procure FedRAMP-authorized cloud services, and cloud service providers are required to be FedRAMP authorized in order to sell to federal agencies and handle their data. FedRAMP.gov has more information about the program including the authorization process, the marketplace, and other helpful resources.
Security controls are a way to state our company’s position on a variety of security topics. It’s not enough to simply say “We encrypt data” since our customers and teams will naturally want to know “what data do we encrypt?” and “how do we encrypt that data?”. When all of our established security controls are operating effectively this creates a security program greater than the sum of its parts. It demonstrates to our stakeholders that GitLab has a mature and comprehensive security program that will provide assurance that data within GitLab is reasonably protected.
This charter establishes the governance framework and organizational structure for maintaining compliance with the Payment Card Industry Data Security Standard (PCI DSS) requirements. It defines roles, responsibilities, and accountability measures to ensure the security of GitLab’s SaaS offerings as a Service Provider.
Program Governance
The Chief Information Security Officer, supported by the Security Assurance team, maintains ultimate accountability for PCI DSS compliance and are responsible for:
As part of our Continuous Control Monitoring and to support PCI requirements 12.4.1 and 12.4.1.1, we conduct internal control reviews for selected controls.
Process
Quarterly, issues are created to confirm that specified activities are performed as required, including testing of the Change Management process, and confirmation that log reviews and configuration reviews occur, alerts are responded to, and configurations are applied to systems per the standards. Procedures for conducting the review activity are detailed in the quarterly issues.
Policy as code (PaC) refers to the practice of codifying policies, rules, and regulations that govern various aspects of an organization’s operations, particularly in compliance, security, and risk management. It involves translating these policies into machine-readable code that can be automatically enforced and continuously monitored within the organization’s systems and infrastructure.
Why use policy-as-code / what are the benefits?
Policy as code (PaC) offers several key benefits for organizations embracing the DevSecOps model. Firstly, PaC ensures consistency and standardization across the infrastructure by defining policies in machine-readable formats and enforcing them through automation. This consistency minimizes the risk of misconfigurations and ensures that all deployed resources adhere to organizational standards, enhancing overall system reliability and security.
Risk-based compliance is our strategic approach to using risk intelligence for informing compliance activities and testing priorities, rather than treating all compliance requirements equally. At GitLab, we sometimes also refer to this as risk-based control testing to differentiate the ongoing continuous monitoring of our SaaS platforms to maintain our certifications/attestations. This strategy recognizes that not all systems, vendors, or controls carry the same level of risk to the organization.
Risk-based control testing refers to control testing and monitoring that aims to ensure controls are operating effectively beyond the scope of GitLab’s SOC 2 reports and information security management system for our SaaS platforms, which have foundational controls in place where customers need the most assurance.
Risk-based control testing is proactive and focuses on mitigating the most significant risks to the organization, providing a more effective and resource-efficient means of maintaining security. It is adaptive, driven by indicators such as GitLab’s quarterly risk assessments, and aims to continually improve security posture.
The purpose of this page is to provide direction on where GitLab needs to go as both a software producer and software consumer to provide transparency, and most importantly visibility, into the security of our software supply chain. GitLab is evaluating a very dynamic regulatory landscape with references to SBOM requirements in numerous draft legislation in both the U.S. and non-U.S., executive orders and directives, customer requests, and numerous community frameworks and formatting specifications.
