Skip to content

What the registry records about you

The registry keeps two things. One is a record about a product. The other is an attributable audit trail about the business and the named people inside it who touched the record, held on three different clocks, and reachable by national authorities and customs on a trigger the instrument does not define. That second record is the one nobody has read.

Sources as at
28 August 2026
Share
LinkedIn X Email
On this page

The short answer

Article 14 of Commission Implementing Regulation (EU) 2026/1778 requires the Commission to establish, maintain and run a log system, and to ensure a complete, accurate and reliable audit trail. Four categories of event are logged, on three retention periods.

The four categories of event the registry logs under Article 14(2), with the retention period Article 14(3) attaches to each.
What is logged, under Article 14(2)How long it is kept, under Article 14(3)
Access and authentication entriesSix months
Data modifications by all registry users, including uploads and updatesFor the duration of the registration
Administrative actions, including account creation, change and deletion, and changes to access rights, permissions and configurationFive years
Data exchange logsFive years

Recital 22 describes the audit trail as tracking access attempts, successful and unsuccessful, and modifications by all users.

Read the second row against the deletion rule and the practical position becomes clear. Article 10(3) deletes registration data ten years after registration where Union law sets no specific availability period. "For the duration of the registration" therefore means, in the ordinary case, a decade of edit history, attributable to named individuals.

Nobody is hiding this. It is in an implementing regulation anybody can read. It is simply not in any of the published explanations of the registry that this research reviewed.

Attribution is the point

An audit trail that records that a change happened is a technical feature. An audit trail that records who made it is a different object, and Article 18 is what makes it the second kind.

Article 18(1) has the Commission store, to verify the identity of every user: the first and last name of each user, or of the person legally entitled to act as legal representative for the economic operator; the authentication credentials associated with the user, including login credentials and authentication tokens; the postal address of economic operators and value chain actors that are users; the email address of each user; and metadata embedded in uploaded documents where that metadata contributes to identifying or verifying the user.

That last one is worth pausing on. Document metadata is not something most businesses think of themselves as submitting. It is something a word processor attaches.

Article 18(2) goes further for natural persons, requiring personal identifiers to be stored, "such as passport number, national identity card number or national eID number, civil registry number, tax identification number" issued by the relevant national authority, or a third country identifier or any documentation identifying the person.

That provision reaches sole traders directly. A one person business registering a passport is handing a national identifier to a Commission system, and a decade of its own edits will be attributable to it by name. Larger companies are affected differently: the named individuals in the log are employees, and the employer is not the controller of the registry side record.

Who can reach it, and on what trigger

Three provisions open the record outwards, and the thresholds in them are worth reading closely because they are not high.

Article 14(4). In the case of suspected incidents, and for the purposes of security audits and random checks, the Commission makes the relevant logs available to the competent national authorities and customs authorities. Recital 24 says the same, adding that access respects the confidentiality and integrity of the logs.

Three things about that provision. A suspected incident is not defined. A random check needs no suspicion at all, by definition. And the instrument contains no duty to notify the operator whose logs were disclosed.

Article 21(3). Data the Commission can obtain from the registry may be transmitted to relevant Commission services or to competent national authorities for measures they are required to carry out under other Union legislative acts, including market surveillance, consumer protection and customs compliance.

Article 13(2). This is the one that surprises people. Written exchanges with the registry helpdesk are stored for six months after the support request is closed, and made available to market surveillance authorities on request.

A support ticket is a place where somebody describes a problem candidly. It is now a six month, disclosable record. That is not a reason to avoid the helpdesk. It is a reason to write to it the way you would write to a regulator, because for six months that is what you are doing.

Two controllers, two instruments

Data protection responsibility here splits in a way that catches people out, and the split is deliberate.

The Commission is the controller for the personal data it processes in the registry, under Regulation (EU) 2018/1725, which is the instrument governing the EU institutions rather than the General Data Protection Regulation. Recital 13 describes processing under that regulation and says data is deleted when accounts are removed, subject to retention where auditing requires it.

