DORA (Digital Operational Resilience Act) Mapping

How GitLab addresses the key contractual requirements of the Digital Operational Resilience Act

Important Notice

The information in this summary is intended as an overview and outline of certain Digital Operational Resilience Act (“DORA”) related matters. Its purpose is to inform and raise awareness amongst GitLab’s current and prospective customers who fall under the DORA regulation. This DORA Mapping does not provide legal advice and shall not be construed or used as such, nor does this document form part of, create or amend any agreement, representations, warranties or any other obligation between GitLab and its customers. Customers must seek and rely only on independent legal advice on any DORA related matter and customers acknowledge that they remain solely responsible for complying with their legal and regulatory requirements. GitLab shall have no liability arising from any errors, misstatements or omissions in the content of this DORA Mapping document.

Regulatory Context

The Digital Operational Resilience Act was created to harmonise security and resilience practices across Financial Entities (“FEs”) operating in the European Union, and requires that all financial market participants, including stakeholders in the financial sector, which so far have not been subject to extensive ICT security regulation (credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, insurance companies, crypto-asset service providers, exchanges and clearing houses, alternative fund managers, pension, credit rating agencies, etc) can maintain resilient operations through severe operational disruption caused by cyber security and information and communication technology (ICT) issues. DORA does not override any existing cyber security regulations applicable to the financial sector (such as NIS-2, EBA etc), it exists alongside those. While GitLab has not historically been considered an outsourcing partner under the EBA Guidelines, DORA doesn’t just apply to outsourcing arrangements, but to the use of all “ICT Services”, casting a much broader net amongst information technology providers. Accordingly, GitLab wishes to help our customers better understand how they may comply with their DORA requirement in the context of their use of GitLab’s DevSecOps platform. DORA officially came into effect on the 16th of January, 2023 and its provisions apply and are enforceable from the 17th of January, 2025 following the implementation period.

GitLab’s Approach

This DORA Mapping document aims at assisting financial services customers that fall under the rules of DORA to navigate the use of GitLab’s Software in relation to the various considerations introduced by DORA. With this document we’d like to make it easier for our financial sector customer to gather the necessary information for their own regulatory compliance. In the below table, you will find a list of requirements under DORA, alongside the references to the relevant information and GitLab policies.

GitLab’s contractual framework relevant for DORA compliance purposes, consists of a number of components, which may include the following:

• GitLab Subscription Agreement (“GLSA”) (or similar document entered into by the parties) includes the terms and conditions applicable to the use of GitLab’s Software;

• Data Processing Addendum (“DPA”) is incorporated into and forms integral part of the GLSA and sets out the data processing rules between the parties;

• Order Form – includes the specific products/services purchased, pricing and any other specific commercial terms and conditions applicable;

• Statement of Work (“SOW”) – if Professional Services are purchased, the SOW includes the description and method of delivery of such services, as well as the assumption and specific obligations of the parties etc. our Professional Services team will work with you to discuss and determine your needs and requirements.

• Service Specific / Additional Terms – depending on the products/services purchased, Additional Terms may apply, such as the AI Terms, Agile Planning, Professional Services Addendum etc; if you are considering GitLab Dedicated, our Sales team will be happy to assist you with any specific terms or provisions.

• Financial Services Addendum – includes additional terms to address specific regulatory requirements applicable to our financial sector customers. Please contact your Account Executive if this regulatory addendum is relevant for your organisation.

All of the above listed documents are referenced in this DORA Mapping document where relevant. Further to the information included in the below informative chart, Gitlab had also engaged a reputable third party firm specialising in IT compliance attestation to perform a DORA related review and assessment of GitLab’s Dedicated services - the summary of this report is available to view on GitLab’s Trust Center.

The information in this document was current as of January 2025.

