On this page (6)
The retention period for data in the entry log is set by the data controller, meaning the company that runs the site, not the system supplier and not the security company. The regulations do not set one period for everyone; the period follows from the purpose for which the data is collected, and it has to be written into a retention policy. The system should carry out that policy automatically, so that deleting data does not depend on someone remembering to do it.
A notebook at the gatehouse never deletes anything. It sits in a cupboard for years and holds names, registration numbers and times: a complete set of personal data with no expiry date at all.
What exactly counts as personal data in the entry log
There is more personal data in an entry log than people usually assume:
- the driver’s first name and surname, which is obvious,
- the vehicle registration number, which is personal data when it can be linked to a person, and in an entry log it usually can,
- the entry and exit times, which are information about a specific person’s activity over time,
- a document scan, if one is collected; this is usually the most sensitive part of the whole record,
- the visit history, a summary showing how often and when a given person has been on site.
Visit history is the item most often forgotten. A single entry is a note, while three hundred entries by the same person compiled in one report are an activity profile, and that is how they will be judged.
How to set the retention period for driver data
The retention period for driver data follows from the answers to three questions. The first is about purpose, because the purpose decides everything. Site security, settling deliveries and monitoring working time are three different purposes, with three different justifications and potentially three different retention periods.
The second question is how long the data is needed for that purpose. It is phrased ‘how long do we need it’, not ‘how long can we keep it’. Data kept longer than the purpose requires is kept without a legal basis.
The third is what happens to the data after that time, and this is where the distinction between deletion and anonymisation comes in.
Deletion vs anonymisation
Deletion means the record is gone. The statistical information goes with it: how many vehicles came in last year, what the average number of entries on a Monday was.
Anonymisation means the record stays, but without the data that would identify the person. The fact ‘entry at 8:15, heavy goods vehicle, dock 3’ remains; the information about who made it disappears.
For most sites anonymisation is the right choice: it keeps the value for statistics and planning and removes what is protected. Anonymisation is irreversible: once it has been done, there is no way to reconstruct who it was, even if that turns out to be needed in a dispute. That is why the period should be longer than the window in which complaints and claims come in.
Data retention and anonymisation in TraxSystem
TraxSystem applies the retention policy in the background, according to the periods set by the controller, and anonymises data instead of deleting it if that is how it has been set up. It keeps an audit trail, a record of who accessed the data and when. It also restricts visibility, because not everyone with access to the system needs to see everyone’s data.
Restricting visibility is sometimes more important than retention itself. The security officer at the gate needs to know whether this vehicle may come in, and the driver’s visit history from a year ago is of no use to them at all.
GDPR compliance: what depends on the data controller
TraxSystem does not make you GDPR compliant on its own, and nobody can promise compliance on your behalf. Compliance depends on how the system is configured, which processing purposes are defined and which retention periods the controller sets. The system provides the mechanisms needed for compliance: retention, anonymisation, an audit trail and restricted visibility. The policy is set by the data controller.
The system does not keep your record of processing activities for you, nor does it generate the documentation required of a controller. It does not recognise faces or collect biometric data as a basis for access either; identification is by card and personal details.
The system mechanisms and organisational practice described here are not legal advice. Agree retention periods and the legal bases for processing with your data protection officer.
Questions and answers
In the cloud variant, does the data leave the European Economic Area?
No. The servers are in Poland, and there is no transfer outside the European Economic Area. In this variant EROW, the maker of the system, acts as the data processor and signs a data processing agreement (DPA); the customer remains the data controller.
With a deployment on your own server, is there a data processor?
No. The data does not leave the customer’s infrastructure. For some companies this is a non-negotiable condition, and then it is the strongest argument for this variant.
Can different periods be set for different categories of data?
Yes. Retention rules are set separately for each category. Their scope is chosen during implementation, starting from the processing purposes defined by the controller.
See also: The entry log and GDPR: who in the company may see driver data · On-premises or cloud: choosing a server for vehicle entry control