EU Data Act Public Emergency Requests FAQ

A public-emergency request is one branch of the Data Act's exceptional-need mechanism. It applies where the requested data are necessary to respond to a public emergency and the requester cannot obtain them by alternative means in a timely and effective way under equivalent conditions. The Chapter V rules have applied since 12 September 2025.

This is narrower than a general public-interest request. The Commission's Data Act explainer gives examples of public emergencies such as major natural or human-induced disasters, pandemics, and cybersecurity incidents, and says the existence of a public emergency is determined under national or EU procedures or laws.

Article 17 requires a written request in clear, concise, plain language. It must specify the data and relevant metadata, purpose, intended use, duration, requester authority, delivery deadline, and deadline for the data holder to decline or seek modification.

The request must justify why the chosen data holder is being asked, identify any other public bodies or third parties expected to receive the data, and commit to avoiding liability for the data holder where possible. If personal data are requested, the request must specify protection measures and whether the data holder can anonymise the data before disclosure.

A data holder that receives a valid Chapter V request must make the data available without undue delay, taking account of necessary technical, organisational, and legal measures. If the holder declines or seeks modification of a public-emergency request, Article 18 requires it to do so without undue delay and no later than five working days after receipt.

The five-working-day period is not a deadline for every operational task in the company. It is the outer limit for declining or seeking modification of a request for data necessary to respond to a public emergency. Internal intake should therefore identify the request date, the requester, the claimed emergency, the requested data, and any Article 17 defects immediately.

Article 18 gives three grounds: the data holder does not control the requested data, a similar request for the same purpose has already been submitted by another eligible body and erasure has not been notified, or the request does not meet the Article 17 content and form conditions.

Use those grounds precisely. A data holder should not refuse simply because the request is inconvenient, commercially sensitive, or urgent. But it should seek modification where the request is overbroad, lacks the required legal or factual justification, asks for data outside the holder's control, or duplicates an unresolved prior request.

Yes, but the Data Act starts from non-personal data. Article 17 requires requests to concern non-personal data, and personal data may be requested only if non-personal data are shown to be insufficient for the exceptional need and the request establishes the necessary technical and organisational protection measures.

Article 18 adds a data holder duty: where requested data include personal data, the data holder must properly anonymise the data unless compliance requires disclosure of personal data; in that case the data holder must pseudonymise the data.

A public emergency does not erase confidentiality duties. Article 17 requires requests to respect the data holder's legitimate aims, including trade-secret protection and the cost and effort needed to make data available. Article 19 requires disclosure of trade secrets only to the extent strictly necessary for the Article 15 purpose.

Before trade secrets are disclosed, the data holder or trade secret holder must identify the protected data, including in metadata. The receiving public body or EU body must take necessary and appropriate technical and organisational measures to preserve confidentiality and is responsible for the security of the data it receives.

For data necessary to respond to a public emergency under Article 15(1)(a), data holders other than microenterprises and small enterprises must make the data available free of charge. They may request public acknowledgement from the recipient.

A microenterprise or small enterprise may claim fair compensation under Article 20(3). The calculation follows Article 20(2): technical and organisational compliance costs, including applicable anonymisation, pseudonymisation, aggregation, and technical adaptation costs, plus a reasonable margin. This is different from the non-emergency obligation, from which microenterprises and small enterprises are exempt under Article 15(2).

Data obtained under Chapter V do not become open public-sector information. Article 17 bars making them available for reuse under the Data Governance Act or Open Data Directive definitions. Article 19 also bars use incompatible with the request purpose.

Sharing is allowed only within the controlled routes in the Data Act. Article 17 allows exchange with other public bodies or named third parties for the Article 15 task when specified in the request, and Article 21 allows sharing with qualifying research or statistical bodies under conditions. The data holder must be notified without undue delay for Article 21 transfers.

Keep enough evidence to show that the request was assessed under the correct Chapter V branch and handled within the required time. Include the written request, receipt timestamp, requester identity, asserted emergency, Article 15 analysis, Article 17 completeness check, data-control analysis, scope, personal-data and trade-secret treatment, delivery record, and any refusal or modification notice.

Also keep records that prove what happened after delivery: public acknowledgement request, compensation position if relevant, recipients identified in the request, confidentiality and security measures, erasure notice from the public body, and any notice of Article 21 sharing with research or statistical bodies.

Keep the legal basis and the implementation evidence together. For a Chapter V public emergency workflow, the most useful sources are the Data Act itself, the Commission explainer, and any internal note showing why the request met Article 15 and Article 17. Link those sources to the final decision so a reviewer can see whether the request was accepted, modified, or declined.

The record should also show whether the team used the five-working-day refusal window, whether personal data were anonymised or pseudonymised, and whether any trade secret or confidentiality measures were agreed before disclosure.

Assign one accountable owner for the Data Act legal assessment and one for the operational response, then keep the rest of the stakeholders as consulted teams. The legal owner should assess Article 15, Article 17, Article 18, and Article 19 issues; the operational owner should coordinate data extraction, security controls, delivery, and recordkeeping.

If the request is cross-border or involves personal data, the ownership file should also show who is responsible for notifying the competent authority or supervisory authority and who tracks the response deadline.

Data Act evidence should show the full chain from request to response. The most useful artifacts are the written request, the Article 17 completeness check, the decision memo on Article 15 exceptional need, the refusal or modification notice if any, the delivery log, and the notices sent to the competent authority or other authorities.

Teams should also keep any data inventory, redaction or anonymisation notes, trade secret protection measures, compensation note, and erasure or onward-sharing notices so that a later reviewer can reconstruct how the request was handled.