/
Regulatory Compliance

Regulatory Compliance

 

1. Summary

This building block aims to guide the data space governance authority in applying legal rules to a data space's design and operation. Specifically, it helps to properly define some participant roles and responsibilities, establish internal policies, and continuously monitor the regulatory compliance of a data space. In addition, it assists data space participants in understanding their rights and obligations under regulatory frameworks that are relevant to their role in a data space or to a specific data transaction. It also provides guidance on relevant legislation to those interested in setting up or joining a data space, including developers, policymakers and others.

Key elements of this building block include:

  • Triggers: Elements, criteria or events (e.g. data type, nature of participant or domain) that have occurred in a particular context of a data space and signals that a specific legal framework must or should be applied.

  • Data space requirements: Regulatory provisions that explicitly refer to data spaces.

  • Additional legal considerations: This element highlights other important legal considerations to be aware of when setting up or operating a data space, e.g. cybersecurity law. 

  • Tools enabling regulatory compliance within a data space: Technical tools or techniques designed to address certain legal requirements (such as secure processing environment, privacy-enhancing technologies etc.).

  • Regulatory Compliance Flowcharts: A step-by-step guidance helping to assess the applicability of a specific legal framework and to determine the requirements to be addressed by specific entities. The main objective of this element is to operationalise the triggers and structure the interplay of the above-mentioned elements. In the future, these flowcharts will become part of the Legal Compass which will reflect more in detail on the relationship between decisions taken in the business, technical or governance of a data space and compliance with particular legal requirements.

2. Purpose of the building block 

The Regulatory Compliance building block encompasses a range of activities designed to ensure compliance with relevant regulatory frameworks. These activities involve understanding the legal requirements for data spaces and ensuring that all elements and functions of the data space comply with the regulatory framework. Regulatory compliance is an ongoing practice throughout the data space lifecycle. 

Implementing the Regulatory Compliance building block requires the data space governance authority to identify the legal rules relevant to its operation. 

The graphic below (Figure 1) shows a sector-agnostic mapping of legislation that could apply to data spaces, data space participants or the data and services offered by data space participants. It constitutes a preliminary analysis allowing for the identification of provisions relevant to the data space as a whole or in particular circumstances. An example of this is the AI Act, which is not likely to be directly applicable to a data space but could be relevant because data used to train high-risk AI systems or general-purpose AI systems may be sourced through data spaces. Depending on the context, the legal frameworks in Figure 1 may apply simultaneously.

While it falls outside the remit of the blueprint to provide an exhaustive listing of such legal frameworks, it is fitting to highlight a number of EU frameworks of particular importance to data spaces. However, it is up to the sectoral data spaces to do a further mapping and identify additional legal requirements from sectoral legislation*. In addition, relevant national legislation must be analysed accordingly.

In this building block, we decided to make an exception for the upcoming European Health Data Space Regulation (EHDS-R) due to its impact on interoperability with other common European data spaces, especially those relevant for health. More information about it can be found in the Data Space Requirements section. We also mention some sector-specific regulatory frameworks in the Examples of domain-specific use cases section.

*While ePrivacy Directive aims to provide for the harmonisation of the national provisions ensuring an equivalent level of protection of fundamental rights and freedoms, respecting at the same time the processing of personal data in the electronic communication sector, it may also apply to non-personal data. As explained in the recent EDPB Guidelines 2/2023, it is especially the case in the art. 5(3) ePrivacy Directive imposing on Member States the obligation to ensure that ‘the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user’ is only allowed on the basis of consent or necessity for specific purposes set out in that Article. According to the Guidelines, and following the CJEU Planet 49 judgment, “the protection applies to any information stored in such terminal equipment, regardless of whether or not it is personal data, and is intended, in particular, as is clear from that recital, to protect users from the risk that hidden identifiers and other similar devices enter those users’ terminal equipment without their knowledge”.

NEW AFTER MBK COMMENTS_EU_Legal_Frameworks.png
Figure 1. EU Legal Frameworks applicable to data spaces development and operation.

