Who Owns Your Fleet Data When the Relationship Ends?
- ktaylor
- 11 minutes ago
- 7 min read
Fleet Continuity Series · Part 2
Part one looked at what happens when your fleet management software vendor is acquired. Part two turns to the moment the relationship ends, whatever the cause, and what becomes of your data and devices when it does.

Most fleet operators assume the data their operation produces belongs to them. Years of route history, delivery records, driver performance, and maintenance logs sit inside the system, and it feels self-evident that a business owns the record of its own work. That assumption holds right up until the relationship with the platform ends. The question of who owns fleet data has a less comfortable answer than it first appears, and it matters most at the moment operators think about least: the end of the platform’s life, the contract, or a device’s supported life.
Who Actually Owns Your Fleet Data?
Ownership of fleet data is not a default you can assume. It is a term set by the contract you signed with the platform, and it varies more than most operators realise. Consider the two ways a vehicle can be connected. Data from a manufacturer’s built-in telematics is transmitted to the manufacturer and governed by their data-sharing terms, so the operator sees it on the manufacturer’s conditions. Data from an aftermarket platform is typically the operator’s to export and integrate, regardless of a later change in vehicle or platform.
The distinction is architectural, not a matter of goodwill, and it decides what an operator can take with them when the relationship ends. International guidance on cloud-service contracts makes the same point in plainer terms: settle data ownership, retention, and deletion with the provider in the contract, before you sign, not after [1].
The practical test is simple to state and often uncomfortable to answer: can you export your full history, in a format you can use, and how long does the window to do so stay open once the contract lapses? If the answer is not written into the agreement, you have no way to enforce it when the relationship turns.
Your Platform Holds Two Kinds of Data, and They Carry Different Risks
Before planning for end of life, it helps to separate the two kinds of data a fleet system holds because they behave very differently when the relationship ends.
The first is data about your drivers: who they are, where a named driver was and when, their behaviour scores, their hours. Because this is information about identifiable people, it is the kind of data privacy rules across the region are built to govern, and that protection is tightening [2][3][4]. It is also the data that becomes complicated to move, particularly across borders.
The second is data about your operation rather than about a person: route history, delivery records, vehicle diagnostics, fuel and maintenance logs. This data usually sits outside those privacy rules, which means recovering it at the end tends to depend less on regulation and more on the terms of your agreement with the platform [1].
The distinction matters because the two carry different risks and need different responses. Driver data raises a privacy and cross-border question, answered by knowing where it is held and under whose rules. Operational data raises a contract question, answered by what you negotiated on export and retrieval. Attaching the wrong concern to the wrong data leads an operator to fix the wrong thing.

When the Platform Goes, So Do the Devices and the Access
End of life is not only a question of data in the cloud. A fleet system depends on physical devices in every vehicle, the units that stream telemetry from the engine and onboard systems, and those have an end of life of their own. It arrives in two ways. A device can reach the point where the manufacturer stops issuing firmware updates, leaving it unsupported and, over time, a security weakness rather than an asset. Or it can depend on a vendor’s cloud service being switched off, at which point working hardware simply stops working.
The risk is not hypothetical, and it is not confined to consumer gadgets. In August 2023, Google shut down Google Cloud IoT Core, the managed service it had marketed for connecting and managing devices at scale, including in transportation and utilities. On the retirement date, devices could no longer connect and existing connections were closed, leaving operators who had built on it to migrate in time or lose the link to their hardware [5]. A telematics estate tied to a discontinued or retired platform faces the same failure: working hardware that stops working because the service behind it was switched off. Fleet hardware is replaced on a three to seven-year cycle in any case [6], so the question is not whether devices reach end of life but whether their retirement is planned, with credentials revoked and data wiped [6], or left to happen by default. Decide in advance who is responsible for decommissioning the hardware, and the difference becomes a task on someone’s list rather than a gap nobody owns.
The access to those devices is the risk operators are most likely to miss. When a platform is dropped or devices retired, the access is frequently left open. Dashboards stay live, vendor accounts remain active, and login credentials, including those of employees who have since left, keep working, because nobody folds the telematics system into the offboarding routine used for email and building access [7]. An abandoned account with live access to route history and driver records is a liability whether or not anyone still uses the system, and it persists until someone thinks to look. Treat the end of a platform relationship as an access-management event, not merely a data-export one, and those doors get closed.

