AVG and IoT data under the Data Act: What startups and scale-ups need to know

The Data Act makes IoT data a strategic theme

The Data Act takes a clear step towards more data sharing. For connected products, this essentially means that users must be able to access the data that their product generates. If that access is not available directly through the product itself, the data holder must make that data available and also make it possible to transfer that data to a third party upon request.

For tech companies, this is big news. Anyone who puts connected hardware, smart equipment or a platform with an accompanying app on the market will be faced with a legal framework in which data is not only a commercial asset, but also something that users can exercise rights to. Think of smart devices in the consumer market, but also business tools, connected vehicles or equipment that is used by employees within an organization.

At the same time, the AVG remains in force. The Data Act therefore does not override the privacy rules. In fact, when it comes to personal data, privacy legislation takes precedence. This is an important starting point for startups and scale-ups. The Data Act opens the door to more access and exchange of data, but the GDPR still sets the rules as soon as that data can be traced back to natural persons.

Not all IoT data is personal data, but often faster than expected

An important distinction in this subject is the difference between digital data in a broad sense and personal data. The Data Act covers digital data in general. The AVG only covers personal data. In theory, therefore, connected products can also generate data that falls outside the GDPR.

In practice, that distinction is less broad than it sometimes seems. This is because a lot of IoT data can quickly be linked to a natural person. This can happen immediately, for example when a user logs in to an app with an email address or account name. It can also be indirect, because data says something about an identifiable person's behavior, location, routine, or usage pattern.

That sometimes makes the difference between a technical data point and personal data surprisingly small. A smart light that turns on and off on a fixed schedule does not necessarily provide information about a specific person on its own. But once the same light accurately shows when a resident gets up, goes to sleep, or wakes up at night, the image shifts. Then suddenly that data does say something about someone's personal life.

For startups and scale-ups, this is a crucial lesson. It's not just about what data a product can technically read, but especially about the context in which that data is used. As soon as an account, user profile, email address, dashboard or other link to an individual comes into view, a GDPR issue quickly arises.

This is also relevant in a purely business context. Equipment that apparently only produces operational data can still provide personal data if that data is linked to employees or other natural persons. Think of tools, vehicles, or other connected assets that are connected to one user via a personal code, badge, or account.

Who has what role? That's where real compliance starts

Many discussions about AVG and IoT data are stuck in roles. That makes sense, because the Data Act works with terms other than the AVG. Where the GDPR talks about controllers and processors, the Data Act mainly concerns the data holder, in addition to manufacturers, providers of related services and other parties involved.

The data holder is not automatically the same as the controller

Nevertheless, in practice, these roles often intertwine. Indeed, when it comes to personal data, the party that can obtain and dispose of the relevant IoT data in fact or law should in many cases also be seen as a controller. A processor is not expected to act as a data holder under the Data Act.

This means that, as a tech company, you can't make do with a superficial qualification. You really have to look at who determines the purpose and means of the processing, who can read the data, who organises access and who decides what happens to that data.

The practice is often more layered than the contract schedule

This is also evident from typical IoT structures. With a smart refrigerator with its own app, it is obvious that the manufacturer acts as controller when that manufacturer makes the data available and uses the app. But as soon as the manufacturer does not have that access themselves and a third app provider is in charge, that third party can come into the picture as controller.

The same applies to rental and lease structures. If a connected bike rental company has insight into rides and GPS locations via an app or dashboard, while the manufacturer does not have access to that data, the responsibility shifts to the rental company. In a work environment, an employer who links connected tools to employees and sees usage data via a dashboard can be considered a controller, while the manufacturer only acts as a processor.

This is extra relevant for startups and scale-ups because their product model often consists of multiple layers at the same time: hardware, firmware, app, management environment, analytics and perhaps another reseller, landlord or business end customer in between. Especially then, it is risky to assume that the manufacturer automatically determines everything, or, on the contrary, decides nothing. The actual data architecture is leading.

The concept of user also deserves attention

The Data Act works with a broad user understanding. This is not limited to just the purchaser of a related product. A party who has temporarily transferred rights to use the product, or someone who receives the related service, can also be a user.

This is interesting for tech practice. Especially in business models involving rent, lease, loan or deployment via an employer, the question may arise who exactly counts as a user. This can be relevant for access rights to data, but also for the relationship with the GDPR. In practice, if a natural person uses the product and the data relates to him or her, the user under the Data Act and the data subject under the GDPR often coincide.

There is something else to add. In business chains, a discussion can arise whether a business user can also be a data holder himself. That is not a matter of detail. For scale-ups that rent out connected assets or make them available to others via a platform, this also determines whether the end user can go somewhere to exercise rights. That is precisely why it is wise not to analyze this division of roles afterwards, but to clarify the contractual and operational terms beforehand.

The Data Act does not provide an automatic GDPR legal basis

One of the most important points for founders and legal teams is that the Data Act does not automatically create an AVG legal basis. The fact that a data holder must make data accessible or transfer data upon request under the Data Act does not automatically mean that the basis for privacy law is also immediately established.

This requires a second layer of analysis. For each processing, it must be assessed which legal basis fits the AVG.

Implementation of the agreement

For a related service, such as an app that allows the user to operate a connected product, execution of the agreement is often obvious. If the app cannot perform its function without that data, that processing can in principle be properly placed within the contractual relationship.

