What a Connected-Car Privacy Duty Requires

The GM/OnStar matter answers the title’s question by shifting attention from the existence of a privacy policy to the continuity of the data’s life. A connected-car privacy duty requires a business to keep each transition—collection, service use, disclosure, retention, consumer choice, and final disposition—tied to a defensible purpose. This final synthesis brings those transitions together so a reader can judge a new use without sacrificing necessary safety or service functions and without treating an undisclosed, unnecessary, or indefinite reuse as an automatic consequence of enrollment.

A duty that travels with the data

The most important distinction in the GM/OnStar record is between a data category and a data lifecycle. “Driving data” is not a complete analysis. A hard-braking event, a precise location, a name, a vehicle identifier, and an inference from repeated trips may travel together, but each field can have a different purpose and different consequences. The recipient can matter just as much as the field. A connected service, a service provider, a contractor, a data broker, and a regulator do not occupy the same relationship to the consumer.

The complaint alleges that GM and OnStar collected names, contact information, driving behavior, and precise geolocation through OnStar and Smart Driver. It describes consumer-facing uses such as driving feedback, emergency assistance, and directions. It then alleges that GM sold OnStar and Smart Driver data to LexisNexis Risk Solutions and Verisk Analytics for driver-rating products intended for insurers. The complaint alleges that Verisk’s contract barred precise geolocation while Lexis received GPS data linked to driving events, including ignition-off locations that could reveal where vehicles were parked. It further alleges that an opt-out mechanism did not affect the transfers.

Those allegations are not a complete finding about every GM system or every connected-car business. They are a concrete illustration of why the duty has to travel with the data. At the first transition, the business must explain why a vehicle or service needs the information. At the second, it must explain whether the new use and recipient fit the consumer’s context. At the third, it must justify each field and the period for which it remains available. At the fourth, it must show that consumer choices, deletion instructions, and governance controls reach the actual path.

The CCPA gives this continuity legal structure. It requires notice at or before collection about categories, purposes, sale or sharing, and intended retention. It requires collection, use, retention, and sharing to be reasonably necessary and proportionate to a disclosed or compatible purpose. It recognizes rights to access, correct, delete, opt out of sale or sharing, and limit the use or disclosure of sensitive personal information, subject to their statutory conditions. It also assigns responsibilities to recipient relationships and creates enforcement routes.

The result is not a demand that a connected vehicle forget everything immediately. It is a requirement to keep the reason for processing visible as the record changes state. A location used to answer an emergency call may be justified for that response. That fact does not prove that the same location should be kept for years, attached to a driving profile, or transferred to a broker for a separate product. A privacy duty is continuous because necessity, sensitivity, audience, and risk can change even when the underlying signal remains the same.

A defensible decision at each transition

A business evaluating a new connected-car use can apply the lifecycle model through a set of linked questions. They are not a substitute for legal advice or a universal compliance checklist. They are a way to prevent one favorable fact—such as consumer enrollment, a legitimate safety function, or a protective contract—from obscuring the other decisions that still need evidence.

Begin with the consumer context and the exact field

The first question is what the consumer was being asked to do and what information the proposed use actually needs. In the GM/OnStar setting, that means separating the OnStar or Smart Driver service from the specific signal: a driving event, a precise coordinate, an account identifier, or a combination of those fields. It also means distinguishing data produced by a vehicle or mobile app from information supplied directly by a consumer.

This level of detail is not needless technicality. It tells the business what can be learned and what a recipient can use. A hard-braking indicator may support feedback without requiring the precise place where the event occurred. A current location may support emergency response without justifying a historical location trail. A name or VIN may be needed to connect a service request to a vehicle, but that does not establish why every downstream product needs the same identifier.

The judgment’s definitions show the value of keeping scope explicit. Its “covered driving data” is tied to information originating from a vehicle or GM-branded mobile app, precise geolocation, and specified events linked or reasonably linkable to a California OnStar customer. Its “covered OnStar data” concerns specified identifiers or a VIN disclosed to third parties with covered driving data. Those are case-specific categories. They should not be silently expanded into every form of vehicle telemetry, nor should a business assume that a control for one category governs a different one.

State the original purpose, the proposed purpose, and the recipient

The next question is why the information entered the system and why someone now wants to use it. The original purpose might be to provide driving feedback, directions, emergency assistance, diagnostics, or another connected-car function. The proposed purpose might be a new analytics service, a third-party product, or a rating built for another industry.