DPDP Act Compliance For Fleets: What Your Drivers’ Tracking Data Now Requires

Your fleet software knows where every driver was at 3:40 pm last Tuesday, how hard they braked getting there, and which charger they plugged into afterwards. Under India’s Digital Personal Data Protection Act, 2023, all of that is personal data about an identifiable individual — and the company running the fleet, not the software vendor, is the party the law holds responsible. DPDP Act compliance is therefore not a legal-department exercise. It is a set of decisions about a telematics stack that is already running.

This is written for fleet and HR or compliance leads at companies whose drivers are tracked continuously — delivery, taxi, staff-transport and logistics operators whose vehicles are monitored all shift. It sets aside the general legal reader and the consumer questions that dominate coverage of the Act.

We have argued elsewhere that AIS-140 splits a commercial fleet’s data into two streams: a regulatory feed to the state command-and-control centre, and an operational feed the business runs on. That post owns the first. The Act governs the second — the stream no transport regulation touches, and where nearly all of a driver’s personal data sits.

DPDP Act Compliance Starts With What Your Stack Already Collects

The Act defines personal data as any data about an individual who is identifiable by or in relation to such data. That catches far more of a fleet stack than operators expect: not just continuous location traces, but driving-behaviour scores, charging sessions tied to a named driver, home-charging reimbursement claims, app or biometric attendance, and the vehicle-assignment records binding a registration number to a person.

Six categories most Indian commercial fleets already collect. Each one needs a named purpose, a retention period and an access list.

The Act’s vocabulary matters as much. A Data Fiduciary is whoever determines the purpose and means of processing; a Data Processor merely processes on the fiduciary’s behalf. Your telematics supplier, your charging network and your fleet platform are processors. You chose to track the vehicle, you set the ping rate, you decided who can see the result. Section 8(1) removes the ambiguity: a Data Fiduciary is responsible for compliance “irrespective of any agreement to the contrary” for processing undertaken by it or on its behalf.

That reverses most operators’ instinct. The data sits on a vendor’s servers, so the vendor feels like the owner of the problem; DPDP Act compliance puts it with the company whose name is on the driver’s payslip. Look at what a single driver management module holds as a matter of course — profiles, documents, vehicle assignment, driver-wise charging history by session and charger, and behavioural performance insights. Every one of those is a purpose you now have to be able to name.

The Consent Problem: Why A Signed Form Is Your Weakest Ground

The Act allows processing on two grounds: consent, or one of the “certain legitimate uses” listed in section 7. Most fleets reach for consent, because consent is what the onboarding pack already collects. It is the weaker choice.

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the specified purpose. Read that against the moment a driver signs: a candidate at onboarding, handed a tracking consent form alongside the employment contract, by the party deciding whether to hire them. “Free” and “unconditional” are carrying a lot of weight there. Section 6(2) adds that any part of a consent which infringes the Act is invalid to that extent — so a consent that was never freely given fails exactly where you were relying on it.

Section 7(i) is the better ground. It permits processing “for the purposes of employment or those related to safeguarding the employer from loss or liability”. Dispatch, shift payroll, accident reconstruction, recovery of a stolen vehicle and EV vehicle tracking for asset protection sit inside that phrase comfortably. Selling aggregated driver-behaviour scores to an insurer does not. Nor does watching the vehicle at 9 pm on a Sunday because the driver takes it home.

Be honest about the trade-off, because it runs the opposite way to most commentary. Sections 11 and 12 attach the driver’s rights of access and erasure to processing “for which she has previously given consent, including consent as referred to in clause (a) of section 7”. Employment processing under section 7(i) is not in that formulation. The sturdier ground leaves the driver fewer levers — which is exactly why the internal test has to be necessity, not permission. The grievance right in section 13 is not conditioned on consent and survives either way.

Retention And Access: The Unlimited-History Default Is The Fixable Failure

Section 8(7) is the obligation most fleets are quietly failing. Unless retention is necessary for compliance with a law in force, a Data Fiduciary must erase personal data as soon as it is reasonable to assume the specified purpose is no longer served — and must cause its processor to erase its copy too.

