Search every question across sub-FAQs

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.

The Data Act context is the starting point for this answer. A non-emergency request qualifies only if the exceptional need is limited in time and scope and concerns non-personal data. The requesting body must be acting under Union or national law and must identify specific data whose absence prevents it from fulfilling a specific task carried out in the public interest and explicitly provided for by law.

The requesting body must also show that it has exhausted other means to obtain the data. The Data Act lists examples such as trying to buy non-personal data on the market at market rates, relying on existing obligations to make data available, or adopting new legislative measures that could guarantee timely availability. This is not a general evidence-gathering power for convenient or recurring data needs.

The Data Act context is the starting point for this answer. The request must be written in clear, concise, plain language and must specify the data required, including metadata needed to interpret and use it. It must demonstrate the exceptional need, explain the purpose, intended use, duration of use, expected erasure timing if possible, why this data holder was chosen, and any expected sharing with other public bodies or delegated third parties.

The request must also state the legal provision assigning the requesting body the relevant public-interest task, specify the deadline for making data available, and state the deadline by which the data holder may decline or seek modification. Where the requester is a public-sector body, the request must be transmitted to the data coordinator for online publication unless publication would create a public-security risk.

The Data Act context is the starting point for this answer. Test proportionality against the exceptional need, not against the requester's general public mission. Article 17 requires the request to be specific about the type of data, correspond to data the holder controls at the time of the request, and be justified by the granularity, volume, and frequency of access requested.

A practical review should separate data the holder controls from data it does not control; non-personal data from personal data; raw data from metadata needed to interpret it; and trade-secret or commercially sensitive elements from ordinary operational data. The record should explain why each included dataset is necessary and why any excluded dataset falls outside control, scope, proportionality, or confidentiality limits.

For a non-emergency exceptional-need request, the data holder may decline or seek modification without undue delay and no later than 30 working days after receiving the request. The Data Act grounds are limited: the holder does not control the requested data, a similar request for the same purpose was already submitted and no erasure notice has been received, or the request does not meet the Article 17 content and condition requirements.

A refusal or modification request should identify the precise ground and the evidence supporting it. If the issue is a previous similar request, the holder must indicate the identity of the body that previously submitted the request for the same purpose. If the requester challenges the refusal, or the holder challenges the request and it cannot be resolved by modification, the matter goes to the competent authority designated under the Data Act.

The Data Act context is the starting point for this answer. The request must respect the data holder's legitimate aims, including trade-secret protection and the cost and effort required to make data available. Disclosure of trade secrets is required only to the extent strictly necessary to achieve the Article 15 purpose. The data holder or trade-secret holder should identify protected data, including relevant metadata, before disclosure.

Before trade secrets are disclosed, the receiving public body or Union institution must take appropriate technical and organisational measures to preserve confidentiality. Article 19 also requires recipients to preserve confidentiality and integrity, secure transfers, use the data only for the requested purpose, erase it when no longer necessary, and avoid using the data to develop or enhance a competing connected product or related service.

The Data Act context is the starting point for this answer. Yes. For Article 15(1)(b) non-emergency exceptional-need requests, Article 20 entitles the data holder to fair compensation. The compensation covers technical and organisational costs incurred to comply with the request, including costs of anonymisation, pseudonymisation, aggregation, and technical adaptation where applicable, plus a reasonable margin.

There is an important official-statistics limit: data holders are not entitled to compensation where the public-interest task is the production of official statistics and national law does not allow the purchase of data. If the requester disagrees with the compensation level, it may complain to the competent authority in the Member State where the data holder is established.

The Data Act context is the starting point for this answer. Keep a request file that can show why the request was accepted, modified, declined, costed, or escalated. The file should include the original request, proof of receipt date, requester identity, legal task cited, exceptional-need analysis, alternative-means analysis, data-scope table, trade-secret markings, security measures, compensation calculation, response letters, delivery evidence, and any competent-authority correspondence.

Also keep evidence of the receiving body's stated use period, erasure expectation, expected sharing with other bodies or delegated third parties, and any later notice that the data was erased. For duplicate-request analysis, keep enough history to identify whether a similar same-purpose request has already been submitted and whether an erasure notice was received.

The Data Act context is the starting point for this answer. This FAQ does not cover the public-emergency route, where different timing and compensation rules apply and personal data may be requested if non-personal data is insufficient. It also does not cover criminal, administrative-offence, customs, or taxation requests, because Article 16 excludes those activities from this Chapter V mechanism.

If a request asks for personal data outside a public emergency, treats a routine reporting duty as an exceptional need, bypasses an existing sector-specific access regime, or seeks data from a microenterprise or small enterprise under Article 15(1)(b), do not force it into this workflow. Treat it as a separate legal and operational assessment.

For non-emergency public-sector requests, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For non-emergency public-sector requests, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For non-emergency public-sector requests, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For non-emergency public-sector requests, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

For non-emergency public-sector requests, the Data Act evidence should be concrete enough for a later reviewer to reconstruct why the team classified the product, service, request, or contract in scope.

For non-emergency public-sector requests, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

For non-emergency public-sector requests, the Data Act answer should be reviewed when the product, service model, dataset, customer role, public-sector request path, or contract wording changes.

For non-emergency public-sector requests, set a review date and an event trigger instead of relying on a one-time legal note.

The Data Act defines non-personal data as data other than personal data. That sounds simple, but it means the team must classify fields by substance, not by dataset label. A machine telemetry export, support log, vehicle dataset, or cloud export can contain both non-personal fields and fields that identify, relate to, or can be linked to a natural person.

For connected products and related services, the Data Act access analysis should start with raw and pre-processed data that is readily available to the data holder, plus metadata needed to interpret and use it. Inferred or derived information, highly enriched outputs, protected content, and material outside the connected-product or related-service boundary should be marked separately instead of silently included.

No. The Data Act complements EU data-protection and privacy law and must not be interpreted to diminish personal-data rights. When a mixed dataset contains personal data, GDPR, the EU institutions data-protection regulation, and ePrivacy rules continue to control the personal-data processing layer.

The Data Act also does not create a new legal basis for collecting or generating personal data. If the user requesting data is not the data subject, personal data generated by a connected product or related service may be made available to the user or a third party only where a valid GDPR legal basis exists and any relevant special-category or ePrivacy conditions are satisfied.

The Data Act context is the starting point for this answer. The main roles are user, data holder, third party, and data recipient. A user is the person or organisation that owns, rents, leases, or receives the related service for the connected product. A data holder is the person or organisation with the right or obligation to use and make data available. A third party can receive data at the user's request, and may also be a data recipient for business-to-business sharing rules.

Do not assign roles once for the whole company. The same organisation can be a user in one workflow, a data holder in another, and a data recipient in a supplier or aftermarket-service workflow. Role classification controls who can request data, who must make it available, who may use it, and who must preserve trade secrets or delete data when it is no longer needed.