Member States are in a different position. Article 22(4) says that when processing personal data to carry out their duties, Member States are regarded as controllers within the meaning of the General Data Protection Regulation. Article 22(5) makes them responsible for onboarding their authorities through the designated national administrator, for ensuring processing complies with the General Data Protection Regulation, and for withdrawing access where registry access has been unauthorised or incorrect.

Meanwhile Article 19(5) makes the verified economic operator the controller of the data it submits.

So one registration involves three controllership positions under two instruments, and a business asking a single question about who is responsible for its data will get three correct and different answers depending on which part of the record it means. Where a business's own responsibility for a published value sits, as opposed to the registry's, is worked through at who has to own this.

What you can and cannot get rid of

Article 10(4) lets registry users request deletion of their account where they are no longer responsible for registry related activities. That is an account, not a history. Nor does the history obviously move: whether a transferee inherits visibility of the transferor's edit log is one of the questions an orderly transfer leaves open.

Nothing in the instrument we read lets an operator delete the log entries attributable to it, and the retention periods in Article 14(3) are stated as periods rather than as maxima subject to request. Registration data itself is deleted automatically on the Article 10(3) clock. We did not find a provision by which a business can shorten either, and that is a statement about where we looked in the enacting terms rather than a claim that no route exists elsewhere in Union data protection law. How this estate types a question it cannot resolve from the source in front of it is set out at how we know.

Two other provisions belong in the same picture. Article 16 requires the Commission to log security events and to take measures to detect unauthorised registry activity. Article 17 lets the Commission act against inappropriate or fraudulent use, naming activity linked to massive data downloads, and obliges any user who suspects malicious behaviour to inform the Commission immediately.

What this actually means in practice

None of this is a reason not to register. It is a reason to register the way you would run any other regulated system of record.

What each provision means in practice for a business running registry accounts.
The factThe consequence
Edits are attributable to named users for the duration of the registrationRegistry accounts should not be shared, and leavers should be removed promptly, because the trail outlives the employment
Administrative actions are kept for five yearsWho granted whom access, and when, is a five year record. Access changes deserve an internal reason
Sole traders hand over a national identifierA one person business should know that before it starts, and should consider which legal entity registers
Helpdesk exchanges are disclosable for six monthsSupport tickets are correspondence with an institution, not an internal note
Logs go to authorities on suspicion or on a random check, with no notification dutyYou may never learn that your logs were read. Your own copy of what you did is the only version you control

That last row is the one worth acting on. The registry's record of your activity is not a record you can obtain on demand, and the instrument gives you no visibility of when it is disclosed. Keeping your own log of what was registered, when, by whom and against which version of the data is the only way to be able to answer a question about your own history without asking the Commission for it.

That is also the discipline that makes the other registry documents work. A proof of registration ties a moment to a hash, and it is only useful later if somebody kept it and knew why. What that document establishes, and the ninety days it stays retrievable, is set out at what proof of registration proves.

What to do now

  1. Decide who gets an account before anybody gets one. Registry users are named in a decade of edit history. That is an access control decision, not an admin task.
  2. Write down which legal entity registers. Verification attaches to an entity, and for a sole trader the identifiers stored are personal ones.
  3. Keep your own registration log. Date, product, version, hash, who submitted it. The registry's copy is not yours to retrieve.
  4. Treat the helpdesk as correspondence. Accurate, complete, no speculation about your own compliance.
  5. Put registry access on the leavers checklist. Article 14 keeps administrative actions for five years, which includes the day nobody remembered to remove somebody.

The architecture this all sits inside, and what the registry holds about the product rather than about you, is set out at where your passport data actually lives.

You might want to read next

Since you have read this, these may answer the questions that usually come next.

Sources

This page states no legal advice on data protection compliance and does not attempt to. It sets out what the instrument requires the registry to keep and who it lets reach it.

Worth sharing?

Help someone else make sense of product passports.

LinkedIn X Email