Help us learn about your current experience with the documentation. Take the survey.

Compliance standards

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

You can use GitLab compliance controls to help meet the requirements of many compliance standards.

The Compliance Adherence Templates project contains a library of JSON templates. Use these templates to quickly adopt predefined compliance frameworks.

FedRAMP compliance requirements

FedRAMP (Federal Risk and Authorization Management Program) categorizes cloud services into three impact levels: Low, Moderate, and High, based on the potential impact of a data breach on government operations, assets, or individuals.

These levels correspond to different sets of security controls and requirements that cloud service providers (CSPs) must meet to achieve FedRAMP authorization. Controls are available for FedRAMP Low, FedRAMP Moderate, and FedRAMP High compliance.

FedRAMP Low compliance requirements

The following table lists the requirements supported by GitLab for FedRAMP Low and the controls for the requirements. You can use the fedramp_low_r5.json template to create a compliance framework for this standard.

FedRAMP Low requirement	Description	Supported controls
CM-5: Access Restrictions for Change	Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.	Default branch protected At least two approvals
CM-6: Configuration Settings	Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies.	Author approved merge request is forbidden
CM-7: Least Functionality	Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services.	Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-10: Software Usage Restrictions	Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.	License compliance running
IA-2(12): Acceptance of PIV Credentials	Accept and electronically verify Personal Identity Verification (PIV) credentials.	Auth SSO enabled
IA-8(1): Acceptance of PIV Credentials From Other Agencies	Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies.	Auth SSO enabled
RA-5: Vulnerability Monitoring and Scanning	Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running

FedRAMP Moderate compliance requirements

The following table lists the requirements supported by GitLab for FedRAMP Moderate and the controls for the requirements. You can use the fedramp_moderate_r5.json template to create a compliance framework for this standard.

FedRAMP Moderate requirement	Description	Supported controls
AC-5: Separation of Duties	Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-3: Configuration Change Control	Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements.	Default branch protected At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-5: Access Restrictions for Change	Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.	Default branch protected At least two approvals
CM-6: Configuration Settings	Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies.	Author approved merge request is forbidden
CM-7: Least Functionality	Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services.	Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-10: Software Usage Restrictions	Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.	License compliance running
IA-2(12): Acceptance of PIV Credentials	Accept and electronically verify Personal Identity Verification (PIV) credentials.	Auth SSO enabled
IA-5(7): No Embedded Unencrypted Static Authenticators	Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.	Secret detection running
IA-8(1): Acceptance of PIV Credentials From Other Agencies	Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies.	Auth SSO enabled
RA-5: Vulnerability Monitoring and Scanning	Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
SA-11(1): Static Code Analysis	Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.	SAST running
SA-11(8): Dynamic Code Analysis	Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.	DAST running Fuzz testing running

FedRAMP High compliance requirements

The following table lists the requirements supported by GitLab for FedRAMP High and the controls for the requirements. You can use the fedramp_high_r5.json template to create a compliance framework for this standard.

FedRAMP High requirement	Description	Supported controls
AC-5: Separation of Duties	Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-3: Configuration Change Control	Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements.	Default branch protected At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-3(1): Automated Documentation, Notification, and Prohibition of Changes	Use automated mechanisms to document proposed changes to the system; notify organization-defined approval authorities; highlight change approvals that have not been received by organization-defined time period; prohibit changes to the system until designated approvals are received; and document all changes to the system.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-5: Access Restrictions for Change	Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.	Default branch protected At least two approvals
CM-6: Configuration Settings	Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies.	Author approved merge request is forbidden
CM-7: Least Functionality	Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services.	Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-10: Software Usage Restrictions	Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.	License compliance running
IA-2(12): Acceptance of PIV Credentials	Accept and electronically verify Personal Identity Verification (PIV) credentials.	Auth SSO enabled
IA-5(7): No Embedded Unencrypted Static Authenticators	Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.	Secret detection running
IA-8(1): Acceptance of PIV Credentials From Other Agencies	Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies.	Auth SSO enabled
RA-5: Vulnerability Monitoring and Scanning	Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
SA-11(1): Static Code Analysis	Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.	SAST running
SA-11(8): Dynamic Code Analysis	Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.	DAST running Fuzz testing running

IRAP compliance requirements

IRAP is the Infosec Registered Assessors Program. Controls are available for IRAP Official, IRAP Protected, IRAP Secret, and IRAP Top Secret.

IRAP Official

