Search every question across sub-FAQs

The service must be tied to a connected product, not merely offered by the same company. Under the Data Act, a connected product is an item that obtains, generates, or collects data about its use or environment and can communicate product data through an electronic communications service, physical connection, or on-device access.

The Commission FAQ adds two practical conditions for related services: there must be bidirectional data exchange between the connected product and the service provider, and the service must affect the product's functions, behaviour, or operation.

Examples under the Data Act include an app that changes smart-light brightness, software that regulates a connected fridge's temperature, or a product-linked service that sends commands or updates to a connected device so that the device performs or changes a function.

A service is less likely to be a related service when it merely surrounds the product commercially, such as regular repair, maintenance, auxiliary consulting, analytics, or financing, without itself being connected to and affecting the connected product's functions.

Under the Data Act, product data is data generated by use of the connected product that the manufacturer designed to be retrievable by the user, data holder, third party, or manufacturer through electronic communications, physical connection, or on-device access. Related service data is data representing digitised user actions or events related to the connected product during the provision of the related service.

The Commission FAQ summarises the Chapter II access scope as raw and pre-processed data that are readily available to a data holder, together with metadata needed to make the data understandable and usable. Highly enriched inferred or derived data is outside that access scope.

Under the Data Act, a user is a natural or legal person that owns a connected product, has temporary contractual rights to use it, or receives related services. A data holder is the person or entity with the right or obligation to use and make available data, including product data or related service data retrieved or generated during the related service where the contract provides for that.

For a related service, the provider can become a data holder once it has a contractual relationship with the user and renders the service in a way that creates data. The same ecosystem may involve several users, such as an owner and a renter, so access arrangements should identify which user has rights over which product or service data.

Under the Data Act, related services must be designed and provided so product data and related service data, including relevant metadata, are by default easy, secure, free of charge, comprehensive, structured, commonly used, machine-readable, and where relevant and technically feasible directly accessible to the user.

Where the user cannot access the data directly from the connected product or related service, the data holder must make readily available data accessible to the user without undue delay and, where relevant and technically feasible, continuously and in real time. A user may also ask the data holder to make the readily available data available to a third party.

Before concluding a related-service contract under the Data Act, the prospective provider must give the user clear information about product data expected to be obtained, related service data expected to be generated, data access or retrieval arrangements, storage arrangements and retention duration, intended use of readily available data, data holder identity, contact means, third-party sharing requests, complaint rights, trade-secret status, and contract duration and termination.

This pre-contractual information matters because users need to understand both the product data already produced by the connected product and the service data that will arise once the related service starts operating.

Under the Data Act, the related-service definition excludes electronic communications services. The Commission FAQ also states that connectivity, power supply, aftermarket services such as auxiliary consulting and analytics, financial services, and regular repair and maintenance cannot be considered related services.

The Chapter II data access scope also excludes certain material even when a connected product or related service is involved. Out-of-scope material includes highly enriched inferred or derived data resulting from additional investments, and content such as textual, audio, or audiovisual material often protected by intellectual property rights.

The Data Act does not override EU personal-data rules. If the user is not the data subject, personal data generated by use of a connected product or related service may be made available only where there is a valid legal basis under GDPR and any relevant conditions under EU privacy rules are met.

Trade secrets must be preserved. The data holder or trade-secret holder must identify protected data and agree proportionate technical and organisational measures with the user or third party. In defined circumstances, the data holder may withhold or suspend access to specific trade-secret data. It may refuse access only if it is also the trade-secret holder. The decision must be substantiated in writing and notified to the competent authority.

Keep a short Data Act related-service register for each product-linked digital service. The record should identify the connected product, the service, the product function affected, the bidirectional data or command path, the user, the data holder, the product data, the related service data, the access route, and any exclusions or safeguards.

The register should be operational, not just legal. It should connect contract text, product architecture, user access mechanisms, and support handling so that a user request can be answered without reclassifying the service from scratch.

Start with three checks: is the service digital, is it linked to the connected product, and does it affect the product's function, behaviour, or operation? If the answer to any of those is no, the service is less likely to be a related service under the Data Act.

Examples and contract wording can help, but the legal test remains the same: the service must be more than an adjacent business service and must interact with the connected product in a way that matters to how the product works.

Keep the legal source, the product or service description, the product function affected, the relevant data flows, and the reason the service was or was not treated as a related service. That makes it easier to show why the classification fits the Data Act definition.

If the service is later updated, repeat the check because the Data Act allows a service to become a related service when it is later connected to a product to add, update, or adapt functions.

Article 36 applies when a vendor of an application using smart contracts, or in the absence of a vendor a professional deployer acting for others, uses a smart contract to execute an agreement or part of an agreement to make data available.

That scope is narrower than the phrase "smart contract" is often used in product teams. A pricing rule, API permission check, workflow automation, or internal data job should not be labelled Article 36 work unless it is the smart-contract mechanism executing data-sharing agreement logic for making data available.

Article 36 lists five requirements. The smart contract must support robustness and access control, safe termination and interruption, data archiving and continuity, access control at governance and smart-contract layers, and consistency with the terms of the data sharing agreement it executes.

A practical control file should translate those requirements into testable evidence: security review results, manipulation-resistance tests, privileged-action controls, stop or reset procedures, archived transaction records, archived logic and code, and a comparison between coded behavior and the signed data sharing terms.

The vendor of the smart contract, or in the absence of a vendor the professional deployer acting for others, must perform a conformity assessment against the Article 36 requirements. Once the requirements are fulfilled, that actor must issue an EU declaration of conformity.

The declaration is not a shortcut around engineering evidence. By drawing it up, the vendor or professional deployer takes responsibility for compliance with the Article 36 essential requirements, so the declaration should be backed by versioned deployment records, tests, access-control evidence, stop-function evidence, archive evidence, and agreement-consistency review.

No. The Commission FAQ states that Article 36 does not affect national contract law and that the Data Act regulates the computer programs used to execute agreements, not the agreements as such.

Teams should therefore maintain two linked records: the data sharing agreement that sets the parties' rights and obligations, and the smart-contract evidence showing that the automated execution is reliable, controllable, auditable, and consistent with those terms. Do not claim that compliant code alone creates, replaces, validates, or overrides the contract.