tyrepas.eu

What mistake do companies make when talking with their software supplier about the tyre passport?

Companies often treat the conversation with their software supplier as a purely technical project and forget who remains responsible for the content and accuracy of the data. This leads to a functioning system with a gap in liability.

The most common mistake when talking with a software supplier about the tyre passport is that the conversation focuses almost entirely on technology: which coupling, which format, which price per QR code. Who remains responsible after that conversation for the accuracy and timeliness of the data in the passport often only comes up when something goes wrong.

This distinction is not pedantic. A software supplier can deliver a technically correct functioning passport, with a QR code that neatly points to a page, while the content of that page is outdated or incomplete because no one agreed who would keep that content current. The regulation is directed at the provider who supplies the data, not automatically at the party that supplies the technology. If this distinction does not explicitly come back in the conversation and the contract, a gap arises between what works technically and what is correct in terms of content.

Why this mistake is so common

A conversation with a software supplier almost always starts from a concrete, practical question: how does the QR code get on the tyre, which system couples with the administration, what does it cost per model. These are logical questions, and a supplier answers them well too. The problem is that these questions suggest that the supplier covers the entire chain, whereas a software company typically supplies a platform and does not perform substantive checks on what a manufacturer or importer provides.

With many other IT projects, this distinction is less relevant, because the user enters the content themselves and remains responsible themselves. With the tyre passport, it is different: the data often comes from a manufacturer or importer further down the chain, is compiled into a passport, and remains accessible for ten years thereafter. Who at that point is still responsible for a correction must be clear before signing the contract, not after.

What goes wrong in practice

In practice, this mistake usually manifests itself in three ways. First, it is not established who may and must correct an error in the data, and within what timeframe this happens. Second, it is not discussed what happens to the data and the QR data carrier if the company switches to a different supplier or ends the cooperation, while the ten-year hosting period simply continues. Third, there is often no agreement on who provides the source data for composite products, for example when an importer merges data from multiple manufacturers into one passport.

None of these points is a technical problem. They are about role division and responsibility, and precisely for that reason they are easily overlooked in a conversation that is set up as an IT project. how the data in a passport comes into being provides a good starting point to see which steps are involved in that process, before you ask the same questions of a supplier.

How to prevent this

The core is simple: discuss the role division before you discuss the technology. Explicitly ask who is responsible for the accuracy of the content, who corrects if an error is discovered, and what happens to the passport if you switch to a different party. Set down these agreements in the contract, not only in a quote or implementation plan, so that they remain valid even after staff changes or a switch of supplier.

It helps to test these questions against the role your company itself has in the chain: an importer has different responsibilities than a wholesaler who only resells. see in a few questions which role fits your company provides a first direction for this, before you discuss that role division with the supplier.

The connection with other agreements

This error is not isolated from other matters already at play in your business. A data processor agreement under the GDPR, for example, regulates who processes personal data and how, but says nothing about who is substantively responsible for product data in a passport. Both agreements can exist side by side, but must not be confused with each other. Whoever keeps these matters clear and separate prevents one contract from being used to cover everything it does not cover.

If you want to see which questions belong to this discussion exactly and which role fits there, provides the knowledge bank with explanations per topic an overview that goes beyond technology alone.

If you are not yet certain where your business stands in this chain, the free quick-scan is a good starting point: in a few questions you get an indication of your situation, without having to read through all the regulations first.

This article is general information and not legal advice.