DORA Requirements and considerations	DORA reference	GitLab’s comment
Pre-contractual due-diligence and general principles
1. The principle of proportionality and the assessment of risks and dependencies. The FEs management of ICT third-party risk shall be implemented in light of the principle of proportionality, taking into account: (i) the nature, scale, complexity and importance of ICT-related dependencies, (ii) the risks arising from contractual arrangements on the use of ICT services concluded with ICT third-party service providers, taking into account the criticality or importance of the respective service, process or function, and the potential impact on the continuity and availability of financial services and activities, at individual and at group level.	Art. 28 (1) b)	GitLab will assist our new or existing financial sector customers in assessing the nature of the services we provide, in the context of our products and the customer’s chosen deployment method. In general, GitLab’s DevSecOps platform is not expected to have a direct impact on the continuity and availability of GitLab’s customers’ ability to deliver financial services to their customers. Please contact your Account Executive with any risk or impact assessment related questions and queries.
2. Information Security Standards. Financial entities may only enter into contractual arrangements with ICT third-party service providers that comply with appropriate information security standards.	Art. 28 (5)	At GitLab, we’re committed to Information Security as detailed in our Security Vision and Mission. We created the GitLab Trust Center, powered by SafeBase, which allows us to maintain a single, unified location for communicating our compliance and assurance credentials, hosting our security and privacy documentation for customer consumption, sharing important notices such as responses to third-party breaches, and hosting our internal knowledge base where customers can readily access the same answers we provide in questionnaire responses. The GitLab Trust Center includes a portal for both GitLab.com and GitLab Dedicated.
3. Access, audit and inspection. In exercising access, inspection and audit rights over ICT third-party service providers, financial entities must, on the basis of a “risk-based approach”, pre-determine the frequency of audits and inspections over third-party service providers and the areas to be audited. Where the ICT services entail high technical complexity, firms must ensure that they verify that the relevant auditors possess appropriate skills and knowledge to effectively perform the audits and assessments.	Art. 28 (6)	Our customers may carry out ongoing remote self-serve assessments via GitLab’s Trust Center, a portal providing access to industry-standard documentation, including various certifications issued against widely recognised relevant professional standards by independent third-party auditors against the objectives stated in ISO 27001, ISO 27017, ISO 27018, SOC 2 Type 2 (or equivalent standards) and other reports and documentation attesting Gitlab’s policies, procedures and security measures. By signing up to the notification function of GitLab’s Trust Center, customers will receive relevant notifications of future or updated versions of the certifications and other collateral.
4. Termination rights. Financial entities must ensure that the contracts they have in place for the use of ICT services may be terminated in a list of circumstances detailed by the referenced article.	Art. 28 (7) a)–d)	GitLab’s FSA addresses these regulatory termination rights. Please contact your Account Executive if this regulatory addendum is relevant for your organisation.
Key contractual provisions
5. The rights and obligations of the financial entity and of the ICT third-party service provider shall be clearly allocated and set out in writing. The full contract shall include the service level agreements and be documented in one written document which shall be available to the parties on paper, or in a document with another downloadable, durable and accessible format.	Art. 30 (1)	The rights and obligations of the parties are set out in writing in the GitLab Subscription Agreement. SaaS service levels are set out in Appendix 1 to the Subscription Agreement and form part thereof. For GitLab Dedicated, a single product-specific attachment, including the respective Service Level Availability of Dedicated SaaS, is available upon request.
6. A clear and complete description of all functions and ICT services to be provided by the ICT third-party service provider, indicating whether subcontracting of an ICT service supporting a critical or important function, or material parts thereof, is permitted and, when that is the case, the conditions applying to such subcontracting.	Art. 30 (2) a)	The description of all functions and services to be provided by GitLab, as set out in the relevant Order Form are included in GitLab’s respective documentation published at https://docs.gitlab.com/. Both GitLab’s FSA and DPA include the appropriate provisions on GitLab’s use of subcontractors / sub-processors. GitLab’s subprocesses are also listed at https://about.gitlab.com/privacy/subprocessors/, together with details of the relevant services and GitLab products with respect to each such sub-processors.
7. The locations where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third party service provider to notify the financial entity in advance if it envisages changing such locations.	Art. 30 (2) b)	GitLab’s FSA sets out location related specific provisions as required. The cloud hosting location for all cloud hosting Sub-processors are as listed at https://about.gitlab.com/privacy/subprocessors/#third-party-sub-processors. To the extent applicable to Customer whose Services include GitLab’s Dedicated software with a specified regional hosting location, as may be mutually agreed and described in an Order Form or Subscription Agreement as applicable, that hosting location will be as so designated. Customers opting for a Self-managed deployment method will install and run the Software on the Customer’s own server and environment.
8. Provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data.	Art. 30 (2) c)	GitLab’s FSA sets out specific provisions related to the availability, authenticity, integrity and confidentiality of data. The DPA sets forth both parties’ obligation with respect to the processing and security of Personal Data, in accordance with applicable data protection laws, and also incorporates the applicable Standard Contractual Clauses. GitLab limits access to Personal Data to personnel who are required to access Personal Data in order to perform the obligations under the Agreement. Customers may also refer to GitLab’s Privacy Statement.
9. Provisions on ensuring access, recovery and return in an easily accessible format of personal and non-personal data processed by the financial entity in the event of the insolvency, resolution or discontinuation of the business operations of the ICT third-party service provider, or in the event of the termination of the contractual arrangements.	Art. 30 (2) d)	GitLab’s FSA sets out specific provisions related to access, recovery and return of data. Customers may, at any time delete any groups through the in-product administrative settings or group dashboard of the Software or may migrate or export their projects at any time during the Subscription as described at https://docs.gitlab.com/ee/user/project/settings/import_export.html.
10. Service level descriptions including updates and revisions thereof.	Art. 30 (2) e)	SaaS service levels are set out in Appendix 1 to the Subscription Agreement and form part thereof. For GitLab Dedicated, a single product-specific attachment, including the respective Service Level Availability of Dedicated SaaS, is available upon request. Service levels are not applicable to Self-Managed customers who deploy and operate the application within their own environment and infrastructure.
11. The obligation of the ICT third-party service provider to provide assistance to the financial entity at no additional cost, or at a cost that is determined ex-ante, when an ICT incident that is related to the ICT service provided to the financial entity occurs.	Art. 30 (2) f)	Provisions on incident reporting and cooperation are set out in the FSA. GitLab’s incident management policy is available to review at https://handbook.gitlab.com/handbook/engineering/infrastructure/incident-management/.
12. The obligation of the ICT third-party service provider to fully cooperate with the competent authorities and the resolution authorities of the financial entity, including persons appointed by them.	Art. 30 (2) g)	GitLab’s cooperation commitment is set out in the FSA.
13. Termination rights and related minimum notice periods for the termination of the contractual arrangements, in accordance with the expectations of competent authorities and resolution authorities.	Art. 30 (2) h)	The GitLab Subscription Agreement clearly sets out termination rights and related notice or cure periods as applicable. GitLab also addresses the additional termination rights as per Art. 28 (7) under the DORA regulation which is included in the FSA.
14. The conditions for the participation of ICT third-party service providers in the financial entities’ ICT security awareness programmes and digital operational resilience training.	Art. 30 (2) i)	Provisions regarding GitLab’s participation in the financial entity’s ICT security awareness programmes are included in the FSA.