EU Data Act Trade Secret Safeguards FAQ

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, should 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.

Under the Data Act, a user or third party that disputes a withholding, suspension, or refusal can take the matter to a competent authority, use the dispute settlement procedure, or seek a judicial remedy, which is why the holder must give written reasons and notify the authority. The safeguard decision has to stand up to that review.

Because the recipient can challenge the decision, the holder should keep the identification list, the agreed measures, and the evidence together so the reasoning can be reconstructed if the decision is questioned.

Under the Data Act, the safeguard package should be reviewed whenever the protected data, the access path, the recipient, or the available controls change, because each can shift the proportionality balance. A new firmware build, a new export field, or a new third-party recipient can each move the risk picture.

Reviews should also be triggered by a confidentiality incident, a complaint, or a dispute settlement outcome, since each can change what counts as a necessary and proportionate measure for that data.