Data privacy in fleet software: Clarify data, purposes and access

Data privacy in fleet software starts with the question of which personal data you need for which specific purpose. Vehicle assignments, charging locations, booking times and location data can make employees identifiable. Before implementation, you should therefore review legal bases, necessary data, access rights and deletion together with the responsible specialists.

A software function alone does not make processing lawful. This article provides an organisational aid for assessing requirements. The legal assessment must account for your actual use, particularly where employee data, location tracking and private vehicle use are concerned.

Identify personal data and the purpose of its use

A vehicle number can be personal data if it can be linked to a particular person. This also applies when the name appears in a separate list. Consider the entire data flow: from the vehicle or charging session through the assignment to the report and export.

Data protection principles require, among other things, a specified purpose, restriction to necessary data and limited storage. The European Data Protection Board also lists transparency, accuracy, integrity and confidentiality, as well as the ability to demonstrate compliance. Source: principles for processing personal data.

Define purposes precisely. “Manage the fleet” is of limited help when designing individual processing steps. “Assign charging costs to a vehicle and cost centre” makes it clearer which information is needed. Assess additional uses separately before using existing data for a new purpose.

Review employee data and participation rights early

In an employment context, the legal basis must be assessed against the specific purpose. Section 26 of Germany’s Federal Data Protection Act, the BDSG, contains provisions on processing for employment-related purposes. For consent, the employee’s dependency within the employment relationship and the circumstances in which consent is given must be considered when assessing whether it is voluntary. A signed declaration is therefore not a blanket authorisation. Source: section 26 BDSG.

Involve the responsible employee representatives in good time. For works councils, section 87(1)(6) of Germany’s Works Constitution Act, the BetrVG, provides a co-determination right concerning the technical devices described there for monitoring behaviour or performance. Which participation rights apply in a particular organisation or with public-sector employers must be clarified for the planned use. Source: section 87 BetrVG.

Before a pilot, define which analyses are planned. A cost centre overview and an individual movement profile are separate processing scenarios. For each scenario, document the assessment, permitted recipients and any agreed limits on use.

Treat location tracking and private use as separate cases

First check whether your operational purpose requires continuous location data at all. A reservation may only need a collection location and return time. A specific dispatch task may require other information. This necessity must be justified.

Where private use is permitted, a clearly described technical and organisational framework is required. Record which data is collected during this time, how employees can recognise the setting and which parties have access. Test implementation with the responsible data protection specialists before recording actual private journeys.

Include exceptions too: how is a device failure handled? Which information remains in exports? Which data continues to be retained after a change? A documented overview of fleet software integrations helps assess the data flows.

Document service providers, access and deletion

Clarify the data protection roles of the parties involved. If a service provider processes personal data on your behalf and under your instructions, the requirements for processing on behalf of a controller must be considered. These include a binding agreement containing the required terms. The Berlin data protection authority also explains that a service provider’s own decision-making powers may require a different classification. Source: guidance on processing on behalf of a controller.

Ask for an explanation of data categories, subprocessors, processing locations, safeguards and possible third-country connections. Connect this to a concrete roles and permissions model. Include checks on exports, cover arrangements and revocation of access after a change in duties.

For every data category, you need a justified retention and deletion rule. Account for applicable retention obligations and different purposes. Also clarify information obligations, data subject rights and the need for a data protection impact assessment. Article 35 GDPR requires this where processing is likely to result in a high risk. Source: GDPR, in particular Articles 13–22 and 35.

Practical example: A monthly charging report

Fictional organisational example: Finance needs monthly charging costs per cost centre. Two authorised people handle the operational assignments. For the regular report, the team checks whether totals per cost centre fulfil the purpose and whether individuals remain identifiable from them.

The team defines which detailed data is needed to resolve errors and who may view it. The regularly distributed report contains the approved scope of information. For very small groups, possible identifiability is expressly included in the assessment.

A test export is then checked. It accidentally contains an extra column with driver names. The export template is adjusted before use. The example shows why data protection also covers the actual output and distribution.

Practical tool: A data card for each processing activity

For every significant activity, document:

1. The specific purpose and assessed legal basis.

2. Data categories, people affected and data sources.

3. Recipients, access roles and permitted exports.

4. Service providers involved and their clarified roles.

5. Retention periods, the deletion process and required evidence.

6. Information for data subjects and responsible contacts.

7. Open risks, assessment decisions and the next review date.

Before implementation, go through the cards with data protection, IT, fleet management and, where required, employee representatives. Check the actual settings against the approved requirements. Repeat the assessment when adding data sources or changing the purposes of analysis.

Bring the approved data cards to the operational requirements discussion: clarify your requirements with StromNow.