EU Data Act Non-Emergency Public-Sector Requests FAQ

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. Mitigation of or recovery from a public emergency and production of official statistics are examples in Article 15(1)(b), but the legal and exhaustion tests still apply.

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 request must be written in clear, concise, plain language and must specify the data required, including metadata needed to interpret and use them. 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.

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 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.

Yes. For an Article 15(1)(b) request, Article 20 entitles the data holder to fair compensation covering the technical and organisational costs of compliance, including anonymisation, pseudonymisation, aggregation, and technical adaptation where applicable, plus a reasonable margin. The requester may ask for the basis of the calculation and may challenge the amount before the competent authority.

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.

Keep a request file showing why the request was accepted, modified, declined, costed, or escalated. Include the original request, receipt date, requester identity, cited legal task, exceptional-need and alternative-means analyses, data-scope table, trade-secret markings, security measures, compensation calculation, response letters, delivery evidence, and 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.

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 are insufficient. It also does not cover criminal, administrative-offence, customs, or taxation requests, because Article 16 excludes those activities from Chapter V.

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), it does not fit this workflow. Assess the applicable reporting, sector, enforcement, or other legal route separately.

Keep an article-level source map for the decision: Article 15 for the exceptional-need test, Article 17 for request contents and proportionality, Article 18 for the 30-working-day response and permitted objections, Article 19 for use and confidentiality controls, and Article 20 for compensation. Record the version or access date of any Commission guidance separately because guidance explains the binding text but does not replace it.

Tie each source to a fact in the request file: requester and legal task, enterprise-size check, data-control finding, non-personal-data classification, alternatives exhausted, requested granularity and frequency, trade-secret measures, compensation basis, response date, and final outcome. Record any unresolved factual assumption instead of presenting it as settled law.

Assign one request coordinator when the request arrives. That person logs receipt, calculates the 30-working-day outside limit, checks that the request identifies its own delivery deadline, and keeps correspondence together. Legal should decide whether Articles 15 and 17 are satisfied; the system or data owner should confirm control, retention, format, and extraction effort; privacy should confirm that the dataset is non-personal; security and the trade-secret holder should set protective measures; and finance should document any Article 20 compensation.

The final response needs one named approver with authority to accept, seek modification, decline, or escalate the request. The coordinator should keep ownership through delivery, compensation, competent-authority review, and receipt of any erasure notice rather than ending the workflow when the first response is sent.

A later reviewer should be able to reproduce the decision from the original written request, proof of receipt, the Article 17 completeness checklist, evidence that alternative means were exhausted, the data-control and non-personal-data analyses, the scope table, and the dated response. If the request changed, preserve both versions and show which change resolved each objection.

For an accepted request, retain the delivery manifest, fields and metadata supplied, export format, transfer log, confidentiality measures, compensation calculation, authorised recipients, and any erasure or onward-sharing notice. For a modified or declined request, retain the exact Article 18 ground, supporting evidence, requester correspondence, competent-authority referral, and final resolution.

Reassess an open decision when the requester narrows or expands the data, purpose, duration, frequency, recipient list, or delivery deadline; when the holder gains or loses control of the requested data; or when personal data enters the dataset. A later similar request also requires a fresh duplicate-request check against any erasure notice.

Review the standing workflow when enterprise status changes, a competent authority resolves a dispute, the Commission updates Chapter V guidance, or the Union or national law supporting the public-interest task changes. Keep a calendar review, but use those events as immediate triggers because they can change the route, deadline, scope, or available objection.