The main objectives of this building block revolve around:

  • Guiding data space initiatives on organising compliance with relevant legislation and ensuring that regulatory compliance is maintained throughout the lifecycle of data space development;

  • Supporting data space governance authorities in identifying relevant legal issues that may warrant the adoption of strategies, procedures and mechanisms to facilitate compliance within the data space; 

  • Helping identify legal entitlements to data, and the rights and obligations of data space participants in relation to them;

  • Providing an overview of additional resources to help data spaces and data space participants assess their obligations under EU law (e.g., guidelines adopted by the European Commission or relevant competent authorities).

3. Elements and their key functions 

The Regulatory Compliance building block is composed of five interrelated elements: 

  • Triggers,

  • Data space requirements,

  • Additional legal considerations,

  • Tools enabling regulatory compliance in a data space,

  • Regulatory Compliance Flowcharts.

 This building block focuses on analysing EU legal frameworks that are relevant to all data spaces. Given the possible impact of the European Health Data Space Regulation (EHDS-R), as well as the planned implementing acts establishing interoperability of HealthData@EU infrastructure with other relevant data spaces, an analysis of the impact of the EHDS-R, despite its sectoral nature, has been included in this legislative framework. You can read about the EHDS impact on other (relevant) common European data spaces in “Data Space Requirements” section of this building block.

3.1 The concept of triggers within a data space

Navigating the complexity of regulatory frameworks requires developing an approach to address the legal requirements stemming from them. This process starts with identifying elements, criteria, and/or events in the data space that flag the need, within particular contexts, to apply or comply with a particular framework. 

An element, criterion or event that has occurred in a particular context of a data space is referred to as a 'trigger' for the purposes of this building block. It signals that a particular legal framework must or should be applied.

The triggers may be classified into different categories, such as: 

  • Types of data: This category pertains to data that is available in a certain context. Depending on the precise kinds of data, it may trigger the need to comply with, for example, the GDPR or Data Act requirements.

  • Types of data space participants: Another category pertains to the legal status of participants. Depending on that legal status, such as being a public or specific private body, different regulations may apply. For example, the Data Governance Act regulates the operation of data intermediation services providers or data altruism organisations, which might be active as data space participants.

  • Types of use cases: A third category is about domains and/or use cases, such as health, mobility, etc., where domain-specific regulations would apply.

The figure presented below (Figure 2.) visualises the triggers that have been chosen as a priority for this version of the Blueprint. The criterion for selection was based on the necessity to address specific aspects of the operation of these elements within the governance or contractual framework of a data space.

Figure 2. Classification of triggers in a data space

3.1.1 Types of data

While the current classification of data types within the EU digital regulatory framework lacks methodological consistency, a key distinction is usually made between personal and non-personal data. However, it is important to remember that this distinction is imperfect and should often be subject to a broader discussion about the category that certain data will fall under. 

While the EU data framework seeks to create a single market for data, increasing its availability for use in the economy and society, certain categories of data may be subject to particular protection regimes, imposing restrictions or specific conditions on access or processing. These “protection” regimes include:

  • Personal data protection: According to GDPR, Charter of Fundamental Rights of the European Union of the Treaty on the Functioning of the European Union (TFEU), the protection of natural persons regarding the processing of personal data is a fundamental right. Thus, personal data protection legislation aims to provide data subjects with relevant rights and adequate organisational and technical safeguards. Due to the particularly sensitive aspect of special categories of data, and significant risks to the fundamental rights and freedoms that their processing might pose, they enjoy specific protection under the GDPR.  The special categories of data mentioned in Figure 3 are discussed in more detail in a subpage regarding types of data as a trigger.  

  • Intellectual property and trade secrets: Besides the categories related to the potential identifiability of an individual, there are legal frameworks granting protection to certain datasets due to the specific attributes they possess. These are primarily intellectual property rights (namely copyright), sui generis database rights, or rights granted to trade secret holders. The classification of certain datasets as either personal or non-personal data or the nature of the ownership of (private/public) datasets does not impact the potential application of other protection regimes, in which the originality and individuality of the work, substantial investment or secrecy of a dataset, among others, are relevant. Thus, there might be datasets containing personal data (e.g., customer information) that are kept by an entity as a trade secret, or personal data databases that enjoy the copyright and/or sui generis database protection. In these situations, the data protection principles and data subjects’ rights provided by the GDPR will still be applicable. 

