How can organizations join or build a Gaia‑X AISBL-compliant environment? In this article, we will describe how to become a member or participant of the Gaia-X program and how to achieve the compliance label.
Becoming a Gaia-X member or participant
- Decide the role and membership type
Gaia-X welcomes users (end-customers) and providers (cloud-/data-service-providers) of all sizes. There are different membership types, with a tiered fee based on your annual consolidated revenue. Before you decide, you must understand your objectives: do you just want to be part of the ecosystem, or do you intend to become a service provider or federator?
Once you are clear on the type of participation, contact Gaia-X through their online membership form. Fill in the application documents, send them, and wait for the Board’s decision. Only then will you pay the membership fees. Once accepted, you can join the working groups, get access to your specification drafts, the Gaia-X network, and start contributing.
As a member of Gaia-X, you can join Working Groups (technical, governance, domain-specific) and contribute to the standard/specifications development. You’ll also benefit from networking, visibility, opportunities for joint tenders, and more.
Once a member (or even non-members in some cases), you can start using the Gaia-X framework: adopt its trust framework with identity/decentralized credentials, label verification, and federation services.
Ultimately, joining Gaia-X as a member provides upstream visibility of how federation, trust, and compliance frameworks are evolving. You can then integrate them into your practice.
Compliance: how to get a Gaia-X label
- Understand the compliance and labelling framework
Gaia-X defines Labels (Levels 1, 2, 3) to indicate different maturity, sovereignty or compliance criteria:
- Label Level 1: Basic compliance (transparency, interoperability)
- Label Level 2: Adds criteria like customer’s data can be processed exclusively in the EEA (European Economic Area) and stronger cybersecurity.
- Label Level 3: More restrictive. Provider headquarters and main establishments in EEA, data processed only in EEA, stronger sovereignty requirements.
Note that a service (not just a provider) is what receives the label. The compliance mechanisms go via the Gaia‑X Digital Clearing House (GXDCH) network (verifier nodes), and the “Policy Rules Compliance Document” lays out mandatory criteria such as transparency, security, portability, interoperability, and sustainability of the certified service.
- Get verified
Onboarding as a service provider and getting verified involves multiple requirements and steps. Here’s a rough checklist:
- You need to enrol your legal entity (company) with a valid registration (VAT/EORI/LEI) etc., so you become a “participant” in the Gaia-X ecosystem.
- Use verifiable credentials (DIDs) and wallets for identity, service description signing and compliance proofs.
- Prepare a self-description of the service (metadata: what it offers, location, data practices, interoperability features, portability features).
- Map your service against the compliance criteria (transparency, security, data localisation, interoperability, etc.). Collect evidences (e.g., certifications, audit reports, data residency declarations).
- Use a clearing house node (one of the GXDCHs) to submit your verifiable credential and service offering for evaluation.
- After verification, you receive a Gaia-X Label Credential as a verifiable credential. This can be placed in your service catalogue.
Technical and infrastructure requirements
Here are some additional considerations about technical and infrastructure requirements to get certified for a service:
- For Level 2/3 you must guarantee that the consumer’s data is processed and shared exclusively in the EEA.
- Use open standards, APIs, service descriptions, federated identity/trust. The Gaia-X architecture document outlines the required technical components.
- The system uses Trust Anchors, verifiable credentials, and open-source compliance software (in the GXDCH).
- The service must expose metadata so that customers can evaluate compliance (e.g., it must include a well-known “/.well-known/gx-compliance” endpoint). Example: Deutsche Telekom-OpenTelekomCloud did that.
- The service must expose metadata so that customers can evaluate compliance (e.g., it must include a well-known “/.well-known/gx-compliance” endpoint). Example: Deutsche Telekom-OpenTelekomCloud did that.
- If you want to become a node (a GXDCH operator), you must deploy mandatory software components (Compliance engine, Registry, Notary) as per Gaia-X’s GitLab.
Governance, certification, and ongoing comopliance
Compliance is not a one-time tick: you must continuously adhere to policies. The Clearing House and GXDCH may require updates, audits, and recertification. For this reason, you should integrate your monitoring and audit workflows.
In your service catalogue, you can embed the verifiable credential and show how you meet transparency, security, and sovereignty criteria.