The following table lists the requirements supported by GitLab for IRAP Official and the controls for the requirements. You can use the irap_official.json template to create a compliance framework for this standard.

IRAP Official requirement	Description	Supported controls
ISM-0402 Application security testing	Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases.	SAST running DAST running
ISM-1163 Continuous monitoring plan	Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
ISM-1422 Development, testing and production environments	Unauthorised access to the authoritative source for software is prevented.	Default branch protected
ISM-1698 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.	Dependency scanning running Container scanning running
ISM-1700 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.	Dependency scanning running Container scanning running DAST running API security running
ISM-1701 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices.	Container scanning running DAST running API security running
ISM-1702 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices.	Dependency scanning running Container scanning running
ISM-1808 Scanning for unmitigated vulnerabilities	A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities.	Dependency scanning running Container scanning running
ISM-1816 Development, testing and production environments	Unauthorised modification of the authoritative source for software is prevented.	Default branch protected
ISM-1875 Protecting credentials	Networks are scanned at least monthly to identify any credentials that are being stored in the clear.	Secret detection running

IRAP Protected

The following table lists the requirements supported by GitLab for IRAP Protected and the controls for the requirements. You can use the irap_protected.json template to create a compliance framework for this standard.

IRAP Protected requirement	Description	Supported controls
ISM-0402 Application security testing	Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases.	SAST running DAST running
ISM-1163 Continuous monitoring plan	Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
ISM-1422 Development, testing and production environments	Unauthorised access to the authoritative source for software is prevented.	Default branch protected
ISM-1698 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.	Dependency scanning running Container scanning running
ISM-1700 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.	Dependency scanning running Container scanning running DAST running API security running
ISM-1701 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices.	Container scanning running DAST running API security running
ISM-1702 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices.	Dependency scanning running Container scanning running
ISM-1808 Scanning for unmitigated vulnerabilities	A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities.	Dependency scanning running Container scanning running
ISM-1816 Development, testing and production environments	Unauthorised modification of the authoritative source for software is prevented.	Default branch protected
ISM-1875 Protecting credentials	Networks are scanned at least monthly to identify any credentials that are being stored in the clear.	Secret detection running

IRAP Secret

The following table lists the requirements supported by GitLab for IRAP Secret and the controls for the requirements. You can use the irap_secret.json template to create a compliance framework for this standard.

IRAP Secret requirement	Description	Supported controls
ISM-0402 Application security testing	Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases.	SAST running DAST running
ISM-1163 Continuous monitoring plan	Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
ISM-1422 Development, testing and production environments	Unauthorised access to the authoritative source for software is prevented.	Default branch protected
ISM-1698 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.	Dependency scanning running Container scanning running
ISM-1700 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.	Dependency scanning running Container scanning running DAST running API security running
ISM-1701 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices.	Container scanning running DAST running API security running
ISM-1702 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices.	Dependency scanning running Container scanning running
ISM-1808 Scanning for unmitigated vulnerabilities	A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities.	Dependency scanning running Container scanning running
ISM-1816 Development, testing and production environments	Unauthorised modification of the authoritative source for software is prevented.	Default branch protected
ISM-1875 Protecting credentials	Networks are scanned at least monthly to identify any credentials that are being stored in the clear.	Secret detection running

IRAP Top Secret

The following table lists the requirements supported by GitLab for IRAP Top Secret and the controls for the requirements. You can use the irap_top_secret.json template to create a compliance framework for this standard.

IRAP Top Secret requirement	Description	Supported controls
ISM-0402 Application security testing	Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases.	SAST running DAST running
ISM-1163 Continuous monitoring plan	Systems have a continuous monitoring plan that includes: conducting vulnerability scans for systems at least fortnightly, conducting vulnerability assessments and penetration tests for systems prior to deployment, including prior to deployment of significant changes, and at least annually thereafter, analysing identified vulnerabilities to determine their potential impact, and implementing mitigations based on risk, effectiveness and cost.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
ISM-1422 Development, testing and production environments	Unauthorised access to the authoritative source for software is prevented.	Default branch protected
ISM-1698 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.	Dependency scanning running Container scanning running
ISM-1700 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.	Dependency scanning running Container scanning running DAST running API security running
ISM-1701 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices.	Container scanning running DAST running API security running
ISM-1702 Scanning for unmitigated vulnerabilities	A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices.	Dependency scanning running Container scanning running
ISM-1808 Scanning for unmitigated vulnerabilities	A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities.	Dependency scanning running Container scanning running
ISM-1816 Development, testing and production environments	Unauthorised modification of the authoritative source for software is prevented.	Default branch protected
ISM-1875 Protecting credentials	Networks are scanned at least monthly to identify any credentials that are being stored in the clear.	Secret detection running