Operators usually ask what the prescribed retention period is. For a fleet there isn’t one. Rule 8(1) of the Digital Personal Data Protection Rules, 2025 attaches a fixed clock only to the classes in the Third Schedule: e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. A logistics or taxi operator is none of those. The absence of a number is not permission to keep everything forever — it is an instruction to set your own and defend it.

Set it by data class, not by database. Raw high-frequency GPS earns a short window sized to dispatch and dispute resolution. Trip summaries feeding payroll, allowances and reimbursement earn whatever period your payroll records already carry. Anything kept indefinitely for fleet analytics — energy per kilometre, route efficiency, depot utilisation — should have the driver identifier stripped first, at which point it stops being personal data at all. That de-identify-then-keep move lets an operator shorten retention without losing a single reporting capability.

The volumes make the argument. Sixty vans pinged every ten seconds across a ten-hour shift produce about 3,600 location points per vehicle per shift, 216,000 a day, close to 7.9 crore in a year — arithmetic on assumptions you should replace with your own. Nobody reviews that history; it accrues exposure.

Access is the other half, and here the Rules are specific. Rule 6(1) requires, at a minimum, encryption, obfuscation, masking or tokenisation of personal data; measures controlling access to the computer resources used; and visibility on who accessed that data, through logs, monitoring and review, with those logs retained for one year. That floor is close to a subset of the controls in ISO/IEC 27001, which is a useful shortcut when you assess a platform — ask what its certificate scope actually covers. The depot consequence is blunter: a shared supervisor login is now a compliance defect, because it makes “who looked at this driver’s history, and why” unanswerable.

The Vendor Clause: What To Get In Writing From Your Platform

Section 8(2) permits a fleet to engage a processor only under a valid contract, while section 8(1) keeps responsibility with the fleet irrespective of any agreement to the contrary. Together they say something uncomfortable: the vendor contract does not move your liability, it only buys you recourse. Which makes four clauses worth arguing over.

• Processing-only terms. The platform processes driver data on your instructions, for your purposes, and for nothing else — no training a shared model on it, no benchmarking other operators with it, no supplying it as an insurance-scoring input, absent a separate written instruction from you.
• A security floor that reads onto rule 6(1). Encryption or masking at rest, role-based access control, access logging with monitoring and review, one-year log retention, and — this is in the rule itself — an express safeguards provision in the contract between fiduciary and processor.
• Breach mechanics tight enough for your clock. Rule 7 puts the duty on you, not the vendor: intimate the Data Protection Board without delay, follow with detailed information within seventy-two hours, and tell each affected driver what happened and what you are doing about it. A contract promising the vendor will tell you “promptly” cannot be reconciled with seventy-two hours. Fix a number of hours.
• Deletion and export on exit. Certified deletion of driver personal data within a fixed period after termination, and a usable export before it. Our AIS-140 checklist already told you to settle who owns the history when you switch vendors; the Act turns that commercial preference into a duty, because section 8(7)(b) makes procuring your processor’s erasure your obligation, not a favour.

None of this waits on the Rules. They were notified on 13 November 2025 and staged deliberately: rules 1, 2 and 17 to 21 took effect on publication, rule 4 one year after, and rules 3 and 5 to 16 — the operating obligations above — eighteen months after publication, which lands in May 2027. The ceilings behind them are not theoretical: the Schedule to the Act, read with section 33(1), allows penalties extending to ₹250 crore for a failure to take reasonable security safeguards and ₹200 crore for a failure to give breach intimation. So start where the effort is smallest and the exposure largest. Write down every category of driver data your stack holds, name the decision each one serves, delete what survives no decision, and set a retention period and an access list against the rest. In a fleet operating system like YoMobility that inventory mostly exists already — DPDP Act compliance rarely changes what a fleet collects, only how long it keeps it and who gets to look.

Frequently Asked Questions

Sources: MeitY — Digital Personal Data Protection Act, 2023 | MeitY — Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)) | PIB — DPDP Rules, 2025 Notified | ISO/IEC 27001:2022 — Information security management

Status and section references verified against the notified texts on 19 September 2026. Operational guidance for fleet operators, not legal advice.