--- title: "Data Act Indirect Access Request Flows FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/faq/indirect-access-request-flows" source_url: "https://www.sorena.io/artifacts/eu/data-act/faq/indirect-access-request-flows" author: "Sorena AI" description: "FAQ for Data Act teams handling user and third-party data requests when direct connected-product access is unavailable, incomplete, or limited." published_at: "2026-05-06" updated_at: "2026-05-06" keywords: - "EU Data Act" - "Regulation (EU) 2023/2854" - "indirect access request" - "connected product data" - "third party data sharing" - "Indirect access requests" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Data Act Indirect Access Request Flows FAQ FAQ for Data Act teams handling user and third-party data requests when direct connected-product access is unavailable, incomplete, or limited. *FAQ* *EU* *Data Act* ## EU Data Act Indirect Access Request Flows FAQ How to handle Data Act requests when users cannot directly retrieve connected-product or related-service data. Use this FAQ to design electronic request intake, verify users and third parties, route data holder decisions, and document limits for security, trade secrets, personal data, and request records. Article 4 of the Data Act makes indirect access relevant when the user cannot directly access readily available product data or related-service data from the connected product or related service. In that case, the data holder must provide the data through a simple electronic request where technically feasible, subject to Data Act limits for verification, personal data, security, trade secrets, and third-party sharing. ## When is an indirect access request needed under the Data Act for Indirect Access Request Flows implementation evidence? 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. - Trigger the workflow when direct access is missing, broken, incomplete, or not technically available for the requested data. - Confirm that the data is readily available to the data holder and is product data or related-service data, not inferred or derived analysis outside Chapter II scope. - Use a simple electronic request route where technically feasible instead of asking users to negotiate a bespoke manual process. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Article 4(1) is the binding rule for data holder access when data cannot be directly accessed by the user. - [European Commission - Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=sorena.io) - Commission explainer describes Chapter II scope as raw and pre-processed connected-product and related-service data that is readily available to the data holder. ## What should the user request form ask for under the Data Act for Indirect Access Request Flows implementation evidence? 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. - Ask for entitlement evidence that fits the product, such as ownership, rental, lease, contract, account, or related-service relationship. - Avoid broad identity or business-information demands that are not needed to verify the user or execute the request. - Keep requester-access logs only as long and as broadly as needed for execution, security, and maintenance of the data infrastructure. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Article 4(5) limits verification information and access-log retention for user access requests. - [European Commission - Data Act FAQs v1.4](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Commission FAQ 30 explains practical user verification and refers to simple request mechanisms and suitable product-specific identification methods. ## How should teams handle a user request to share data with a third party under the Data Act? 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. - Do not reject a third-party request only because the user can already access the data directly. - Screen out Digital Markets Act gatekeepers as Article 5 third parties. - Do not treat an entity or person outside the Union as someone the data holder is obliged to serve under Chapter II. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Article 5(1) creates the user right to have readily available data made available to a third party. - [European Commission - Data Act FAQs v1.4](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Commission FAQs 31, 36, and 37 clarify direct access, gatekeeper exclusion, and non-EU recipient limits for Chapter II sharing. ## What should the data holder verify before delivering data under the Data Act? 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. - Verify user or third-party qualification with the minimum information needed for the request. - Classify requested data as readily available raw or pre-processed data plus necessary metadata, or document why it is outside that category. - Route mixed personal and non-personal data through a privacy review before delivery, anonymisation, narrowing, or refusal. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Articles 4(5), 4(12), 5(4), and 5(7) support minimal verification and personal-data legal-basis checks. - [European Commission - Data Act FAQs v1.4](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Commission FAQs 25a and 25b explain GDPR legal-basis and controller-accountability considerations for Data Act requests. ## When may the data holder limit, withhold, suspend, or refuse access under the Data Act? 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. - Use data-scope exclusions for inferred, derived, unavailable, or out-of-scope data rather than calling every exclusion a refusal. - For security restrictions, record the legal security requirement, the serious adverse effect, the restriction chosen, and the authority notification. - For trade-secret withholding, suspension, or refusal, give written reasons without undue delay and notify the competent authority where Article 4 or Article 5 requires it. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Articles 4(2), 4(7), 4(8), 5(10), and 5(11) define security restrictions and trade-secret withholding, suspension, and refusal mechanics. - [European Commission - Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=sorena.io) - Commission explainer summarizes trade-secret and security safeguards and challenge routes for users. ## How should trade secrets be protected without turning protection into a blanket denial under the Data Act? 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. - Mark the specific data or metadata treated as trade secrets before disclosure discussions. - Match protection measures to the disclosure purpose and recipient rather than using generic NDA language as the only safeguard. - Keep the non-secret or adequately protected part of the response moving where the Data Act allows partial delivery. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Articles 4(6)-(8) and 5(9)-(11) require trade-secret identification, proportionate safeguards, written substantiation, and authority notification. - [European Commission - Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=sorena.io) - Commission explainer confirms that trade-secret protection should not undermine the Data Act goal of making more data available. ## What records should be kept for indirect access requests under the Data Act? 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. - Retain request and access records only to the extent necessary for request execution, infrastructure security, maintenance, dispute handling, and legal accountability. - Use decision codes that distinguish delivered, partially delivered, outside scope, personal-data blocked, security restricted, trade-secret withheld or suspended, and trade-secret refused. - Record the challenge route given to the user or third party when access is refused, withheld, or suspended. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Articles 4(5), 5(4), 4(9), and 5(12) support limited request-record retention and redress records for challenged decisions. - [European Commission - Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=sorena.io) - Commission explainer identifies competent-authority, court, and dispute-settlement challenge routes for refused, withheld, or suspended sharing. ## What is the shortest defensible workflow from intake to closure under the Data Act? 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. - Publish one intake route that product, support, privacy, legal, and data operations teams all use. - Separate user self-access, user-requested third-party sharing, and rejected or restricted requests in the workflow. - Review the workflow whenever the product interface, account model, related service, data map, or delivery API changes. Sources for this answer: - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Articles 4, 5, and 6 together support the intake, verification, delivery, safeguard, and third-party-use steps in an indirect access workflow. - [European Commission - Data Act FAQs v1.4](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Commission FAQs explain legitimate-user verification, third-party transfers, safety and security restrictions, and dispute settlement. ## What should teams keep on file to show the Data Act source basis for indirect access decisions? 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. - Store the source URL, article reference, decision date, and approver in the same record as the request. - Attach the affected workflow or product area so later reviewers can see where the decision was implemented. - Keep the evidence artifact, review trigger, and follow-up date together so the decision can be rechecked when the process changes. ## Who should own Data Act indirect access request handling inside the team? 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. - Assign a single accountable owner for the intake path, the third-party path, and the refusal or restriction path. - Record the affected workflow and the team that can approve product or service changes. - Keep the review trigger visible so ownership changes when the product, interface, or legal analysis changes. ## Which supporting documents make the EU Data Act indirect access answer usable later for reviewers? 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. - Keep source URLs, request logs, data inventories, contract clauses, technical controls, notices, and approval records together. - Include the owner, affected workflow, and the decision rationale in the same evidence set. - Store a review trigger so the answer can be updated when the product design or request path changes. ## When should the Data Act indirect access FAQ answer be reviewed again? 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. - Review after changes to the product interface, account model, related service, data map, or delivery API. - Review after a new legal interpretation, complaint, or authority decision affects the request path. - Review after the ownership model or approval process changes so the named owner stays current. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding Data Act text for Article 4 indirect user access, Article 5 third-party sharing, Article 6 third-party use limits, verification limits, security restrictions, trade-secret safeguards, and redress routes. - [European Commission - Data Act FAQs v1.4](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Commission FAQ support for user verification, direct access versus third-party sharing, non-EU recipient limits, safety and security restrictions, GDPR legal-basis checks, and dispute settlement. - [European Commission - Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=sorena.io) - Commission explainer support for Chapter II scope, readily available raw and pre-processed data, third-party sharing, trade-secret and security safeguards, and challenge routes. ## Topic Guides - [Data Act and Common European Data Spaces](/artifacts/eu/data-act/data-act-and-common-european-data-spaces.md): How Data Act Article 33 connects data-space participation with metadata, vocabularies, APIs, access terms, data quality, governance, and standards monitoring. - [Data Act and Data Governance Act Overlap FAQ](/artifacts/eu/data-act/faq/data-governance-act-overlap.md): FAQ explaining where the EU Data Act and Data Governance Act overlap, how they differ, and how to route product, cloud, public-sector reuse, intermediary, and data altruism workflows. - [Data Act and GDPR Personal Data Overlap FAQ](/artifacts/eu/data-act/faq/gdpr-personal-data-overlap.md): FAQ on how the EU Data Act works when connected-product or related-service data includes personal data, mixed datasets, GDPR roles, lawful basis, trade secrets, and third-party sharing. - [Data Act Audit Evidence And Request Logs FAQ](/artifacts/eu/data-act/faq/audit-evidence-and-request-logs.md): FAQ for Data Act request logs covering user and third-party access, B2G exceptional need requests, cloud switching records, contract terms, trade secrets, and GDPR boundaries. - [Data Act B2B Data-Sharing Contract Clauses](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): Clause guide for EU Data Act B2B data sharing: FRAND terms, compensation, trade secret safeguards, recipient limits, termination, logs, and GDPR boundaries. - [Data Act B2B Data-Sharing Contract Template](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A usable EU Data Act B2B data-sharing template outline covering access requests, data schedules, permitted use, trade secrets, security, compensation, GDPR boundaries, audit records, and termination. - [Data Act B2G Exceptional-Need Requests](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): A grounded guide to EU Data Act Chapter V requests from public bodies: exceptional need, public emergencies, request contents, limits, safeguards, costs, and records. - [Data Act Cloud Switching Compliance Checklist](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A grounded EU Data Act checklist for cloud and data processing service providers covering switching clauses, notices, export formats, charges, interoperability, and evidence. - [Data Act Cloud Switching Contract Terms FAQ](/artifacts/eu/data-act/faq/cloud-switching-contract-terms.md): FAQ on EU Data Act cloud switching contract terms: Article 25 clauses, assistance, notice, transition, charges, export, termination, interoperability, and records. - [Data Act Cloud Switching Fees And Deadlines FAQ](/artifacts/eu/data-act/faq/cloud-switching-fees-and-deadlines.md): FAQ on EU Data Act cloud switching charges, 2027 fee removal, notice periods, transition windows, data retrieval, contract terms, and evidence records. - [Data Act Complaints and Dispute Settlement FAQ](/artifacts/eu/data-act/faq/complaints-and-dispute-settlement.md): FAQ on EU Data Act complaints, competent authorities, dispute settlement bodies, B2B data-sharing disputes, B2G requests, cloud switching disputes, and evidence records. - [Data Act Exportable Data and Metadata FAQ](/artifacts/eu/data-act/faq/exportable-data-and-metadata.md): FAQ explaining which product, related service, metadata, and cloud switching data must be exportable under the EU Data Act, and which data can be excluded. - [Data Act FAQ for Aftermarket Repair and Mobility Services](/artifacts/eu/data-act/faq/aftermarket-repair-and-mobility-services.md): FAQ on EU Data Act vehicle-data access for repairers, independent service providers, fleets, insurers, and mobility services. - [Data Act Functional Equivalence FAQ](/artifacts/eu/data-act/faq/functional-equivalence.md): FAQ on Data Act functional equivalence for cloud switching: IaaS scope, customer outcomes, export support, interoperability duties, limits, and evidence. - [Data Act International Government Access FAQ](/artifacts/eu/data-act/faq/international-government-access.md): FAQ on EU Data Act safeguards for non-EU government access to non-personal data held in the Union by data processing service providers. - [Data Act Interoperability Standards FAQ](/artifacts/eu/data-act/faq/interoperability-standards.md): FAQ on EU Data Act interoperability standards for data spaces, cloud switching, smart contracts, harmonised standards, common specifications, and M/614. - [Data Act Model Contractual Terms FAQ](/artifacts/eu/data-act/faq/model-contractual-terms.md): FAQ on the EU Data Act non-binding model contractual terms for data access and use, cloud switching clauses, B2B use, unfair terms, and evidence. - [Data Act Public Emergency Requests FAQ](/artifacts/eu/data-act/faq/public-emergency-requests.md): FAQ on EU Data Act public emergency requests: exceptional need, request content, timing, data holder response, compensation, confidentiality, and records. - [Data Act Smart Contracts for Data Sharing](/artifacts/eu/data-act/smart-contracts-for-data-sharing.md): Data Act Article 36 smart contract guide for data-sharing agreements: scope, robustness, access control, termination, interruption, archiving, standards status, and conformity evidence. - [Data Act SME Exceptions and Startups FAQ](/artifacts/eu/data-act/faq/sme-exceptions-and-startups.md): FAQ on where the EU Data Act gives micro, small, medium-sized, startup, and SME actors narrower treatment for access duties, compensation, and B2B terms. - [Data Act Trade Secret Technical Protection Measures FAQ](/artifacts/eu/data-act/faq/trade-secret-technical-protection-measures.md): FAQ on how EU Data Act data holders can protect trade secrets with confidentiality safeguards, technical measures, limited withholding, suspension, refusal, and evidence. - [Data Act Trade Secrets and Protection Measures](/artifacts/eu/data-act/trade-secrets-and-protection.md): Data Act guide for protecting trade secrets during access and sharing: classification, safeguards, refusal thresholds, notices, evidence records, and reviews. - [Data Act Unfair Contractual Terms | Article 13 B2B Contract Review](/artifacts/eu/data-act/unfair-contractual-terms.md): Review B2B data-sharing clauses under EU Data Act Article 13: unilateral terms, always unfair examples, presumed unfair terms, model clauses, evidence, and remediation. - [Data Act Vehicle Data Guidance](/artifacts/eu/data-act/vehicle-data-guidance.md): Commission-grounded guide to Data Act vehicle data access: connected vehicles, vehicle-related services, raw and pre-processed data, aftermarket use cases, access routes, safeguards, and GDPR boundaries. - [Data Act vs GDPR: connected-product data access](/artifacts/eu/data-act/data-act-vs-gdpr.md): Compare EU Data Act connected-product access duties with GDPR personal-data rules: scope, roles, lawful basis, data subject rights, third-party sharing, trade secrets, and conflicts. - [EU Data Act and Common European Data Spaces FAQ](/artifacts/eu/data-act/faq/data-act-and-common-european-data-spaces.md): FAQ on how EU Data Act interoperability duties, Data Governance Act rules, and sector data-space governance fit together without treating participation as a general obligation. - [EU Data Act Applicability Test](/artifacts/eu/data-act/applicability-test.md): Check whether a product, related service, data holder, cloud service, data-space role, smart contract, or B2G request is in scope of the EU Data Act. - [EU Data Act Application Dates And Transition FAQ](/artifacts/eu/data-act/faq/application-dates-and-transition.md): FAQ on when the EU Data Act applies, which obligations are delayed, and what product, contract, cloud, and evidence records teams should maintain. - [EU Data Act Article 3 Pre-Contract Information](/artifacts/eu/data-act/pre-contractual-information-obligations.md): What Article 3 of the EU Data Act requires before connected-product purchase, rent, lease, or related-service contracting: data categories, access, data holder identity, third-party sharing, complaints, and evidence. - [EU Data Act Article 36 Smart Contract Controls FAQ](/artifacts/eu/data-act/faq/article-36-smart-contract-controls.md): FAQ explaining when EU Data Act Article 36 applies to smart contracts for data-sharing agreements and what controls, conformity evidence, and limits it requires. - [EU Data Act B2B Data Sharing Compensation FAQ](/artifacts/eu/data-act/faq/compensation-for-b2b-data-sharing.md): FAQ on when Data Act data holders may charge B2B data recipients, what reasonable compensation can include, SME limits, unfair terms, disputes, and trade secret safeguards. - [EU Data Act B2G Compensation and Costs FAQ](/artifacts/eu/data-act/faq/b2g-compensation-and-costs.md): FAQ on when Data Act B2G exceptional-need requests are free, when fair compensation may be claimed, which costs can be included, and what records to keep. - [EU Data Act B2G Exceptional Need FAQ](/artifacts/eu/data-act/faq/b2g-exceptional-need.md): When public-sector bodies can request business-held data under the EU Data Act, what a valid request must contain, and how data holders handle limits, trade secrets, compensation, and evidence. - [EU Data Act Checklist for Product, Cloud, and Contract Teams](/artifacts/eu/data-act/checklist.md): A grounded EU Data Act checklist for connected-product data access, third-party sharing, B2G requests, cloud switching, unfair terms, smart contracts, personal data boundaries, evidence, and owners. - [EU Data Act Cloud Switching and Exit Plans](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): A grounded EU Data Act guide for data processing service exit plans: switching contracts, exportable data, assistance, charges, interoperability, retrieval, erasure, and records. - [EU Data Act Cloud Switching Procurement FAQ](/artifacts/eu/data-act/faq/cloud-switching-procurement-checklist.md): Procurement checklist FAQ for EU Data Act cloud switching: contract terms, exit support, exportable data, switching charges, interoperability, termination, and supplier evidence. - [EU Data Act Compliance Program](/artifacts/eu/data-act/compliance.md): Build a Data Act compliance program for connected-product data access, contracts, B2G requests, cloud switching, smart contracts, GDPR boundaries, records, and ownership. - [EU Data Act Connected Product Scope and Data Types](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): Classify EU Data Act connected products, related services, product data, related-service data, readily available data, metadata, and excluded derived outputs. - [EU Data Act Connected Product Scope FAQ](/artifacts/eu/data-act/faq/scope-connected-products.md): FAQ explaining when connected products, related services, generated data, EU market placement, and SME exceptions fall within EU Data Act scope. - [EU Data Act Data Processing Service Switching](/artifacts/eu/data-act/data-processing-services-switching.md): A grounded EU Data Act guide for provider and customer switching duties: exit assistance, exportable data, contract clauses, charges, interoperability, retrieval, and erasure. - [EU Data Act data spaces interoperability FAQ](/artifacts/eu/data-act/faq/data-spaces-interoperability.md): FAQ explaining Article 33 Data Act interoperability requirements for data-space participants, common European data spaces, standards, APIs, metadata, and architecture evidence. - [EU Data Act deadlines and compliance calendar](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): A source-linked calendar for EU Data Act application dates, product design timing, contract remediation, cloud switching charges, response periods, standards work, and evidence records. - [EU Data Act Direct Access by Design FAQ](/artifacts/eu/data-act/faq/direct-access-by-design.md): FAQ for product and legal teams designing user access to connected-product and related-service data under the EU Data Act. - [EU Data Act Enforcement And Competent Authorities FAQ](/artifacts/eu/data-act/faq/enforcement-and-competent-authorities.md): FAQ on who enforces the EU Data Act, how complaints work, how Member States set penalties, when dispute settlement can be used, and when GDPR authorities remain responsible. - [EU Data Act FAQ: scope, access rights, B2G, cloud switching, GDPR, and dates](/artifacts/eu/data-act/faq.md): Grounded EU Data Act FAQ index covering connected-product data access, third-party sharing, B2G exceptional need, cloud switching, smart contracts, GDPR boundaries, unfair terms, trade secrets, and application dates. - [EU Data Act Non-Emergency Public-Sector Requests FAQ](/artifacts/eu/data-act/faq/non-emergency-public-sector-requests.md): FAQ on EU Data Act requests where a public body claims exceptional need outside a public emergency, including scope, request contents, limits, compensation, confidentiality, and evidence. - [EU Data Act Non-Personal Data and Mixed Datasets FAQ](/artifacts/eu/data-act/faq/non-personal-data-and-mixed-datasets.md): FAQ on how the EU Data Act treats non-personal data, mixed datasets, GDPR precedence, user and third-party access, trade-secret limits, and evidence records. - [EU Data Act Penalties and Enforcement](/artifacts/eu/data-act/penalties-and-fines.md): Grounded guide to Data Act penalties under Article 40, Member State enforcement, penalty factors, complaints, judicial remedies, and the GDPR enforcement boundary. - [EU Data Act Pre-Contractual Information FAQ](/artifacts/eu/data-act/faq/pre-contractual-information.md): FAQ on EU Data Act Article 3 pre-contract information for connected products and related services, including data categories, access methods, data holder identity, third-party sharing, and GDPR boundaries. - [EU Data Act Product Data vs Related Service Data FAQ](/artifacts/eu/data-act/faq/product-data-and-service-data.md): FAQ explaining how the EU Data Act separates connected product data, related service data, readily available raw and pre-processed data, metadata, and inferred or derived outputs. - [EU Data Act Readily Available Data FAQ](/artifacts/eu/data-act/faq/readily-available-data.md): FAQ on what counts as readily available data under the EU Data Act, including product data, related service data, metadata, inferred data, and access mechanics. - [EU Data Act Related Services FAQ](/artifacts/eu/data-act/faq/related-services.md): FAQ explaining when software is a Data Act related service, how it links to connected products, which product and service data are in scope, and what exclusions apply. - [EU Data Act requirements](/artifacts/eu/data-act/requirements.md): Source-grounded EU Data Act requirements for connected-product data access, B2B sharing terms, B2G exceptional needs, cloud switching, smart contracts, interoperability, GDPR boundaries, and records. - [EU Data Act Smart Contracts for Data Sharing FAQ](/artifacts/eu/data-act/faq/smart-contracts-for-data-sharing.md): Answers on Article 36 Data Act smart-contract requirements for data sharing: scope, robustness, access control, termination, archiving, conformity assessment, contract terms, and standards status. - [EU Data Act Third-Party Data Sharing FAQ](/artifacts/eu/data-act/faq/third-party-data-sharing.md): FAQ on user-directed third-party data sharing under the EU Data Act, covering data holder duties, recipient limits, trade secrets, security, GDPR, and gatekeepers. - [EU Data Act Trade Secret Safeguards FAQ](/artifacts/eu/data-act/faq/trade-secrets-safeguards.md): FAQ on protecting trade secrets when handling EU Data Act user and third-party data access requests, including safeguards, withholding, suspension, refusal, notices, and records. - [EU Data Act Unfair Contractual Terms FAQ](/artifacts/eu/data-act/faq/unfair-contractual-terms.md): FAQ on Article 13 of the EU Data Act: B2B unfair contract terms, unilateral take-it-or-leave-it clauses, always-unfair terms, presumed-unfair terms, SMEs, model terms, and review evidence. - [EU Data Act User Access and Portability Rights](/artifacts/eu/data-act/access-rights-and-portability.md): Practical guide to EU Data Act user access, connected-product data portability, third-party sharing, trade secret safeguards, and the GDPR boundary. - [EU Data Act Users, Data Holders, and Recipients FAQ](/artifacts/eu/data-act/faq/users-data-holders-and-recipients.md): FAQ explaining Data Act users, data holders, data recipients, connected products, related services, user access, third-party limits, and GDPR boundaries. - [EU Data Act Vehicle Data Guidance FAQ](/artifacts/eu/data-act/faq/vehicle-data-guidance.md): FAQ on EU Data Act vehicle data guidance for connected vehicles, aftermarket repair, mobility services, third-party access, trade secrets, security, and GDPR boundaries. - [EU Data Act vs Data Governance Act](/artifacts/eu/data-act/data-act-vs-data-governance-act.md): Compare the EU Data Act with the Data Governance Act: connected-product access, cloud switching, B2B/B2G duties, protected public-sector reuse, intermediaries, altruism, governance, and enforcement. *Recommended next step* *Placement: after request records section* ## Operationalise Data Act indirect access requests Turn indirect Data Act access into a request workflow with verification limits, third-party sharing controls, safeguard decisions, and request records that product, support, legal, privacy, and data operations teams can run. - [Open Research Copilot](/solutions/research-copilot.md): Get cited answers on Data Act indirect access, third-party sharing, security limits, and trade-secret safeguards. - [Discuss Data Act access flows](/contact.md): Review how indirect access requests should map to your products, related services, data routes, and support operations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/faq/indirect-access-request-flows