ISMAP compliance requirements

The Information system Security Management and Assessment Program (ISMAP) aims to secure the security level of the government’s cloud service procurement by evaluating and registering cloud services that meet the security requirements of the government in advance, thereby contributing to the smooth introduction of cloud services.

The following table lists the requirements supported by GitLab for ISMAP and the controls for the requirements. You can use the ismap.json template to create a compliance framework for this standard.

ISMAP requirement	Description	Supported controls
6.1.2 Segregation of duties	Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
9.3.1 Use of secret authentication information	Users should be required to follow the organization’s practices in the use of secret authentication information.	Secret detection running
9.4.5 Access control to program source code	Access to program source code should be restricted.	Default branch protected
12.1.2 Change management	Changes to the organization, business processes, information processing facilities and systems that affect information security should be controlled.	Default branch protected
12.6.1 Management of technical vulnerabilities	Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organization’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.	Dependency scanning running Container scanning running
14.2.1 Secure development policy	Rules for the development of software and systems should be established and applied to developments within the organization.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running
14.2.8 System security testing	Testing of security functionality should be carried out during development.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running
18.1.2 Intellectual property rights	Appropriate procedures should be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.	License compliance running

ISO 27001 compliance requirements

ISO 27001 is an internationally recognized standard that provides a framework for implementing and managing an Information Security Management System (ISMS).

The following table lists the requirements supported by GitLab for ISO 27001 and the controls for the requirements. You can use the iso_27001:2022.json template to create a compliance framework for this standard.

ISO 27001 requirement	Description	Supported controls
5.3 Segregation of duties	Conflicting duties and conflicting areas of responsibility shall be segregated.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
5.17 Authentication information	Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.	Secret detection running
5.18 Access rights	Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
5.32 Intellectual property rights	The organization should implement appropriate procedures to protect intellectual property rights.	License compliance running
8.4 Access to source code	Read and write access to source code, development tools and software libraries shall be appropriately managed.	Default branch protected
8.8 Management of technical vulnerabilities	Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.	Dependency scanning running Container scanning running SAST running DAST running API security running Fuzz testing running
8.28 Secure coding	Secure coding principles shall be applied to software development.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running
8.29 Security testing in development and acceptance	Security testing processes shall be defined and implemented in the development lifecycle.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running
8.32 Change management	Changes to information processing facilities and information systems shall be subject to change management procedures.	Default branch protected

NIST compliance requirements

The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) provides standards, measurements, and testing for information systems, focusing on interoperability, security, usability, and reliability. These compliance standards involves implementing security and privacy controls across various areas, including:

Risk management
Identification and authentication
Incident response
System and communications protection

Controls are available for NIST 800-53, NIST 800-171, NIST SP 800-218, and NIST CSF 2.0 compliance standards.

NIST 800-53 compliance requirements

The following table lists the requirements supported by GitLab for NIST 800-53 Revision 5 and the controls for the requirements. You can use the nist_800-53_r5 template to create a compliance framework for this standard.