Even when a user requests the transfer of their data to a third party, the execution of an agreement can play a role. This is especially true if that transfer is a functional part of the service desired by the user.

Legitimate interest

For other processing operations, the legitimate interest may come into play. This will mainly play a role when using IoT data for own business purposes that do not directly coincide with the core performance towards the user. For example, analysis of product use, improvement of services or broader insights based on aggregated data.

But that's where the nuance lies. Not every commercial wish passes that test. So it's not enough that processing is convenient or valuable. It must be considered whether the processing is necessary for the interests pursued and whether the user's interests do not outweigh. Moreover, this will not require every category of IoT data. A company that reads everything because it can be technically possible does not get anywhere legally.

consent

Consent remains relevant, especially if third parties get access to IoT data for their own purposes. But consent is not necessarily the only route for each subsequent processing. This is an important distinction, especially for product teams that tend to put all data flows under one consent flag. In some situations, consent may be logical; in other cases, a different legal basis is more obvious.

With special personal data, the space automatically becomes smaller. Then it is necessary to look even more explicitly at whether consent is really necessary, or whether another exception is available. And if consent is used, it must also be possible to withdraw it.

Don't forget article 11.7a Tw when reading connected products

For many startups, the reflex is to mainly look at the AVG. However, there is an extra layer at play here. Reading IoT data from connected products may fall under the rules of article 11.7a Telecommunications Act, a provision that is often associated with cookie rules but works more broadly than just cookies.

For connected products that qualify as peripherals, permission must in principle be obtained to access information on that device. This therefore directly affects the reading of data from connected devices.

For product teams, the exception is particularly important. If reading is strictly necessary to provide a service requested by the user, such as an app that functionally belongs to the product, permission does not always need to be requested. But as soon as another party gains access for its own purposes, such as a rental company, manufacturer, or app provider that does more than just provide the requested service, that consent requirement quickly comes back into view.

That makes this topic extra relevant for startups. Not only does the further processing of data have to be legally correct, the first reading moment itself also deserves attention.

Access and transfer sound simple, but they are not

At first glance, the rights under the Data Act seem to be well in line with the AVG right to access and the right to data portability. However, they are not completely the same.

The Data Act gives the user the right to access IoT data and transfer it to a third party. The GDPR includes access and data portability, but these rights have their own scope and conditions. Especially when it comes to data portability, nuance arises, because this GDPR right is linked to specific legal grounds and whether the data was provided by the person concerned.

This is possible to discuss this with IoT data. A broad explanation makes much of that data transferable, because it can also include observed usage data. A limited explanation reduces that space. In practice, this means that a transfer request cannot always be dealt with with a single standard response. Under the Data Act, the obligation may be wider than under the GDPR, while both regimes play a role at the same time.

The real tension lies in restrictions, trade secrets and gatekeepers

This is where it becomes clear that the relationship between Data Act and AVG is workable, but not frictionless. The Data Act has situations where access or transfer can be restricted, for example if the security of the product is compromised, or if trade secrets need to be protected.

This sometimes affects the user's AVG rights. A data holder who wants to restrict access or transfer will then have to explain why it is necessary and how it relates to the rights and freedoms of others. For tech companies, this is an important warning. Restrictions should not be used voluntarily or by default. They require a well-founded consideration.

An even more difficult point is when handing over to gatekeepers. The Data Act wants to prevent certain dominant parties from gaining even more data power. At the same time, the AVG provides, under certain conditions, a right to transfer to another controller. So a collision can occur there. This is not a comfortable position for companies that need to share data. In such cases, the legal playing field has not yet fully crystallized.

What does this mean in concrete terms for startups and scale-ups?

For startups and scale-ups in the tech sector, this topic ultimately revolves around three questions.

The first is: what data do you actually read out, and when does that become personal data? This requires a substantive analysis of the product, the app, the metadata and the context in which the user becomes identifiable.

The second is: who plays which role? In an IoT chain, this is seldom self-evident. Manufacturer, app provider, host, employer, or platform operator can each have a different position, depending on who has access and who decides.

The third is: on what legal basis does each step rest? Not only further processing, but also the reading itself can be legally sensitive. Especially if several parties want to use data for their own purposes, it is unwise to think that one privacy statement or one contractual provision covers the entire playing field.

At Startup-Recht, we regularly see that it is precisely this combination of product development, platform logic and data-driven business models that means that privacy issues cannot be viewed separately from the commercial model. If you want to make good use of IoT data, you must therefore not only be able to read and analyze it technically, but also be able to explain legally why, under what role and on what basis this happens.

Conclusion: not an unhappy marriage, but a relationship with tensions

The relationship between the Data Act and the GDPR is not fundamentally contradictory. The two regimes can work side by side, even with connected products and IoT data. But it is not easy.

Especially because IoT data quickly becomes personal data, because roles can be diffuse in practice, and because rights to access and transfer can conflict with security, trade secrets, or other protected interests. For startups and scale-ups, the challenge therefore lies not in choosing between Data Act or AVG, but in taking both seriously.

Those who develop or operate connected products would do well not to see this topic as a compliance detail for later. This is where product design, data governance and legal architecture come together directly.

‍