Regulation 2023/2854 · Regulation 2016/679 · overlap
A connected product produces a stream of readings. Some of those readings identify a person, most do not, and both kinds travel through the same pipeline. The GDPR governs the first category and has done for years. The Data Act governs the whole stream as data generated by use, and gives the user a right to reach it. Neither replaces the other, the overlap is genuine, and the practical question is not which one applies but which duty attaches to which piece of data.
Personal dataNon-personal dataUser rightsAccessBoth mandates
The first line on each side is the whole difference. The GDPR asks whether data relates to an identified or identifiable person. The Data Act asks whether data was generated by the use of a connected product. A machine reading with no person attached is invisible to one regime and central to the other.
| Point | Data Act | GDPR |
|---|---|---|
| Data covered | Personal and non-personal, generated by product use | Personal data only |
| Who holds the right | The user of the product, business or consumer | The data subject, a natural person |
| Core right | Access to product data and sharing with a chosen third party | Access, rectification, erasure, portability and more |
| Legal basis | Does not create one for personal data | Article 6 basis always required |
| Representative | Required for entities outside the Union | Required under Article 27 |
| Where published | Pre-contractual information | Privacy notice, Article 13(1)(a) |
| Enforcement | National competent authorities designated by Member States | Data protection authorities |
| Penalties | Set nationally, effective and dissuasive | Up to €20 million or 4%, or €10 million or 2% depending on the article |
One data dictionary, with a column marking which fields are personal. Two separate inventories is how contradictions get published.
The Data Act obliges you to make data available; it does not authorise you to process personal data for your own purposes. That still needs a GDPR basis.
When a user sends product data to a recipient and it contains personal data, the GDPR travels with it. Contracts and roles have to be settled before the first request.
The Article 27 representative in the privacy notice, the Data Act representative in the pre-contractual information. Same entity if you like, different documents.
Requests do not arrive labelled with a regulation. One inbox, one log, one process, then route internally.
It covers the personal part. Machine readings with no person attached fall entirely outside it and are the bulk of most industrial products.
It does not. Making data available to the user is an obligation; using it yourself still needs an Article 6 basis.
One provider can, with two mandates. One mandate cannot, because they are different regulations with different scopes.
Genuinely anonymous data escapes the GDPR. It does not escape the Data Act, which does not care whether data is personal.
Under the GDPR they are not data subjects; under the Data Act they are users with the full access right. The reverse of what people assume.
Only trade secrets, with safeguards, and only on the narrow grounds the regulation sets out.
This is the practical summary that most companies want and rarely find written down in one place.
| If you | You need |
|---|---|
| Sell a connected product into the Union from outside it | Data Act representative, Article 27 GDPR representative, Article 16 GPSR responsible person |
| Also provide the cloud service behind it | Add NIS2 if cloud computing is offered as a service in the Union |
| Sell software or firmware with digital elements | Consider the CRA authorised representative, optional but decisive for the reporting route |
| Sell only to customers outside the Union | None of the above |
| Have a real operating entity in the Union | No representatives; the entity itself carries the duties |
The clearest way to see how the two laws interact is to follow a single request through both, which is what actually happens when a user asks for data that contains personal elements.
| Step | Data Act question | GDPR question |
|---|---|---|
| Request arrives | Is the requester the user of the product? | Is any of the data personal, and whose? |
| Scope the answer | Which fields are product or related service data? | Which fields identify a person? |
| Check limits | Trade secrets, safety, security restrictions | Rights and freedoms of others, third-party data |
| Deliver | Machine-readable, same quality, without undue delay | Secure transmission, minimisation where relevant |
| To a third party | Permitted at the user's request, with recipient limits | Roles, basis and contract for the personal part |
| Record it | Log for the competent authority | Records under Article 30 |
Two columns, one process. Companies that build separate workflows for each regulation end up sending contradictory answers to the same customer, which is worse than being slightly late. One inbox, one log, one decision per request, with both questions asked at each step.
Machine data is usually non-personal, so a mature GDPR programme covers almost none of it. The Data Act is the first European data regime that reaches them properly.
Under the GDPR that reduces exposure; under the Data Act it does not, because business users hold the access right.
Anonymisation is a GDPR answer. It does nothing under a regulation that applies regardless of whether data is personal.
Nobody owns this internally, so it arrives as a customer complaint rather than as a project.
The GDPR asks whether data relates to a person; the Data Act asks whether data was generated by the use of a connected product. On a modern device both questions get a yes for part of the stream and a no for the rest, so both regimes apply to the same pipeline with different scopes. Neither creates a legal basis for the other, neither designation satisfies the other, and the practical answer is one data dictionary, one request process and two mandates held with the same provider so that a request never lands somewhere nobody is watching.
Six questions that place any connected product company on the map of both regimes, answered honestly and written down with a date.
If yes, the Data Act is in play regardless of whether any of it is personal.
If yes, the GDPR applies to that part, with its own basis, notice and rights.
If no, both regulations require a representative, and they are two separate mandates.
Privacy notice for Article 27, pre-contractual information for the Data Act.
One address, monitored, with a log. Requests do not arrive labelled by regulation.
Derived data and identified trade secrets, with safeguards prepared for the second category.
If the answers to the first three are yes, yes and no, you need both designations and the only real decision left is whether they sit with one provider or two.
If your product generates data through use, the Data Act reaches all of that data and the GDPR reaches only the part that identifies people; both require a representative when you are established outside the Union, both are published in different documents, and the only sensible arrangement is one provider, two mandates and one process that asks both questions about every request that arrives.
The two laws read differently because they were written for different problems, and knowing the problem explains most of the drafting.
| The problem it was written for | How that shows in the text | |
|---|---|---|
| GDPR | Individuals losing control of information about them | Rights attach to a natural person, with a lawful basis required for every processing |
| Data Act | Data from machines locked inside the manufacturers that made them | Rights attach to whoever uses the product, with access as the default and design duties on the maker |
That is why the Data Act says almost nothing about consent and a great deal about formats, and why the GDPR says almost nothing about formats and a great deal about basis and purpose. Applying the reflexes of one to the other is what produces the two classic errors: treating a Data Act request as a subject access request, and assuming a mature privacy programme has already covered machine data it never touched.
Abstractions are hard to apply. Here is a single device followed through both regimes, which is usually the fastest way to see where the line falls.
| Data the device produces | Data Act | GDPR |
|---|---|---|
| Motor temperature, once per second | Product data, user can obtain it | Not personal, outside |
| Operating hours and cycles | Product data | Not personal unless tied to one worker |
| Location traces during use | Product data | Personal where the user is a person or the driver identifiable |
| The operator's login and shift | Related service data | Personal data, full GDPR duties |
| Predicted failure score we computed | Derived, stays with the holder | Personal only if it relates to a person |
| Support chat transcripts | Not generated by product use | Personal data |
Row five is where most arguments happen, and it is worth being precise: the raw inputs are the user's to reach, the model output is yours. Row three is where the two regimes genuinely overlap, and the correct handling is to satisfy the Data Act request while applying the GDPR to the personal part of what leaves your systems.
One regime protects people, the other opens data generated by machines, and a connected device produces both kinds through the same pipeline. Run the Data Act analysis on the whole stream and the GDPR analysis on the part that identifies people. Publish the Article 27 representative in your privacy notice and the Data Act representative with your pre-contractual information. Hold both mandates with one provider, on one renewal date, so that when a request arrives nobody has to work out which inbox it belongs in first.
No. They apply in parallel. The GDPR continues to govern personal data in full, including data that is also product data.
Yes, and that is its main difference from the GDPR. Machine readings with no person attached are squarely inside it.
Two mandates, yes, one under each regulation. One provider can hold both, with separate designations and certificates.
No. It obliges you to make data available; your own processing still needs an Article 6 basis under the GDPR.
The person or company that owns, rents or leases the connected product, or receives the related service. Businesses included.
No. Article 20 GDPR covers personal data provided by the data subject. The Data Act covers data generated by product use, whoever it relates to.
It leaves the GDPR but stays inside the Data Act, because the Data Act does not depend on data being personal.
Competent authorities designated by each Member State, with data protection authorities supervising the personal data aspects.
Yes, and when they do, GDPR obligations follow the data. Settle roles and contracts before the first request.
No, they are not natural persons. They do have the full Data Act access right, which is broader in this specific context.
The Article 27 one in the privacy notice; the Data Act one with the pre-contractual information.
No. GDPR ceilings are set in the regulation; Data Act penalties are set nationally and must be effective, proportionate and dissuasive.
No. Different regulations require different mandates, even when the same entity signs both.
Then the GDPR may barely apply and the Data Act applies fully. That is the case most companies underestimate.
It applies to connected products and related services. Pure software without a connected product is generally outside, though cloud switching rules may still catch you.
Micro and small enterprises are largely carved out of the Data Act sharing duties. The GDPR has no such carve-out.
Both within 24 hours of a completed form and a short call, with two certificates and one renewal date.
€490 for the Data Act designation, with a combined price when held together with the Article 27 mandate.
Related: the Data Act mandate · the Article 27 test
The Data Act representative and the Article 27 GDPR representative from Europe Services, SE in Prague, each with its own certificate and verification code.
Request this service