+150 XP

Running the privacy and data audit: a hands-on checklist

A single modern connected car generates roughly 25 gigabytes of data per hour (a figure widely cited across industry sources, order-of-magnitude, not exact). GPS pings, cabin microphone activations, brake pressure, driver-facing camera frames. Now imagine a regulator asking your OEM (Original Equipment Manufacturer, the carmaker) a simple question: "Show me every place this vehicle's location was stored, who consented, and when you deleted it." If you cannot answer in a week, you have a problem. This lesson walks you through the audit that finds that problem first.

Why this audit exists

Connected-vehicle data is now heavily regulated. The main laws you must name:

  • GDPR (General Data Regulation, EU): governs any personal data from EU drivers. Location and in-cabin data are personal data. Fines reach up to 4 percent of global annual revenue.
  • CCPA/CPRA (California Consumer Privacy Act, amended by the California Privacy Rights Act): gives California residents rights to know, delete, and opt out of sale of their data.
  • The EU's EDPB Guidelines 01/2020 on connected vehicles, which explicitly address location, biometric, and telematics data. Read them here: EDPB connected vehicle guidelines.

In 2023, US regulators and press scrutiny landed hard on automakers sharing driving-behavior data with data brokers and insurers, sometimes without clear consent. That is the exact failure mode this audit catches.

Key terms before we start:

  • PII (Personally Identifiable Information): data that identifies a person. A VIN (Vehicle Identification Number) tied to an owner is PII.
  • Data lineage: the documented path of a data element from origin (a sensor) to every store and downstream use.
  • Retention: how long you keep data before deletion.
  • Consent: a specific, informed, freely given agreement to a defined processing purpose.

The pipeline you are auditing

Picture a typical telematics pipeline:

Vehicle sensors to in-car gateway to cloud ingestion to data lake to analytics/ML to third-party sharing (dealers, insurers, mapping partners).

Your job is to walk this pipeline and stamp each stage against three failure modes: un-consented collection, over-retention, and missing lineage.

Step 1: build the data inventory

You cannot audit what you cannot see. Start with a complete inventory of data elements flowing through the pipeline.

For each element, capture: source sensor, data category, whether it is PII, the consent basis, retention period, and every storage location.

A minimal inventory row looks like this:

ElementCategoryPII?Consent basisRetentionStores
GPS lat/longLocationYesOpt-in (nav feature)30 daysingest topic, lake, maps partner
Hard-braking eventsTelematicsYes (via VIN)??????lake, insurer feed

The "???" cells are exactly where audits find fines. In our example, hard-braking events flow to an insurer but the consent basis is undocumented. Flag it.

Step 2: trace location data end to end

Location is the highest-risk category in connected vehicles. The EDPB treats precise geolocation as especially sensitive because it reveals home, workplace, and habits.

Run this check: pick one VIN and follow its GPS data through every system.

Ask:

  • Was location collected only for a purpose the driver agreed to (for example, navigation)?
  • Did it leak into a purpose the driver did not agree to (for example, a marketing model or a broker feed)?
  • Is it stored longer than the stated purpose requires?

A practical query against your event store to spot location data sitting in the wrong topic:

sql
-- Find location fields present in topics that should not carry them
SELECT topic_name, field_name, COUNT(*) AS records
FROM data_catalog_fields
WHERE field_name IN ('gps_lat', 'gps_long', 'geohash')
  AND topic_name NOT IN ('navigation_service', 'emergency_ecall')
GROUP BY topic_name, field_name
ORDER BY records DESC;

If marketing_events or partner_export shows up in the results, you have found un-consented location logging. This is the single most common finding in real audits.

Step 3: test consent against reality

Consent on paper is not consent in the pipeline. Verify that the technical system honors what the driver actually chose.

Concrete test: create a test account, opt OUT of location sharing in the vehicle's privacy menu, drive a route, then check whether GPS still landed in the analytics lake. If it did, consent enforcement is broken.

