EU Data Act Product Data vs Related Service Data FAQ

Product data are data generated by the use of a connected product that the manufacturer designed to be retrievable by a user, data holder, or third party, including the manufacturer. They concern the product's performance, use, or environment. Classify the field from the product's design and generation source, regardless of whether the business labels it 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.

Related-service data represent user action, inaction, or events related to the connected product during provision of a related service. A related service is a digital service, other than an electronic communications service, connected with the product at sale, rent, or lease so that the product could not perform one or more functions without it, or later connected by the manufacturer or a third party to add, update, or adapt functions. It is not every service sold near the product.

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.

Yes. Chapter II covers raw and pre-processed data when they are product data or related-service data and are readily available to a data holder. Raw data are source or primary data points generated automatically without further processing. Pre-processed data can include records made understandable and usable before further analysis, such as a sensor signal converted into a physical quantity.

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. Include it when it 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.

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. The test includes stored, retrievable, or externally transmitted data available by design; it does not cover every signal a redesigned 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 as is 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.

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 Article 3 pre-contractual transparency about type, format, estimated volume, generation frequency, storage or retention, access and retrieval, the data holder, third-party sharing, and the trade-secret holder where relevant. The Article 3(1) duty to design for direct access where relevant and technically feasible applies to connected products and related services placed on the market after 12 September 2026.

Map each classification to the legal source that controls it: Article 2 for the defined categories, Recitals 15 to 17 for raw, pre-processed, inferred, content, and related-service boundaries, Articles 3 to 5 for disclosure and access, and the current Commission FAQ for implementation examples. Record the guidance version and access date because the regulation is binding while the FAQ is explanatory.

Keep the source beside the actual field decision, not only in a page-level bibliography. The record should identify the connected product, related service if any, field name, generation event, retrievability by design, processing step, availability, necessary metadata, classification, exclusion or safeguard, reviewer, decision date, and unresolved assumption.

Product and engineering should own the factual inventory: what the connected product generates, what the manufacturer designed to be retrievable, which service affects product functions, how each field is processed, and whether the data holder can obtain it by a simple operation. Legal should approve the Data Act category and access consequence, while privacy, security, and the trade-secret holder approve only the safeguards within their remit.

Name one classification owner for each product and related service and one operational owner for the access route. Procurement or partner management should obtain missing facts from third-party service providers, and support should use the approved inventory when answering users instead of inventing categories during request handling.

A reviewer should be able to trace a field from generation to delivery. Keep a sample record or schema, the sensor or service event that creates it, each pre-processing step, the metadata needed to interpret it, where it is stored or transmitted, the extraction method, a sample export, and the internal or user-facing name. For an inferred or derived exclusion, identify the additional investment, algorithmic step, or enrichment that creates the separate output.

The delivery evidence should show the user and data holder roles, request or direct-access route, format and quality supplied, timing, excluded fields, and any GDPR, trade-secret, or security measure. This separates the category decision from a later safeguard decision and lets the team reproduce the same answer for the same product version.

Reclassify affected fields after a hardware, sensor, firmware, app, API, or data-model change; when a digital service starts or stops affecting a product function; when a new preprocessing or proprietary algorithm changes a raw field into an enriched output; or when storage, transmission, retention, or lawful access changes. A new user, data holder, or recipient role can also change the access analysis even when the field itself is unchanged.

Review the delivery consequence when direct access, export format, metadata, contract use, personal-data basis, trade-secret measure, or security requirement changes. Connected products and related services placed on the market after 12 September 2026 also need the separate Article 3(1) design-duty check, so release review should identify which market-placement date applies.