Search every question across sub-FAQs

The Data Act context is the starting point for this answer. 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.

Under the Data Act, a registered data intermediation service still follows the DGA neutrality rules, but it can also be the practical channel through which a connected-product user exercises a Data Act sharing right, since the user may direct readily available data to a third party. The two regimes stack rather than replace each other in that scenario.

The intermediary should keep its DGA neutrality obligations distinct from any Data Act sharing facilitation, so a single service does not blur the line between organising sharing and being a data holder.

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.

The deciding question is direction of flow: a Data Act exceptional-need request pulls data into the public body from a business, while the DGA reuse route pushes the body's own protected data out 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.

The practical safeguard is a structural and contractual separation so the data-holder role does not contaminate the neutrality the DGA requires of the 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.

No. Article 1(5) is the boundary rule: the Data Act complements EU data-protection and privacy law, and GDPR rules prevail where personal-data protection conflicts with a Data Act access or sharing step. The Data Act is therefore not a shortcut around GDPR purpose limitation, lawful basis, special-category conditions, transparency, minimisation, security, or data-subject rights.

The practical consequence is that a Data Act request should be split into at least two questions: what product or related-service data is in Data Act scope, and what GDPR condition allows the personal-data part to be processed or disclosed. Non-personal data can often proceed under the Data Act while personal data is limited, separated, anonymised, or routed through a GDPR process.

Start with the Data Act scope, then classify the dataset. Chapter II covers raw and pre-processed data generated by the use of a connected product or related service that is readily available to the data holder, including relevant metadata. Commission material explains that this can include personal and non-personal data, and that co-generated IoT data may be difficult to separate.

A mixed dataset should not be treated as all-disclosable or all-blocked. Separate fields, records, time ranges, identifiers, and metadata where possible. Deliver non-personal data and personal data that can be lawfully provided; anonymise, pseudonymise, aggregate, redact, or withhold the rest when GDPR conditions are not met.

When the user is the data subject for the requested personal data, the Data Act access or porting request resembles GDPR access and portability in an IoT setting. The Data Act can complement GDPR Articles 15 and 20 by covering connected-product and related-service data and, where relevant and technically feasible, real-time access or portability.

That still does not remove GDPR controls. The data holder should verify identity, scope the request to data concerning the requester, protect other data subjects, and use a format that supports Data Act access while remaining consistent with GDPR transparency and security duties.

This is the highest-risk overlap. Recital 7 and the Commission FAQ make clear that the Data Act does not create a GDPR lawful basis for disclosing personal data to a user who is not the data subject or to a third party chosen by that user. The controller must identify an Article 6 GDPR basis or provide data in a form that no longer identifies the data subject.

Common examples include an employer requesting connected-equipment data that includes worker data, a fleet owner requesting vehicle data about drivers, or a buyer of a used connected product requesting historical data about the previous user. In those cases, the answer may be partial delivery, anonymisation, disclosure only of the requester-related data, or refusal of the personal-data portion.

Data Act roles and GDPR roles are separate labels. A data holder is typically the connected-product manufacturer or related-service provider that can make readily available data available. A processor under GDPR is not considered a data holder merely because it processes data for a controller, although a controller can task a processor with making data available.

For GDPR purposes, the Commission FAQ explains that personal data may be requested by a controller or by the data subject. Where a business user is not the data subject and is not in a shared-household situation, it should be treated as a controller for the requested personal data and must meet its own GDPR obligations.

The Data Act context is the starting point for this answer. For controller-to-controller sharing, each controller must be able to demonstrate GDPR compliance. The Commission FAQ says controllers should cooperate by sharing strictly necessary information so each can demonstrate compliance. That does not mean the data holder should collect excessive privacy paperwork, but it should not transmit personal data blindly.

A practical request form should ask whether the requester is the data subject, whether another lawful basis is relied on, whether special-category data may be present, whether other data subjects appear in the file, and which third party will receive the data. The data holder can then decide whether to deliver, narrow, anonymise, pseudonymise, or refuse the personal-data element.

Data-subject rights do not disappear because a request is framed as a Data Act request. Data subjects can still use GDPR access, portability, information, objection, restriction, and complaint routes where applicable. The Data Act can add an IoT-specific access or sharing route, but the personal-data part remains supervised through data-protection authorities.

Commission FAQ guidance says data subjects should not need to go to two authorities when access and porting rights overlap under the Data Act and GDPR. For operational teams, that means complaint handling should route privacy issues to the privacy function or DPO while preserving the Data Act request file.

Trade secrets and GDPR are different protections. The Data Act does not remove trade-secret protection, and it allows confidentiality safeguards before disclosure. If agreed safeguards are missing or not implemented, sharing trade-secret-protected data can be withheld or suspended. In exceptional cases, refusal may be possible where disclosure is highly likely to cause serious economic damage.

Do not use a trade-secret label to hide a weak GDPR analysis, and do not use GDPR as a blanket reason to suppress non-personal data. The review should identify the affected fields, the protected interest, the safeguard proposed, and what data remains available after applying privacy, trade-secret, and security controls.