Search every question across sub-FAQs

Under the Data Act, a related service is a digital service, other than an electronic communications service, that is connected with the product at purchase, rent, or lease so that the product would lose one or more functions without it, or that is later connected to add, update, or adapt product functions. Software can be a related service when it is linked to product operation.

The Commission FAQ describes two practical conditions: there must be bidirectional exchange of data between the connected product and service provider, and the service must affect the product's functions, behavior, or operation. An app that adjusts light brightness or regulates a fridge temperature can be a related service; connectivity, power supply, auxiliary consulting, analytics, financial services, and regular repair or maintenance are not related services merely because they interact with the product ecosystem.

Under the Data Act, Chapter II focuses on product data and related service data that is readily available to the data holder. Product data is data generated by use of the connected product and designed to be retrievable. Related service data is data representing user actions or events related to the product during the related service.

The scope includes raw data and pre-processed data, together with relevant metadata needed to interpret and use it. Commission materials describe this as raw or pre-processed data that is readily available, such as sensor measurements, status data, timestamps, or event logs where the data holder can obtain them without disproportionate effort beyond a simple operation.

Under the Data Act, several exclusions matter. Prototypes are outside scope because their manufacturing stage has not been completed. Data that is inferred or derived from product data through additional investment, including proprietary complex algorithms, is not treated as data that must be made available under Chapter II unless the parties agree otherwise.

The Data Act also distinguishes connected-product data from content. If a user watches a film on a smart TV, the film itself is not the Chapter II product data, but product-generated data such as screen brightness may be in scope if otherwise readily available. Data generated by infrastructure that the user does not own, rent, lease, or otherwise have rights over is not pulled into scope merely because the user's connected product uses that infrastructure.

Article 7 of the Data Act creates an important Chapter II limitation. The Chapter II obligations do not apply to data generated through connected products manufactured or designed, or related services provided, by a microenterprise or small enterprise, if the linked-enterprise and subcontracting conditions in Article 7 are satisfied.

The same Article also covers data generated through connected products manufactured by, or related services provided by, an enterprise that has qualified as a medium-sized enterprise for less than one year, and connected products for one year after they were placed on the market by a medium-sized enterprise. This is a narrow status-and-timing check; it should not be generalized into an SME exemption for every data-sharing issue.

If the connected product or related service is in scope, Article 3 of the Data Act requires product data and related service data, including relevant metadata, to be designed or provided so that they are easily, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format accessible to the user, where relevant and technically feasible directly.

Before contracts for a connected product or related service are concluded, the seller, rentor, lessor, or related-service provider must provide clear information about the type, format, volume, frequency, storage, retention, access or retrieval arrangements, data-holder identity, trade-secret status where relevant, and third-party sharing process. Where direct access is not available, Article 4 requires the data holder to make readily available data accessible to the user on request.

Use Data Act examples that separate the product, the user, the data holder, and the data. A company operating a connected bulldozer may be the user, while the bulldozer manufacturer is typically the data holder. A connected fridge with an app can involve two data holders: the entity placing the fridge on the market and the provider of the related app.

Vehicle and infrastructure examples are useful because they show the boundary. If a vehicle receives data from roadside sensors or records road conditions and the vehicle data holder has access to that data, the vehicle user may request the vehicle data. But driving on a road does not make the driver a Data Act user of the road infrastructure sensors.

A useful Data Act scope file should be narrow: product identifier, EU market-placement basis, manufacturer or designer, related-service provider if any, user categories, data holder, generated data categories, readiness of access, exclusions applied, and source citation. It should be written so product, legal, engineering, support, and sales teams can apply the same classification.

For each product family, keep the architecture facts that support the decision: sensor list, data fields, metadata, communication routes, storage location, retention period, whether direct access is technically feasible, and where customer disclosures describe access and third-party sharing. If the answer relies on Article 7 SME status, keep the linked-enterprise, subcontracting, and timing evidence.

Keep the Data Act legal basis and the practical facts together. For each scope decision, store the cited clause or recital, the Commission guidance relied on, the product family or service, the data categories involved, the trigger for the review, and the person who approved the classification.

A concise evidence file should also preserve the source URL, the date of the decision, any unresolved assumptions, and the implementation artifact that reflects the conclusion. That makes the classification auditable when the product design, data flow, or contract changes.

Assign one accountable owner who can change the affected process under the Data Act, then record the supporting teams separately. Legal, product, procurement, cloud, support, and security may all be involved, but the scope file should name a single owner for follow-up.

The owner should be the person who can update the product record when architecture, contractual terms, or data flows change and who can trigger a new review when the scope facts move.

The Data Act context is the starting point for this answer. Article 33 targets participants in data spaces that offer data or data services to other participants. The relevant question is not whether an organisation mentions a data space in marketing copy; it is whether the organisation is offering data, a data-sharing service, or a service used by other participants inside a purpose-specific, sector-specific, or cross-sector data-sharing framework.

For architecture and contract work, identify the participant role for each flow: data provider, data holder, data recipient, catalogue operator, API provider, data intermediation provider, analytics service, or governance body. Article 33 says participants must comply with the essential requirements only for elements under their control, so the evidence should show which metadata, interface, usage-term, or automation component each participant can actually change.

