Search every question across sub-FAQs

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.

No. The grounding sources support common European data spaces as EU-backed infrastructure and governance initiatives, not as a general Data Act duty for every company to join. The Data Act creates obligations for specific actors and fact patterns, including connected-product data access, B2B data sharing, public-sector exceptional-need requests, cloud switching, interoperability, and smart contracts.

For data spaces, the relevant Data Act trigger is usually narrower: Article 33 applies to participants in data spaces that offer data or data services to other participants. Participation can still be commercially or sectorally important, but do not describe it as mandatory unless a separate sector rule, procurement condition, contract, or programme requirement says so.

The most direct Data Act obligation is Article 33 on interoperability of data, data-sharing mechanisms and services, and common European data spaces. It requires relevant data-space participants to describe dataset content, use restrictions, licences, collection methodology, data quality, uncertainty, data structures, formats, vocabularies, classification schemes, taxonomies, code lists, access methods, terms of use, quality of service, and, where applicable, tools such as smart contracts.

Those duties are not generic documentation advice. They are meant to make data discoverable, accessible, usable, and technically interoperable across data-sharing arrangements.

The Data Act context is the starting point for this answer. The Commission describes common European data spaces as combining data infrastructures with governance frameworks for data pooling and sharing. The data.europa.eu panel report adds that data spaces are service-focused, user-centric, decentralised, automated, and based on common standards. That is a different operating model from simply publishing a static catalogue or downloadable files.

For Data Act implementation, this difference matters because Article 33 focuses on interoperability across data, services, mechanisms, technical access, and automation. A data-space operating file should therefore include more than a dataset list: it should include participant roles, governance rules, metadata, access controls, APIs or other technical means, licence and use restrictions, data quality information, and escalation paths.

The Data Act and the Data Governance Act address different parts of the EU data-sharing framework. The Data Act supplies horizontal rules on fair access and use of data and Article 33 interoperability requirements for data spaces. The Data Governance Act supports trust in voluntary data sharing through rules for protected public-sector data reuse, data intermediation services, data altruism, and the European Data Innovation Board.

A data-space governance file should therefore show which rule is doing the work. For example, a neutral data intermediary or data altruism organisation raises Data Governance Act questions, while a participant offering data services inside a common European data space raises Data Act Article 33 questions.

The Data Act context is the starting point for this answer. The Commission's staff working document identifies data spaces in strategic fields such as health, agriculture, manufacturing, energy, mobility, finance, public administration, skills, the European Open Science Cloud, and the Green Deal priority, with later examples including media and cultural heritage. Individual data spaces then add sector-specific datasets, identifiers, services, governance, and access arrangements.

That means teams should not copy one data-space rulebook into another sector. A procurement data space, a legal data space, a health data space, and a mobility data space can all share Data Act interoperability logic while still having different legal bases, data categories, confidentiality needs, technical standards, and public-interest objectives.

A useful participation file should show both access and protection. Under Article 33, recipients need enough metadata, format, vocabulary, taxonomy, licence, quality, and access information to find and use data. Under the Data Act more broadly, technical protection measures such as encryption and smart contracts may be used to prevent unauthorised access, but they must not become a disguised barrier to lawful access.

The file should also flag trade secrets, commercially confidential material, personal data, protected public-sector data, and sector restrictions. Those safeguards should explain what is protected, what remains available, and which legal or governance rule supports the limitation.

The Data Act context is the starting point for this answer. Keep evidence that connects the legal trigger to the operational exchange. The minimum useful set is a participant-role map, data catalogue, metadata profile, licence and use-restriction record, standards mapping, API or access specification, quality-of-service terms, security controls, smart-contract assessment where relevant, and a log of requests, refusals, restrictions, and changes.

For sector data spaces, add the sector-specific documents that make the exchange understandable: procurement ontologies or TED access material for procurement data, ELI/ECLI and legal-depository references for legal data, or the equivalent identifiers and standards in another sector.

The main risk is overgeneralising. A team may say that a data space is interoperable or EU-backed without proving the specific Article 33 items for the exchange it operates. The opposite risk is also common: treating a sector data-space participation decision as only a policy project and missing binding Data Act access, interoperability, contract, cloud-switching, or public-sector request duties.

The practical control is to maintain one exchange-by-exchange matrix. Each row should identify the participant role, data or data service, applicable Data Act chapter, Data Governance Act or sector overlay, interoperability evidence, protection measure, owner, and review trigger.