Search every question across sub-FAQs

Natural and legal persons can lodge a Data Act complaint with the relevant competent authority if they consider that their rights under the Regulation have been infringed. The complaint can be individual or, where relevant, collective.

The complaint may be lodged with the competent authority in the Member State of the person's habitual residence, place of work, or establishment. If the right authority is unclear, the data coordinator must provide the information needed to lodge the complaint with the appropriate competent authority.

Competent authorities must handle complaints about alleged Data Act infringements, investigate the subject matter to the extent appropriate, and keep complainants informed of progress and outcome in accordance with national law. They also cooperate with other competent authorities, the Commission, the EDIB, data protection authorities, sectoral authorities, and electronic-communications authorities where the issue crosses regimes.

For an internal playbook, avoid promising a fixed national procedure unless the specific Member State source confirms it. The Data Act itself supports a practical intake record: complaint, alleged infringement, authority route, investigation status, cooperation needs, outcome, and any corrective action.

A certified dispute settlement body can be used for specified Data Act disputes between users, data holders, data recipients, customers, and providers of data processing services. The route covers disputes under Articles 4 and 5, disputes about fair, reasonable, non-discriminatory and transparent terms for making data available under Chapter III and Chapter IV, and disputes between cloud or other data-processing-service customers and providers about Articles 23 to 31.

This is not a mandatory first step. The Commission FAQ explains that recourse to a dispute settlement body is voluntary and requires agreement by both parties. The Data Act also preserves access to courts.

The Data Act context is the starting point for this answer. A dispute settlement body decision is binding only if the parties explicitly consent to its binding nature before the proceeding starts. The body must give the parties a chance to express their views, share the other side's submissions and expert statements, and allow comments on those materials.

The body must adopt its decision within 90 days of receiving a covered request. The decision must be in writing or on a durable medium and supported by reasons. Fees or fee-calculation mechanisms must be known before the parties request a decision.

The Data Act uses parallel routes. A person can complain to a competent authority without losing other administrative or judicial remedies. Affected natural and legal persons also have a right to an effective judicial remedy against legally binding competent-authority decisions.

If a competent authority fails to act on a complaint, affected persons must have, in accordance with national law, either an effective judicial remedy or access to review by an impartial body with appropriate expertise. Proceedings are brought before the courts or tribunals of the Member State of the competent authority against which the judicial remedy is sought.

For mandatory B2B data sharing, Data Act disputes often concern whether terms for making data available are fair, reasonable, non-discriminatory, and transparent. The dispute file should show the legal obligation to make data available, the data requested, compensation basis, technical conditions, transparency information, and the counterparty category used for non-discrimination analysis.

For unfair contractual terms, focus on the specific term concerning access to and use of data, or liability and remedies for data-related obligations. The Commission FAQ states that, if a party disputes the unfairness assessment and does not withdraw the term, the matter can be brought to a competent authority, courts, or a dispute settlement body if the other party agrees.

For business-to-government requests, the complaint or objection record should focus on whether the Chapter V request is specific, transparent, proportionate, tied to an exceptional need, and limited to the data and duration required for the public-interest task. The Data Act also gives competent authorities the task of examining Chapter V requests.

Do not add unsupported national enforcement details. If a public-sector request is challenged, keep the request, legal basis, exceptional-need explanation, requested data categories, purpose, duration, confidentiality measures, personal-data analysis, response, and any competent-authority or court route.

The Data Act context is the starting point for this answer. Customers and providers of data processing services can use certified dispute settlement bodies for disputes about breaches of customer rights and provider obligations under Articles 23 to 31. These include switching, porting, contractual transparency, assistance, service continuity, exportable data, switching charges, and technical aspects of switching.

Competent authorities responsible for Articles 23 to 31 and Articles 34 and 35 must have experience in data and electronic communications services. They also cooperate to enforce those provisions consistently with other Union law and self-regulation applicable to providers of data processing services.

A useful evidence file lets a reviewer identify the Data Act role, route, legal issue, disputed data or service, affected counterparty, chronology, source basis, decision maker, and outcome without reconstructing the matter from informal messages.

Keep facts separate from legal conclusions. The same complaint may involve a competent authority, a data coordinator, a certified dispute settlement body, GDPR supervisory authority involvement, sectoral authority coordination, or a court remedy.

For complaints and dispute settlement, teams should keep the exact Data Act article or Commission guidance that supports the answer, plus the issue type, the affected workflow, and the date the decision was made.

The most useful evidence is a source URL, a short rationale for why the provision applies, and a linked implementation record showing who reviewed the question and what follow-up action was assigned.

