EU Data Act Product Data vs Related Service Data FAQ

The Data Act context is the starting point for this answer. Product data is data obtained, generated, or collected by a connected product and related to that product's performance, use, or environment. The key test is whether the connected product itself obtains, generates, or collects the data through its components or operating systems, not whether the business labels the record as telemetry, diagnostics, or customer data.

Examples can include sensor measurements, hardware status, malfunction data, position, acceleration, speed, temperature, pressure, pH value, liquid level, flow rate, or similar data generated from the product's use or environment. Purely descriptive material that accompanies a product, such as a manual or packaging text, is not product data simply because it is about the product.

The Data Act context is the starting point for this answer. Related service data is data representing user actions, inaction, or events related to the connected product during the provision of a related service. A related service is not every service sold near the product; it must be linked to the operation of the connected product's functions, such as a service or app that exchanges data or commands with the product and can affect its action or behaviour.

A fridge app that regulates temperature or a machine service that changes operating parameters can generate related service data. Auxiliary consulting, analytics, financial services, regular repair, maintenance, power supply, or connectivity supply are not treated as related services merely because they concern the same product.

The Data Act context is the starting point for this answer. Yes, Chapter II covers raw data and pre-processed data when the data is product data or related service data and is readily available to a data holder. Raw data means source or primary data points generated automatically without further processing. Pre-processed data can include data prepared to make it understandable and usable before further analysis, such as sensor data converted into a physical quantity or quality.

Pre-processing does not require the data holder to make substantial new investments in cleaning or transforming data for a requester. The boundary is between making raw data usable and creating enriched outputs or insights from additional investment.

The Data Act treats relevant metadata as part of what makes product data and related service data usable. The metadata must be necessary to interpret and use the data, such as basic context, timestamp, or conditions under which the data was collected or generated.

Metadata should not become a catch-all for every internal note, model feature, support annotation, or analytics output. The practical question is whether the metadata is needed to understand and use the raw or pre-processed data being made available.

Information inferred or derived from product data or related service data is generally outside Chapter II when it results from additional investment into assigning values or insights, especially through proprietary, complex algorithms. The Data Act draws this line to preserve incentives to build analytics, transformations, and autonomous decision processes.

Examples of out-of-scope material can include highly enriched data, proprietary sensor-fusion outputs, predictive insights, and textual, audio, or audiovisual content often protected by intellectual property rights. Privacy-preserving processes such as anonymisation, pseudonymisation, or encryption should not by themselves be treated as enough to exclude otherwise in-scope data.

The Data Act context is the starting point for this answer. Readily available data means 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 going beyond a simple operation. This availability test matters because Chapter II access duties focus on data the data holder can access, not every possible signal a device could theoretically generate.

If data cannot be directly accessed by the user, the data holder must make readily available data and the necessary metadata accessible without undue delay, in the same quality available to the data holder, easily, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Where relevant and technically feasible, this can include continuous and real-time access.

The Data Act context is the starting point for this answer. Use a field-level inventory rather than broad buckets. A smart-home thermostat may generate product data such as temperature readings and device status; a control app may generate related service data when it records user settings or sends commands that affect product behaviour; a vendor's proprietary comfort score or predictive energy model may be inferred or derived information if it results from additional analytics investment.

For vehicles, industrial machines, health devices, home equipment, agricultural machinery, or similar connected products, the same structure applies: identify the connected product, identify any related service that affects product functions, list raw and pre-processed fields, add necessary metadata, then separate enriched insights, content, trade-secret handling, personal-data handling, and unavailable data.

A useful classification record should be narrow: product or service name, data field, generation source, whether the field is product data or related service data, whether it is readily available, the metadata needed to interpret it, the enrichment level, and the reason for any exclusion. For personal data, trade secrets, or security-sensitive data, classification should be paired with the relevant safeguards rather than used as a reason to ignore the Data Act category.

The record should also support pre-contractual transparency. Before a connected-product or related-service contract, users need clear information about the type, format, estimated volume, frequency, storage, retention, access or retrieval arrangements, data holder identity, third-party sharing route, and trade-secret holder where relevant.

For product data and service data, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For product data and service data, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For product data and service data, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For product data and service data, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

For product data and service data, the Data Act evidence should be concrete enough for a later reviewer to reconstruct why the team classified the product, service, request, or contract in scope.

For product data and service data, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

For product data and service data, the Data Act answer should be reviewed when the product, service model, dataset, customer role, public-sector request path, or contract wording changes.

For product data and service data, set a review date and an event trigger instead of relying on a one-time legal note.