Untitled Diagram-1738832109236.drawio.png
Figure 3. Protection regimes over data(sets)

 

The EU data legislation (notably Data Act, Data Governance Act, Open Data Directive, Regulation on the free flow of non-personal data) is meant to bring about a shift in the accessibility of data, opening up considerably more data for use by a variety of parties. That being said, the “access” regime largely depends on the nature of a data holder, imposing different requirements on the access to:

  • Privately-held data: This includes categories of data governed by specific legal frameworks, mainly the Data Act. It imposes requirements on certain entities, such as the obligation to make product and related services data (IoT data) accessible to users (as specified in Article 3 of the Data Act) or to provide data based on an exceptional need expressed by a public sector body (Business-to-government; B2G) (as specified in Article 14 of the Data Act).

  • Data held by public sector bodies (PSB): These types of data can be distinguished based on their level of openness to the general public. High-value datasets are of particular importance for society, the environment and the economy, therefore they can be re-usable for any purpose. On the other hand, the Data Governance Act (DGA) outlines the conditions under which public sector bodies can allow the reuse of certain protected data (for example, data protected on grounds of commercial confidentiality, including business, professional and company secrets).  

Untitled Diagram-1738834782310.drawio.png
Figure 4. Access regimes with regards to the data

 

Knowing that navigating a long document of descriptions can be challenging, we direct the reader to the sub-pages of the Blueprint, as we want to keep this building block accessible and user-friendly. Within the subpages, the reader will be able to see the description and assessment of impact of the legal requirements concerning different types of triggers.

Click here if you want to read more about data as a trigger: Types of data

3.1.2 Types of participants

Some data space participants will simultaneously be entities whose very existence or specific functions in the ecosystem have been regulated by law and who may have specific requirements imposed on them. The data space participants fall into two main groups: private and public entities. EU regulations, both horizontal and sectoral, as well as various national laws, impose specific rights and obligations depending on whether an entity operates as a public sector organisation, a private company, or a consumer. In the latest EU data regulatory frameworks, the distinction between private and public entities is becoming blurred, introducing rules that apply to entities from both sectors under certain conditions. This is evident for, for instance, data intermediation service providers under the Data Governance Act (DGA). When they facilitate the sharing of non-public sector data to establish commercial relationships, they are subject to the same legal regime as any other data intermediary, provided they offer a ‘service’. Therefore, the dichotomy of participant types should be presented within the spectrum below, from the types of participants considered (most likely) to fall under the category of private entities on the left side (such as gatekeepers), through the borderline or uncertain cases in the middle (such as data altruism organisations), to the types of participants falling under the category of public entities (such as public sector bodies).

Untitled Diagram-1738837178599.drawio.png
Figure 5. Types of participants in the data space.

 

Click here if you want to read more about participant as a trigger: Types of participants

3.1.3 Sector-specific use cases

Although several EU regulations apply broadly to data spaces, specific sectoral regulations may also impact the development of a particular use case. While a complete catalogue of all use cases for individual sectoral data spaces is not feasible, we highlight selected opportunities below for using data to develop different technologies, using the infrastructure of common European data spaces and noting specific legal requirements that may be triggered.

In some situations, it will be important to analyse the sectoral regulations and the broader, horizontal framework. A good example of mapping the legal landscape for developing specific use cases could be the overview prepared by the Green Deal Data Space.

Click here if you want to read more about examples of domain-specific use cases: Types of Use Cases

Untitled Diagram-1738838666340.drawio.png
Figure 6. Overview of the examples of domain-specific use cases.

 

3.2 Data space requirements

The category of data space requirements encompasses legislation that directly regulates data spaces. While the current list of such regulations is limited, there could be various legislative proposals aimed at specific sectoral data spaces, such as the case of the proposed European Health Data Space. 

3.2.1 Interoperability within/between data spaces

3.2.1.1 Data Act

A key piece of legislation that directly regulates data spaces is the Data Act. This act requires data space participants who offer data or data services to meet essential requirements to ensure data interoperability, effective data-sharing mechanisms, and the proper functioning of common European data spaces.

