EU Data Act Readily Available Data FAQ

The Data Act defines readily available data as product data and related service data that a data holder lawfully obtains, or can lawfully obtain, from the connected product or related service without disproportionate effort beyond a simple operation. It is a scope boundary for Chapter II user access and sharing rights.

For an implementation review, ask four questions in order: is there a connected product or related service, is the dataset product data or related service data, can the data holder obtain it without disproportionate effort, and is it raw or pre-processed rather than inferred, derived, or protected content?

The Data Act context is the starting point for this answer. Product data is data generated by use of a connected product that the manufacturer designed to be retrievable through an electronic communications service, physical connection, or on-device access. Related service data is data representing user actions, inaction, or events related to the connected product during the related service.

That means the in-scope inventory should describe actual generated or collected data about performance, use, or environment, not descriptive material that merely accompanies the product, such as packaging or user-manual text. Examples from Commission guidance include sensor-style data such as temperature, pressure, flow rate, audio, pH value, liquid level, position, acceleration, or speed.

Yes, where metadata is needed to interpret and use the product data or related service data. The Data Act definition of metadata covers structured descriptions that facilitate discovery or use of data, and Articles 3, 4, and 5 attach relevant metadata to access and sharing duties.

In practice, the export or API should include enough context for a user or chosen third party to understand the data without guessing: field names, units, timestamps, device or sensor references, collection frequency, quality indicators, retention limits, and other context that explains the conditions under which the data was collected or generated.

The Data Act context is the starting point for this answer. Inferred or derived data is outside the Chapter II scope described by the Commission. The boundary turns on enrichment: raw and pre-processed data are in scope, while highly enriched data, inferred or derived data, and data resulting from additional investments such as proprietary complex algorithms are out of scope.

Content is also treated separately. Commission guidance gives the connected-TV example: data about screen brightness can be in scope, but the film watched on the TV is not. A field-level review should therefore separate sensor or usage data from audiovisual, textual, or other content and from analytics outputs that assign insights or values.

The Data Act uses two access routes. Article 3 addresses design for direct access where relevant and technically feasible. Articles 4 and 5 address indirect access, where the user or a party acting for the user asks the data holder to make readily available data and relevant metadata accessible to the user or a chosen third party.

For indirect access, Articles 4 and 5 require access without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge to the user, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, continuously and in real time.

The Data Act context is the starting point for this answer. Edge processing does not automatically remove data from Chapter II. Commission guidance says readily available data includes raw or pre-processed data that is stored even temporarily, retrievable, or transmitted externally. If raw or pre-processed data was at any point accessible or externally transmittable, the access analysis should not stop merely because the product later processes it locally.

By contrast, if the connected product design inherently prevents external data storage or transmission, the Commission FAQ says that data is not considered readily available. Teams should base the answer on actual architecture: on-device buffers, remote servers, communication modules, local export paths, and whether raw or pre-processed data can be obtained proportionately.

The readily-available-data analysis does not override privacy, security, trade-secret, or intellectual-property rules. For personal data, the Data Act is without prejudice to GDPR and privacy law, and Articles 4 and 5 require a valid legal basis where the user is not the data subject whose personal data is requested.

Trade secrets can be protected through proportionate technical and organisational measures. Where agreed measures are missing or not respected, the data holder may withhold or suspend sharing of trade-secret data. Refusal is narrower: Articles 4 and 5 require exceptional circumstances and a substantiated case that disclosure is highly likely to cause serious economic damage.

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.