Security Compliance Team

Security Compliance Team

Security Compliance Team Charter

Last Updated: 2025-03-20

Mission Statement

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.

Core Competencies

  1. Security certifications and attestations

    • Gap Analysis Program: feasibility analysis for certification expansion
    • External Audit coordination and execution
  2. Continuous Monitoring of GitLab’s Security Controls which are mapped to applicable regulatory requirements and security certifications/frameworks we have committed to.

  1. Observation and Remediation Management
  • Identify control weaknesses and gaps (observations)
  • Provide remediation recommendations and guidance
  • Track remediation to completion
  1. 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.
  2. 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 in 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

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.

  1. Sub-epics group tasks required to deliver an item mentioned
  2. Sub-epics represent an item from the roadmap and are delivered in a specific phase
  3. 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:

graph TD
A(Security Compliance top-level epic) --> B(SOC 2 Type 2 attestation)
B --> C([Epic])
B --> D([SOC 2 Type 2 Gap Assessment for GitLab.com])
B --> E([Expand SOC 2 TSC scope to include Availability criteria])
C --> G([Sub-epic])
E --> H([Q1 Continuous Control Monitoring])
E --> I([Q1 CCM: GitLab.com backend])
B --> F([...])
E --> J([...])
G --> K([Issue 1])

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:

  1. Work with others to move issues through the boards, for example, moving from triage to in progress to complete
  2. Ensure epic and any nested child epics and issues are using the appropriate labels
  3. Ensure the epic meets criteria outlined in epic structure (next section)
  4. 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):

## Background

## Objective

## Exit criteria
- [ ]

/label ~"FY26-Q1" ~"seccomp-function::gap assessments"  ~"seccomp workflow::triage" ~"team::security compliance" ~"seccomp-roadmap"
/health_status on_track
/set_parent &289

-----------
<!--DO NOT EDIT BELOW THIS LINE-->

<!--STATUS NOTE START-->

<!--STATUS NOTE END-->

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

  1. Assignee is the DRI which should be populated whenever an epic moves to seccomp workflow::in progress
  2. Start date is set to the expected start date, and updated to be the actual start date when the project begins
  3. Due date is set to be the expected end date
    1. The due date is set based on the Roadmap
    2. The date that a project actually ended is taken from the date that the epic was closed
  4. Health status should be kept updated (on track, needs attention, at risk)

Labels are described in the Labels section.

Roadmap

All epics and issues are set with due dates according to the official roadmap.

Process to update epic due dates / roadmap items:

  1. 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.
  2. Management then determines roadmap adjustments so that planned work in future phases remains realistic after shifting open work.
  3. 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:

  1. 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.
  2. 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.
  3. Top-Level Epic Status Update automation 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.
  4. 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?)
  • Objective (SMART goal explaining the plan/solution: Specific, Measurable, Achievable, Relevant, Time-bound)
  • 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
  • Tag us in GitLab
    • @gitlab-com/gl-security/security-assurance/security-compliance

Success Metrics

Key Metric Why It Matters How it’s Calculated Target Thresholds Measurement Frequency Reporting Mechanism Additional Notes
Median Time to Remediate This metric tracks our ability to remediate compliance observations compared to our SLAs. A calculation of the time between and issues being created and closed within the observation project broken out by quarter and each risk level. High = 6 months, Medium = 1 year Quarterly Tableau Dashboard n/a
TCV / ARR of new business opportunities by certification This metric tracks demand ($) for certifications to prioritize efforts with Product and Engineering We are working on adding a drop-down field to Salesforce to capture customer certification requests. TBD TBD TBD This is not complete. We are working with the sales team to make this possible.
Compliance posture by NIST CSF function and category (% of controls passing) Demonstrates the level of control effectiveness in each function/category, helping management understand which areas are strong or need improvement. We leverage the testing consculsions for the assessments completed in the fiscal year for each NIST CSF category and function area. 90% or greater passing in each function and category Annual Tableau Dashboard n/a
Number of compliance findings (Observations) that are fresh This metrics captures our ability to stay engaged with remediation owners and activities that affect our certifications and security posture. This looks at the last updated date of the open issues in the observation management repo. 80% of issues are fresh Real-time Tableau Dashabord n/a

FY26 Strategic Initiatives

Primary Focus Areas

# Objective Key Deliverables Timeline
1 FedRamp ATO - 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:

  1. GitLab Strategy
  2. Security Division Mission and Vision
  3. Security’s Multi-year Strategy (internal only)
  4. Security Assurance Mission and Vision
  5. Security Assruance Multi-year Strategy - In Development

Next scheduled review: [2025-07-31]

References

Return to the Security Assurance Homepage


Access Review Procedure
Purpose GitLab’s user access review is an important control activity required for internal and …
Automated Evidence Collection and Control Testing
Objectives The automated evidence collection and control testing program aims to: Streamline the …
External Audits, Certifications, and Attestations
The Security Compliance team is instrumental in supporting external audits, certifications, and …
FedRAMP Vulnerability Deviation Request Procedure
Submit a Request Click here to submit a Deviation Request! Team members working with security …
Gap Analysis Program
Purpose A gap analysis as it relates to security compliance refers to an in-depth review that helps …
GCF Security Control Lifecycle
Process Overview {: width=“600px”} Purpose As new GitLab security controls are …
GitLab FedRAMP Authorization Program
Overview The Federal Risk and Authorization Management Program (FedRAMP) is a United States …
GitLab Security Compliance Controls
Security controls are a way to state our company’s position on a variety of security topics. …
PCI Charter
Purpose This charter establishes the governance framework and organizational structure for …
PCI Internal Control Review Procedures
Purpose As part of our Continuous Control Monitoring and to support PCI requirements 12.4.1 and …
Policy-as-code
What is policy-as-code? Policy as code (PaC) refers to the practice of codifying policies, rules, …
Risk-based Compliance at GitLab
On this page Overview Risk-Based Control Testing Evolution of Our Approach Industry Validation Risk …
Risk-based Control Testing
What is Risk-based control testing? Risk-based control testing refers to control testing and …
Security Content Automation Protocol (SCAP) Scanning
A primer on SCAP and how to get started with OpenSCAP and Podman to scan container images.
Software-Bill-of-Materials (SBOM) Maturity Model and Implementation Plan
Purpose The purpose of this page is to provide direction on where GitLab needs to go as both a …