EU Data Act Connected Products and Data Types

Defines connected product, user, data holder, product data, related-service data, and readily available data for the Chapter II scope analysis.

Gives practical examples of connected products and explains user control over data generated by owned, rented, or leased connected products.

Clarifies connected-product boundaries, including products whose main function is data storage, processing, or transmission and infrastructure-sensor examples.

Section 2

When is software a related service that falls under the Data Act scope?

A related service is a digital service, including software, that is connected with the product at purchase, rental, or lease in a way that absence of the service would prevent one or more product functions, or that is later connected by the manufacturer or a third party to add to, update, or adapt the product's functions.

The practical test is whether the service affects the connected product's operation or behaviour. A washing-machine app that adjusts a cycle based on sensor data can be a related service. In the vehicle guidance, remote door locking, cockpit pre-conditioning, charging management, driver-preference syncing, and route optimisation shown on the dashboard are treated as examples of vehicle-related services.

Classify apps, software modules, cloud functions, and integrations by whether they add to, update, adapt, or control product functions.
Separate related services from analytics, consulting, insurance pricing, financial services, or offline repair work that only uses data and does not affect product operation.
Expect multiple data holders where a product maker and an app or service provider each obtain data from the same user relationship.
Attach the related-service contract and product-function dependency to the scope record.

Sources for this answer

Uses smart-fridge and washing-machine app examples to show how related services can sit beside the connected product.

Commission guidance on vehicle data - Official Journal

Explains the automotive related-service test and distinguishes vehicle-related services from offline repair, analytics, financial, and insurance services.

Section 3

Which product data and related service data are in scope of the Data Act?

Product data is data generated by use of the connected product that the manufacturer designed to be retrievable by a user, data holder, or third party. Related-service data is data representing digitised user actions, inaction, or events related to the connected product during the provision of a related service.

Scope is field-level, not product-line-level. For each data stream, identify the event or sensor source, whether the data comes from the product or the related service, who can lawfully obtain it, and whether the user or a chosen third party needs metadata to interpret and use it.

Product data examples include sensor signals, status data, event logs, location, speed, pressure, temperature, liquid level, acceleration, and component condition where generated by product use.
Related-service data examples include app commands, service events, user settings, charging-management events, remote-control actions, and dashboard service interactions tied to the product.
Purely descriptive material in user manuals, packaging, or marketing copy is not product data for Chapter II access purposes, though Article 3 pre-contract information still matters.
For mixed datasets, flag personal-data fields separately because Data Act access and sharing must still comply with GDPR and ePrivacy conditions.

Sources for this answer

Provides the legal definitions of product data and related-service data and ties access duties to those categories.

Clarifies that product data relates to product performance, use, or environment and that related-service data represents user actions, inaction, and product-related events during the service.

Commission guidance on vehicle data - Official Journal

Lists vehicle-sector examples of raw and pre-processed product data, including sensor signals, component status, speed, battery level, odometer values, and fault codes.

Section 4

How should readily available data and metadata be classified under the Data Act?

Readily available data means product data and related-service data that the data holder lawfully obtains or can lawfully obtain from the connected product or related service without disproportionate effort beyond a simple operation. The analysis should therefore cover both data already retrieved and data the architecture can lawfully retrieve without disproportionate effort.

Metadata is part of the access package when it is necessary to interpret and use the data. A useful metadata dictionary names units, timestamps, identifiers, sampling or collection frequency, format, quality limits, location or context fields, retention, and the source system that supplies the value.

Classify each field as directly accessible from the product, indirectly available through the data holder, lawfully retrievable but not currently stored, or not readily available.
Record the technical reason when a field cannot be obtained without disproportionate effort, such as architecture limits, transmission constraints, or data deleted before any party can access it.
Include metadata needed for practical use, not only schema labels; examples include units, time zone, sensor identity, calibration state, collection conditions, and quality notes.
Do not omit metadata protected as a trade secret from the analysis; identify protected metadata and the confidentiality measures needed if it must be shared.

Sources for this answer

Defines metadata and readily available data, and requires relevant metadata where data is made accessible to users or third parties.

Explains that Chapter II covers raw and pre-processed data readily available to the data holder, including relevant metadata.

Explains metadata as information needed to understand conditions such as time, weather, or location under which data was collected or generated.

Recommended next step

Build a Data Act product-and-data scope map

Turn connected-product architecture, related services, data fields, metadata, exclusions, and safeguards into a maintained scope record before implementing user or third-party access.

Research workflow

Open Research Copilot

Classify Data Act product and data scope with cited outputs.

Explore next step

Talk to Sorena

Talk through implementation

Review your product scope, access routes, safeguards, and evidence model.

Explore next step

Section 5

Where is the Data Act line between raw, pre-processed, and derived data?

