Search every question across sub-FAQs

For pre contractual information, 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 pre contractual information, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

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.

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.