The Data Act Trade-Secret Carve-Out: Redaction and Classification So Sharing Doesn’t Bleed IP

The Data Act lets you protect trade secrets when you share product data. It does not let you protect data you never bothered to identify as a trade secret before the request landed.

Most of the commentary on the Data Act’s trade-secret provisions reads like reassurance for manufacturers: your intellectual property is safe, there is a carve-out, relax. That reading is dangerously incomplete. The carve-out exists, but it is conditional on work you have to do in advance, in your systems, before anyone asks. Regulation (EU) 2023/2854 has applied since 12 September 2025. If a user or a third party makes a data-access request tomorrow and you have never tagged which fields in your telemetry stream carry commercially sensitive information, you do not have a trade-secret defence to invoke. You have a spreadsheet you will try to assemble under time pressure while the clock on a statutory obligation runs.

What the carve-out actually says

The trade-secret provisions sit in two places. Article 4 governs the user’s right to access data generated by a connected product they own or use; Article 5 governs the user’s right to have the data holder share that data with a third party of their choosing. Both articles carry a matching set of trade-secret paragraphs — Article 4(6) to (8) and Article 5(9) to (11) — and they impose a sequence rather than a blanket exemption.

Free · 4 minutes

When two of your systems disagree, do you know which one to believe?

Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.

The sequence runs like this. Trade secrets are to be preserved and disclosed only where the data holder and the recipient have agreed the necessary technical and organisational measures to keep them confidential. To reach that point the data holder must first identify the data protected as trade secrets, including in the metadata. Where no agreement on measures is reached, or the recipient breaches the agreed measures, the data holder may withhold or suspend the sharing of the data identified as trade secrets — and must notify the competent authority. In exceptional cases, the data holder may refuse a specific request outright, but only where it can demonstrate, on objective evidence, that it is highly likely to suffer serious economic damage from disclosure. Each escalation raises the evidential bar.

Read that sequence as an engineer, not a lawyer, and the load-bearing word is identified. Every protection in the chain depends on you having already marked the data as a trade secret. You cannot preserve, cannot condition disclosure on measures, cannot withhold, and certainly cannot refuse, over data you have never distinguished from the ordinary product data you are obliged to hand over.

This is a classification problem wearing a legal costume

There is a second, quieter dependency that catches firms out. The Data Act does not define “trade secret” afresh; it points to the Trade Secrets Directive (EU) 2016/943. That definition has three limbs: the information is secret, it has commercial value because it is secret, and the holder has taken reasonable steps to keep it secret. The third limb is the trap. If you cannot show you took reasonable steps to keep something confidential, it is not a trade secret in law — and undifferentiated data sitting in the same table, under the same access policy, as data you are about to share on request is not obviously the subject of reasonable protective steps.

So the carve-out has a precondition that is not written in the Data Act at all: to qualify for it, you must already be treating the data as a secret through a classification and access regime. This is the same discipline I have argued is a prerequisite rather than a parallel workstream when firms reach for AI. The Data Act makes it a prerequisite for defending your IP. Classification stops being hygiene and becomes the thing that decides whether you have a legal position.

What “identified as a trade secret” means in a schema

The regulation says identify the trade secrets, including in the metadata. In practice that means field-level, not dataset-level, classification. A connected product emits a stream in which the raw sensor readings, the derived diagnostics and the proprietary calibration or model coefficients often travel together. The user is entitled to the product data. Your inference models, your calibration curves, the derived signals that encode how you tune the device — those may be the trade secrets. If your only unit of classification is “the telemetry export”, you are forced into a binary you will lose: share everything, or refuse and try to justify serious economic damage over the whole payload.

The workable pattern is a classification tag carried on each field or message type in the schema itself, propagated through the pipeline, so that at the moment a request is served the system can partition the response: release these fields, apply agreed measures to those, withhold that subset and log why. This is the design-time work that makes runtime compliance mechanical. It belongs in the same conversation as engineering the access interface itself, which I have covered under data access by design — the classification layer and the access layer are the same project, built once.

Redaction that does not break the payload

Withholding is not deletion. If you strip the trade-secret fields crudely, you can break the schema, orphan references, or hand the recipient data that is now useless for the purpose they are legally entitled to pursue — which invites a complaint that you have frustrated the access right rather than protected a secret. Redaction has to preserve the structural integrity and utility of the data the recipient is owed while removing only what genuinely qualifies. That is a considered transform: null the sensitive field but keep the record; substitute a derived signal with a coarser, non-proprietary equivalent where one exists; document what was removed and on what classification basis. The recipient gets working data; you keep the calibration model. Both can be true, but only if the redaction is engineered rather than improvised.

The evidence a dispute will actually demand

When you withhold, you notify the competent authority, and the recipient can challenge you. What you will be asked to produce is not an opinion that something was sensitive. It is the record: the classification decision, when it was made, the policy under which the field was marked a trade secret, the measures you proposed, and — if you escalated to outright refusal — the objective evidence of likely serious economic damage. A classification applied the week the request arrived, visible in your audit log as a last-minute reclassification, is worth very little. A field that has carried a trade-secret tag and a restricted access policy since the product shipped is worth a great deal. The evidential weight of your carve-out is a function of how long, and how consistently, you have been treating the data as secret.

This is also where the trade-secret regime meets the commercial one. When the sharing is business-to-business, the same classification underpins what you can protect while still meeting your obligations on fair terms — the contract and API pattern I have set out for data sharing on FRAND terms assumes you can already say, field by field, what is proprietary and what is not.

Build the tagging before the request, not after

There is one caveat worth stating plainly. The Commission’s Digital Omnibus proposals, tabled in late 2025 and still under negotiation through 2026, would loosen these thresholds for data holders — softening the “highly likely” and “exceptional cases” language and adding a third-country ground. That is a proposal, not law; do not plan against text that has not been adopted, and verify the final wording before relying on any relaxation. But note the direction: even a more generous carve-out is still a carve-out you can only invoke over data you have identified. Loosening the threshold does not remove the precondition.

The trade-secret carve-out is not a shield you pick up when the request arrives. It is a shield you forge months earlier, in your schema, and can only lift if it was already there. Firms that treat it as a legal argument to be made later will find they are arguing about data they cannot distinguish. Firms that treat it as a classification problem to be solved now will find the argument mostly makes itself.

Free interactive tool

Website compliance checklist

What your site has to do, based on what it actually does

Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming