Search every question across sub-FAQs

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

The Data Act context is the starting point for this answer. Article 13 protects one enterprise from unfair data-related contract terms unilaterally imposed by another enterprise. The rule covers terms about access to and use of data, and terms about liability and remedies for breach or termination of data-related obligations.

If the term is unfair under Article 13, it is not binding on the enterprise on which it was imposed. The rest of the contract can still bind the parties if the unfair term can be severed from the remaining terms.

The Data Act context is the starting point for this answer. A term is treated as unilaterally imposed when one contracting party supplied it and the other party could not influence its content despite trying to negotiate it. This is the practical issue behind take-it-or-leave-it data access and data use clauses.

The party that supplied the contested term bears the burden of proving that it was not unilaterally imposed. The same party cannot use Article 13 to argue that its own supplied term is unfair.

The Data Act context is the starting point for this answer. The general test is whether the term grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing. That test matters for terms not already captured by the Article 13 always-unfair or presumed-unfair examples.

A practical review should compare the clause against the Data Act purpose of fair data access and use, the parties' bargaining position, the data involved, the impact on legitimate interests, and the remedies available if obligations are not performed.

The Data Act context is the starting point for this answer. Article 13 lists three types of terms that are unfair where their object or effect matches the list. These are the closest equivalent to a black-list review for B2B data contracts.

The always-unfair examples cover terms that exclude or limit the imposing party's liability for intentional acts or gross negligence, remove remedies for the enterprise on which the term was imposed, or give the imposing party the exclusive right to decide data conformity or interpret the contract.

The Data Act context is the starting point for this answer. Article 13 also lists terms presumed unfair. These are not automatically final in the same way as the always-unfair terms: the party that imposed the term can try to show that the term is not unfair.

The presumed-unfair group includes inappropriate limits on remedies or liability, harmful access to or use of the other party's data, preventing the other party from using data it provided or generated, blocking termination within a reasonable period, blocking a copy of provided or generated data, termination at unreasonably short notice, or substantial unilateral changes to price or data-sharing conditions without a valid reason and termination right.

The Data Act context is the starting point for this answer. Article 13 does not apply to terms defining the main subject matter of the contract or to the adequacy of the price as against the data supplied in exchange. That exclusion should be recorded before treating a pricing or core-scope clause as an Article 13 unfair term.

The exclusion is narrow in practice. A price number or core data-sharing description may sit beside other reviewable terms, such as unilateral changes to price, format, quality, quantity, termination, remedies, or copy rights.

The Data Act applies from 12 September 2025, and Chapter IV applies to contracts concluded after 12 September 2025. Older contracts concluded on or before 12 September 2025 enter Chapter IV from 12 September 2027 only if they are of indefinite duration or are due to expire at least 10 years from 11 January 2024.

For contract operations, keep a contract population view that separates new contracts, renewals or amendments, indefinite-duration contracts, and very long-running older contracts. Do not apply the older-contract rule to every legacy agreement without checking the duration criteria.