EU Data Act Implementation Checklist

Start with a role map because the Data Act applies to different actors in different chapters. A connected-product manufacturer, related-service provider, data holder, user, data recipient, cloud provider, public-sector requester, data-space participant, or smart-contract vendor will not have the same checklist items.

Record the EU nexus, product or service family, legal entity, accountable owner, reviewer, and escalation path for every workstream. Also record the product placement date, contract date and duration, and the date any underlying data-sharing obligation entered into force. Where a connected-product manufacturer or related-service provider is not established in the Union but makes the covered product or service available there, flag the Union legal-representative requirement in Article 37(11)-(13) for legal review.

For each product and related service, build a data inventory that distinguishes product data, related-service data, readily available data, relevant metadata, inferred or derived data, content, personal data, non-personal data, and trade-secret material.

The access design should cover the data that the product or related service can lawfully make available without disproportionate effort. Do not promise enriched analytics, proprietary algorithmic outputs, protected content, or cloud-hosted third-party data unless the source and contract support that position.

Product and related-service teams should treat user access as a disclosure and request-handling requirement, plus a design requirement for products and related services placed on the market after 12 September 2026. The checklist should require a tested route for users to access or retrieve data and a pre-contract information record that explains what the product or service can generate.

Where data cannot be directly accessed by the user, the data holder should provide the readily available data and relevant metadata in the required quality and format through a simple electronic request route where technically feasible.

The checklist should separate direct user access from data-holder delivery to a user-selected third party. Third-party sharing needs eligibility checks, purpose controls, trade-secret safeguards, personal-data checks, and recipient restrictions before the data is released.

A third party can use the data only for the purpose and conditions agreed with the user. The checklist should make prohibited uses visible, especially profiling beyond the requested service, onward sharing without the required contract and safeguards, sharing to Digital Markets Act gatekeepers, competing connected-product development, and use that harms product or service security.

The Data Act does not supersede GDPR, ePrivacy, or other privacy rules. If the user is not the data subject, personal data should not be released to the user or a third party unless a valid data-protection basis and any special-category or terminal-equipment conditions are satisfied.

Trade secrets and security restrictions should be handled as documented exceptions, not informal blockers. The checklist should require objective justification, written notice, competent-authority notification where required, and a route for users or third parties to challenge the decision.

B2G handling needs a dedicated intake process because public-sector, Commission, ECB, and Union-body requests must demonstrate an exceptional need and satisfy detailed request criteria. Treat each request as a legal, security, data, and operations matter.

The checklist should distinguish public emergency requests from non-emergency exceptional-need requests. It should also require controls for personal data, trade secrets, compensation, reuse limits, erasure, data-holder refusal or modification, and cross-border competent-authority routing.

Contract review should cover both mandatory B2B data-sharing arrangements and unilaterally imposed terms concerning data access, use, liability, remedies, and termination. The checklist should not treat a standard procurement template as sufficient without clause-level review.

For mandatory B2B sharing, terms should be fair, reasonable, non-discriminatory, and transparent. For unilaterally imposed terms, identify clauses that are always unfair, presumed unfair, or severable, and preserve evidence of negotiation attempts.

Cloud and edge providers should maintain a switching checklist for contracts, public information, technical export, business continuity, security, and customer support. Customers should use the same checklist to review source-provider and destination-provider obligations before signing or switching.

The workstream should cover exportable data and digital assets, service-type scope, functional equivalence where applicable, notice, transition, retrieval, erasure, switching charges, known technical limits, open interfaces, online registers, and third-country government access transparency for non-personal data.

If smart contracts automate all or part of a data-sharing agreement, the checklist should include the Data Act's essential requirements and conformity evidence. This is separate from ordinary API access, contract drafting, or workflow automation that does not deploy a smart contract for executing a data-sharing agreement.

Close each checklist item with evidence that can be reviewed later: source rule, product or service scope, decision, owner, reviewer, control, test result, contract clause, request log, refusal notice, notification, or remediation ticket.