Autosalona datu pārvaldības un BDAR rokasgrāmata

1. Inventarizējiet mērķus pirms sistēmām

Viena un tā pati persona var būt potenciālais klients, pircējs, aizņēmējs, transportlīdzekļa naudotājs, servisa klients, sūdzības iesniedzējs vai darbinieks. Tas pats VIN var parādīties vērtēšanā, reģistrācijā, finansējumā, apdrošināšanā, garantijā, remontā, ceļa palīdzībā un savienotos pakalpojumos. Sistēmu inventarizācija vien nevar parādīt, vai atkārtota izmantošana ir likumīga vai gaidīta.

Izveidojiet apstrādes karti pēc mērķa. Katrai darbībai reģistrējiet datu subjektus, kategorijas, avotu, tiesisko pamatu, saņēmējus, pārsūtījumus, saglabāšanu, drošību, automatizētus lēmumus un atbildīgo. Saistiet to ar 30. panta apstrādes ierakstu, kur piemērojams. Nošķiriet datus, kas vajadzīgi līguma izpildei, no neobligāta mārketinga un analītikas. Nesaistiet nesaistītus mērķus vienā piekrišanā.

BDAR pieprasa likumību, godīgumu un pārredzamību; mērķa ierobežojumu; datu minimizāciju; precizitāti; glabāšanas ierobežojumu; drošību; un pārskatatbildību. [1] Šie principi nav tikai dokumentācijas prasības. Tiem jāmaina, kuri CRM lauki ir obligāti, kuras lomas var eksportēt klientu sarakstu un kad tiek noņemti novecojuši potenciālo klientu dati.

2. Klasificējiet klienta un transportlīdzekļa datus kontekstā

Vārdi, personiskās e-pasta adreses, telefonu numuri, paraksti un finanšu dati ir skaidri personas dati. Transportlīdzekļa datiem vajadzīga kontekstuāla analīze. VIN, reģistrācija, atrašanās vietas pēdas, braukšanas modelis, servisa vēsture vai auto iekšējais identifikators var attiekties uz identificējamu īpašnieku, turētāju, vadītāju vai pasažieri. Pseidonimizācija mazina risku, bet ne obligāti izved datus ārpus BDAR, ja atkārtota identificēšana joprojām ir iespējama.

Eiropas Datu aizsardzības kolēģijas vadlīnijās par savienotiem transportlīdzekļiem uzsvērts, ka liela daļa transportlīdzekļa radīto datu ir personas dati, un kā īpaši jutīgas kategorijas kontekstā izceltas atrašanās vietas, biometriskie un ar pārkāpumiem saistītie dati. Tās dod priekšroku vietējai apstrādei, kur iespējams, un naudotāja kontrolei pār ievākšanu. [2]

Klasificējiet laukus pēc jutīguma un mērķa, nevis pēc lietotnes. Ieraksta dati vienā darba plūsmā var būt parasti, bet kombinācijā atklājoši. Brīvā teksta piezīmes ir īpaši riskantas, jo darbinieki var ievadīt veselības, ģimenes, finanšu vai sūdzību detaļas bez struktūras. Izmantojiet uzvedinājumus, mācības un ierobežotus laukus, lai mazinātu nevajadzīgu ievākšanu.

3. Noskaidrojiet lomas starp tirgotāju, grupu, OEM un piegādātājiem

Tirgotājs bieži ir pārzinis pārdošanas un servisa darbībai, bet attiecības atšķiras. OEM var būt neatkarīgs pārzinis garantijas vai savienoto pakalpojumu jomā, kopīgs pārzinis kopīgi noteiktai kampaņai vai saņemt datus saskaņā ar citu definētu vienošanos. DMS sniedzējs parasti darbojas kā apstrādātājs mitinātiem tirgotāja datiem, bet var būt pārzinis savai konta administrēšanai vai drošības žurnāliem.

Nekopējiet lomas apzīmējumu no līguma, nepārbaudot realitāti. Jautājiet, kas nosaka mērķi un būtiskos līdzekļus, kas atbild uz tiesību pieprasījumiem, kas kam paziņo par pārkāpumu, kuri apakšapstrādātāji ir iesaistīti un vai dati tiek izmantoti modeļu apmācībai vai klientu salīdzināšanai. Dokumentējiet kopīgošanas pamatu un datu minimizāciju katrā saskarnē.

Piekļuve savienotas transportlīdzekļa datiem tagad krustojas arī ar ES Datu aktu. Eiropas Komisijas 2025. gada nesaistošās automobiļu vadlīnijas skaidro, kā Datu akta jēdzieni attiecas uz transportlīdzekļa datiem, vienlaikus uzsverot, ka BDAR turpina attiekties uz personas datiem. [3] Tiesības piekļūt produkta datiem vai tos kopīgot nav visaptveroša atļauja ignorēt privātuma tiesības.

