Search every question across sub-FAQs

The Data Act does not supersede GDPR. It complements Union data-protection and privacy law and does not create a new legal basis for providing access to personal data where the user is not the data subject. If personal data generated by a connected product or related service is to be made available to a third party and the user is not the data subject, the data holder needs a valid Article 6 GDPR legal basis and, where relevant, conditions for special-category data and ePrivacy terminal-equipment rules.

Where data contains several people's personal data, teams should separate, anonymise, pseudonymise, or otherwise control delivery as needed. The Commission FAQ also warns that privacy-enhancing technologies should not be used simply to circumvent Data Act sharing obligations where data remains readily available.

Article 5 says the data must be made available to the third party free of charge to the user. Separately, Article 9 allows reasonable and non-discriminatory compensation agreed between a data holder and a data recipient in business-to-business relations, and says compensation may include a margin.

There is a special cap for SME data recipients and not-for-profit research organisations that do not have linked or partner enterprises outside the SME category: compensation must not exceed the costs incurred for making the data available. The data holder must provide enough detail on the calculation basis for the data recipient to assess whether Article 9 requirements are met.

Use a simple sequence: first confirm the request comes from the user or someone acting on the user's behalf, then confirm the recipient is eligible, then check the data scope and any GDPR issues. If the request is valid, make the data available without undue delay and in the required format. If trade secrets or security concerns apply, use the Article 5 or Article 4 safeguards, and if the issue cannot be resolved, withhold, suspend, or refuse only within the conditions in the Data Act.

A good implementation workflow also records the request, the data categories shared, the legal checks performed, the confidentiality measures agreed, the delivery date, and any authority notification or dispute route used.

Keep a request record that shows the user authority, recipient identity and eligibility, requested data categories, personal-data assessment, trade-secret and security assessment, recipient purpose, delivery route, delivery format, compensation position if any, and final outcome. These records should be enough to explain why data was shared, limited, suspended, withheld, or refused.

For recipient misuse, Article 11 supports remedies such as erasure of data and copies, ending production or use of goods or services produced from unlawfully used data where the legal test is met, informing the user of unauthorised use or disclosure, and compensation for misuse or disclosure of unlawfully accessed or used data.

Assign one accountable owner for the Data Act request workflow, with clear support from legal, privacy, security, product, and operations as needed. The owner should be the person who can actually change the affected process and decide whether the request is fulfilled, limited, suspended, or refused.

Keep consulted teams and evidence dependencies separate from the accountable owner so the process stays traceable without creating overlapping ownership.

Yes. The Data Act says trade secrets must be preserved when product data or related-service data is disclosed to a user or to a third party chosen by the user. The data holder, or the trade secret holder if different, must identify the protected data before disclosure, including in relevant metadata where needed.

That protection is not a general veto. The Commission FAQ explains that a data holder can decide which data it considers trade secrets, but that claim is not enough by itself to prevent Data Act access rights from being exercised.

Before disclosure to a user, the data holder and user must take necessary measures to preserve confidentiality, especially where third parties may later be involved. The Data Act gives examples: model contractual terms, confidentiality agreements, strict access protocols, technical standards, and codes of conduct.

The safeguard should match the actual risk. For example, a limited export file, named-user access, encryption, logging, recipient training, onward-sharing limits, or secure API controls may be relevant when they preserve confidentiality without making access unnecessarily difficult.

Keep a short decision record that ties the request to the specific Data Act article, the trade-secret holder, the agreed safeguard package, and the person who approved the decision. That record should also show the request date, the data category, and whether the outcome was disclosure, withholding, suspension, or refusal.

For later review, save the source URL, the notice sent to the user or third party, the written reasons, and any authority notification together with the supporting evidence. A clear record makes it easier to show that the safeguard was proportionate and limited to the data actually at issue.

The main mistake is treating trade-secret status as a broad reason to block or delay a Data Act request. The safer operational approach is to identify the specific trade-secret data, agree proportionate safeguards, share the remaining data where possible, and reserve withholding, suspension, or refusal for the limited conditions in the Data Act.

A second mistake is using confidentiality language that the product, support, security, or partner team cannot actually implement. A safeguard that exists only in contract text will not support a withholding, suspension, or refusal decision if the practical controls and evidence are missing.

The Data Act expects identification before disclosure rather than a vague claim afterwards, so the holder, or the trade-secret holder where they differ, should map the precise fields, calculated values, calibration parameters, or metadata that reveal the secret. Identification at this granularity is what later justifies a proportionate safeguard rather than a broad refusal.

A practical approach is to classify the dataset element by element, marking each field as shareable, shareable with a control, or genuinely secret, so the access route stays open for everything that is not actually confidential.

Under the Data Act, suspension is available where a user or third party fails to implement the agreed confidentiality measures or breaches them, and it must be accompanied by written reasons to the recipient and a notification to the competent authority. It is a temporary, breach-driven response rather than a way to reverse the access right.

The holder should tie the suspension to a concrete failure and reopen sharing once the agreed measure is implemented again, keeping the suspension proportionate to the confidentiality risk that triggered it.

Under the Data Act, a data holder may refuse a specific request only in exceptional circumstances and only where it demonstrates with objective evidence that disclosure is highly likely to cause serious economic damage despite the agreed measures. The assessment is per request, not a standing policy across all telemetry.

A defensible refusal points to the particular data, the recipient, and the reason the agreed safeguards were insufficient, rather than a general worry about competition or a blanket label over an entire interface.

Under the Data Act, when a user directs sharing to a third party under Article 5, the confidentiality undertakings, access controls, and onward-disclosure limits should bind that recipient too, and Article 6 restricts the third party from using the data to build a competing connected product. Safeguards agreed for user access should carry through to the third-party path.

The agreement with the third party should state the permitted purpose, the confidentiality duties, and the onward-sharing limits in writing, so the protection does not stop at the first recipient.

Under the Data Act, technical and organisational measures must be necessary and proportionate, so the right safeguard is the least restrictive control that still protects the identified secret. A measure that blocks the whole access route, or is far broader than the risk, can itself breach the prohibition on hindering Data Act rights.

Matching a control to a named risk and a named field makes proportionality easier to defend than a blanket refusal, and it keeps the access right usable for the rest of the dataset.

Under the Data Act, trade-secret protection is a separate question from personal data protection, and the Regulation is without prejudice to the GDPR, so a confidentiality control that shields a secret does not remove the need for a valid legal basis where the same dataset includes personal data. Both analyses can apply to one export.

Run the two assessments in parallel: identify the secret elements and proportionate measures, and separately identify the personal data, the GDPR basis, and minimisation, keeping the records distinct so neither limit is over-applied.