Whereas the Data Act specifically targets participants of data spaces, the obligations of Article 33 of the Data Act, by their very nature, should be considered as intrinsically linked to the infrastructure and governance framework of the data space. The essential requirements to facilitate interoperability should be addressed by the data space governance authority at the level of the data space, taking into account available (harmonised) standards and any potential further delegated acts or guidance adopted by the European Commission. Adequate implementation of the building blocks related to Data Interoperability (Data Models, Data Exchange and Provenance & Traceability building blocks) should also ensure compliance with the provisions of Article 33 of the Data Act. Currently, however, on the basis of art. 3(4) Data Act, the Commission requested relevant European standardisation organisations to draft harmonised standards that satisfy the essential requirements laid down in paragraph 1 of this Article.

3.2.1.2 European Health Data Space Regulation

The European Health Data Space Regulation is currently the only legal instrument setting in place a common European data space. It aims to establish a pan-European infrastructure for trustworthy health data sharing for primary and secondary use. In the context of secondary use, the Regulation also addresses the importance of connecting various common European data spaces, especially by providing interoperability between the European Health Data Space and data spaces from other sectors, such as the environmental, social, and agricultural sectors that may be relevant for additional insights on health determinants. According to art. 52 (12) EHDS, Member States and the Commission shall seek to ensure interoperability of HealthData@EU with other relevant common European data spaces as referred to in the Data Governance Act and Data Act. In addition, by implementing acts, the European Commission may set out common specifications for the interoperability and architecture of HealthData@EU with other relevant common European data spaces.

This building block refers to the most recent publicly available version of the EHDS Regulation text from 8th January 2025. The final version has been adopted by the European Parliament will and published in the Official Journal in March 2025.

3.3 Additional legal considerations

In addition to the legal frameworks outlined above relevant to specific data types, participants and domains, it's crucial to consider additional legal aspects stemming from, for instance, cybersecurity legislative frameworks. Ensuring robust cybersecurity measures is essential to protect data integrity and privacy promotes fair access and innovation within the data space. These considerations play a vital role in maintaining a secure and equitable environment for data management and sharing.

The NIS-2 Directive lays down risk management measures and reporting obligations building resilience and incident response capacities across the Union, with a view to achieve a high common level of cybersecurity. 

It applies to medium and large entities, as well as to to an entity of any size that:

  • Is a public administration entity, 

  • Is the sole provider of a service in a member state, 

  • Could have an impact on public safety, security or health if its services are disrupted, 

  • Could induce systemic risks or have cross-border impacts if its services are disrupted,  

  • Is a critical entity because of its importance at the regional or national level for its sector or type of service, 

  • Provides services by public electronic communications networks, publicly available electronic communications services, trust service providers, or top-level domain name registries and domain name system service providers. 

The directive introduces also the new classification of the essential and important entities, related to the covered organization's industry. Entities of any size that meet any of the first five criteria, and medium-size entities that meet the sixth criteria, are considered essential entities. For example, essential entities are covered organizations in the energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration and space industries. Important entities, on the other hand, are covered organisations in, for example, waste management, chemical production and distribution, manufacturers of medical devices, electrical equipment, transport equipment, digital providers of online marketplaces, search engines and social networking platforms.

While certain data space members or participants might fall under the categories of entities for highly critical or other critical sectors (such as producers of electricity, operators of Intelligent Transport Systems, healthcare providers, trust service providers), and therefore, will be obliged to implement relevant cybersecurity requirements, it should be further analysed whether data spaces as a whole can be considered as one of the critical infrastructures itself in one of the mentioned sectors. If that is the case, it is important to remember that the provisions of the Directive are primarily addressed to be transposed by the Member States on a national level.  Entities falling within the scope of this Directive shall be considered to fall under the jurisdiction of the Member State in which they are established (with several exceptions). However, respective entities can prepare already for the requirements laid down in the art. 21 (2) NIS-2 with the minimum catalogue of risk-management measures, such as: 

  • policies on risk analysis and information system security; 

  • incident handling; 

  • business continuity, such as backup management and disaster recovery, and crisis management; 

  • supply chain security; 

  • security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; 

  • policies and procedures to assess the effectiveness of cybersecurity risk-management measures; 

  • basic cyber hygiene practices and cybersecurity training;

  • policies and procedures regarding the use of cryptography and, where appropriate, encryption; 

  • human resources security, access control policies and asset management; 

  • the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