In ASEAN, Getting Your Data Back Crosses Borders
For a fleet operating across more than one ASEAN market, the driver-data question carries a complication a single-country operator never faces. Driver data may be held under the rules of the country it was collected in, and moving it, which is exactly what end-of-life retrieval requires, can trigger cross-border transfer obligations that differ from one market to the next.
The regional picture is specific and current. Vietnam’s Law on Personal Data Protection, in force from 1 January 2026, requires a cross-border transfer impact assessment to be filed with the authorities within 60 days of the first transfer and sets penalties of up to 5 per cent of annual revenue for transfer violations [2][3]. Indonesia’s Personal Data Protection Law has been in full effect since October 2024 and sets its own conditions on moving personal data out of the country [2]. Thailand’s regime restricts transfers to jurisdictions it recognises as offering adequate protection, of which it has so far designated none [4].
Singapore, by contrast, imposes no general data-localisation requirement, so it is important not to assume the whole region behaves like its strictest members [4]. Where transfers are needed, the ASEAN Model Contractual Clauses, adopted by the region’s digital ministers in January 2025, give operators a recognised mechanism to rely on [4].
The practical consequence is that recovering driver data at end of life is not a single action but several, one per jurisdiction, each with its own conditions. An operator who knows in advance which markets hold which data can plan the retrieval. One who does not will discover the complexity at the worst possible moment.
What to Settle Before End of Life
None of this requires an operator to change platforms or to treat every contract as a liability. It requires settling a small number of things in advance, while there is still leverage to settle them, because the end of a relationship is the one moment at which they cannot be renegotiated.
Three are worth fixing at the next contract renewal.
Data. Establish in writing that your operational history can be exported in a machine-readable format you can actually use, such as a structured data file or direct access through an interface, rather than a locked report and that a defined retrieval window stays open after the contract ends rather than an open-ended assumption.
Devices. Make explicit whether you or the vendor is responsible for decommissioning the hardware when the relationship ends, or a device reaches end of support, so that credentials are revoked, and data is wiped by a named party rather than left to whoever notices.
Access. Fold the platform into the same joiners-and-leavers process that governs the rest of your systems, so that vendor accounts and former-employee logins are closed on the same schedule as email and building access, not left standing after the relationship ends.
Settle those three and the end of a platform relationship becomes a managed handover. Leave them unsettled, and it becomes a scramble to recover what you assumed was always yours.
Closing
The end of a vendor relationship is not the dramatic risk in fleet management, and that is why it goes unplanned. It is quiet, it is deferred, and it arrives with the least warning of any moment in the platform’s life. The operators who come through it intact are the ones who settled ownership, retrieval, device retirement, and access while the relationship was healthy and the terms were still open to negotiation. The data an operation produces can belong to it at the end, but only if the operator made sure of it at the start.
SAAN Mobility A fleet management platform for last-mile fleets across ASEAN, built so your operational data stays exportable, and your operation stays yours.
References
1. United Nations Commission on International Trade Law (UNCITRAL), Notes on the Main Issues of Cloud Computing Contracts, on customer rights to data and the terms to settle in the contract, 2019.
2. Data localisation and cross-border transfer requirements across Southeast Asia (ASEAN Briefing; Recording Law), 2025 to 2026.
3. Rouse and Tilleke & Gibbins analysis of Vietnam’s Law on Personal Data Protection (Law 91/2025/QH15), including the 5 per cent cross-border penalty and CTIA requirement; DataGuidance, 2025 to 2026.
4. Data localisation and transfer issues in Southeast Asia, including Thailand, Singapore, and the ASEAN Model Contractual Clauses (Lexology; Rouse), September 2025.
5. Coverage of Google Cloud IoT Core’s retirement on 16 August 2023 and its effect on connected-device deployments (iTnews; IT Pro; The Stack; InfoQ), 2022 to 2023.
6. IoT and telematics device lifecycle management guidance: refresh cycles, secure decommissioning, credential revocation, and certified data erasure, 2025 to 2026.
7. Reporting on telematics access and deprovisioning gaps in fleet operations, July 2026.



Comments