How should location data be processed in employee shuttles under KVKK?
A practical guide to data minimization, privacy notices, masking, access logs and retention periods for processing address and vehicle location data in employee shuttle operations in line with KVKK, Turkey's Law No. 6698 on personal data protection.
Managing employee shuttles inevitably means processing personal data: employees' home addresses, stop assignments, boarding records and the locations of shuttle vehicles. Turkey's Law No. 6698 on the Protection of Personal Data (KVKK, comparable to the GDPR) does not prohibit processing this data; but it expects it to be processed in a way that is limited to the purpose, proportionate, transparent and secure. In this guide, we explain step by step how you can handle location and address data in shuttle operations according to these principles.
Important note: This article is for general information and is not legal advice. For obligations specific to your organization, we recommend consulting your legal department or KVKK consultant.
What personal data is processed in shuttle operations?
The first step is to clarify the inventory. A typical employee shuttle system contains the following data groups:
- Identity and contact: full name, employee number, department, phone, email
- Address data: home address and the location of that address on the map (coordinates)
- Assignment data: which stop, line and shift the employee belongs to
- Boarding data: which trip they boarded, or didn't, on which day
- Vehicle location data: the GPS trace of the shuttle vehicle during the trip
- Driver data: driving license, SRC professional driver certificate and psychotechnical assessment documents (as required in Turkey), assignment records
Let us correct a common confusion here: vehicle tracking is not employee tracking. What is monitored is the location of the shuttle vehicle. However, when the vehicle trace is combined with boarding records, it can indirectly be linked to individuals. That is why the safest approach is to protect vehicle location data as if it were personal data too.
Core principles: purpose limitation and data minimization
The general principles in Article 4 of KVKK translate into shuttle operations as follows:
Purpose limitation
Address data is processed to determine stops, plan lines and assign passengers. Using the same data for, say, performance evaluation or a disciplinary process is a different purpose and must be assessed separately. Not reporting boarding data per person for punitive purposes is a practical application of this principle.
Data minimization
Ask yourself the following questions:
- Is the full address needed for planning, or is the location of the address plus the district enough?
- Is location data collected outside of trips? If so, why?
- Does every member of the operations team need to see every employee's address?
In most cases the answer is "no." Collecting location data only during trips and making addresses visible only to the roles that need them are the two most effective steps toward minimization.
Privacy notice: what should you tell employees?
Under Article 10 of KVKK, you must inform your employees about the processing of their data. A privacy notice covering the shuttle service usually includes the following headings:
- The identity of the data controller
- The categories of data processed (address, location, boarding, etc.)
- The purposes of processing (shuttle planning, operations, cost management)
- The legal basis or bases
- The parties to whom the data is transferred (e.g. the shuttle vendor, the software provider)
- The collection method (HR system import, employee portal, driver app)
- The data subject's rights under Article 11 of KVKK
Which legal basis applies and whether explicit consent is required can vary from organization to organization; it is important to make this assessment together with your legal department.
Role-based access and address masking
The data that carries the most risk is the full address and exact location. The practical way to protect it is to divide access into layers:
| Role (example) | Address information visible | Rationale |
|---|---|---|
| Shuttle planning specialist | Full address and location | Stop and line design |
| Operations manager | District / province, stop information | Daily trip management |
| Department manager | No address, only shuttle and stop | Knowing their staff's shuttle |
| Vendor representative | No address, their own trips | Running trips |
The table is a hypothetical example; define the roles according to your organization's structure.
The principle is simple: mask by default, reveal only what is needed. Partial masking can also be applied to contact details such as phone numbers and email addresses.
Access logs: who saw what, and when?
Most systems have a change log (audit log); but from a KVKK perspective, viewing matters too. Recording who viewed a sensitive field such as a full address or exact location, on which screen and when:
- deters unauthorized, curiosity-driven access,
- enables an investigation when a breach is suspected,
- makes the principle of accountability concrete.
It is good practice for access logs to be immutable and to be purged themselves after a certain period.
Retention periods and destruction
KVKK requires data to be kept only as long as necessary for the purpose for which it is processed. In shuttle operations, it makes sense to define different periods for different types of data:
- Trip traces (vehicle GPS history): the period needed for vendor payment and dispute processes
- Old addresses: a reasonable period for planning history after an address changes
- Notification and message delivery records: a short period
- Access logs: according to audit needs
- Employees who have left: anonymizing identity fields and deleting the address after a certain period; keeping historical statistics in anonymous form
Make sure the periods are consistent with your organization's personal data retention and destruction policy. Most importantly, destruction should not be a task someone has to remember to do by hand; it should run automatically and regularly.
Encryption and technical measures
Article 12 of KVKK requires appropriate technical and administrative measures for data security. The main technical measures for shuttle systems are:
- Storing the address text encrypted in the database
- Separating data between organizations at the database layer (in multi-tenant systems)
- Two-factor authentication and enterprise single sign-on (SSO)
- Regular backups and restore tests
- TLS encryption in transit
AI and cross-border data transfers
AI assistants are becoming common in shuttle software. The large language model providers these assistants use are mostly located outside Turkey. Under Article 9 of KVKK, transfers abroad are a matter that needs to be assessed separately. Points to watch:
- It should be clear exactly what data goes to the model; not sending data such as personal names, addresses and coordinates significantly reduces the risk.
- The provider should be consciously chosen by the organization, and the feature should not work until explicit approval has been given for the transfer.
- Assistant conversations should also have a retention period.
How does RotaMerkezi support these principles?
RotaMerkezi offers many of the measures above out of the box. For details, see the Security and privacy page:
- Encrypted addresses: employee address text is stored encrypted.
- Server-side masking: address information is never sent to users without permission; the full address is revealed with a separate permission, and contact details are partially masked.
- Access logs: views of full addresses and exact locations are recorded immutably.
- Retention jobs: trip traces, old addresses, notifications, message records, Copilot conversations and access logs are purged automatically every day according to the periods in the organization's settings; inactive employees can optionally be anonymized.
- Purpose-limited location: location data is not collected outside of trips; boarding data is not reported per person for punitive purposes.
- Explicit approval for AI: the AI features work only when the organization has chosen the provider and given explicit approval for cross-border data transfer; no personal names, addresses or coordinates are sent to the model.
- Data scope: users see only the employees of the departments and regions they are authorized for (people and organization).
These features make your organization's KVKK compliance work easier; but decisions such as the privacy notice, legal basis and retention policy belong to your organization as the data controller.
If you would like to see together how you can protect your organization's shuttle data, you can request a demo.
Frequently asked questions
Does monitoring the shuttle vehicle's location mean monitoring employees?
No, what is monitored is the vehicle's location. However, because the vehicle trace can be linked to individuals when combined with boarding records, it is recommended to protect this data as personal data too, collect it only during trips and define a retention period.
Who should see an employee's full address?
Only the roles that plan stops and lines and genuinely need it. For other users, showing district-level information or no address at all is an approach consistent with the principle of data minimization.
Does using an AI assistant create problems under KVKK?
That depends on what data goes to the model and on what legal basis the transfer is made. A design that sends no personal data and the organization's explicit approval reduce the risk; we recommend making the final assessment with your legal department.