There are five teams in the Security Assurance sub-department.
The Security Assurance sub department utilizes a variety of tools to carry out day to day activities. The system admin is responsible for the following:
All other actions are the responsibility of the assigned DRI.
Purpose Control Health and Effectiveness Ratings (CHER) determine a GitLab Security Controls overall control health and effectiveness.
Scope Observation risk ratings play a key role in determining how to establish a controls CHER. The procedures outlined in the sections below are used specifically by the Security Assurance Team once an observation’s risk rating is determined. Team members utilizing the CHER for rating information system risks outside of control testing activities will not need to engage in the procedures below.
Governance and Field Security team charter
Field Security Team The Field Security team serves as the public representation of GitLab’s internal Security function. Our vision is to be the leading example in collaborative and transparent Customer Assurance Programs. Our mission is to empower the GitLab community with confidence and trust that their data is protected with high levels of security assurance to drive revenue growth. We partner with our fellow GitLab team members and customers to provide a pathway to yes!
Team Charter Mission The mission of the Governance and Field Security team is to: (i) drive the development of GitLab’s internal security strategy and posture through automation, security awareness, policy management, and regulatory and compliance oversight, and (ii) drive company ARR through effective and efficient customer assurance activities and external security evangelism; and support the sales organization through field security focused training and strategy alignment.
Roles and responsibilities Please refer to the following roles and responsibilities for Governance and Field Security team members:
Purpose The Observation Management Program at GitLab is used to identify, track, remediate and provide a risk ratings of identified findings, exceptions or deficiencies for any Tier 3 information system risks that are identified as an output of compliance operations or other mechanisms by team members, such as self-identification of a system specific risk.
This procedure details the creation process for observations.
Introduction to Observation Management at GitLab Scope Tier 3 risks or observations identified at the information system or business process levels
Purpose The Observation Management Program at GitLab is used to identify, track, remediate and provide a risk ratings of identified findings, exceptions or deficiencies for any Tier 3 information system risks that are identified as an output of compliance operations or other mechanisms by team members, such as self-identification of a system specific risk.
This procedure details the remediation process for observations.
Scope Tier 3 risks identified at the information system or business process levels
The Compliance Production Readiness Assessment is a process designed to make it clear what obligations systems owners have for configuring and hardening a system/tool/service in order for GitLab to meet its compliance and regulatory obligations.
Scope This Compliance Production Readiness Assessment process applies to new systems/tools/services or any existing system/tool/service that is processing new data or existing data in a different way that might change the compliance and regulatory obligations.
Purpose This policy is intended to establish requirements for the creation and management of security and technology related policies.
Scope This policy applies to security and technology policies that fall within the scope of GitLab’s security compliance audits and assessments.
Roles & responsibilities: Role Responsibility Security Governance Team Responsible for conducting annual controlled documents review and enforcing this policy Security Assurance Management (Code Owners) Responsible for approving changes to this policy Policy Policy creation and requirements All in-scope policies must be created as version controlled documents in GitLab.
Purpose This page provides an overview of the various ZenGRC Activities that are carried out by the Security Assurance sub department. Additionally, this page will also provide information on when stakeholders outside of the Security Assurance sub department may engage with ZenGRC.
Field Security Activities Customer Assurance Activities The Field Security team utilizes the following ZenGRC objects:
Requests are used for each Customer Assurance Request Issues are used when an observation is noted during the assessment Metrics and Reporting are used to track status, types of requests, and data related to each customer for trend analysis Risk Activities Security Operational Risk Management(StORM) All activities related to the StORM program are executed exclusively within ZenGRC.
Security Compliance Mission Security Compliance (Commercial) Mission:
Enable GitLab to be the most trusted DevSecOps offering on the market, demonstrated by security certifications and attestations. Achieve, maintain and grow industry specific security certifications and attestations for GitLab.com Identify and mitigate GitLab information security risk through continuous control monitoring of the GitLab.com SaaS offering and key in-scope auxiliary applications and third party sub-processors. Enable security to scale through the discovery and application of compliance automation.
Security Compliance (Dedicated Markets) Mission Our Mission is to advance customer trust with a focus on customers operating in highly regulated industries or who otherwise have unique security and compliance requirements. We will accomplish this mission by:
Enabling GitLab Dedicated to be the most trusted DevSecOps offering in the market, demonstrated by security certifications and attestations. Achieving and maintaining industry-specific security certifications such as FedRAMP and FIPS 140-2 compliance for the U.
Security Governance Program
Security Risk Mission To drive security risk treatment at GitLab by empowering teams to make informed and intelligent decisions through proactive identification, monitoring, prioritization, and reporting of security risks.
Core Competencies Security Operational Risk Management (StORM) Program The Security Risk team manages an integrated Operational Risk Management program focused on the identification, assessment, continuous monitoring, and reporting of Security Risks across the organization. Risk Reduction is 1 of 5 of the Security Department’s operating principles (Security Vision and Mission).
Overview The Security Assurance team performs various types of security questionnaires, assessments and audits. If you have any questions, please feel free to contact us:
Join our slack channel: #sec-assurance Email: security-assurance@gitlab.com Security Questionnaire A document that is meant to provide an overview of a Security Program or portions thereof. Security Questionnaires are routinely used during Security Assessments. An example of an industry standard security questionnaire includes the CAIQ and which GitLab makes publicly available in our Customer Assurance Package
Purpose System-level risk scores are intended to be a quantitative representation of the amount of security risk a given system holds. This quantitative approach to risk scoring is meant to inform GitLab management about where risk exists and help with prioritization and resourcing.
Scope The procedures outlined in the sections below are used specifically by the Security Assurance Team once an observation’s risk rating is determined. This procedure is limited to systems in scope of GitLab’s security continuous control monitoring program.
Technical and Organizational Security Measures for GitLab Cloud Services GitLab Cloud Services (including GitLab.com and GitLab Dedicated) meet the specific requirements of data protection, including, without limitation, Article 28 of the General Data Protection Regulation and which are listed as SOC 2 Type 2 (Security & Confidentiality).
At a minimum, GitLab has implemented for the GitLab Cloud Services the technical and organizational measures and maintains security practices within the production environments as follows:
GENERAL FAQ What is ZenGRC? ZenGRC is a governance, risk, and compliance (GRC) management platform. How can I access ZenGRC? ZenGRC has been configured to authenticate team members with Single Sign-On (SSO) via Okta. Team members are able to access the system by clicking on the ZenGRC Okta tile from their Okta dashboard. A screenshot of the Okta tile has been provided below as a reference: Why can’t I access ZenGRC when I click on the Okta tile?
