Search every question across sub-FAQs

A data holder should keep the written request, the basis for accepting or challenging it, the response deadline, the data disclosed or withheld, and the safeguards applied to the transfer. The record should also show any cross-border notification and any competent-authority contact.

If the data holder relies on a refusal or a request for modification, it should record the reason and the relevant Article 18 ground. If the request is fulfilled, the record should include the purpose limitation, security measures, any trade-secret identification, and later erasure or onward-sharing notices.

For non-emergency requests, only non-personal data may be requested. For public-emergency requests, the request must concern non-personal data unless those data are demonstrably insufficient. If personal data are required, Article 17 requires the request to seek them in pseudonymised form and specify the safeguards; Article 18 requires the data holder to anonymise the data unless compliance requires disclosure of personal data, in which case the holder must pseudonymise them.

Where personal data is involved, the request must identify the technical and organisational safeguards needed to protect data-protection principles, and the relevant supervisory authority must be notified.

A data holder may decline or seek modification without undue delay, and in any event within five working days for data necessary to respond to a public emergency or within 30 working days for other exceptional-need requests.

The Data Act gives three listed grounds: the data holder does not control the requested data; a similar request for the same purpose was previously submitted by another eligible public body or EU institution and the data holder has not been notified that the earlier data was erased; or the request does not meet the Article 17 requirements.

Data received under Chapter V does not become open public-sector information for general reuse. It must be used only for the purpose stated in the request, protected with technical and organisational measures, and erased once no longer necessary for that stated purpose unless archiving is required under Union or national public-access law in the context of transparency obligations.

Trade secrets may be disclosed only to the extent strictly necessary for the Article 15 purpose. The data holder or trade-secret holder must identify the protected data, including relevant metadata, and the requesting body must take necessary and appropriate measures to preserve confidentiality before disclosure.

For a public-emergency request, data holders other than microenterprises and small enterprises must make the necessary data available free of charge, but may request public acknowledgement. Article 20(3) applies the Article 20(2) compensation rule when a microenterprise or small enterprise makes a claim, so the calculation covers the technical and organisational costs incurred to comply plus a reasonable margin. Those enterprises may also request public acknowledgement.

For non-emergency exceptional-need requests under Article 15(1)(b), the data holder is entitled to fair compensation covering technical and organisational costs, including anonymisation, pseudonymisation, aggregation, and technical adaptation where applicable, plus a reasonable margin. There is an exception where the task is official statistics and national law does not allow purchase of the data.

Keep enough evidence to show whether the request was valid, how the company responded, what data was made available or withheld, and which safeguards governed the data after transfer. Build the evidence file around the Article 17 request contents and the Article 18 response, not generic compliance notes.

A useful record includes the written request, requester identity, statutory task and legal provision, exceptional-need route, a public-emergency determination or declaration, or a non-emergency exhaustion analysis, data scope and metadata, personal-data analysis, trade-secret identification, timestamps, refusal or modification reasons, compensation calculation, delivery logs, onward-sharing notices, erasure notice, and competent-authority communications.

Keep one decision record that maps each incoming request to Articles 14 through 18. It should identify the requester, the legal-person data holder, the Article 15 route, the statutory public-interest task, the data and metadata requested, control over those data, purpose, duration, response deadline, and the reviewer who accepted, challenged, or modified the request.

Attach the public-emergency determination or declaration, or the non-emergency exhausted-means analysis, the cited legal provision assigning the task, any market-purchase evidence, and unresolved assumptions. That record lets a later reviewer distinguish a valid exceptional-need request from ordinary procurement, regulatory reporting, law enforcement, customs, or taxation access.

Assign one request owner with authority to control the five- or 30-working-day decline-or-modification clock and coordinate legal, privacy, security, data engineering, finance, and records teams. Give separate named owners the legal-validity review, data extraction, confidentiality controls, compensation calculation, and authority communications.

The requesting body retains responsibility for the Article 17 request, purpose limitation, security, onward-sharing notices, and erasure. The data holder should name internal owners who obtain and preserve the evidence needed to challenge a defective request or prove a compliant disclosure.

A usable file shows what happened after the legal classification. Preserve the signed or transmitted request, receipt timestamp, validation checklist, modification or refusal correspondence, disclosed dataset and metadata, transfer proof, safeguards, compensation workpaper, onward-sharing notices, and erasure confirmation.

Keep the actual version of each artifact, not only a policy template. For a cross-border request, include the notification to the competent authority in the data holder's Member State and the authority's examination outcome under Article 22.

Reassess the decision if the requester, statutory task, exceptional-need branch, requested data, availability of alternative means, data-holder control, personal-data content, trade-secret scope, intended recipients, or use period changes. A revised or repeated request needs its own Article 17 and Article 18 review.

Reopen the file when the public emergency ends, the stated purpose is completed, an onward transfer is proposed, erasure becomes due, a similar request arrives, or a competent authority challenges the request or response. Use both a review date and these event triggers.

Start by confirming that the supplier is providing a data processing service to a customer, such as cloud or edge services using configurable, scalable computing resources. The Commission FAQ explains that the Data Act concept covers common IaaS, PaaS, and SaaS delivery models when the service has the Article 2(8) characteristics.

Then ask whether the contract removes the obstacles listed in Article 23: termination after the permitted notice and successful switch, new contracts with another provider, porting exportable data and digital assets, functional equivalence where applicable, and technically feasible unbundling.

Article 25 requires the customer's switching rights and the provider's obligations to be set out clearly in a written contract that the customer can store and reproduce before signing. Exit language found only in a help-center article, commercial slide, or support policy outside the contract pack does not satisfy that contract-content requirement.

The contract should cover at least switching or porting on request, support for the customer's exit strategy, termination mechanics, a maximum notice period, exportable data categories, provider-internal data exemptions, a retrieval period, erasure after retrieval or an agreed later date, and any permitted switching charges.

For switching or porting, Article 25 requires reasonable assistance, due care to maintain business continuity, clear information on known continuity risks, and high security during transfer and retrieval. Ask for named support channels, technical documentation, migration tooling, continuity risk notices, and security controls during the switch.

Article 26 adds a separate information obligation: the provider must give switching and porting procedures, methods, formats, known restrictions, technical limitations, and a reference to an up-to-date online register for data structures, data formats, relevant standards, and open interoperability specifications.

For cloud switching procurement checklist, the Data Act record should identify the source clause, Commission guidance, affected service, decision owner, and the evidence used to approve the supplier's switching terms. Keep the contract pack, supplier redlines, export tests, fee schedule, and online-register snapshot together so the decision can be checked later.

Review the checklist again when the service architecture, supplier documentation, standards references, or renewal timetable changes. A later reviewer should be able to see what was agreed, why it was acceptable, and what would require a fresh review.

Under the Data Act, Article 29 phases out switching charges, including data egress fees, so that from 12 January 2027 providers cannot impose them, and in the interim period any charge must not exceed the provider's costs directly linked to the switching process concerned. Procurement should ask the supplier to confirm which date its contract reflects and how any interim charge is calculated.

A buyer should reject open-ended egress pricing and require the contract to state that switching charges fall away on the statutory date, so the cost of leaving is predictable rather than a lock-in lever.