Classify whether a connected product, related service, data holder, cloud service, data-space role, smart contract, or public-sector request is in scope.
Use the test to separate Chapter II product-data duties from B2B, B2G, cloud switching, interoperability, smart-contract, and exclusion questions.
Start by asking whether the item is a , then run a separate role, data, exclusion, date, and EU-nexus test for the relevant chapter. Record a scoped answer for the specific product, service, contract, data request, or technical role because one corporate-level answer cannot resolve access, portability, switching, contract remediation, or public-sector response work.
1
Section 1
Start with the Data Act chapter, not the brand or business unit
The Data Act applies through different role and scenario tests. Article 1 covers manufacturers of connected products placed on the Union market, providers of related services, users in the Union, data holders making data available to data recipients in the Union, public-sector exceptional-need requests, providers of data processing services to customers in the Union, data-space participants, and vendors or deployers of smart contracts used to execute data-sharing agreements.
A single company can therefore be out of scope for one workflow and in scope for another. For example, a manufacturer may have Chapter II duties for a connected machine, Chapter IV exposure in a data-sharing contract, and Chapter VI duties only if it also provides a qualifying .
Identify the concrete scenario: , , B2B data-sharing term, B2G request, , data-space participation, or smart-contract deployment.
Name the actor role in that scenario: manufacturer, provider, user, , , customer, public-sector body, data-space participant, smart-contract vendor, or smart-contract deployer.
Record the EU nexus: placed on the Union market, user or recipient in the Union, services provided to customers in the Union, non-personal data held in the Union, or public authority request covered by Chapter V.
Keep separate conclusions for each chapter; do not use a product-family or corporate-level answer as the applicability decision.
For Chapter II, ask whether the item is a and whether the digital service is a . A connected product obtains, generates, or collects data about its use or environment and can communicate product data by electronic communications, physical connection, or on-device access. Its primary function must not be storing, processing, or transmitting data on behalf of another party.
A is not every digital service around a product. The Commission FAQ describes two practical indicators: there is bidirectional exchange of data between the and service provider, and the service affects the connected product's functions, behaviour, or operation. Connectivity, power supply, auxiliary consulting, analytics, financial services, and ordinary repair or maintenance are not related services merely because they concern the product.
Connected vehicles, industrial equipment, smart-home devices, and fitness or health equipment are representative examples, but the label does not decide scope. A cloud storage service, ordinary web service, or prototype may fall outside Chapter II while another Data Act chapter still applies.
Describe the physical product and how it communicates product data.
Confirm the product was placed on the Union market; the FAQ treats placement as product-specific, not product-type-wide.
For each app, portal, firmware service, or remote-control service, document whether it changes product functions, behaviour, or operation.
Exclude prototypes and products whose primary function is storing, processing, or transmitting data for someone other than the user, unless another Data Act chapter applies.
Classify users, data holders, and recipients before promising access
A user is a natural or legal person that owns a , has temporary contractual rights to use it, or receives related services. The FAQ warns that ordinary use of a product inside a service, such as being a passenger, does not automatically make that person the Data Act user of the connected product.
A is the person with the right or obligation to use and make available data under the Data Act or other applicable EU or national law. A is a business actor, other than the user, to whom the data holder makes data available. Data Act Chapter II third-party sharing is limited to recipients in the Union, and DMA gatekeepers cannot be the third party under that mandatory IoT data-sharing route.
Tie the user role to ownership, rental, lease, temporary contractual use rights, or receipt of a .
Identify every likely , including a manufacturer, related-service provider, fleet operator, or service provider that lawfully obtains readily available data.
Check whether the requested recipient is in the Union and is not relying on the Article 5 route as a DMA gatekeeper.
Where the request involves personal data and the user is not the data subject, require a separate GDPR legal-basis check before access or onward sharing.
Separate in-scope product data from derived, protected, or unavailable material
Chapter II is about product data and related-service data that are readily available to a . The Commission describes the core in-scope set as raw and pre-processed data, including metadata needed to understand and use it. Data does not leave scope simply because privacy-enhancing technologies such as anonymisation, pseudonymisation, or encryption were applied.
Do not treat all analytics as user-access data. The FAQ places highly enriched data, inferred or derived data, data resulting from additional investments, and content often protected by intellectual property rights outside the Chapter II access set. The test should therefore distinguish sensor measurements, status logs, usage events, and necessary metadata from proprietary scores, predictions, models, reports, or creative content.
List product data, related-service data, and metadata separately.
Mark whether each category is raw, pre-processed, inferred, derived, content, personal data, non-personal data, or trade-secret material.
Record why data is readily available or not readily available, including whether it can be lawfully obtained without disproportionate effort beyond a simple operation.
For edge processing, document whether raw or pre-processed data was stored, retrievable, or transmitted externally at any point.
Use the chapter, actor, EU nexus, data category, exclusion, and safeguard fields from this page to create a cited Data Act applicability worksheet for product launches, contract reviews, request handling, and cloud switching.
Check exclusions, safeguards, and the delayed Chapter II design duty
Chapter II does not apply to data generated through connected products manufactured or designed, or related services provided, by a microenterprise or small enterprise, unless the enterprise has a partner or linked enterprise that is not micro or small, or is subcontracted to manufacture, design, or provide the product or service. The same exclusion temporarily covers data from products manufactured or related services provided by an enterprise that has qualified as medium-sized for less than one year, and connected products for one year after that medium-sized enterprise places them on the market.
Even when Chapter II applies, access is not absolute. The Data Act preserves GDPR and privacy law, allows narrowly framed security restrictions, and protects trade secrets through proportionate technical and organisational measures. Article 50 also delays the Article 3(1) design-by-default duty for connected products and related services placed on the market after 12 September 2026.
Check microenterprise, small-enterprise, linked-enterprise, partner-enterprise, and subcontracting facts before applying the Chapter II SME exclusion.
Do not use the SME exclusion for other chapters unless the specific chapter supports that result.
Escalate personal-data requests where the requester is not the data subject or where several users or data subjects are involved.
For trade secrets, record the protected data, the confidentiality measures offered, and whether any refusal is based on the Data Act's exceptional serious-economic-damage test.
The Regulation generally applies from 12 September 2025, but not every duty starts or reaches older arrangements on that date. Article 3(1), which requires accessible-by-design connected products and related services, applies only to products and related services placed on the market after 12 September 2026. Articles 4 and 5 request-based user and third-party access are separate duties and are not postponed by that Article 3(1) transition.
For obligations created by other Union law or qualifying national legislation, Chapter III applies where that law or legislation enters into force after 12 September 2025. Chapter IV applies to contracts concluded after 12 September 2025; from 12 September 2027 it also applies to older contracts of indefinite duration or contracts due to expire at least 10 years from 11 January 2024.
Record the product placement date separately from the model launch date and contract date.
Do not use the Article 3(1) transition to postpone an Article 4 or Article 5 request workflow.
For B2B terms, record when the data-sharing obligation entered into force and when the reviewed contract was concluded.
For an older contract, check duration and scheduled expiry before deciding whether Chapter IV applies from 12 September 2027.
Run a separate test for cloud and data processing services
Chapter VI does not depend on a . It applies to providers of data processing services that provide qualifying services to customers in the Union, including cloud and edge models that enable on-demand network access to configurable, scalable, and elastic computing resources.
For cloud applicability, identify the source provider, customer, service type, exportable data, digital assets, switching route, and any custom-built or testing-only service status. Article 31 excludes non-production testing and evaluation services provided for a limited period, and gives certain custom-built services a lighter regime rather than removing every Chapter VI duty.
Classify the service as IaaS, PaaS, SaaS, edge, or another only if it meets the Article 2 definition.
Map the contract, service catalogue entry, exportable data, digital assets, source provider, destination provider, and any on-premises target.
Check whether the service is custom-built for one customer and not offered at broad commercial scale, or is a non-production testing and evaluation service for a limited period.
Do not apply connected-product raw-data rules to cloud switching; use the Chapter VI switching, portability, open-interface, and contract tests instead.
Check B2G requests, data spaces, and smart contracts only when those facts exist
A public-sector request is in the Data Act's Chapter V route only where a public sector body, the Commission, the European Central Bank, or a Union body demonstrates an exceptional need for specific data to perform a statutory public-interest task. Non-emergency requests are limited to non-personal data and require the requester to show why other means were exhausted.
Data-space and smart-contract scope is a different test. Article 33 applies to participants in data spaces that offer data or data services to other participants. Article 36 applies to vendors of applications using smart contracts, or deployers of smart contracts for others, where the smart contract executes all or part of an agreement to make data available.
For B2G requests, capture the requesting body, statutory task, exceptional-need basis, data categories, metadata, proportionality, purpose, deadline, erasure plan, and trade-secret or personal-data safeguards.
For data spaces, confirm the organization offers data or data services to other participants before applying Article 33 interoperability requirements.
For smart contracts, confirm the program automates execution of a data-sharing agreement before applying Article 36 requirements such as robustness, access control, safe interruption, archiving, continuity, and consistency with the agreement.
If the facts only show ordinary voluntary sharing, procurement, analytics, hosting, or a blockchain component not used to execute data sharing, do not label the scenario as Article 33 or Article 36 scope.
Write the applicability result as a scoped conclusion
The final record should say exactly what is in scope, what is out of scope, what chapter applies, and which facts remain unresolved. A useful conclusion is specific enough for product, legal, procurement, cloud, security, and support teams to act without re-litigating the whole scenario.
Use exclusion labels carefully. The Data Act does not apply to areas outside Union law, certain criminal-law, customs, taxation, public-security, defence, and national-security matters, and it does not supersede GDPR, privacy, IP, consumer-protection, or sector-specific data-access rules. Those overlaps should be recorded as parallel legal checks, not as shortcuts around the Data Act.
State the conclusion as in scope, out of scope, partly in scope, or unresolved pending named facts.
Attach the chapter and article basis, actor role, EU nexus, data categories, exclusions, safeguards, and owner for the next action.
Keep launch, contract, request-response, and cloud-switching decisions in separate rows if they rely on different facts.
Update the record when product architecture, service packaging, market placement, customer location, data flows, or official guidance changes.