Ownership of the Data Act question should sit with the team that can actually change the process: legal for the interpretation, product or engineering for technical access, procurement for vendor terms, support for intake routing, and cloud operations for switching or portability issues.

One owner should be named for each action item, with consulted teams and evidence dependencies listed separately so a later reviewer can see who approved the position and who has to execute it.

Data Act evidence is usable later when a reviewer can tell what decision was made, why it was made, and what concrete record supports it. That means the file should show the applicable article, the affected data or service, the route chosen, and the follow-up action.

Useful evidence is specific: source URLs, contract clauses, complaint records, dispute settlement forms, authority correspondence, switching logs, and implementation notes that show the decision can be recreated without guessing.

The Data Act context is the starting point for this answer. For connected products and related services, the key scope term is readily available data. It means product data and related service data that a data holder lawfully obtains, or can lawfully obtain, from the connected product or related service without disproportionate effort beyond a simple operation.

Product data is generated by the use of a connected product and designed to be retrievable from that product. Related service data represents user actions or events related to the connected product during the provision of a related service. The Commission explains the practical scope as raw and pre-processed data generated from use of a connected product or related service, where that data is readily available to the data holder.

The Data Act context is the starting point for this answer. The metadata obligation is not a separate nice-to-have documentation exercise. Article 3 requires product data and related service data to include relevant metadata necessary to interpret and use the data. Article 4 uses the same standard where the user cannot directly access the data and the data holder must make readily available data accessible.

In practice, an export that contains values but omits basic context can fail the point of the access right. The metadata set should let the user or an authorized third party understand what each field is, when and how it was generated, how units and identifiers work, and what quality or access limitations apply.

The Data Act does not name one universal file type for every connected product or related service. Instead, it requires access in a comprehensive, structured, commonly used and machine-readable format. Where relevant and technically feasible, Article 3 also expects direct access by default, and Article 4 expects continuous and real-time access where relevant and technically feasible.

A practical export catalogue should therefore state the actual delivery method and format for each dataset: API, bulk file, real-time stream, device interface, or another technical route. The format should be understandable outside the vendor's internal systems and should include the metadata needed to interpret and use the data.

The Data Act context is the starting point for this answer. Before a connected product purchase, rent, or lease contract is concluded, the seller, renter, or lessor must give the user clear and comprehensible information about the type, format, and estimated volume of product data the product can generate, whether it can generate data continuously and in real time, where it can store data, retention information, and how the user can access, retrieve, or erase data.

Before a related service contract is concluded, the provider must disclose the nature, estimated volume, and collection frequency of product data it expects to obtain, the nature and estimated volume of related service data to be generated, access and retrieval arrangements, storage and retention arrangements, whether readily available data will be used by the prospective data holder, and how the user can request sharing with a third party.

The Data Act context is the starting point for this answer. For cloud and other data processing services, exportable data is a defined term used for switching obligations. It covers input and output data, including metadata, directly or indirectly generated or cogenerated by the customer's use of the data processing service. It excludes assets or data protected by intellectual property rights, or constituting a trade secret, of the provider or third parties.

The customer-facing question is not only whether data can be downloaded. The provider must remove obstacles that inhibit customers from porting exportable data and digital assets to another provider of the same service type or to on-premises ICT infrastructure.

The Data Act context is the starting point for this answer. A provider of data processing services must give customers information on available switching and porting procedures, including available methods and formats, and known restrictions or technical limitations. The provider must also refer customers to an up-to-date online register with details of data structures, data formats, relevant standards, and open interoperability specifications in which the exportable data is available.

Where switching is between services of the same service type and no relevant common specifications or harmonised interoperability standards have been published in the central Union standards repository, the provider must, at the customer's request, export all exportable data in a structured, commonly used and machine-readable format.

The Data Act context is the starting point for this answer. For connected products and related services, the ordinary access scope does not include inferred or derived information that results from additional investments into assigning values or insights, particularly through proprietary complex algorithms, unless the user and data holder agree otherwise. The Commission gives examples such as highly enriched data and content being outside the Chapter II scope.

For cloud switching, exportable data excludes provider or third-party assets or data protected by intellectual property rights or constituting trade secrets. Providers are also not required to develop new technologies or services, disclose protected digital assets, or compromise customer or provider security and service integrity.

The Data Act preserves trade secrets, but it does not allow a broad confidentiality label to erase the access right. For user access and third-party sharing, the data holder or trade secret holder must identify protected data, including in the relevant metadata, and agree proportionate technical and organisational measures to preserve confidentiality.

Withholding, suspending, or refusing access on trade-secret grounds is limited and must be substantiated. Security restrictions for connected products require a risk that security requirements laid down by Union or national law would be undermined with serious adverse effects on health, safety, or security of natural persons.