NIST 800-53 requirement	Description	Supported controls
AC-3(2): Dual Authorization	Enforce dual authorization for organization-defined privileged commands and/or other organization-defined actions.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
AC-5: Separation of Duties	Separate duties of individuals to prevent malevolent activity without collusion; document separation of duties; and define system access authorizations to support separation of duties.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
AU-9(5): Dual Authorization	Enforce dual authorization for the deletion or modification of organization-defined audit information.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-3: Configuration Change Control	Determine types of configuration-controlled changes; review and approve changes with security/privacy impact analysis; document decisions; implement approved changes; retain records; monitor activities associated with changes; and coordinate change control oversight through designated elements.	Default branch protected At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-3(1): Automated Documentation, Notification, and Prohibition of Changes	Use automated mechanisms to document proposed changes to the system; notify organization-defined approval authorities; highlight change approvals that have not been received by organization-defined time period; prohibit changes to the system until designated approvals are received; and document all changes to the system.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-5: Access Restrictions for Change	Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.	Default branch protected At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-5(4): Dual Authorization	Enforce dual authorization for implementing changes to organization-defined system components and system-level information.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-6: Configuration Settings	Establish and document secure configuration settings for system components; implement these settings; identify, document, and approve deviations based on operational requirements; and monitor and control changes to configurations according to organizational policies.	Author approved merge request is forbidden
CM-7: Least Functionality	Configure the system to provide only organization-defined mission essential capabilities; and Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services.	Committers approved merge request is forbidden Merge requests approval rules prevent editing
CM-9(1): Assignment of Responsibility	Assign responsibility for developing the configuration management process to organizational personnel that are not directly involved in system development.	Default branch protected
CM-10: Software Usage Restrictions	Use software and associated documentation in accordance with contract agreements and copyright laws; track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.	License compliance running
CP-9(7): Dual Authorization	Enforce dual authorization for the deletion or destruction of organization-defined backup information.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
IA-2(10): Single Sign-on	Provide a single sign-on capability for organization-defined system accounts and services.	Auth SSO enabled
IA-2(12): Acceptance of PIV Credentials	Accept and electronically verify Personal Identity Verification (PIV) credentials.	Auth SSO enabled
IA-5(7): No Embedded Unencrypted Static Authenticators	Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.	Secret detection running
IA-5(9): Federated Credential Management	Use organization-defined external organizations to federate credentials.	Auth SSO enabled
IA-8(1): Acceptance of PIV Credentials From Other Agencies	Accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies.	Auth SSO enabled
IA-8(5): Acceptance of PIV-I Credentials	Accept and verify Personal Identity Verification-I (PIV-I) credentials.	Auth SSO enabled
RA-5: Vulnerability Monitoring and Scanning	Scan for vulnerabilities in the system and hosted applications; employ vulnerability scanning tools and techniques; analyze vulnerability scan reports and results; remediate legitimate vulnerabilities; and share vulnerability information.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
SA-11(1): Static Code Analysis	Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.	SAST running
SA-11(8): Dynamic Code Analysis	Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.	DAST running Fuzz testing running

NIST 800-171 compliance requirements

The following table lists the requirements supported by GitLab for NIST 800-171 Revision 3 CMMC and the controls for the requirements.

NIST 800-171 requirement	Description	Supported controls
03.01.04 Separation of Duties	a) Identify the duties of individuals requiring separation. b) Define system access authorizations to support separation of duties.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
03.04.04 Impact Analyses	a) Analyze changes to the system to determine potential security impacts prior to change implementation. b) Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented.	Default branch protected
03.04.05 Access Restrictions for Change	a) Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.	Default branch protected
03.04.10 System Component Inventory	a) Develop and document an inventory of system components. b) Review and update the system component inventory. c) Update the system component inventory as part of installations, removals, and system updates.	License compliance running
03.05.07 Password Management	b) Verify that passwords are not found on the list of commonly used, expected, or compromised passwords when users create or update passwords. c) Transmit passwords only over cryptographically protected channels. d) Store passwords in a cryptographically protected form.	Secret detection running
03.11.02 Vulnerability Monitoring and Scanning	a) Monitor and scan the system for vulnerabilities and when new vulnerabilities affecting the system are identified. c) Update system vulnerabilities to be scanned and when new vulnerabilities are identified and reported.	Dependency scanning running Container scanning running SAST running DAST running API security running Fuzz testing running

NIST CSF 2.0 compliance requirements

The following table lists the requirements supported by GitLab for NIST CSF and the controls for the requirements.

NIST CSF 2.0 requirement	Description	Supported controls
ID.RA-01 - Identity - Risk Assessment: The cybersecurity risk to the organization, assets, and individuals is understood by the organization.	Vulnerabilities in assets are identified, validated, and recorded.	Dependency scanning running Container scanning running
ID.RA-07 - Identity - Risk Assessment: The cybersecurity risk to the organization, assets, and individuals is understood by the organization.	Changes and exceptions are managed, assessed for risk impact, recorded, and tracked.	Default branch protected
PR.AA-05 - Protect - Identity Management, Authentication, and Access Control: Access to physical and logical assets is limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access.	Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
PR.PS-06 - Protect - Platform Security: The hardware, software (for example, firmware, operating systems, and applications), and services of physical and virtual platforms are managed consistent with the organization’s risk strategy to protect their confidentiality, integrity, and availability.	Secure software development practices are integrated, and their performance is monitored throughout the software development lifecycle.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running

NIST SP 800-218 compliance requirements

The following table lists the requirements supported by GitLab for NIST SP 800-218 and the controls for the requirements.