For more information about compliance requirements laid down in NIS-2: nis2-directive-101-chart.pdf (iapp.org)

One of the category listed in the Annex II of NIS-2 Directive concerns “digital providers”, namely providers of online marketplaces, online search engines, and social networking services platforms. In the light of this, it should be further examined whether a data space can be considered a “provider of online marketplace”. According to the Unfair Commercial Practices Directive, “online marketplace” means a service using software, including a website, part of a website or an application, operated by or on behalf of a trader which allows consumers to conclude distance contracts with other traders or consumers. Although most data spaces will be considered as enablers of B2B relations in the context of data transactions, there may be domains where ''consumers'' will also wish to access data (for example, the Green Deal Data Space allows consumers of relevant resources to participate in specific use cases supported by the data space, targeting objectives at different levels and sharing in the value created through a variety of business models). There are no technical or legal restrictions for a data space to allow only the professionally oriented transactions, thus such consideration remains open to explore. 

 

3.4 Technical tools enabling regulatory compliance within a data space

Within a data space ecosystem, participants assume distinct roles which may come with a number of general or specific legal requirements. The absence of established compliance practices for new legislative frameworks related to the data economy adds complexity, particularly given their interaction with the pre-existing body of regulation (both with a general or digital economy-specific scope, sector-specific and national laws).

Given this complexity and the numerous interconnected decisions within a data space, efficiently addressing certain requirements may warrant using technical tools, aside from the commonly deployed organisational and contractual measures. Such technical tools could vary from tools that assist in identifying relevant requirement to (partially) automating compliance. A number of technical tools are already available that could support compliance within the data spaces. Yet, there is a growing need for automated compliance solutions, which offer greater scalability, efficiency, continuous compliance monitoring, as well as accountability and transparency in reporting. Although automated solutions may have one common purpose - ensuring regulatory compliance by implementing/fulfilling certain legal requirements - they can differ based on the type of legal requirement they aim to implement through automatic means. Currently, there are 4 projects funded by the Horizon Europe Programme which aim to help companies and public sector to easily comply with existing and emerging regulation, creating value on data assets that they possess or that they acquire from the market, More information about the projects can be found via this link.

3.5 Regulatory Compliance Flowcharts (“decision trees”)

As highlighted above, regulatory compliance within a data space requires not only mapping relevant regulations but also identifying “triggers”, data space requirements or other legal considerations. They help to determine which aspects, elements or criteria in the development or operation of a data space must be aligned with specific legal provisions.

The Regulatory Compliance Flowcharts (“decision trees”) presented below provide a simplified guidance for data space governance authority, as well as data space participants to identify relevant triggers within the data space development and operation, that should be addressed in a relevant manner.

Once the applicability of a given framework or requirement is identified, the flowcharts refer the entity to potential “check list” with additional questions to be considered to effectively address the requirements associated with the existence of a trigger. In certain circumstances, flowcharts may also provide additional resources to help better understand the compliance requirements. However, they do not aim to definitively assign roles - instead, they aim to provide guidance on appropriate organizational, legal, or technical tools to help relevant entities independently determine their responsibilities.

The visuals presented below are not a reflection of decisions that specific entities must make but rather illustrates how existence of particular "triggers" might condition the further actions that need to be taken (Figure 7, 8, 9 and 10).




Untitled Diagram-1738771714327.drawio.png
Figure 7. “Personal data as a trigger” flowchart.

 

 

Untitled Diagram-1738653191908.drawio.png
Figure 8. “Trade secret-protected data(sets) as a trigger” roadmap.

 

Untitled Diagram-1738653463933.drawio.png
Figure 9. “Access Regimes and Exceptions” flowchart.
Untitled Diagram-1738653572107.drawio.png
Figure 10. “Data intermediation service provider (DISP)” flowchart.

