Search every question across sub-FAQs

Under the Data Act, the Article 33 essential requirements bind operators of data spaces and participants that offer data or data services to other participants, rather than every organisation that merely consumes data within a data space. The trigger is offering data or services, so a pure consumer does not carry the same description duties.

Teams should map each participant's role before applying the requirements, since a single organisation can be an offering participant for one dataset and a consumer for another within the same data space.

The Data Act context is the starting point for this answer. Direct access by design means the connected product and any related service must be built so the user can access product data and related-service data by default. Article 3 requires the access path to include relevant metadata, use a comprehensive, structured, commonly used and machine-readable format, and be easy, secure, and free of charge.

The obligation is not just a helpdesk process. Product teams should decide during architecture, release, and UX design whether the user will retrieve data from on-device storage, an app, an account portal, an API, or a remote server. Where direct access is relevant and technically feasible, it should be available without making the user ask support to manually extract the data.

The Data Act context is the starting point for this answer. The design should cover product data and related-service data that are readily available to the data holder. The Commission explains this as raw and pre-processed data generated from use of a connected product or related service that can be accessed without disproportionate effort, including relevant metadata.

The data map should distinguish raw data, pre-processed data, relevant metadata, personal data, non-personal data, inferred or derived data, trade-secret material, and data that is not stored or transmitted by the product design. Inferred or derived insights produced through additional investment, such as proprietary analytics, should not be mixed into the direct-access dataset unless the parties have agreed otherwise.

The Data Act context is the starting point for this answer. Article 4 applies where the user cannot directly access the data from the connected product or related service. In that case, the data holder must make readily available data and necessary metadata accessible to the user without undue delay, with the same quality available to the data holder, and through a simple electronic request where technically feasible.

A product can therefore need both paths: direct access for data that can be exposed by design, and a request-based route for data that cannot be directly accessed. The request route should not be used to compensate for avoidable design gaps in a new product that falls under Article 3.

The Data Act context is the starting point for this answer. No. The Commission FAQ states that users can still ask a data holder to transfer data to a third party under Article 5 even where the user already has direct access under Article 3. Direct access helps the user retrieve data, but it does not supersede the separate user right to have a data holder make readily available data available to a chosen third party.

The product design should therefore avoid a dead end where the user can download data but cannot authorize third-party sharing. Teams should provide a clear route for third-party requests, eligibility checks, trade-secret safeguards, and refusal or suspension records where the Data Act allows them.

The Data Act context is the starting point for this answer. Before a connected-product contract, Article 3 requires clear and comprehensible information about the type, format, and estimated volume of product data; whether data can be generated continuously and in real time; storage location and retention where applicable; and how the user may access, retrieve, or erase the data.

Before a related-service contract, the provider must explain the expected product data and related-service data, collection frequency, access or retrieval arrangements, storage and retention, intended use of readily available data, third-party sharing routes, complaint rights, relevant trade-secret holder information, and contract termination arrangements. These pre-contract disclosures should match the actual product interface and API behavior.

The Data Act context is the starting point for this answer. Security controls can verify that the requester is a user and protect the data infrastructure, but they should not make access unduly difficult. Article 4 limits verification requests to necessary information, and the Commission FAQ points to simple request mechanisms and automatic execution where possible.

Security also has a substantive limit: users and data holders may restrict access, use, or onward sharing if processing could undermine security requirements of the connected product laid down by EU or national law, with serious adverse effects on people's health, safety, or security. That is narrower than a general preference not to share data.

The Data Act preserves trade secrets, but it does not allow a blanket trade-secret label to erase user access. The data holder or trade-secret holder must identify protected data, including in relevant metadata, and agree proportionate technical and organisational measures such as confidentiality terms, strict access protocols, technical standards, and codes of conduct.

Withholding, suspension, or refusal should be exceptional and documented. Article 4 requires written substantiation and competent-authority notification when data sharing is withheld, suspended, or refused on trade-secret grounds. Refusal for serious economic damage must be assessed case by case and supported by objective elements.

The Data Act generally applies from 12 September 2025, but Article 50 states that the obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. Teams should keep those two dates separate in release plans and customer-facing materials.

For products already in the market, other Data Act duties can still matter, including user access under Article 4, data holder contracts for non-personal readily available data, and third-party sharing under Article 5 where the conditions are met. Do not present the later Article 3 design date as a full exemption from the Data Act.

The evidence file should let a reviewer connect the product architecture to the Data Act duty without reconstructing decisions from tickets. Keep a data inventory, Article 3 design specification, pre-contract disclosure, UX/API evidence, security and identity assessment, trade-secret register, request-path procedure, and release approval.

Evidence should also show that the access path works in practice. Useful records include sample exports, API schemas, metadata dictionaries, user journey screenshots, access logs limited to what is necessary, support scripts, test results for machine readability, and records of any security or trade-secret restriction.

Under the Data Act, assign one accountable owner for the design decision itself and separate owners for the supporting work. The accountable owner should be the team that can approve changes to the product or related service, while legal, security, procurement, support, and engineering can supply review and evidence inputs.

For direct-access by design, the workflow should name the owner who signs off on the Article 3 interpretation, the owner who maintains the data map, and the owner who closes any open review trigger. Consulted teams and evidence dependencies should be recorded, but they should not replace a single accountable owner.

Under the Data Act, Article 3 requires direct access to product and related-service data to be provided to the user easily, securely, and free of charge, in a comprehensive, structured, commonly used, machine-readable format with relevant metadata. A data holder cannot put the statutory user access behind a fee or a premium tier.

Compensation can arise in the separate context of sharing with a third party under Articles 4 and 5, but that is distinct from the user's own free access by design, which the product must support without charge.

Under the Data Act, the Article 3 design obligation applies to connected products and related services placed on the market after 12 September 2026, so products designed before that date are not retrofitted by the rule but may still owe Article 4 access on request. Teams should map each product to the date it was or will be placed on the market.

A product roadmap crossing that date should bake direct access into the design rather than relying on a manual export, so the access path is easy, secure, and free of charge from launch.

Each Member State must designate one or more competent authorities for Data Act application and enforcement. A Member State can create a new authority or rely on an existing public body, so companies should not assume that the same office is responsible in every country.

If a Member State designates more than one competent authority, it must designate a data coordinator from among them. The data coordinator is the national single point of contact for Data Act application questions and helps route people and businesses to the appropriate competent authority.

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 disputes about the Chapter II handbrakes, FRAND terms, Chapter III compensation, and Chapter VI 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.