Chapter II covers raw and pre-processed data, plus metadata needed to make that data understandable and usable. Pre-processing can include preparing sensor output so it describes a physical quantity or quality, such as temperature, pressure, flow rate, audio, pH value, liquid level, position, acceleration, or speed.

Inferred or derived information is different. It is usually the result of additional investment, proprietary or complex algorithms, substantial transformation, sensor fusion that creates new insight, or analytics that assign new value beyond the underlying measurement. The data holder should still assess whether the underlying raw or pre-processed input data remains in scope.

Treat calibrated, normalised, reformatted, filtered, timestamped, unit-converted, or basic calculated measurements as potentially in scope when they still describe the underlying event or condition.
Treat predictions, proprietary scoring, behavioural profiles, object detection, complex diagnostics, and model-derived insights as candidates for the derived-data exclusion.
Do not use the word derived as a blanket exclusion for any data that passed through a pipeline; explain what new information or investment changes the classification.
Keep content such as films on a smart TV or creative audiovisual material separate from device-use telemetry such as brightness, battery, timestamps, location, and event logs.

Sources for this answer

Explains the distinction between raw and pre-processed data in scope and inferred or derived data outside Chapter II.

States that inferred or derived data and content, such as highly enriched data and audiovisual material, are out of scope.

Commission guidance on vehicle data - Official Journal

Provides sector examples of raw data, pre-processed data, derived information, sensor fusion, predictions, and basic mathematical operations.

Section 6

What exclusions and safeguards should appear in the Data Act scope record?

A complete scope record should not only list data to share. It should also explain excluded data, protected data, and conditions that may affect delivery. The strongest record ties each exclusion to a legal definition, guidance example, technical architecture fact, or protection measure.

Common exclusions or constraints include inferred or derived information, content protected by intellectual property rights, unavailable edge-processed data that no party can access, personal data without a valid processing basis, trade secrets needing confidentiality measures, security restrictions grounded in EU or national law, gatekeeper ineligibility for third-party access, and the ban on using accessed data to develop a competing connected product.

For each excluded field, name the reason: not product data, not related-service data, not readily available, inferred or derived, content, personal-data constraint, trade secret, security restriction, or other law.
For each protected but shareable field, record the safeguard: access control, confidentiality terms, encryption, metadata marking, quality limits, recipient restrictions, or authority notification route.
For each third-party request path, check whether the recipient is eligible and whether the requested use could develop a competing connected product.
Review the record when product architecture, related services, data pipelines, retrieval design, guidance, or contracts change.

Sources for this answer

Supports the access, third-party sharing, trade-secret, security, personal-data, gatekeeper, and competing-product limitations that affect scope records.

Summarises practical limits on use of accessed data, GDPR interaction, trade secrets, security requirements, and third-party sharing.

Explains that content and highly enriched data are out of scope and gives examples for cameras, smart TVs, and sensor-like imagery.

Section 7

What should the finished Data Act scope map for connected products contain?

The useful output is a product-and-data scope map that product, legal, security, engineering, and support teams can use before notices, access portals, APIs, contracts, or helpdesk scripts are written. It should let a reviewer trace each field from product architecture to Data Act classification.

Keep the map concise enough to maintain, but specific enough to stop overbroad exports and unsupported exclusions. The record should show the product or service, user relationship, data holder, data category, availability, metadata, safeguards, delivery route, source, owner, and review trigger.

Product/service fields: connected product name, related service name, product function affected by the service, user type, data holder, recipient paths, and relevant contracts.
Data fields: source event or sensor, product data or related-service data classification, raw/pre-processed/derived label, readily available status, metadata needed, format, quality, and retention.
Exclusion fields: excluded category, source-linked reason, technical fact, safeguard or restriction, reviewer, and escalation path for trade-secret, security, or personal-data issues.
Maintenance fields: product owner, legal reviewer, engineering owner, last reviewed date, change trigger, and citation to the official source used for the classification.

Sources for this answer

Article 3 pre-contract information requirements and Articles 4-5 access duties support maintaining a field-level record of data types, formats, access means, metadata, and data holders.

Provides the data-in-scope factors that can be translated into scope-map columns: data category, availability, enrichment level, personal-data status, and trade-secret status.

Commission guidance on vehicle data - Official Journal

Shows how a sector-specific implementation can turn Data Act scope rules into data-point classifications and access-quality checks.

Primary sources

References and citations

Commission guidance on vehicle data - Official Journal

eur-lex.europa.eu

Referenced sections

Shows how a sector-specific implementation can turn Data Act scope rules into data-point classifications and access-quality checks.

digital-strategy.ec.europa.eu

Referenced sections

Summarises practical limits on use of accessed data, GDPR interaction, trade secrets, security requirements, and third-party sharing.

ec.europa.eu

Referenced sections

Provides the data-in-scope factors that can be translated into scope-map columns: data category, availability, enrichment level, personal-data status, and trade-secret status.