GitLab has adopted the ISO/IEC 27001:2013 standards for our information security management system (ISMS) to provide GitLab team members, customers and community members with a high level of assurance on the robustness of our information security policies, standards and procedures, and the strength of our control environment. The purpose of this document is to define the boundaries and objectives of GitLab's ISMS.
The scope of GitLab's ISMS is limited to the resources that directly support the GitLab.com SaaS application.
Assets within the scope of the ISMS include: customer data, software, people, and internal information assets to host and operate the cloud-based solution.
As an all remote company, there are no physical office locations in the scope of the ISMS. All third party data center operations and physical hardware assets are not in scope and are managed by the third party service provider.
GitLab's headquarter mailing address is in scope and covers all sub organizations. Please note this is a mailing addresses only, there is no physical location to visit:
Business functions included in the scope of the ISMS include:
GitLab is committed to information security. The general objective for the ISMS is to protect GitLab's confidential information and assets against new and existing security and privacy risks while maintaining confidentiality, integrity and availability. Objectives for individual security controls are inherited by the in scope security standards and regulations which are: ISO 27001, SOC 2 Type 2 Security and PCI DSS Level 1.
The ISMS council, comprised of Security and Privacy leadership, shall meet on a minimum of an annual basis to discuss the state of the ISMS and measure the fulfillment of all ISMS objectives. The following topics will be covered:
|ISMS Council||Oversight, implementation and continual improvement of the ISMS|
|VP, Security||Executive sponsor of the ISMS; coordinate, promote and improve information security; establish information security policy|
|Security Assurance||Reporting on the performance of the information security management system to top management; security risk assessments and treatment; continuous monitoring and auditing; customer assurance activities; security awareness program; security governance activities|
|Application Security||Manage third party penetration and bug bounty programs; provide input to the software development lifecycle; manage application vulnerability program; administer security champions program; maintain application security tools; identify security risks|
|SIRT||Monitor, manage and report on security incidents; monitor compliance with security policies through technical tools; identify security risks;|
|Infrastructure Security||Manage infrastructure vulnerability program; maintain infrastructure security tools; identify security risks|
|Other ISMS Business units||Implement, operate and/or administer information security requirements; remediate information security findings; collaborate with the Security department|
|All GitLab Team Members||Awareness of responsibilities as it relates to information security; adherence to information security controlled documents; reporting of suspected security violations|
GitLab has implemented a formal Security Operational Risk Management (“StORM”) program at GitLab to identify, rank, track, and treat cybersecurity, IT, and privacy operational risks in support of GitLab's organization-wide objectives. The process for selecting in scope information security controls is executed by the Security Compliance team, leveraging technical functionality from the third party GRC application, and overseen by the Security Risk team. Implementation status is captured in GitLab's GRC application as well as in the Statement of Applicability.
The GitLab Security team executes quarterly cascading Objectives and Key Results (OKRs) to define our security objectives and a plan for achieving those objectives while ensuring alignment throughout the organization.
GitLab has implemented a formal security awareness training program that includes: new hire security awareness training, global annual security awareness training and quarterly targeted phishing exercises. These trainings are administered via a third party portal and include a quiz to test understanding of the security topics presented.
A formal controlled document procedure is in place to ensure that there is consistency in developing and maintaining controlled documents at GitLab utilizing a hierarchal approach. All controlled documents are available to all GitLab team members and the public via the GitLab handbook unless otherwise noted. Updates to controlled documents are managed via GitLab merge requests which are also accessible to all GitLab team members for the entire workflow. An annual review of controlled documents is required by the ISMS owner or assigned representative.
GitLab publishes Job Families to define roles and responsibilities based on level for all team members. This information is publicly available and the foundation for team member hiring and performance reviews. On a minimum of an annual basis, GitLab management executes talent assessments with team members to ensure competency to Job Family.
The GitLab team handbook is the central repository for how we run the company. Everything at GitLab is handbook first, to include development of company policies, standards and procedures. Key controlled documents that support the ISMS include:
GitLab has a dedicated Security Compliance team responsible for monitoring design and effectiveness of the GitLab common control framework to ensure GitLab's security objectives are thoughtfully planned, implemented and monitored.
If using a third party service to outsource or supplement security processes, a third party risk assessment is executed prior to onboarding. Critical vendors are also reviewed once per calendar year after onboarding, or at contract renewal if it comes first.
GitLab monitors, measures, and improves security controls through various continuous monitoring measures, such as:
GitLab is committed to continually improving the suitability, adequacy and effectiveness of the ISMS.
As part of GitLab's tier 2 security operational risk program, Each risk identified and triaged through the StORM program is required to undergo a risk treatment determination. This is an activity that will be discussed with each individual risk owner for the risks that they own. Additionally, GitLab identifies and monitors tier 3 risks, also referred to as observations, as per the Observation Management Procedure.
Exceptions to Information Security policies or procedures will be tracked as per the Information Security Policy Exception Management Process.