Search every question across sub-FAQs

Natural and legal persons can lodge a complaint, individually or collectively where relevant, with the relevant competent authority if they consider that their Data Act rights have been infringed. The correct Member State is tied to the complainant's habitual residence, place of work, or establishment.

The data coordinator must, on request, provide the information needed to lodge the complaint with the appropriate competent authority. After a complaint is lodged, the competent authority must inform the complainant of the progress and the decision in accordance with national law.

No single EU penalty table is set in the Data Act. Member States set the rules on penalties for Data Act infringements and must make sure the penalties are effective, proportionate, and dissuasive.

The Data Act lists criteria for penalties, including the nature, gravity, scale, and duration of the infringement, mitigation or remediation, previous infringements, financial benefits gained or losses avoided, other aggravating or mitigating factors, and the infringing party's EU annual turnover in the preceding financial year.

Under the Data Act, certified dispute settlement bodies are a voluntary route. Users, data holders, and data recipients can use them for the Article 4 and 5 disputes identified in Article 10, disputes about fair, reasonable, and non-discriminatory terms and transparent data sharing under Chapters III and IV, and disputes under Articles 23 to 31 on data processing services.

A dispute settlement body decision binds the parties only if they explicitly consented to its binding nature before proceedings began. The route does not remove the right to seek an effective remedy before a Member State court or tribunal.

Data Act competent authorities do not replace GDPR supervisory authorities. Under Article 37, the authorities responsible for monitoring the GDPR are responsible for monitoring the Data Act insofar as protection of personal data is concerned.

That boundary matters when a Data Act access, sharing, or complaint file involves personal data. The GDPR authority remains responsible for checking whether the data are personal, whether a valid GDPR legal basis exists, and how the personal-data rules apply in the case.

A useful enforcement file should be narrow and factual. It should show which Data Act right or obligation is involved, which Member State authority path is relevant, whether a data coordinator should route the issue, whether dispute settlement is available, and whether GDPR or sectoral authorities have separate competence.

For complaints, refusals, penalties, or authority inquiries, keep enough evidence to reconstruct the issue without relying on chat history or unsupported assumptions.

For Data Act enforcement and competent authorities, teams should keep the source clause, any Commission guidance used, the actor role, the Member State route, and the reviewer who approved the interpretation.

Keep the cited external URL, decision date, unresolved assumptions, and implementation record together so the answer stays auditable.

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

Use one accountable owner per action, then record consulted teams and evidence dependencies separately.

Under the Data Act, the most useful evidence is the set of documents and references that let a later reviewer see why the team chose a particular authority path or complaint route.

That usually means the source article, the Commission explainer or FAQ, the authority register entry, and the internal approval note.

Under the Data Act, review the answer when the product, service model, customer base, authority structure, or national penalty rule changes.

Also review it when the Commission updates its guidance or when a new Member State authority or data coordinator appears in the public register.

Do not treat the Data Act enforcement answer as a generic checklist without checking the actual authority, route, and legal basis.

Avoid reusing an old authority list, assuming a single EU-wide penalty scale, or copying notes that are not supported by the Data Act or Commission guidance.

Under the Data Act, competent authorities must cooperate with each other and with authorities in other Member States, sharing relevant information so a cross-border issue does not fall between national gaps. The European Data Innovation Board supports consistency, including coordinating on the approach to penalties so they remain comparable across the Union.

For a complainant, this means a matter involving providers or users in several Member States can be coordinated rather than duplicated, and the data coordinator helps route the issue to the authority with competence.

Under the Data Act, functional equivalence means re-establishing a minimum level of functionality after a customer switches to a new data processing service of the same service type. The comparison is based on the customer's exportable data and digital assets, and it looks at whether the destination service delivers a materially comparable outcome for the same input and for shared contractual features.

The definition does not promise identical performance, identical configuration, or a full replica of the old environment. Teams should frame functional equivalence as a switching outcome to support, not as a warranty that every workload, integration, latency profile, or provider-specific feature will carry across unchanged.

Article 30(1) applies the functional-equivalence duty to providers whose service is limited to scalable and elastic infrastructural resources such as servers, networks, and the virtual resources needed to operate them, without access to the operating services, software, and applications deployed on that infrastructure. The Commission FAQ describes this as IaaS.

PaaS and SaaS providers remain covered by Chapter VI when they meet the definition of a data processing service, but Article 30 gives them different duties. They must make open interfaces available to customers and destination providers. Compatibility with a referenced harmonised standard or common specification becomes mandatory at least 12 months after the reference is published in the central Union repository. Until a relevant reference is published, Article 30(5) requires a structured, commonly used, machine-readable export for a same-service-type switch at the customer's request.

For an in-scope IaaS switch, the customer should be supported toward using a destination service of the same service type with materially comparable outcomes for the same input and for shared contractual features. The Data Act does not say the source provider must make the destination service identical, rebuild the workload for the customer, or control the destination provider's environment.

A useful switching plan therefore states the target outcome in operational terms: which workloads, configurations, data categories, access rights, security settings, machine images, containers, or other digital assets will be exported or documented; which destination features are shared; and which differences remain outside the source provider's control.

For IaaS functional equivalence, the source provider must take reasonable measures within its power. Article 30 describes the support as capabilities, adequate information, documentation, technical support, and, where appropriate, necessary tools.

The provider's switching contract and public information should also tell customers how switching and porting work, which methods and formats are available, what restrictions or technical limitations are known, and where to find the provider's register of data structures, formats, standards, and open interoperability specifications for exportable data.

The contract may set a notice period of no more than two months, followed by a maximum transition period of 30 calendar days and at least 30 calendar days for retrieval. If 30 days is technically infeasible, the provider must notify and justify that conclusion within 14 working days of the request and may specify an alternative transition period of no more than seven months. The customer may extend the transition once for a period it considers more appropriate.