4. Co-creation questions

  • How does the data space manage legal aspects such as privacy policy, data protection policy and cybersecurity policy?

  • Which legislative frameworks/triggers must be considered for the internal rules?

  • Do any of the parties involved in the data space function as a data intermediary or collaborate with one?

  • Are there intermediaries or gatekeepers involved in the data transactions of this data space?

5. Links to other building blocks

Given the broad regulatory landscape and the diverse provisions that apply to different elements of the data space, the Regulatory Compliance building block will be closely interconnected with all aspects of the Blueprint. It is always important to consider regulatory compliance, as it ensures that all components of the data space adhere to legal requirements and helps mitigate potential risks.

Some of the key interlinkages are highlighted below:

  • Intermediaries and Operators: Some data space intermediaries may qualify as providers of data intermediation services subject to the DGA. Chapter III of the DGA is, therefore, highly relevant to data spaces. In future versions of the Blueprint, it will be important to consider the potential application of the provisions of Chapter III of DGA to different categories of data space intermediaries and data space governance authorities.

  • Organisational Form and Governance Authority: The choice of business model and legal form may require compliance with certain legal frameworks and regulatory requirements. For example, form and minimum contents are regulated by the national law of the respective European Union Member State or by European Union law.

  • Participation Management: onboarding and offboarding data space participants requires putting relevant data protection policies in place.

  • Contractual Framework: Legal provisions might require addressing certain aspects in the specific clauses of the General Terms & Conditions (for example, data protection, intellectual property or cybersecurity and risk management policies, as well as technical standards required by law, especially regarding interoperability).

  • Provenance & Traceability: Implementing this building block should facilitate compliance with the IP data protection rules (for example, compliance with transparency requirements from the GDPR, implementation of the access logging policies and access control, etc.).

  • Identity And Attestation Management: Onboarding and offboarding participants into a data space, if it involves the processing of personal data of data subjects, can be considered as separate purposes for processing, around which appropriate steps must be taken to ensure that the processing of personal data complies with the GDPR. The European Digital Identity Regulation (eIDAS 2.0) governs the verification of participants and attestations of identity. It creates a European internal market for trust services by ensuring they work across borders and have the same legal status as their traditional paper-based equivalents.

  • Use Case Development: Different horizontal and sectoral/national regulations may apply depending on the use case being developed. This version of the Regulatory Compliance Building Block highlights some sectors (and thereby possible use cases) with specific regulations that would be relevant to consider.

6. Future topics 

Given the complexity of data spaces, which involve multiple actors and fit into a variety of existing legal and emerging digital policy frameworks, it is challenging to analyse each regulation in a way that sets uniform obligations for all common European data spaces. Therefore, future versions will continue to provide more user-centric guidance to help navigate the legal landscape.

Future versions of this building block will cover:

  • Regulatory compliance flowcharts based on other triggers and data space requirements described in the building block;

  • Mapping and analysing other categories and types of triggers such as contracts and technology/technical tools (for example, secure processing environment, blockchain, etc.);

  • Regulatory compliance checklists for data space governance authority.

7. Further reading 

7.1 Documents and Guidelines to Implement the Building Blocks

8. Glossary

Term

Definition

Term

Definition

Data

any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of sound, visual or audiovisual recording;

(DGA Article 2(1))

Explanatory text:

The definition is the same in the Open Data Directive and the Data Act.

Data sharing

the provision of data by a data subject or a data holder to a data user for the purpose of the joint or individual use of such data, based on voluntary agreements or Union or national law, directly or through an intermediary, for example under open or commercial licences subject to a fee or free of charge;

(DGA Article 2(10))

Explanatory text:

In the context of data spaces, data sharing refers to a full spectrum of practices related to sharing any kind of data, including all relevant technical, financial, legal, and organisational requirements.

Data holder

a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, which, in accordance with applicable Union or national law, has the right to grant access to or to share certain personal data or non-personal data;

(DGA Article 2(8))

 a natural or legal person that has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation adopted in accordance with Union law, to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service;(DA Article 2(13))

Explanatory text:

