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.

Interoperability is the technical and organisational foundation that makes switching realistic. For PaaS and SaaS, the Data Act focuses on open interfaces, sufficient service information for software communication, compatibility with published common specifications or harmonised standards, and structured, commonly used, machine-readable exports where standards have not yet been published.

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.

Under the Data Act, 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. For PaaS and SaaS the duty is lighter: export the exportable data and digital assets in a structured, commonly used, machine-readable format.

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.

The Data Act context is the starting point for this answer. An indirect access request is needed when the user cannot get the relevant connected-product or related-service data directly from the product, app, service interface, device storage, or connected server path. Article 4 then shifts the operational route to the data holder: the holder must make readily available data and the metadata needed to interpret and use it accessible to the user.

The request flow should not become the default if direct access already works. It is a fallback for unavailable, incomplete, or technically unavailable direct access, and it should still deliver the same Data Act qualities: easy, secure, free of charge to the user, structured, commonly used, machine-readable, and, where relevant and technically feasible, continuous and real-time.

The Data Act context is the starting point for this answer. The form should collect enough information to identify the requester as a 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.

The Data Act context is the starting point for this answer. 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.

The workflow should therefore separate user access from third-party transfer. The third-party branch should record the user's instruction, the third party's identity and EU nexus where relevant, the agreed purpose, the data categories, the delivery route, and whether Articles 8 and 9 terms or compensation issues apply to the third party.

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.

The Data Act context is the starting point for this answer. Keep a request record that proves the route was lawful and operationally complete 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.

The Data Act context is the starting point for this answer. A compact workflow is: receive the electronic request, verify only what is necessary, identify the connected product or related service, classify the requested data, run personal-data, security, and trade-secret checks, choose user delivery or third-party delivery, communicate the outcome, and close the record with evidence of delivery or written reasons for any limit.

The common failure is treating indirect access as a generic support ticket. A Data Act request needs a legal and technical trail: why direct access was unavailable, what readily available data was in scope, which safeguards changed the response, and what the user or third party was told.

For indirect access request flows, keep the specific Article 4 or Article 5 citation, the official source URL, and the internal decision note together with the request record. That makes it easier to show which Data Act rule supported the action.

Keep the evidence pack focused on the decision itself: who approved it, which request it covered, what data categories were in scope, and what safeguard or limit was applied.

For Data Act indirect access request flows, the owner should be the team member who can coordinate product, legal, privacy, and support actions for the specific request path. The legal rule may sit with one team, but the operational response usually needs cross-functional ownership.

Use one named owner for each request path, then record the supporting teams that need to review verification, security, trade-secret, or delivery issues.

For indirect access request flows, the most useful supporting material is whatever lets a later reviewer reconstruct the decision without guessing. That usually means the Data Act citation, request logs, product or service data map, the verification method, and any security or trade-secret notes.

Keep the evidence set practical. The goal is to show how the team handled the request, not to create a large archive of unrelated operational material.

For Data Act indirect access request flows, the answer should be reviewed when the product, service model, dataset, customer role, or contract wording changes, or when the team changes how requests are received or routed.

Set both a calendar review date and an event-based trigger. That helps keep the answer aligned with the live request process instead of relying on a one-time note.