For EU drivers, remember the eCall exception. Mandatory emergency call systems can collect location without consent, but only for the emergency purpose. If that same eCall location feeds an analytics dashboard, that is unlawful repurposing.

Step 4: audit retention

Over-retention is keeping PII past the point it is useful or lawful. Regulators expect a defined, documented, and enforced retention schedule.

Check three things:

  1. Is there a written retention period per data category?
  2. Is deletion actually automated (not "we delete on request")?
  3. Do backups and third-party copies also expire?

That third point catches people. You delete GPS from the lake after 30 days, but a mapping partner keeps it for two years under an old contract. Under GDPR, you are still the controller and remain responsible.

A quick worked example

Suppose you store raw GPS for 10 million vehicles, each sending one ping every 10 seconds, and your stated retention is 30 days.

  • Pings per vehicle per day: 8,640 (6 per minute times 60 times 24)
  • Over 30 days: 259,200 pings per vehicle
  • Across 10 million vehicles: about 2.59 trillion location records live at any time

If your policy says 30 days but your lake still holds pings from 90 days ago, you are holding roughly 3 times the lawful volume. That is a concrete, measurable finding you can hand a regulator or your own board. (Illustrative math, not a real fleet.)

Knowledge check

1. A regulator asks an OEM to show every place a vehicle's location was stored, who consented, and when it was deleted. Which capability is MOST directly being tested by this request?

2. Why is a VIN tied to an owner treated as PII, while a VIN alone might be treated differently?

3. The lesson notes a connected car generates roughly 25 GB of data per hour. What is the main conceptual reason this figure matters for a privacy audit?

MULTIPLE CHOICE

4. Select ALL correct answers about how GDPR applies to connected-vehicle data.

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers describing failure modes this privacy audit is designed to catch.

Select all the correct answers.

Step 5: verify data lineage

Missing lineage is the failure that makes every other problem unfixable. If you cannot trace where a data element came from and where it went, you cannot honor a deletion request, prove consent, or scope a breach.

For each PII element, you need a traceable chain: sensor to gateway to topic to table to export.

Tools like OpenLineage or a data catalog (Collibra, Alation, or open-source alternatives) capture this. But the audit test is simple: pick a driver, issue a Data Subject Access Request (DSAR, the legal right to see one's own data), and time how long it takes to assemble every copy of their data. If it takes more than the legal window (GDPR requires a response within one month), your lineage is inadequate.

Step 6: check third-party sharing

The 2023 scrutiny of automakers centered here: driving data flowing to brokers and insurers. For every outbound feed, verify:

  • A signed data processing agreement exists.
  • The shared fields match what consent covers (no sneaking VIN plus location into a "diagnostics" feed).
  • The partner's retention aligns with yours.

Document the balance of power honestly. Large OEMs (Toyota, Volkswagen, GM, Ford, Stellantis) sit at the center; mapping providers (Google, HERE), insurers, and data brokers pull data outward. You, the controller, carry the liability no matter how big the partner is.

Step 7: write the findings

An audit is worthless without a ranked findings list. Rate each issue by regulatory exposure and likelihood, and assign an owner and a deadline. Example:

  • Critical: GPS in partner_export with no consent basis. Owner: Data platform lead. Fix in 14 days.
  • High: Retention not enforced on backups. Owner: Infra. Fix in 30 days.
  • Medium: DSAR assembly takes 6 weeks. Owner: Governance. Fix in 60 days.

Key Takeaways

  • Start every audit with a complete data inventory; the empty cells (unknown consent, unknown retention) are where fines hide.
  • Location is the highest-risk category in connected vehicles; trace one VIN end to end and prove it never entered an un-consented store.
  • Test consent and retention against the live pipeline, not the policy document; opt out with a test account and confirm the data actually stops.
  • Over-retention is measurable; compare stated retention to actual data age and quantify the excess.
  • If a DSAR takes longer than one month to fulfill, your lineage is broken, and every other control is unenforceable.