NIST SP 800-218 requirement	Description	Supported controls
PO.1.1 Define Security Requirements for Software Development	PO.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.	Default branch protected
PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality	PW.4.1: Acquire and maintain well-secured software components (for example, software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software. PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.	License compliance running Dependency scanning running Container scanning running
PW.5.1 Create Source Code by Adhering to Secure Coding Practices	PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.	Code quality running
PW.7 Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements	PW.7.1: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization. PW.7.2: Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.	SAST running DAST running Secret detection running
PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements	PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.	DAST running API security running Fuzz testing running
RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis	RV.1.1: Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.	Dependency scanning running Container scanning running

PCI DSS v4.0.1 compliance requirements

PCI DSS is the PCI Data Security Standard.

The following table lists the requirements supported by GitLab for PCI DSS v4.0.1 and the controls for the requirements. You can use the pci_dss_v4-0-1.json template to create a compliance framework for this standard.

PCI DSS v4.0.1 requirement	Description	Supported controls
6.2 Bespoke and custom software are developed securely.	6.2.3 Review bespoke and custom software prior to release to identify and correct coding vulnerabilities. Ensure code follows secure coding guidelines and addresses emerging vulnerabilities. Implement software engineering techniques to prevent common software attacks.	API security running DAST running Fuzz testing running SAST running Secret detection running
6.5 Changes to all system components are managed securely.	6.5.1 Implement changes to system components according to established procedures including: documenting reason and description, security impact analysis, approval by authorized parties, and testing for security impacts. Separate production and pre-production environments. 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls. 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.	Code changes requires code owners Author approved merge request is forbidden Committers approved merge request is forbidden At least two approvals Reset approvals on push Default branch protected Merge requests approval rules prevent editing
7.2 Access to system components and data is appropriately defined and assigned.	7.2.5 All application and system accounts and related access privileges are assigned and managed as follows: Based on the least privileges necessary for the operability of the system or application; access is limited to the systems, applications, or processes that specifically require their use.	CI/CD job token scope enabled User-defined CI/CD variables restricted to maintainers Project visibility not public Restricted build access Strict Permission for Repository
7.3 Access to system components and data is managed via an access control system(s).	7.3.1 An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. 7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function.	CI/CD job token scope enabled User-defined CI/CD variables restricted to maintainers Project visibility not public Restricted build access Strict Permission for Repository
8.3 Strong authentication for users and administrators is established and managed.	8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: Something you know, such as a password or passphrase; something you have, such as a token device or smart card; Something you are, such as a biometric element.	Auth SSO enabled Require MFA at organization level Require MFA for contributors
8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.	8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access. 8.4.2 MFA is implemented for all non-console access into the CDE.	Auth SSO enabled Require MFA at organization level Require MFA for contributors
8.6 Use of application and system accounts and associated authentication factors is strictly managed.	8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.	Secret detection running
11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.	11.3.1 Perform internal vulnerability scans using authenticated scanning methods. Address high-risk/critical vulnerabilities promptly and manage other vulnerabilities based on risk assessment. Conduct scans after significant changes to systems. 11.3.2 Perform external vulnerability scans via qualified personnel. Address high-risk/critical vulnerabilities promptly and manage other vulnerabilities based on risk assessment. Conduct scans after significant changes to systems.	Container scanning running Dependency scanning running DAST running Fuzz testing running IaC scanning running

SOC 2 compliance requirements

SOC is the System and Organization Controls.

The following table lists the requirements supported by GitLab for SOC 2 and the controls for the requirements.

SOC 2 requirement	Description	Supported controls
CC3.2 - COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.	POF 7: Identifies Vulnerability of System Components - The entity identifies the vulnerabilities of system components, including system processes, infrastructure, software, and other information assets.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running
CC3.4 - COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control.	POF 4: Assesses Changes in Systems and Technology - The risk identification process considers changes arising from changes in the entity’s systems and changes in the technology environment. POF 6: Assesses Changes in Threats and Vulnerabilities - The risk identification process assesses changes in (1) internal and external threats to and vulnerabilities of the components of the entity’s systems and (2) the likelihood and magnitude of the resultant risks to the achievement of the entity’s objectives.	Dependency scanning running Container scanning running DAST running API security running Fuzz testing running Default branch protected
CC5.1 - COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.	POF 6: Addresses Segregation of Duties - Management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities.	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
CC6.6 - The entity implements logical access security measures to protect against threats from sources outside its system boundaries.	POF 2: Protects Identification and Authentication Credentials - Identification and authentication credentials are protected during transmission outside its system boundaries.	Secret detection running
CC6.8 - The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.	POF 2: Detects Unauthorized Changes to Software and Configuration Parameters - Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software.	Default branch protected
CC7.1 - To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.	POF 5: Conducts Vulnerability Scans - The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment. Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity’s objectives.	Dependency scanning running Container scanning running SAST running DAST running API security running Fuzz testing running
CC7.2 - The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.	POF 1: Implements Detection Policies, Procedures, and Tools - Detection policies, procedures, and tools are defined and implemented on infrastructure and software to identify potential intrusions, inappropriate access, and anomalies in the operation of or unusual activity on systems. Procedures may include (1) a defined governance process for security event detection and management; (2) use of intelligence sources to identify newly discovered threats and vulnerabilities; and (3) logging of unusual system activities.	Secret detection running
CC8.1 - The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.	POF 2: Authorizes Changes - A process is in place to authorize system and architecture changes prior to design, development, or acquisition and configuration. POF 7: Tests System Changes - A process is in place to test internally developed and acquired system changes prior to implementation into the production environment. Examples of testing may include unit, integration, regression, static and dynamic application source code, quality assurance, or automated testing (whether point in time or continuous). POF 8: Approves System Changes - A process is in place to approve system changes prior to implementation. POF 16: Protects Confidential Information - The entity protects confidential information during system design, development, testing, implementation, and change processes to support the achievement of the entity’s objectives related to confidentiality.	SAST running DAST running Secret detection running Default branch protected At least two approvals

TISAX compliance requirements

TISAX is the Trusted Information Security Assessment Exchange.

The following table lists the requirements supported by GitLab for TISAX and the controls for the requirements.

TISAX requirement	Description	Supported controls
1.2.2 To what extent are information security responsibilities organized?	A successful ISMS requires clear responsibilities in the organization. An appropriate organizational separation of responsibilities should be established to avoid conflict of interests (separation of duties). (C, I, A)	At least two approvals Author approved merge request is forbidden Committers approved merge request is forbidden Merge requests approval rules prevent editing
1.3.4 To what extent is it ensured that only evaluated and approved software is used for processing the organization’s information assets?	Information processing is mostly done using of specific software. Security issues in software can become a risk for the information processed. Accordingly, software must be appropriately managed. Software is approved before installation or use. The software repositories are protected against unauthorized manipulation. Approval of software is regularly reviewed. Software versions and patch levels are known.	Dependency scanning running Container scanning running License compliance running
5.2.1 To what extent are changes managed?	The objective is to ensure that information security aspects are considered in case of any changes to the organization, business processes and IT systems (Change Management) to prevent these changes from causing an uncontrolled reduction in the information security level. Information security requirements for changes to the organization, business processes, and IT systems are determined and applied. A formal approval procedure is established.	Default branch protected
5.2.5 To what extent are vulnerabilities identified and addressed?	Vulnerabilities increase the risk of IT systems being unable to meet the requirements for confidentiality, availability and integrity. Exploitation of vulnerabilities is among the possible ways for attackers to gain access to the IT system or to threaten its operating stability. Information on technical vulnerabilities for the IT systems in use is gathered (for example, information from the manufacturer, system audits, CVS database) and evaluated. For example, Common Vulnerability Scoring System (CVSS). Potentially affected IT systems and software are identified, assessed and any vulnerabilities are addressed.	Dependency scanning running Container scanning running
5.3.1 To what extent is information security considered in new or further developed IT systems?	Information security is an integral part of the entire lifecycle of IT systems. This particularly includes consideration of information security requirements in the development or acquisition of IT systems. The information security requirements associated with the design and development of IT systems are determined and considered. The information security requirements associated with the acquisition or extension of IT systems and IT components are determined and considered. Information security requirements associated with changes to developed IT systems are considered. System approval tests are carried out under consideration of the information security requirements.	Dependency scanning running Container scanning running SAST running DAST running API security running Secret detection running Fuzz testing running
7.1.1 To what extent is compliance with regulatory and contractual provisions ensured?	Non-compliance with legal, regulatory, or contractual provisions can create risks to the information security of customers and the own organization. Therefore, it is essential to ensure that these provisions are known and observed. Legal, regulatory, and contractual provisions of relevance to information security (see examples) are determined at regular intervals.	License compliance running