Search every question across sub-FAQs

Keep evidence that the challenged clause is in Article 13 scope: the contract, negotiation history, requested changes, the final refused or imposed wording, and the link between the clause and data access, data use, or data-related liability or remedies.

Then classify the term. Some terms are always unfair under Article 13(4), such as excluding liability for intentional acts or gross negligence by the imposing party. Others are presumed to be unfair under Article 13(5), such as inappropriate remedy limits, significantly detrimental access to the other party's data, or unilateral changes to substantive data-sharing conditions without a valid reason and termination right.

Chapter V has a different size rule. Article 15(2) says the non-emergency exceptional-need route in Article 15(1)(b) does not apply to microenterprises and small enterprises. A non-emergency public-sector request under that route is therefore not an ordinary obligation for a micro or small company.

For public emergencies, Article 20 treats micro and small enterprises differently on compensation. Data holders other than micro and small enterprises must make data necessary for public-emergency response available free of charge, but Article 20(3) allows the fair-compensation rule to apply where a microenterprise or small enterprise claims compensation.

Create one status file per Data Act workflow, not one generic SME certificate for the whole company. The useful record names the legal entity, partner and linked-enterprise position, Data Act role, affected product or related service, data request or contract, chapter relied on, date of status review, and source used.

For startup teams, the record should also note that startup status is not itself a legal category in the Data Act. The practical question is whether the entity qualifies as a microenterprise, small enterprise, or medium-sized enterprise under Commission Recommendation 2003/361/EC, and whether the Article 7 or Article 9 conditions actually apply.

For SME exceptions and startups, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For SME exceptions and startups, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For SME exceptions and startups, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For SME exceptions and startups, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

For SME exceptions and startups, the Data Act evidence should be concrete enough for a later reviewer to reconstruct why the team classified the product, service, request, or contract in scope.

For SME exceptions and startups, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

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.

Users, third parties, and data recipients must not alter or remove Article 11 controls without the data holder's agreement. If a recipient obtains data through deception or coercion, uses it for an unauthorised purpose, discloses it unlawfully, fails to maintain agreed trade-secret safeguards, or removes protection measures without agreement, Article 11 can require erasure, cessation of specified goods or services where the legal test is met, notice to the user, and compensation.

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

A data holder may withhold or suspend the identified trade-secret data where necessary safeguards cannot be agreed, the user or third party fails to implement agreed measures, or confidentiality is breached. The holder must give a duly substantiated written decision without undue delay and notify the competent authority. Withholding or suspension is a narrow response to the safeguard failure, 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 that is also the trade-secret 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.