Search every question across sub-FAQs

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.

Before conclusion of a purchase, rent, or lease contract for a connected product, Article 3(2) requires the seller, rentor, or lessor to give the user clear and comprehensible information. The disclosure must cover the type, format, and estimated volume of product data the connected product can generate.

The same pre-contract notice should also tell the user whether the product can generate data continuously and in real time, whether data can be stored on the device or on a remote server, the intended retention duration where applicable, and how the user may access, retrieve, or, where relevant, erase the data.

For a related service, Article 3(3) requires the prospective provider to disclose both product data it expects to obtain and related service data that will be generated. The notice must explain the nature, estimated volume, and, for product data, collection frequency, plus access or retrieval arrangements and storage or retention arrangements.

A related service disclosure also has to say whether the prospective data holder expects to use readily available data itself, the purposes of that use, and whether one or more third parties may use the data for purposes agreed with the user.

The Article 3 notice should focus on product data and related service data, not a broad inventory of every file associated with the product. Commission guidance describes Chapter II as covering raw and pre-processed data that are readily available to the data holder, including relevant metadata, while inferred or derived data and protected content can fall outside that Chapter II access scope.

For a useful pre-contract notice, translate internal labels such as telemetry, diagnostics, sensor logs, or app events into the Data Act categories that matter to the user: product data, related service data, readily available data, relevant metadata, and material that is not being offered because it is derived, inferred, content, or otherwise outside the access duty.

Article 3(1) requires connected products and related services to be designed so product data and related service data are easily, securely, and freely accessible to the user in a structured, commonly used, machine-readable format, and directly accessible where relevant and technically feasible.

The pre-contract information should therefore say whether access is direct, indirect, or split by data type. Commission FAQ material explains direct access as user access without asking the data holder to act, while indirect access means the user has to ask the data holder, for example through a portal or approval process.