EU Data Act Trade Secret Technical Protection Measures FAQ

Not as a blanket answer. Articles 4 and 5 preserve trade secrets, but they require the data holder or trade secret holder to identify the protected data and agree necessary, proportionate technical and organisational measures before disclosure. The Commission FAQ is explicit that a trade secret claim by itself is not enough to defeat Data Act access rights.

For implementation, treat trade secret protection as a scoped safeguard process: identify the exact data fields or metadata that reveal the secret, decide whether access is to the user or to a third party, and define the controls that preserve confidentiality while leaving the Data Act access route available.

The Data Act points to proportionate technical and organisational measures such as model contractual terms, confidentiality agreements, strict access protocols, technical standards, and codes of conduct. Article 11 also allows technical protection measures, including smart contracts and encryption, to prevent unauthorised access or disclosure and to support compliance with Articles 4, 5, 6, 8, and 9.

Useful measures are specific to the access path. Examples include field-level redaction, role-based access, secure API authentication, encryption at rest and in transit, read-only workspaces, recipient access logs, download limits, time-bound credentials, confidentiality undertakings, and controls on onward disclosure. The measure should preserve confidentiality without discriminating between recipients or hindering the user right to obtain, retrieve, use, or share data.

Under the Data Act, the record should show what data was requested, which parts were identified as trade secrets, which proportionate measures were agreed, who must implement them, and how the data was delivered. If the holder withholds or suspends sharing, it should also document the missing agreement, the unimplemented measure, or the confidentiality incident, plus the written reasons and authority notification required by Articles 4 and 5.

If the holder refuses access in exceptional circumstances, the file should also include the objective evidence supporting serious economic damage, the specific data refused, and why the agreed technical and organisational measures were still insufficient.

Under the Data Act, a data holder may withhold or suspend sharing only where the user or third party fails to implement the agreed technical and organisational measures, or where confidentiality is breached, and the holder must give written reasons and notify the competent authority. Withholding is the narrow exception, not the default response to a trade secret claim.

The decision should be tied to a concrete failure: a missing confidentiality agreement, an unimplemented control, or an actual breach. The holder must still keep the access route open once the safeguard is in place again, because suspension is meant to be temporary and proportionate to the risk.

Under the Data Act, a data holder may refuse a specific request only in exceptional circumstances, where it demonstrates with objective evidence that disclosure is highly likely to cause serious economic damage despite the agreed technical and organisational measures. Refusal must be assessed per request and supported by demonstrable, case-specific reasoning.

This is a high bar. A generic concern about competition or a broad assertion that all telemetry is sensitive will not meet it. The holder should show why the agreed safeguards were insufficient for that particular data and recipient, and keep the refusal scoped to the data that actually carries the risk.

Under the Data Act, technical protection measures applied under Article 11 must not be used to prevent a user from exercising the right to share readily available data with a third party, and must not discriminate between data recipients. The same controls that protect a trade secret in user access should carry through to the third-party path under Article 5.

When data goes to a third party, the confidentiality undertakings, access controls, and onward-disclosure limits should bind that recipient as well. The third party is also restricted by Article 6 from using the data to develop a competing connected product or to share it onward outside agreed terms.

Under the Data Act, trade secret protection is a separate question from personal data protection, and both can apply to the same export. The Regulation is without prejudice to the GDPR, so a confidentiality control that protects a secret does not remove the need for a valid legal basis when the same dataset contains personal data.

In practice, run the two analyses in parallel: identify the trade secret elements and the proportionate measures, and separately identify the personal data and the GDPR basis, minimisation, and recipient duties. Keep the two records distinct so each limit has its own justification.

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

Proportionality is easier to demonstrate when the control is matched to a named risk and a named data element. Field-level redaction, scoped credentials, and recipient confidentiality undertakings are usually more defensible than a blanket refusal to expose an entire interface.

Under the Data Act, the evidence file should let a later reviewer rebuild the decision: the Article 4, 5, or 11 basis relied on, the identified trade secret fields, the agreed measures, the delivery method, and any withholding, suspension, or refusal record. Each factual claim about scope or risk should map to a cited source.

The record should also capture the date of the decision, the assumptions made about the recipient, and the controls actually implemented, so the file remains auditable if the product, contract, or data flow later changes.

Under the Data Act, one accountable owner should be able to change the access design and the safeguard set, with security, legal, product, and data operations recorded as consulted teams. Spreading the decision across functions without a named owner is how confidentiality measures drift out of date.

The owner should be the person who can approve a new control, update the confidentiality terms, and trigger a fresh review when a product release, API change, or new recipient alters the risk picture.

Under the Data Act, the decision should be reviewed whenever the protected data, the access path, the recipient, or the safeguard set changes. A new firmware build, a new export field, a new third-party recipient, or a change in confidentiality terms can each move the risk and the proportionality balance.

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

Under the Data Act, the most common mistake is treating a trade secret label as an automatic block. The Regulation preserves trade secrets but still requires identified data, proportionate measures, and a usable access route, so a blanket unavailable response is not defensible.

Other frequent errors are refusing access without objective evidence of serious economic damage, applying measures that discriminate between recipients, and failing to send the written reasons and competent-authority notifications the Regulation requires.