EU Data Act Indirect Access Request Flows FAQ

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.

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 or third-party delivery, communicate the outcome, and close the record with delivery evidence or written reasons for any limit.

Treating indirect access as a generic support ticket loses the required 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.