In general context we use data holder within the meaning of DGA Art. 2(8) and in case the word data holder is used in the context of DA (IoT data), we identify it with DA at the end of the term. Please note that data rights holder has a specific and different meaning than data holder and is used especially in data transactions.

Data recipient (Data Act)

a natural or legal person, acting for purposes which are related to that person’s trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with a legal obligation under Union law or national legislation adopted in accordance with Union law;

(DA Article 2(14))

Explanatory text:

Data recipient has a broader (not limited to IoT) meaning in the context of data transactions enabled by data space: ''A transaction participant to whom data is, or is to be technically supplied by a data provider in the context of a specific data transaction''.

When we use data recipient in the meaning of DA (IoT data), we specify it with DA at the end of the word.

Data user

a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes;

(DGA Article 2(9))

Data intermediation service

a service that is legally defined in the Data Governance Act and enforced by national agencies. An operator in a data space may qualify as a data intermediation service provider, depending on the scope of the services.

DGA definition (simplified): ‘Data intermediation service’ means a service which aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data.

(DGA Article 2 (11))

Explanatory text:

Services that fall within this definition will be bound to comply with a range of obligations. The most important two are: (1) Service providers cannot use the data for other purposes than facilitating the exchange between the users of the service; (2) Services of intermediation (e.g. catalogue services, app stores) have to be separate from services providing applications. Both rules are meant to provide for a framework of truly neutral data intermediaries.

Data altruism

the voluntary sharing of data on the basis of the consent of data subjects to process personal data pertaining to them, or permissions of data holders to allow the use of their non-personal data without seeking or receiving a reward that goes beyond compensation related to the costs that they incur where they make their data available for objectives of general interest as provided for in national law, where applicable, such as healthcare, combating climate change, improving mobility, facilitating the development, production and dissemination of official statistics, improving the provision of public services, public policy making or scientific research purposes in the general interest;

(DGA Article 2(16))

Personal data

any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

(GDPR Article 4(1))

Non-personal data

data other than personal data;

(DGA Article 2(4))

Data subject

an identified or identifiable natural person that personal data relates to.

(GDPR Article 4(1))

Explanatory text:

Data subject is implicitly defined in the definition of ‘personal data’. In the context of data spaces we  use the broader term data rights holder, to refer to the party that has (legal) rights and/or obligations to use, grant access to or share certain personal or non-personal data. For personal data, this would equal the data subject.

Consent

any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;

(GDPR Article 4(11))

Permission

giving data users the right to the processing of non-personal data;

(Data Governance Act Article 2(6))

DMA Gatekeeper

an undertaking providing core platform services, designated by the European Commission if:

  1. it has a significant impact on the internal market;

  2. it provides a core platform service which is an important gateway for business users to reach end users; and

  3. it enjoys an entrenched and durable position, in its operations, or it is foreseeable that it will enjoy such a position in the near future (art. 3 (1) DMA).

An undertaking shall be presumed to satisfy the respective requirements in paragraph 1:

  1. as regards paragraph 1, point (a), where it achieves an annual Union turnover equal to or above EUR 7,5 billion in each of the last three financial years, or where its average market capitalisation or its equivalent fair market value amounted to at least EUR 75 billion in the last financial year, and it provides the same core platform service in at least three Member States;

  2. as regards paragraph 1, point (b), where it provides a core platform service that in the last financial year has at least 45 million monthly active end users established or located in the Union and at least 10 000 yearly active business users established in the Union, identified and calculated in accordance with the methodology and indicators set out in the Annex;

  3. as regards paragraph 1, point (c), where the thresholds in point (b) of this paragraph were met in each of the last three financial years. (art. 3 (2) DMA).

Core platform service

a service that means any of the following:

  1. online intermediation services;

  2. online search engines;

  3. online social networking services;

  4. video-sharing platform services;

  5. number-independent interpersonal communications services; (f) operating systems;

  6. web browsers;

  7. virtual assistants;

  8. cloud computing services;

  9. online advertising services, including any advertising networks, advertising exchanges and any other advertising intermediation services, provided by an undertaking that provides any of the core platform services listed in points (1) to (9);

