Search every question across sub-FAQs

The Data Act context is the starting point for this answer. Maintain a field-level readily-available-data register for each connected product and related service. The register should identify the product or service, user-facing data category, field name, source system, format, metadata supplied, retention period, access route, quality level, latency, and the reason for any exclusion or safeguard.

The most useful record is operational rather than legalistic: it should let support, product, legal, and engineering teams answer whether the requested data is raw or pre-processed, whether it is product data or related service data, whether it can be obtained without disproportionate effort, how the user or third party can receive it, and what limits apply.

Keep the Data Act source clause, the relevant product or service description, the field-level classification, and the reason each field is in scope or out of scope. Add the access route, the metadata supplied, and any safeguard relied on so the decision can be rechecked if the product or service changes.

A short decision note should also capture the review date and the person who approved the classification. That gives future teams a clear trail when they need to confirm whether the same data is still readily available.

Ownership of the Data Act answer should sit with the team that can change the data path or the access process, usually product, engineering, or platform operations, with legal and privacy input where needed. The owner should be able to explain how the field is generated, where it is stored, and how a user or third party receives it.

For cross-functional work, keep one accountable owner and list supporting teams separately. That makes it easier to resolve questions about access design, metadata, retention, and any safeguard for personal data or trade secrets.

Useful Data Act evidence is concrete and easy to revisit: source URLs, data inventories, contract clauses, API descriptions, request logs, and any technical or organisational safeguards. The evidence should show why the field was treated as product data, related service data, metadata, or out of scope.

If the answer depends on architecture, include diagrams or system notes that show whether the data is stored, retrievable, transmitted externally, or only processed locally. That makes the decision easier to defend if the product design changes later.

Review the Data Act answer when the product design, related service, telemetry path, retention policy, or access interface changes. A new firmware release, a changed API, or a new contract term can move a field into or out of scope, or change how the user receives it.

Also review the answer when the legal basis, safeguard, or ownership changes. The goal is to keep the classification tied to the current system rather than to a one-time note.

Under the Data Act, a related service is a digital service, other than an electronic communications service, that is connected with a product at purchase, rent, or lease in a way that the product would lose one or more functions without it. A service can also become a related service later if the manufacturer or a third party connects it to the product to add, update, or adapt the product's functions.

The Commission FAQ describes the practical test as a digital service linked to the operation of a connected product that affects the product's functionality, for example by transmitting data or commands to it.

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, suspend, or refuse access to specific trade-secret data, but 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.

The Data Act context is the starting point for this answer. Article 36 applies when a vendor of an application using smart contracts, or another professional deployer acting for others, uses a smart contract in the context of executing 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.

The Data Act context is the starting point for this answer. 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 Data Act context is the starting point for this answer. 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.