4. Izstrādājiet tiesisko pamatu un pārredzamību ap klienta ceļu

Šī tabula ir sākumpunkts, nevis juridisks noteikums. E-privātuma un tiešā mārketinga noteikumi atšķiras pēc kanāla un nacionālās ieviešanas. Piekrišanai jābūt brīvi dotai, konkrētai, informētai, nepārprotamai un atsaucamai. Leģitīmām interesēm vajadzīgs mērķa, nepieciešamības un līdzsvara izvērtējums.

Nodrošiniet slāņotus paziņojumus nozīmīgos brīžos, nevis vienu attālu privātuma lapu. Izskaidrojiet būtisko apstrādi iesūtīšanas, izmēģinājuma brauciena, pirkuma, servisa un lietotnes savienojuma brīdī. Padariet preferences viegli maināmas un izplatiet atsaukšanu uz katru attiecīgo kampaņas sistēmu.

5. Kontrolējiet identitāti, precizitāti, piekļuvi un saglabāšanu

Klientu sasaiste palīdz nepārtrauktībai, bet var arī nepareizi apvienot divas personas. Izmantojiet pārbaudītus identifikatorus, pārliecības līmeņus, pārskatiet nozīmīgas apvienošanas un atgriezenisku audita pēdu. Saglabājiet, kurš avots sniedza vērtību. Tirgotājam jāspēj izskaidrot, kāpēc persona saņēma ziņu, un ātri labot piederības izmaiņu.

Ieviesiet uz lomām balstītu piekļuvi un pienākumu nodalīšanu. Pārdevējam var būt vajadzīgs pašreizējais kontakts un darījuma konteksts, nevis neierobežoti eksporti vai algu dati. Grupas ziņošanai var būt vajadzīgi apkopoti filiāles dati, nevis klienta līmeņa detaļas. Pārskatiet privileģētas lomas un neaktīvus kontus. Reģistrējiet piekļuvi augsta riska datu kopām un izmeklējiet masveida eksportus.

Nosakiet saglabāšanu pēc ieraksta un mērķa. Nodokļu dokumentiem, līgumiem, garantijas pierādījumiem, neveiksmīgiem potenciālajiem klientiem, zvanu ierakstiem, atrašanās vietas datiem un modeļu apmācības paraugiem vajadzīgi dažādi periodi. Ņemiet vērā noilguma termiņus un juridiskus saglabāšanas pienākumus, tad dzēsiet vai anonimizējiet. Pārbaudiet dublējumus un lejupējās integrācijas, lai priekšpuses dzēšana nebūtu tikai kosmētiska.

6. Padariet darbojošās tiesības, DAIN un incidentus

Izveidojiet pārbaudītu pieņemšanas procesu piekļuves, labošanas, dzēšanas, ierobežošanas, iebilduma un pārnesamības pieprasījumiem. Meklējiet pēc klienta un transportlīdzekļa identifikatoriem CRM, DMS, zvanu, dokumentu un mārketinga sistēmās. Pirms izpaušanas pārskatiet trešo pušu datus un citu personu tiesības. Reģistrējiet lēmumu un atbildes datumu.

Izmantojiet datu aizsardzības ietekmes novērtējumu, kur apstrāde varētu radīt augstu risku, īpaši sistemātiskai uzraudzībai, jauniem savienotiem datiem vai nozīmīgiem automatizētiem lēmumiem. DAIN jāietekmē dizains pirms palaišanas. Tas nav retrospektīvs apstiprinājuma veidlapa.

Sagatavojiet pārkāpumu šķirošanu. Darbiniekiem jāatpazīst nepareizi nosūtīti rēķini, atklāti eksporti, konta kompromitēšana un izpirkuma programmatūra kā iespējami personas datu incidenti. Ātri fiksējiet faktus, ierobežojiet piekļuvi, saglabājiet pierādījumus un atbalstiet pārziņa novērtējumu par paziņošanas pienākumiem. BDAR nosaka 72 stundu uzraudzības iestādes paziņošanas periodu, kad ir sasniegts piemērojamais riska slieksnis. [1]

Kur iederas Omnetic

Omnetic dokumentētie moduļi ienes klienta, transportlīdzekļa, darījuma, komunikācijas, pārbaudes, krājuma un cenu kontekstu darbības procesos. Šī nepārtrauktība var atbalstīt precizitāti, avota pārredzamību un mazāk nekontrolētu nodošanu. Tas pats par sevi nenodrošina BDAR atbilstību.

Tirgotājiem jājautā Omnetic par pārziņa un apstrādātāja lomām, datu atrašanās vietām, apakšapstrādātājiem, saglabāšanas un dzēšanas uzvedību, piekļuves kontroli, audita žurnāliem, eksporta atbalstu, incidentu nosacījumiem un MI apstrādes detaļām. Valsts, pakotnes un izvietošanas izvēle var mainīt atbildi.