The Data Act context is the starting point for this answer. Article 33 requires descriptions that make data findable, accessible, usable, and technically exchangeable. The required descriptions cover dataset content, use restrictions, licences, collection methodology, data quality and uncertainty; data structures, formats, vocabularies, classification schemes, taxonomies and code lists where available; technical means of access such as APIs, terms of use, and quality of service; and, where applicable, means for interoperable automation of data-sharing agreements such as smart contracts.

The practical output should be a participant-facing interoperability profile, not a generic compliance memo. For each offered dataset or data service, document the catalogue fields, machine-readable metadata, accepted formats, semantic assets, API or bulk download route, QoS terms, access conditions, licence or usage restriction, and any smart-contract or policy-automation mechanism used for the exchange.

The Data Act context is the starting point for this answer. Common European data spaces are EU-supported data infrastructures and governance frameworks for trusted data pooling and sharing in strategic sectors and domains of public interest. Commission material describes the original strategic fields as health, agriculture, manufacturing, energy, mobility, financial, public administration, skills, the European Open Science Cloud, and the Green Deal, with further areas such as media and cultural heritage emerging later.

This matters because Article 33 is horizontal, while data-space practice is often sector-specific. A manufacturer, cloud provider, public-sector platform, research infrastructure, or mobility service should therefore separate the horizontal Article 33 requirements from the sector's own governance rulebook, participant agreements, catalogue profile, identity model, and data-quality conventions.

No single named technical standard is mandated by Article 33 itself. The Data Act creates essential requirements and a standards route: the Commission requests European standardisation organisations to draft harmonised standards, participants using harmonised standards cited in the Official Journal can benefit from a presumption of conformity for covered requirements, and common specifications are a fallback when the standardisation route does not deliver as required.

As implementation context, CEN and CENELEC announced that Mandate M/614 on the European Trusted Data Framework was accepted on 7 July 2025, with CEN, CENELEC, and ETSI agreeing to develop standardisation deliverables to support Article 33. Teams should monitor those deliverables and any Official Journal citations, but should avoid writing contracts or product requirements that falsely say Article 33 already requires one specific named technology across all data spaces.

The Data Act context is the starting point for this answer. Treat interoperability as a published contract between participants. Architecture work should make the data discoverable, the meanings stable, the access route documented, and the governance constraints enforceable. In practice, that means versioned catalogue metadata, data dictionaries, semantic mappings, API or file-transfer specifications, licence and restriction fields, quality and uncertainty fields, authentication and authorisation rules, audit logs, error handling, and service-level descriptions.

The architecture should also distinguish data-space interoperability from cloud-switching interoperability. Article 33 is about interoperability of data, data-sharing mechanisms and services, and common European data spaces. Separate Article 30 and Article 35 work for data processing services, open interfaces, exportable data, and the central Union standards repository from Article 33 work for data-space participation.

The Data Act context is the starting point for this answer. Keep evidence that proves the participant did more than connect systems. A useful file includes the Article 33 scope assessment, participant role map, data-space governance rulebook or participation terms, catalogue extract, metadata schema, data-quality and uncertainty fields, licence and use-restriction fields, API or transfer specification, QoS description, semantic mappings, standards tracker, and test results for automated access or transmission.

Also keep a standards watch record. It should show which harmonised standards, common specifications, sector rulebooks, and data-space technical profiles were checked; whether any Official Journal citation or implementing act is relevant; why any named technology was selected; and which owner must update the profile when the data space, source dataset, access route, or standardisation status changes.

Under the Data Act, keep a short decision record that shows the article or clause relied on, the data-space participant role, the dataset or service in scope, and the person who approved the interpretation. The record should also note the source URL, date, reviewer, and any unresolved assumptions that still need follow-up.

That record should sit next to the implementation evidence, such as the catalogue entry, data model, API description, or smart-contract rule. If a later reviewer opens the file, they should be able to see both why the flow was treated as in scope and what the team changed to satisfy it.

Under the Data Act, assign one accountable owner who can change the affected process, plus the technical and legal contacts who will help maintain the Article 33 profile. That owner should be named in the record, along with the workflow they control, such as catalogue publishing, API maintenance, data-model governance, procurement, or participant onboarding.

Ownership should also include a review trigger. Article 33 profiles become stale when the data space adds a new participant rule, changes a dataset format, updates the API, or adopts a harmonised standard or common specification. The owner should be the person who gets notified when any of those changes happen.

Under the Data Act, the useful evidence is the kind that lets a later reviewer reconstruct the decision without guesswork. That usually includes the relevant clause, the participant's role, the dataset or service, the contract or request trigger, and the external source URL. If the team relied on a standards or governance assumption, that assumption should be written down too.

The same file should also point to the concrete implementation artifact. A reviewer should not have to search separately for the catalogue entry, metadata schema, API note, or smart-contract setting that operationalised the decision.

Under the Data Act, review the decision whenever the participant role, dataset, service, contract wording, or governance rule changes. A new API version, a new data structure, or a new sector rulebook can all change what Article 33 requires in practice.

It is also worth reviewing the decision when new harmonised standards, common specifications, or Commission guidance are published. If the profile already relies on a standards assumption, the review should confirm whether that assumption is still valid or whether the implementation should be updated.

Do not treat the Data Act Article 33 answer as a generic privacy, cloud, or procurement checklist. The right answer depends on the participant role, the data-space governance context, and the exact dataset or service being shared.

Also avoid over-claiming that a technology is mandatory when the source only supports a description, a presumption of conformity, or a standards route. The safer approach is to keep the source note, the implementation profile, and the review trigger aligned.