Public sector body

the State, regional or local authorities, bodies governed by public law or associations formed by one or more such authorities, or one or more such bodies governed by public law (art. 2 (17) DGA).

Sui Generis Database Right

right for the maker of a database which shows that there has been qualitatively and/or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents to prevent extraction and/or re-utilization of the whole or of a substantial part, evaluated qualitatively and/or quantitatively, of the contents of that database (art. 7 Directive 96/9/EC Of The European Parliament And Of The Council of 11 March 1996 on the legal protection of databases).

Trade Secret

information which meets all of the following requirements:

  1. it is secret in the sense that it is not, as a body or in the precise configuration and assembly of its components, generally known among or readily accessible to persons within the circles that normally deal with the kind of information in question;

  2. it has commercial value because it is secret;

  3. it has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret. (art. 2 (1) Trade Secrets Directive).

High-risk AI system

'AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments (Art. 3 (1) AIA).

AI system shall be considered to be high-risk where both of the following conditions are fulfilled:

  1. the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I;

  2. the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I (art. 6 (1); art. 6 (2) AIA).

Explanatory text:

In addition to the high-risk AI systems referred above, AI systems referred to in Annex III shall be considered to be high-risk, such as:

  • biometrics, in so far as their use is permitted under relevant Union or national law;

  • critical infrastructures (e.g. transport), that could put the life and health of citizens at risk;

  • educational or vocational training, that may determine the access to education and professional course of someone’s life (e.g. scoring of exams);

  • safety components of products (e.g. AI application in robot-assisted surgery);

  • employment, management of workers and access to self-employment (e.g. CV-sorting software for recruitment procedures);

  • essential private and public services (e.g. credit scoring denying citizens opportunity to obtain a loan);

  • law enforcement that may interfere with people’s fundamental rights (e.g. evaluation of the reliability of evidence);

  • migration, asylum and border control management (e.g. automated examination of visa applications);

  • administration of justice and democratic processes (e.g. AI solutions to search for court rulings).

Connected product

an item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user (art. 2 (5) DA).

Explanatory text:

This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.

Related service

means a digital service, other than an electronic communications service, including software, which is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product (art. 2 (6) DA).

Explanatory text:

This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.

High-Value Datasets (HVDs)

data held by a public sector body associated with important benefits for society, the environment, and the economy when reused (Open Data Directive). The thematic categories of high-value datasets are: geospatial data; earth observation and environment data; meteorological data; statistics; companies and company ownership data; mobility data (Annex I, Open Data Directive).

Explanatory text:

These datasets are suitable for creating value-added services, applications, and new jobs, and are made available free of charge in machine-readable format documents, the reuse of high-value datasets is associated with important benefits for the society and economy. They are subject to a separate set of rules ensuring their availability free of charge, in machine readable formats. They are provided via Application Programming Interfaces (APIs) and, where relevant, as a bulk download. The thematic scope of high-value datasets is provided in an Annex to the Directive.

FAIR principles

a collection of guidelines by which to improve the Findability, Accessibility, Interoperability, and Reusability of data objects. These principles emphasize discovery and reuse of data objects with minimal or no human intervention (i.e. automated and machine-actionable), but are targeted at human entities as well (Common Fund Data Ecosystem Documentation).

Explanatory text:

In 2016, the ‘FAIR Guiding Principles for scientific data management and stewardship’ were published in Scientific Data. The authors intended to provide guidelines to improve the Findability, Accessibility, Interoperability, and Reuse of digital assets. The principles emphasise machine-actionability (i.e., the capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention) because humans increasingly rely on computational support to deal with data as a result of the increase in volume, complexity, and creation speed of data (GO FAIR Initiative)

Research data

documents in a digital form, other than scientific publications, which are collected or produced in the course of scientific research activities and are used as evidence in the research process, or are commonly accepted in the research community as necessary to validate research findings and results (art. 2 (9) PSI Directive).

Interoperability (DA)

means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions (art. 2 (40) DA).

HealthData@EU

cross-border infrastructure for secondary use of electronic health data established by the European Health Data Space Regulation (art. 52 (2) EHDS).