Search every question across sub-FAQs

The switching file should distinguish exportable data from digital assets and from material that the Data Act does not require the provider to disclose or transfer. Exportable data covers input and output data, including metadata generated or co-generated by the customer's use of the service, but excludes provider or third-party intellectual property and trade secrets.

Digital assets are broader practical enablers for using the customer's data in a new environment. The Commission FAQ gives examples such as configuration settings, security and access-control metadata, applications, virtual machines, and containers where the customer has an independent right to use them.

For PaaS and SaaS, the Data Act requires providers to make open interfaces available free of charge, to an equal extent, to all customers and the concerned destination providers. It also requires sufficient information for software-to-software communication. Compatibility duties depend on publication of the relevant harmonised standard or common specification in the central Union repository and the 12-month period in Article 30(3). Where no relevant reference has been published, Article 30(5) supplies the machine-readable export rule for same-service-type switching.

For IaaS, interoperability standards and open specifications can also help customers reach functional equivalence, but they do not turn the source provider into the operator of the destination environment. The standardisation route should be tracked as a dependency because the Data Act ties some compatibility duties to publication in the central Union standards repository.

Functional-equivalence wording should not imply unlimited responsibility. The Data Act limits the source provider's technical obligations to the services, contracts, and commercial practices it provides. It also says providers are not required to develop new technologies or services, disclose or transfer protected intellectual property or trade secrets, or compromise security and service integrity.

The customer-facing explanation should also separate included switching assistance from optional additional services. A customer may request additional support beyond the provider's Data Act switching obligations, but that should be described and priced as an additional service agreed in advance rather than hidden inside the mandatory switching process.

For functional equivalence, 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.

Keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

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

For functional equivalence, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

The functional-equivalence duty centres on IaaS, where the source provider must take reasonable measures so the customer can re-establish a minimum level of functionality on a same-type destination service. PaaS and SaaS providers do not owe that outcome. They must provide the open interfaces required by Article 30(2), meet the compatibility duty after the Article 30(3) trigger, and provide the Article 30(5) export when no relevant repository reference has been published.

Teams should classify the service before promising an outcome, because expecting functional equivalence from a SaaS provider, or accepting only a raw export from an IaaS provider, both misread the Regulation.

Under the Data Act, the source provider must offer reasonable assistance, exercise due care to maintain business continuity, provide capabilities and information to support the switch, and keep a high level of security during transfer and retrieval. The duty is about enabling the customer to reach a comparable outcome, not rebuilding the destination environment.

The measures should be scoped to the provider's own service and contractual features, with any work beyond that treated as a separately agreed additional service rather than part of the mandatory switching support.

Under the Data Act, a source provider is not required to develop new technologies or services, disclose or transfer protected intellectual property or third-party trade secrets, or compromise the security and integrity of its service to deliver functional equivalence. These are genuine limits rather than excuses to avoid the switching duty.

A defensible decline points to one of those specific limits for the requested step, while still delivering the export, assistance, and continuity measures the Regulation requires for everything else.

Use indirect access whenever the product or related service is designed so that the user needs the data holder's intervention to obtain the relevant data. It also covers data that are not directly accessible even if other fields are available through the product, app, device storage, or service interface. Article 4 then requires the holder to make readily available data and the metadata needed to interpret and use them accessible to the user.

The data holder route must be easy, secure, free of charge to the user, and provide data in a comprehensive, structured, commonly used, machine-readable format. Access must be continuous and real-time only where that is relevant and technically feasible. The general Chapter II access rules have applied since 12 September 2025; the Article 3(1) product-design duty applies to connected products placed on the market after 12 September 2026 and the services related to them.

The form should collect enough information to identify the requester as a Data Act user, identify the connected product or related service, describe the requested data, and choose the delivery route. Article 4 limits verification: the data holder may not require more information than necessary to verify that the person qualifies as a user.

A practical intake record should capture the requester identity, relationship to the product or related service, product identifier or account identifier, requested period or event range, requested format or endpoint, whether personal data may be included, and whether the user is asking for delivery to themselves or a third party.

Article 5 gives the user a separate right to ask the data holder, or have a party acting on the user's behalf ask, for readily available data and necessary metadata to be made available to a third party. This right is not limited to cases where the user lacks direct access; the Commission FAQ states that third-party transfer can still be requested even where direct access has been granted.

Separate user access from third-party transfer. For Article 5, the third party must be established in the Union, and a Digital Markets Act gatekeeper is ineligible. Record the user's instruction, the recipient's identity and establishment, the agreed purpose, data categories, delivery route, and whether the terms and compensation rules in Articles 8 and 9 apply.

The data holder should verify the requester role, the product or related-service relationship, whether the requested data is readily available, and whether the delivery would include personal data, trade secrets, or data subject to security restrictions. Verification should support the Data Act request; it should not become a barrier that makes the user's rights unduly difficult to exercise.

For personal data, the workflow needs a GDPR checkpoint. Where the user is not the data subject, Article 4(12) and Article 5(7) require a valid legal basis under GDPR Article 6 and, where relevant, special-category and ePrivacy conditions before personal data is made available to the user or third party.

A data holder should distinguish ordinary scoping from formal limits. Data can be outside the request because it is not readily available, is inferred or derived, or is not product or related-service data. By contrast, security and trade-secret limits are Data Act safeguards that require specific handling, written reasons, and, in several cases, competent-authority notification.

Security limits under Article 4(2) require a risk that processing could undermine connected-product security requirements laid down by Union or national law and result in serious adverse effects to the health, safety, or security of natural persons. Trade-secret withholding or suspension can apply where confidentiality measures are not agreed or implemented, while refusal is reserved for exceptional circumstances where serious economic damage is highly likely despite the measures taken.

The Data Act does not allow the data holder to deny access merely because requested data includes trade secrets. The holder or trade-secret holder should identify protected data, including in relevant metadata, and agree proportionate technical and organisational measures with the user or third party before disclosure.

Useful measures include confidentiality terms, strict access protocols, technical standards, and codes of conduct. If those measures are not agreed, are not implemented, or are undermined, the data holder may withhold or suspend the affected trade-secret data. Refusal should stay narrow: it is case-by-case, tied to specific data, and requires objective substantiation that serious economic damage is highly likely.

Keep a request record that explains the route and outcome without collecting more access-log information than Article 4 or Article 5 permits. The record should show the requester, verification basis, product or service, data categories, scope decision, personal-data assessment, trade-secret or security safeguard, delivery method, and outcome.

For refused, withheld, suspended, narrowed, or delayed requests, preserve the written reason, the objective elements relied on, the notification made to the competent authority where required, and any complaint, court, or dispute-settlement path communicated to the user or third party. For third-party sharing, keep the user's instruction and the third party's agreed purpose and restrictions.