The most common mistake when combining the battery passport with GDPR is that companies allow personal data to flow into a document that becomes visible to everyone. The battery passport is public, after all: anyone who scans the QR code sees the data without needing an account or permission. Data that seem harmless in an internal system, such as the name of a contact person at the supplier or a direct employee email address, generally do not belong there.
This mistake usually does not arise from carelessness, but from convenience. The passport is often compiled by taking data from existing sources: a procurement system, a quality file, an email exchange with the manufacturer. These sources were created for internal use and often contain more than is needed for the passport. Without deliberate review of what exactly ends up in the public document, such fields slip through.
Why this specific risk is often overlooked
The Battery Regulation and GDPR are two separate regulations with their own purpose. The Battery Regulation prescribes which product data must be available, such as composition, origin and performance of the battery. GDPR concerns the protection of data that identify a natural person. Both regulations apply at the same time, but in practice are often treated as a single work process: whoever submits the passport thinks first and foremost of compliance with the Battery Regulation and not about whether a field contains personal data.
This is more pronounced in smaller companies, where the same person is responsible for both the submission of technical data and as the first point of contact with the manufacturer. The boundary between "data about the product" and "data about the people managing the product" is then less clear than in an organisation where this is divided across multiple departments. Software suppliers who technically set up the passport also typically transfer all submitted fields without themselves assessing whether a field contains personal data; that assessment is the responsibility of the passport provider, not the hosting party.
What specifically goes wrong
In practice, it usually concerns a limited number of recurring fields: the name of a quality officer who signed the certificate, a direct telephone number instead of a general company number, or an attachment such as a scan of an invoice showing a person. In itself, this seems harmless, because it was always shared that way within the company. The difference is that the passport remains accessible to everyone for ten years, even after the employee in question no longer works for the company or has changed position.
A second recurring point is that companies assume the Battery Regulation itself already makes an exception to GDPR, because disclosure is mandatory anyway. This assumption is incorrect: an obligation to make product data public says nothing about whether a specific piece of data is personal data and on what basis that data may then be processed. This is a separate assessment that should take place for each case in the context of your own data processing.
How to prevent this in practice
The core is a review step before publication: someone assesses the completed product passport specifically to check whether it contains a name, function, direct contact details or other identifiable information that is not functionally necessary for the product information. This is not a legal exercise but a practical check, comparable to reviewing a document before it goes out the door. If you want to outsource this structurally, you can establish it as a fixed part of your submission process, separately from the technical integration with the software supplier.
It also helps to distinguish between the file that is kept internally as evidence of due diligence, and the passport that is visible externally. The first may contain names and contact details to the extent necessary for your own business operations; the second is intended for product information. In the knowledge base where this subject is worked out per situation you will find how these two components relate to each other. If you want to know how data for the passport is compiled and who has what role in it, you will find that via an overview of how the data for the passport is compiled.
Because this interface lies between two regulations, a general assessment of your situation by a lawyer or the data protection authority is the appropriate route if you are in doubt about a specific field. How we as a platform handle access to and storage of data submitted to us is described on the page on how we handle data and access.
Would you like to first get an idea of where your company stands before diving deeper into this topic? With a few questions you get a first indication of your situation, entirely without obligation and without needing an account.