EU Data Act Compliance Program

The Data Act applies across several different operating areas, so a useful program begins with a scope register rather than a single policy. Record whether the organization makes connected products available in the Union, provides related services, acts as a data holder, receives data as a data recipient, provides data processing services, receives public-sector requests, participates in data spaces, or deploys smart contracts for data-sharing agreements.

Keep application dates separate from control ownership. The Data Act applies from 12 September 2025. The Article 3(1) accessible-by-design obligation applies only to connected products and related services placed on the market after 12 September 2026; the Article 4 and Article 5 request routes are separate. Chapter IV applies to contracts concluded after 12 September 2025 and, from 12 September 2027, to specified older indefinite or long-running contracts. No switching charges may be imposed from 12 January 2027.

For connected products and related services, the program needs a product-by-product data access model. The key question is whether readily available data includes the relevant product data or related service data and must be made accessible to the user or to a third party chosen by the user. Keep this Article 4 and Article 5 request model separate from the Article 3(1) design duty for products and related services placed on the market after 12 September 2026.

The access workstream should distinguish raw and pre-processed data from inferred or derived data, include relevant metadata needed to make data usable, and define the technical channel for direct user access or indirect access through the data holder.

A Data Act program should connect pre-contractual product information, user contracts, and operational access controls. Before sale, rent, or lease, users need clear information about the product data the connected product can generate and how they can access, retrieve, or, where relevant, erase it. Before a related-service contract, users need the separate Article 3(3) information on expected product and related-service data, access and storage, intended use and sharing, relevant parties, complaints, trade secrets, and contract duration and termination.

Data holders also need a contract with the user to use readily available non-personal data generated by the connected product or related service. Existing contracts should be checked for whether they identify the data holder, describe data use, preserve user rights, and support the access workflow that support and engineering will operate.

The contract workstream should cover both mandatory data-sharing terms and the unfairness control for business-to-business data clauses. Chapter III addresses situations where a data holder is legally obliged to make data available to a data recipient, including Data Act sharing. Chapter IV targets unilaterally imposed terms on data access, use, liability, remedies, breach, or termination that grossly deviate from good commercial practice.

For implementation, procurement and legal teams should not only update templates. They should identify where data-sharing clauses already sit inside product sales, logistics, financing, advertising, management, cloud, or other commercial contracts, then decide whether the data clauses are negotiable, fair, reasonable, non-discriminatory, and separable from unrelated commercial terms.

Business-to-government requests need their own intake route because they are not ordinary customer data requests. Chapter V allows public sector bodies, the Commission, the European Central Bank, and Union bodies to request data from data holders where there is an exceptional need, including public emergencies and certain non-emergency public-interest tasks.

The program should require every B2G request to be logged, validated, scoped, reviewed for personal data and trade secrets, and answered through an approved owner. In emergencies, non-personal data is the starting point; personal data should be requested only where non-personal data is insufficient and, where possible, should be anonymised or pseudonymised.

Providers and buyers of data processing services should treat cloud switching as a contract, technical, support, and evidence workstream. Chapter VI covers providers of data processing services, including cloud and edge services, and requires removal of contractual, technical, commercial, organisational, and pre-commercial obstacles to switching, porting exportable data and digital assets, and using several providers at the same time.

For providers, the program should map every covered service to written switching terms, exit support, export formats, interfaces, security controls, continuity steps, and support responsibilities. For customers, procurement should capture the same items during vendor onboarding and renewal.

Smart-contract obligations apply where an application uses smart contracts to execute a data-sharing agreement, or part of one, to make data available. The program should therefore identify which products, data spaces, APIs, marketplaces, or contract automation tools use smart contracts for data-sharing execution, then put those releases through engineering, security, legal, and records review.

Article 36 focuses on the smart contract program itself, not the legal agreement as such. Controls should cover robustness, access control, safe termination or interruption, archiving, continuity, consistency with the data-sharing agreement, conformity assessment, and the EU declaration of conformity.

The Data Act does not supersede GDPR analysis. Personal data processing under the Data Act still needs a valid GDPR basis, and the GDPR prevails where there is a conflict on personal-data protection. This matters because connected-product data may combine personal and non-personal data, and a user requesting data may not always be the data subject.

Privacy review should sit inside the access, third-party sharing, B2G, cloud, and evidence workstreams rather than at the end. The reviewer should decide whether data is personal, whether the requester is the data subject, whether anonymisation or pseudonymisation is required, whether special-category or terminal-equipment rules are implicated, and which authority or complaint route applies.

Evidence should be designed around operational events: access requests, third-party sharing, contract approvals, B2G requests, cloud switching, smart-contract releases, GDPR decisions, complaints, refusals, and guidance updates. A reviewer should be able to move from a Data Act obligation to a named owner, implemented control, system record, contract clause, request log, and closure decision.

The records model should also show which sources were used. Binding law, Commission explainers, Commission FAQs, model terms, standards, and helpdesk replies do not all carry the same weight, so the source type and date should be visible in the record.

The enforcement path should be part of the control design. Member State competent authorities handle the tasks assigned under Article 37, affected parties may lodge complaints and seek judicial remedies, and national penalties must be effective, proportionate, and dissuasive. For personal-data infringements within Chapters II, III, and V, data-protection authorities may use GDPR fine powers within their competence. The applicable authority and penalty still depend on the Member State, chapter, and facts.