EU Data Act Requirements by Workstream

Article 3(1) requires connected products and related services placed on the market after 12 September 2026 to make product data, related service data, and necessary metadata accessible by design. The format must be comprehensive, structured, commonly used, and machine-readable; access must be easy, secure, free to the user, and direct where relevant and technically feasible.

Article 4 is the separate request route where the user cannot access data directly. From the Data Act's general application on 12 September 2025, the data holder must make readily available data and necessary metadata accessible on request. Start the requirement record with what the product generates, what the related service generates, what is raw or pre-processed, what is inferred or derived, and what the holder can lawfully obtain without disproportionate effort beyond a simple operation.

Users can ask the data holder to make readily available data and necessary metadata available to a third party. The data holder cannot use transmission-arrangement disputes to block the user's Data Act sharing right, but the third party must use the data only for the agreed purpose and must erase it when it is no longer necessary unless the user agrees otherwise for non-personal data.

The requirement record should distinguish the user's access right from the third party's obligations. It should also flag gatekeeper restrictions, competing connected-product restrictions, profiling restrictions, trade-secret safeguards, and security limits.

When a data holder must make data available to a data recipient in a business-to-business setting, the arrangements must be fair, reasonable, non-discriminatory, and transparent. Compensation can be agreed, but the basis must be explainable; for SME and not-for-profit research recipients, compensation is limited to the costs of making the data available that are listed in the Data Act.

A usable requirement is therefore a contract-and-pricing control, not just a policy statement. The record should show comparable-recipient treatment, data scope, purpose, format, compensation basis, trade-secret measures, technical protection measures, and dispute path.

The Data Act makes certain unilaterally imposed B2B terms non-binding if they are unfair. Article 13 covers access to and use of data, liability, remedies, breach, and termination of data-related obligations. It excludes terms defining the main subject matter and the adequacy of the price against the data supplied in exchange.

Contract review should flag terms that grossly deviate from good commercial practice, contradict good faith and fair dealing, or match the listed unfair or presumed unfair examples. The output should identify who supplied the term, whether the other party could influence it, the affected data obligation, and the replacement position.

Chapter V is narrower than ordinary public-sector access. A public sector body, the Commission, the European Central Bank, or a Union body must demonstrate an exceptional need, limited in time and scope, to use certain data for a statutory public-interest task.

A public emergency request can include personal data only when the Data Act conditions and GDPR safeguards are met. For non-emergency exceptional need, the route is limited to non-personal data and depends on the public body showing that lack of specific data prevents a legally provided public-interest task and that other means have been exhausted.

Providers of data processing services must remove contractual, technical, commercial, organisational, and pre-commercial obstacles to switching to another provider, to on-premises ICT infrastructure, or to in-parallel use. Written contracts must set out switching rights and provider obligations before signature.

The switching requirement should be implemented through contract clauses, customer exit materials, exportable-data registers, support procedures, security controls, and charge controls. Providers also need public and contractual transparency about infrastructure jurisdiction and measures against unlawful third-country governmental access to non-personal data held in the Union.

Data-space participants that offer data or data services to other participants must describe dataset content, use restrictions, licences, collection methodology, quality, uncertainty, structures, formats, vocabularies, taxonomies, code lists, access means, API terms, and quality of service sufficiently for recipients to find, access, and use the data.

Smart contracts used to automate execution of data-sharing agreements have separate essential requirements: robustness and access control, safe termination and interruption, data archiving and continuity, governance-layer access control, and consistency with the data-sharing agreement. The vendor, or the professional deployer if there is no vendor, must perform a conformity assessment and issue an EU declaration of conformity when the requirements are fulfilled.

The Data Act does not supersede the GDPR. Where personal data is processed in a Data Act workflow, GDPR rules apply and prevail in a conflict. The requirement record should identify whether the dataset is personal, non-personal, or mixed before an access, sharing, B2G, cloud, or interoperability control is marked complete.

If the user is not the data subject whose personal data is requested, the data holder may make the personal data available only where a valid GDPR legal basis exists and any relevant special-category and ePrivacy conditions are met. For B2G requests, the request must specify personal-data safeguards such as pseudonymisation and whether anonymisation can be applied before disclosure.

The Data Act gives competent authorities complaint-handling, investigation, cooperation, information-request, and penalty powers. Records should therefore show not only that a requirement exists, but that the company can explain the rule, scope, actor, decision, control, and evidence if a user, third party, public body, customer, or authority challenges it.

Avoid one broad Data Act sign-off. The useful artifact is a requirements register with separate rows for connected-product access, related-service access, third-party sharing, B2B terms, unfair terms, B2G requests, cloud switching, international access, interoperability, smart contracts, personal-data boundaries, and unresolved exceptions.