At least one of taxID, vatID, EUID, EORI or leiCode must be defined.
The PARTICIPANT signing the Self-Description agrees as follows: - to update its descriptions about any changes, be it technical, organizational, or legal - especially but not limited to contractual in regards to the indicated attributes present in the descriptions. The keypair used to sign Verifiable Credentials will be revoked where Gaia-X Association becomes aware of any inaccurate statements in regards to the claims which result in a non-compliance with the Trust Framework and policy rules defined in the Policy Rules and Labelling Document (PRLD).
type of data support: digital, physical.
type of Media Types (formerly known as MIME types) as defined by the IANA.
a resolvable link to the service offering self-description related to the service and that can exist independently of it.
a resolvable link to the resources self-description related to the service and that can exist independently of it.
a resolvable link to the participant self-description providing the service.
a list of policy expressed using a DSL (e.g., Rego or ODRL) (access control, throttling, usage, retention, …).
Refer to https://gaia-x.gitlab.io/policy-rules-committee/trust-framework/service_and_subclasses/#service-offering Personal Data Protection Regimes
list of methods to export data from your user’s account out of the service
A Physical resource is, but not limited to, a datacenter, a bare-metal service, a warehouse, a plant. Those are entities that have a weight and position in physical space.
A list of resolvable links to Gaia-X Credentials of participant manufacturing the resource.
A resolvable link of resources related to the resource and that can exist independently of it.
a list of physical GPS in ISO 6709:2008/Cor 1:2009 format.
A list of resolvable links to Gaia-X Credentials of participant owning the resource.
A list of resolvable links to Gaia-X Credentials of participants maintaining the resource in operational condition and thus having physical access to it.
It represents static data in any form and necessary information such as dataset, configuration file, license, keypair, an AI model, neural network weights, etc.
A list of policy expressed using a DSL (e.g., Rego or ODRL) (access control, throttling, usage, retention, ...). If there is no specified usage policy constraints on the VirtualResource, the policy should express a simple default: allow intent
A list of SPDX identifiers or URL to document.
A list of copyright owners either as a free form string or as resolvable link to Gaia-X Credential of participants. A copyright owner is a person or organization that has the right to exploit the resource. Copyright owner does not necessarily refer to the author of the resource, who is a natural person and may differ from copyright owner.
An Instantiated Virtual Resource is an instance from a Virtual Resource, and is a running resource exposing endpoints such as, and not limited to, a running process, an online API, a network connection, a virtual machine, a container, an operating system.
A list of participant maintaining the resource in operational condition.
A resource where the process is located (physical server, datacenter, availability zone, …).
A virtual resource (normally a software resource) this process is an instance of.
A list of participant with contractual relation with the resource.
A list of Service Access Point which can be an endpoint as a mean to access and interact with the resource.
A service access point is an identifying label for network endpoints used in the OSI model. The format below doesn’t represent all possible service access point types.
A data resource is extending the DCAT-3 Dataset class and primarily refers to an analytical dataset exposed via one or more InstantiatedVirtualResource service access points.
a resolvable link to the participant self-description legally enabling the data usage.
A resolvable link to the data exchange component that exposes the data resource.
date time in ISO 8601 format after which data is obsolete.
date time in ISO 8601 format after which data is expired and shall be deleted.
Whether the service contains Personal Identifiable Informations.
Country code in ISO 3166-1 alpha2, alpha-3 or numeric format.
The v:locality property specifies the locality (e.g., city) of a postal address.
Reasons to process PII as detailed in your personal data protection regime
an URL pointing to a contact form or an emailaddress.
a resolvable link to the service offering self-description to which label level is assigned to.
Gaia-X Policy Rules and Labelling Criteria for Providers
The Provider shall offer the ability to establish a legally binding act. This legally binding act shall be documented.
The Provider shall have an option for each legally binding act to be governed by EU/EEA/Member State law.
The Provider shall clearly identify for which parties the legal act is binding.
The Provider shall ensure that the legally binding act covers the entire provision of the Service Offering.
The Provider shall ensure there are specific provisions regarding service interruptions and business continuity (e.g., by means of a service level agreement), Provider’s bankruptcy or any other reason by which the Provider may cease to exist in law.
The Provider shall ensure there are provisions governing the rights of the parties to use the service and any Customer Data therein.
The Provider shall ensure there are provisions governing changes, regardless of their kind.
The Provider shall ensure there are provisions governing aspects regarding copyright or any other intellectual property rights.
The Provider shall declare the location of the processing of any Customer Data at urban area level.
The Provider shall explain how information about subcontractors and related Customer Data localization will be communicated.
The Provider shall communicate to the Customer where the applicable jurisdiction(s) of subcontractors will be.
The Provider shall include in the contract the contact details where Customer may address any queries regarding the Service Offering and the contract.
The Provider shall adopt the Gaia-X Trust Framework, by which Customers may verify Provider’s Service Offering.
The Provider shall provide transparency on the environmental impact of the Service Offering provided
Service Offering shall include a policy using a common Domain-Specific Language (DSL) to describe Permissions, Requirements and Constraints.
Service Offering requires being operated by Service Offering Provider with a verified identity.
Service Offering must provide a conformant self-description.
Self-Description attributes need to be consistent across linked Self-Descriptions.
The Provider shall ensure that the Consumer uses a verified identity provided by the Federator.
The Provider shall offer the ability to establish a contract under Union or EU/EEA/Member State law and specifically addressing GDPR requirements.
The Provider shall define the roles and responsibilities of each party.
The Provider shall clearly define the technical and organizational measures in accordance with the roles and responsibilities of the parties, including an adequate level of detail.
The Provider shall be ultimately bound to instructions of the Customer.
The Provider shall clearly define how Customer may instruct, including by electronic means such as configuration tools or APIs.
The Provider shall clearly define if and to which extent third country transfer will take place.
The Provider shall clearly define if and to the extent third country transfers will take place, and by which means of Chapter V GDPR these transfers will be protected.
The Provider shall clearly define if and to which extent sub-processors will be involved.
The Provider shall clearly define if and to the extent sub-processors will be involved, and the measures that are in place regarding sub-processors management.
The Provider shall define the audit rights for the Customer.
In case of a joint controllership, the Provider shall ensure an arrangement pursuant to Art. 26 (1) GDPR is in place.
In case of a joint controllership, at a minimum, the Provider shall ensure that the very essence of such agreement is communicated to data subjects.
In case of a joint controllership, the Provider shall publish a point of contact for data subjects.
Organization of information security: Plan, implement, maintain and continuously improve the information security framework within the organisation.
Information Security Policies: Provide a global information security policy, derived into policies and procedures regarding security requirements and to support business requirements.
Risk Management: Ensure that risks related to information security are properly identified, assessed, and treated, and that the residual risk is acceptable to the CSP.
Human Resources: Ensure that employees understand their responsibilities, are aware of their responsibilities with regard to information security, and that the organisation’s assets are protected in the event of changes in responsibilities or termination.
Asset Management: Identify the organisation’s own assets and ensure an appropriate level of protection throughout their lifecycle.
Physical Security: Prevent unauthorised physical access and protect against theft, damage, loss and outage of operations.
Operational Security: Ensure proper and regular operation, including appropriate measures for planning and monitoring capacity, protection against malware, logging and monitoring events, and dealing with vulnerabilities, malfunctions and failures.
Identity, Authentication and access control management: Limit access to information and information processing facilities.
Cryptography and Key management: Ensure appropriate and effective use of cryptography to protect the confidentiality, authenticity or integrity of information.
Communication Security: Ensure the protection of information in networks and the corresponding information processing systems.
Portability and Interoperability: The CSP shall provide a means by which a customer can obtain their stored customer data, and provide documentation on how (where appropriate, through documented API’s) the CSC can obtain the stored data at the end of the contractual relationship and shall document how the data will be securely deleted from the Cloud Service Provider in what timeframe.
Change and Configuration Management: Ensure that changes and configuration actions to information systems guarantee the security of the delivered cloud service.
Development of Information systems: Ensure information security in the development cycle of information systems.
Procurement Management: Ensure the protection of information that suppliers of the CSP can access and monitor the agreed services and security requirements.
Incident Management: Ensure a consistent and comprehensive approach to the capture, assessment, communication and escalation of security incidents.
Business Continuity: Plan, implement, maintain and test procedures and measures for business continuity and emergency management.
Compliance: Avoid non-compliance with legal, regulatory, self-imposed or contractual information security and compliance requirements.
User documentation: Provide up-to-date information on the secure configuration and known vulnerabilities of the cloud service for cloud customers.
Dealing with information requests from government agencies: Ensure appropriate handling of government investigation requests for legal review, information to cloud customers, and limitation of access to or disclosure of Customer Data.
Product safety and security: Provide appropriate mechanisms for cloud customers to enable product safety and security.
The Provider shall implement practices for facilitating the switching of Providers and the porting of Customer Data in a structured, commonly used and machine-readable format including open standard formats where required or requested by the Customer.
The Provider shall ensure pre-contractual information exists, with sufficiently detailed, clear and transparent information regarding the processes of Customer Data portability, technical requirements, timeframes and charges that apply in case a professional user wants to switch to another Provider or port Customer Data back to its own IT systems.
For Label Level 2, the Provider shall provide the option that all Customer Data are processed and stored exclusively in EU/EEA.
For Label Level 3, the Provider shall process and store all Customer Data exclusively in the EU/EEA.
For Label Level 3, where the Provider or subcontractor is subject to legal obligations to transmit or disclose Customer Data on the basis of a non-EU/EEA statutory order, the Provider shall have verified safeguards in place to ensure that any access request is compliant with EU/EEA/Member State law.
For Label Level 3, the Provider’s registered head office, headquarters and main establishment shall be established in a Member State of the EU/EEA.
For Label Level 3, Shareholders in the Provider, whose registered head office, headquarters and main establishment are not established in a Member State of the EU/EEA shall not, directly or indirectly, individually or jointly, hold control of the CSP. Control is defined as the ability of a natural or legal person to exercise decisive influence directly or indirectly on the CSP through one or more intermediate entities, de jure or de facto. (cf. Council Regulation No 139/2004 and Commission Consolidated Jurisdictional Notice under Council Regulation (EC) No 139/2004 for illustrations of decisive control).
For Label Level 3, in the event of recourse by the Provider, in the context of the services provided to the Customer, to the services of a third-party company - including a subcontractor - whose registered head office, headquarters and main establishment is outside of the European Union or who is owned or controlled directly or indirectly by another third-party company registered outside the EU/EEA, the third-party company shall have no access over the Customer Data nor access and identity management for the services provided to the Customer. The Provider, including any of its sub-processor, shall push back any request received from non-European authorities to obtain communication of Customer Data relating to European Customers, except if request is made in execution of a court judgment or order that is valid and compliant under Union law and applicable Member States law as provided by Article 48 GDPR.
For Label Level 3, the Provider must maintain continuous operating autonomy for all or part of the services it provides. The concept of operating autonomy shall be understood as the ability to maintain the provision of the cloud computing service by drawing on the provider’s own skills or by using adequate alternatives
The Provider shall not access Customer Data unless authorized by the Customer or when the access is in accordance with EU/EEA/Member State law.
Link to website to complete evidence information
Link to attestation PDF to complete evidence information