EU Data Act Non-Emergency Public-Sector Requests FAQ

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.