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 obligation in Article 3(1) for connected products and related services applies to products and related services placed on the market after 12 September 2026. Cloud switching charges are subject to the phase-out rules, with no switching charges from 12 January 2027.

For connected products and related services, the program needs a product-by-product data access model. The key question is not whether the organization has data in general; it is whether product data or related service data is readily available to a data holder and must be made accessible to the user or to a third party chosen by the user.

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, lease, or related service contracting, users need clear information about what data the product or service will generate and how it can be accessed, retrieved, used, and shared.

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.