Search every question across sub-FAQs

The Data Governance Act is mainly a governance framework for trusted data sharing. It covers reuse of certain protected data held by public sector bodies, rules for data intermediation services, and voluntary data altruism for objectives of general interest.

The Data Act is more direct about access and use. It gives users of connected products and related services access to data they generate, sets conditions for mandatory B2B data sharing, creates an exceptional-need route for public-sector requests to businesses, and regulates switching between data processing services such as cloud and edge services.

A useful routing question is: is the organisation asking how to make a trusted sharing mechanism available, or is someone asserting a Data Act access, sharing, request, contract, or switching right?

Data Act actor mapping usually starts with a user, data holder, data recipient, public sector body, or provider of data processing services. In connected-product cases, the user may be a consumer, business, or public sector body that owns, rents, leases, or receives a related service for the product.

Data Governance Act actor mapping is different. It focuses on public sector bodies holding protected data, potential reusers, data intermediation service providers, data holders and data users using those services, data altruism organisations, competent authorities, and registers.

The same organisation can appear in both maps. For example, a public authority may be a Data Act user of connected equipment in one workflow and a DGA public sector body making protected data available for reuse in another.

The Data Act often starts from a legally recognised access or sharing route. A connected-product user can access certain raw and pre-processed data that is readily available to the data holder and can ask for it to be shared with a third party of the user's choice, subject to the Data Act limits.

The Data Governance Act does not create that connected-product access route. Its mechanisms are trust and reuse infrastructure: protected public-sector data can be reused under safeguards where other law allows reuse, intermediaries can organise data sharing under neutrality rules, and altruism organisations can collect voluntary data contributions for general-interest objectives.

If a request asks for sensor or related-service data generated by use of a connected product, start with the Data Act. If it asks to reuse protected public-sector data, register or operate a neutral data intermediary, or structure voluntary data altruism, start with the DGA.

Under the Data Act, keep a short decision pack that shows why the team chose Data Act only, DGA only, or both. The pack should name the route, the trigger, the actors, the date, and the source URL used for the interpretation so a reviewer can recreate the decision later.

Assign one accountable owner who can change the affected workflow - usually legal, product, procurement, cloud, support, or security depending on the issue. Capture consulted teams separately so responsibility does not get blurred across functions.

Review the answer again when the product, service model, dataset, customer role, public-sector request path, or contract wording changes, or when a new source note or implementation issue creates a different boundary question.

A data intermediation service notified under the Data Governance Act still follows the DGA conditions for neutrality and separation. It can also provide the channel through which a connected-product user directs readily available data to a third party under the Data Act. The DGA governs the intermediation service; the Data Act governs the access and sharing right.

Keep the intermediary's role separate from the data holder's role. Operating the channel does not by itself make the intermediary the data holder, but the same group may carry both roles through different activities or entities.

Under the Data Act, a public sector body uses the Chapter V exceptional-need route to require a business to provide data it cannot get otherwise, mainly in emergencies or to fulfil a specific legal task. The Data Governance Act route is different: it governs how protected data the body already holds can be made available for reuse under safeguards.

Direction of flow controls the route. A Data Act exceptional-need request pulls data into the public body from a business, while the DGA reuse route makes the body's protected data available to a reuser.

Under the Data Act, a data space project can rely on DGA mechanisms for trusted intermediation and altruism while still being subject to Data Act access, use, and interoperability obligations where connected-product data or data processing services are involved. A mature data space often needs both regimes at once.

Teams should map each function of the project to the regime that governs it, so the interoperability and access duties from the Data Act are not assumed to be covered by the DGA governance layer alone.

Under the Data Act, trade secrets are preserved through identification and proportionate safeguards before a connected-product disclosure, whereas the Data Governance Act focuses on safeguards for categories of protected public-sector data such as confidential or commercially sensitive information held by a public body. The protected interests overlap but the mechanisms differ.

A team handling sensitive data should apply the Data Act safeguard analysis for product and B2B sharing and the DGA safeguard analysis for protected public-sector reuse, rather than reusing one set of controls for both.

Under the Data Act, a company that holds connected-product data has data-holder duties, and if it also runs a registered DGA data intermediation service it must keep that service neutral, which the DGA largely prevents from also commercialising the data it intermediates. The duties must be kept on separate sides of the business.

Use structural and contractual separation to keep the data-holder role from compromising the neutrality required of the DGA intermediation service.

Under the Data Act, Member States designate competent authorities to enforce its access, sharing, and cloud-switching rules, while the Data Governance Act has its own competent authorities for intermediation registration and data altruism oversight. A complaint should be routed to the authority for the regime that actually governs the issue.

Teams should record which authority oversees each workflow, because a Data Act access dispute and a DGA intermediation complaint can fall to different bodies even within the same Member State.

Under the Data Act, Article 32 guards against unlawful third-country government access to non-personal data held in the EU, while the Data Governance Act sets safeguards for international transfers of protected public-sector data and for intermediaries and altruism organisations. Both address cross-border risk but at different points in the data lifecycle.

A team moving non-personal data abroad should check the Data Act safeguard for data processing services and the DGA safeguard for protected public-sector data separately, since the triggers are not identical.

Under the Data Act, the boundary analysis should be repeated whenever the programme adds a connected-product data flow, a cloud switching dependency, an intermediation service, or a public-sector reuse element, because each can pull a new regime into scope. A change in actors or data categories is the usual trigger.

Teams should also re-run the analysis after new Commission guidance or a competent-authority decision, since either can shift where the Data Act ends and the DGA begins for a given workflow.

A request log should show the route from intake to outcome. For connected-product and related-service data, record whether the requester is the user, a party acting on the user's behalf, or a third party chosen by the user. The log should identify the product or related service, requested data and metadata, format, timing, delivery route, and any refusal, suspension, limitation, compensation, or dispute route.

Keep the log narrow. The Data Act allows data holders to verify user or third-party status, but it also says they should not require more information than necessary and should not keep access information beyond what is necessary for execution, security, and maintenance of the data infrastructure.

Trade secret handling needs its own evidence trail. The log should identify the data marked as trade secrets, the trade secret holder, the agreed technical and organisational measures, and whether the measures were accepted, not implemented, undermined, or still insufficient in exceptional circumstances.

A refusal or suspension should not be logged as a bare legal conclusion. The Data Act requires written substantiation for withholding, suspension, or case-by-case refusal based on serious economic damage, and notification to the competent authority in specified trade secret refusal scenarios.

For public-sector exceptional-need requests, keep the incoming written request and a structured review record. The record should show the requesting body, legal task, exceptional-need basis, specific data and metadata requested, purpose, intended use, deadline, erasure expectation, onward-sharing plan, and whether personal data, trade secrets, or cross-border procedure steps are involved.

The Data Act gives data holders short challenge windows for these requests. A holder may decline or seek modification no later than five working days after receiving a public-emergency request, and no later than 30 working days for other exceptional need requests, when the statutory grounds apply.