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?

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 help people discover or use 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.

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.

Article 3 addresses design for direct access where relevant and technically feasible. Article 4 provides request-based user access where data cannot be accessed directly. Article 5 separately lets the user or a party acting on its behalf ask the data holder to share readily available data and necessary metadata with an eligible third party, including when the user already has direct access.

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.

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: the data holder must also be the trade-secret holder, and Articles 4 and 5 require exceptional circumstances and a substantiated case that disclosure is highly likely to cause serious economic damage.

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.

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.

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.