Search every question across sub-FAQs

A useful classification record should be narrow: product or service name, data field, generation source, whether the field is product data or related service data, whether it is readily available, the metadata needed to interpret it, the enrichment level, and the reason for any exclusion. For personal data, trade secrets, or security-sensitive data, classification should be paired with the relevant safeguards rather than used as a reason to ignore the Data Act category.

The record should also support Article 3 pre-contractual transparency about type, format, estimated volume, generation frequency, storage or retention, access and retrieval, the data holder, third-party sharing, and the trade-secret holder where relevant. The Article 3(1) duty to design for direct access where relevant and technically feasible applies to connected products and related services placed on the market after 12 September 2026.

Map each classification to the legal source that controls it: Article 2 for the defined categories, Recitals 15 to 17 for raw, pre-processed, inferred, content, and related-service boundaries, Articles 3 to 5 for disclosure and access, and the current Commission FAQ for implementation examples. Record the guidance version and access date because the regulation is binding while the FAQ is explanatory.

Keep the source beside the actual field decision, not only in a page-level bibliography. The record should identify the connected product, related service if any, field name, generation event, retrievability by design, processing step, availability, necessary metadata, classification, exclusion or safeguard, reviewer, decision date, and unresolved assumption.

Product and engineering should own the factual inventory: what the connected product generates, what the manufacturer designed to be retrievable, which service affects product functions, how each field is processed, and whether the data holder can obtain it by a simple operation. Legal should approve the Data Act category and access consequence, while privacy, security, and the trade-secret holder approve only the safeguards within their remit.

Name one classification owner for each product and related service and one operational owner for the access route. Procurement or partner management should obtain missing facts from third-party service providers, and support should use the approved inventory when answering users instead of inventing categories during request handling.

A reviewer should be able to trace a field from generation to delivery. Keep a sample record or schema, the sensor or service event that creates it, each pre-processing step, the metadata needed to interpret it, where it is stored or transmitted, the extraction method, a sample export, and the internal or user-facing name. For an inferred or derived exclusion, identify the additional investment, algorithmic step, or enrichment that creates the separate output.

The delivery evidence should show the user and data holder roles, request or direct-access route, format and quality supplied, timing, excluded fields, and any GDPR, trade-secret, or security measure. This separates the category decision from a later safeguard decision and lets the team reproduce the same answer for the same product version.

Reclassify affected fields after a hardware, sensor, firmware, app, API, or data-model change; when a digital service starts or stops affecting a product function; when a new preprocessing or proprietary algorithm changes a raw field into an enriched output; or when storage, transmission, retention, or lawful access changes. A new user, data holder, or recipient role can also change the access analysis even when the field itself is unchanged.

Review the delivery consequence when direct access, export format, metadata, contract use, personal-data basis, trade-secret measure, or security requirement changes. Connected products and related services placed on the market after 12 September 2026 also need the separate Article 3(1) design-duty check, so release review should identify which market-placement date applies.

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.