Bayilik Veri Yönetişimi ve GDPR Rehberi

1. Sistemlerden önce amaçları envanterleyin

Aynı kişi; potansiyel müşteri, alıcı, kredi kullanan, araç kullanıcısı, servis müşterisi, şikâyetçi veya çalışan olabilir. Aynı VIN; değerleme, tescil, finans, sigorta, garanti, onarım, yol yardımı ve bağlantılı hizmetlerde görülebilir. Yalnızca bir sistem envanteri, yeniden kullanımın hukuka uygun veya beklenen olup olmadığını göstermez.

Amaca göre bir işleme haritası oluşturun. Her faaliyet için veri sahiplerini, kategorileri, kaynağı, hukuki dayanağı, alıcıları, aktarımları, saklama süresini, güvenliği, otomatik kararları ve sahibi kaydedin. Uygulanabildiğinde bunu Madde 30 işleme faaliyetleri kaydına bağlayın. Bir sözleşmenin ifası için gerekli veriyi isteğe bağlı pazarlama ve analitikten ayırın. Birbiriyle ilgisiz amaçları tek bir onay altında birleştirmeyin.

GDPR; hukuka uygunluk, dürüstlük ve şeffaflık; amaçla sınırlama; minimizasyon; doğruluk; saklama süresi sınırlaması; güvenlik; ve hesap verebilirlik gerektirir. [1] Bu ilkeler yalnızca dokümantasyon gereklilikleri değildir. Hangi CRM alanlarının zorunlu olduğunu, hangi rollerin müşteri listesi dışa aktarabileceğini ve eski potansiyel müşteri verilerinin ne zaman silineceğini değiştirmelidir.

2. Müşteri ve araç verilerini bağlam içinde sınıflandırın

Adlar, kişisel e-posta adresleri, telefon numaraları, imzalar ve finansal bilgiler açıkça kişisel veridir. Araç verileri bağlamsal analiz gerektirir. Bir VIN, tescil, konum izi, sürüş örüntüsü, servis geçmişi veya araç içi tanımlayıcı; tanımlanabilir bir sahip, zilyet, sürücü veya yolcuyla ilişkilendirilebilir. Sözde isimsizleştirme (pseudonymisation) riski azaltır; ancak yeniden tanımlama mümkün kaldığı sürece veriyi GDPR kapsamının dışına çıkarmaz.

Avrupa Veri Koruma Kurulu'nun (EDPB) bağlantılı araçlara ilişkin rehberi, araçtan üretilen verilerin büyük bölümünün kişisel veri olduğunu vurgular ve konum, biyometrik veri ile suça ilişkin verileri bağlam içinde özellikle hassas kategoriler olarak öne çıkarır. Mümkün olduğunda yerel işlemeyi ve kullanıcının toplama üzerindeki kontrolünü tercih eder. [2]

Alanları uygulamaya göre değil, hassasiyete ve amaca göre sınıflandırın. Kayıt verisi bir iş akışında sıradan olabilirken başka verilerle birleştirildiğinde açığa çıkarıcı olabilir. Serbest metin notları özellikle risklidir; çünkü personel yapılandırılmamış biçimde sağlık, aile, finansal veya şikâyet bilgileri girebilir. Gereksiz toplamayı azaltmak için yönlendirmeler, eğitim ve kısıtlı alanlar kullanın.

3. Bayi, grup, OEM ve tedarikçiler arasındaki rolleri netleştirin

Bayi genellikle satış ve servis faaliyetleri için veri sorumlusudur; ancak ilişkiler değişebilir. Bir OEM; garanti veya bağlantılı hizmetler için bağımsız bir veri sorumlusu, ortaklaşa belirlenen bir kampanya için müşterek veri sorumlusu olabilir veya başka tanımlı bir düzenleme kapsamında veri alabilir. DMS tedarikçisi genellikle barındırılan bayi verileri için veri işleyen olarak hareket eder; ancak kendi hesap yönetimi veya güvenlik günlükleri için veri sorumlusu olabilir.

Bir rol etiketini gerçekliği sınamadan sözleşmeden kopyalamayın. Amacı ve temel araçları kimin belirlediğini, hak taleplerini kimin yanıtladığını, bir ihlali kimin kime bildirdiğini, hangi alt işleyenlerin dahil olduğunu ve verilerin modelleri eğitmek veya müşterileri kıyaslamak için kullanılıp kullanılmadığını sorgulayın. Her arayüzdeki paylaşım gerekçelerini ve veri minimizasyonunu belgeleyin.

Bağlantılı araç erişimi artık AB Veri Yasası ile de kesişiyor. Avrupa Komisyonu'nun 2025 tarihli, bağlayıcı olmayan otomotiv rehberi, Veri Yasası kavramlarının araç verilerine nasıl uygulandığını açıklarken GDPR'nin kişisel verilere uygulanmaya devam ettiğini vurgular. [3] Ürün verisine erişim veya bu veriyi paylaşma hakkı, gizlilik hukukunu göz ardı etmek için genel bir izin değildir.

4. Yolculuk boyunca hukuki dayanağı ve şeffaflığı tasarlayın

Bu tablo bir başlangıç noktasıdır; hukuki bir tespit değildir. E-gizlilik ve doğrudan pazarlama kuralları kanala ve ulusal uygulamaya göre değişir. Onay; özgürce verilmiş, belirli, bilgilendirilmiş, açık ve geri alınabilir olmalıdır. Meşru menfaatler; amaç, gereklilik ve denge testi değerlendirmeleri gerektirir.

Tek bir uzak gizlilik sayfası yerine anlamlı anlarda katmanlı bildirimler sunun. Sorgu, test sürüşü, satın alma, servis ve uygulama bağlantısı sırasında temel işlemeyi açıklayın. Tercihlerin değiştirilmesini kolaylaştırın ve geri çekmeyi ilgili her kampanya sistemine yayın.

5. Kimliği, doğruluğu, erişimi ve saklamayı kontrol edin

Müşteri eşleştirme sürekliliğe yardımcı olur; ancak iki kişiyi yanlış biçimde birleştirebilir de. Doğrulanmış tanımlayıcılar, güven düzeyleri, önemli birleştirmeler için gözden geçirme ve geri alınabilir bir denetim izi kullanın. Hangi kaynağın bir değeri sağladığını koruyun. Bir bayi, bir kişinin neden bir mesaj aldığını açıklayabilmeli ve bir sahiplik değişikliğini hızla düzeltebilmelidir.

Rol tabanlı erişim ve görevler ayrılığı uygulayın. Bir satış görevlisinin güncel iletişim ve işlem bağlamına ihtiyacı olabilir; sınırsız dışa aktarmaya veya bordroya değil. Grup raporlaması, müşteri düzeyinde ayrıntı yerine toplulaştırılmış şube verisine ihtiyaç duyabilir. Ayrıcalıklı rolleri ve kullanılmayan hesapları gözden geçirin. Yüksek riskli veri kümelerine erişimi kaydedin ve toplu dışa aktarmaları inceleyin.

Saklama süresini kayda ve amaca göre belirleyin. Vergi belgeleri, sözleşmeler, garanti kanıtları, sonuçsuz kalan potansiyel müşteriler, çağrı kayıtları, konum verisi ve model eğitimi örnekleri farklı süreler gerektirir. Zamanaşımı sürelerini ve hukuki tutma yükümlülüklerini dikkate alın, ardından silin veya anonimleştirin. Ön yüzdeki bir silme işleminin yalnızca görünürde kalmaması için yedekleri ve aşağı akış entegrasyonlarını test edin.

6. Hakları, DPIA'ları ve olayları operasyonel hâle getirin

Erişim, düzeltme, silme, kısıtlama, itiraz ve taşınabilirlik talepleri için doğrulanmış bir kabul süreci oluşturun. CRM, DMS, çağrı, belge ve pazarlama sistemleri genelinde müşteri ve araç tanımlayıcılarına göre arama yapın. İfşadan önce üçüncü taraf verilerini ve diğer kişilerin haklarını gözden geçirin. Kararı ve yanıt tarihini kaydedin.

İşlemenin yüksek risk yaratması muhtemel olduğu durumlarda -özellikle sistematik izleme, yeni türde bağlantılı veri veya önemli otomatik kararlarda- bir veri koruma etki değerlendirmesi (DPIA) kullanın. DPIA, lansmandan önce tasarımı etkilemelidir. Geriye dönük bir onay formu değildir.

İhlal triyajına hazırlanın. Personel; yanlış yönlendirilmiş faturaları, açığa çıkmış dışa aktarmaları, hesap ele geçirmelerini ve fidye yazılımlarını olası kişisel veri olayları olarak tanımayı bilmelidir. Olguları hızla kaydedin, erişimi sınırlayın, kanıtı koruyun ve veri sorumlusunun bildirim yükümlülüklerine ilişkin değerlendirmesini destekleyin. GDPR, ilgili risk eşiğinin karşılandığı durumlarda 72 saatlik bir denetim otoritesi bildirim süresi öngörür. [1]

Omnetic'in konumu

Omnetic'in belgelenmiş modülleri müşteri, araç, işlem, iletişim, inceleme, stok ve fiyatlandırma bağlamını operasyonel iş akışlarına taşır. Bu süreklilik doğruluğu, kaynak görünürlüğünü ve daha az kontrolsüz aktarımı destekleyebilir. Tek başına GDPR uyumluluğunu oluşturmaz.

Bayiler Omnetic'ten veri sorumlusu ve veri işleyen rollerini, veri konumlarını, alt işleyenleri, saklama ve silme davranışını, erişim kontrollerini, denetim günlüklerini, dışa aktarma desteğini, olay koşullarını ve YZ işleme ayrıntılarını sormalıdır. Ülke, paket ve kurulum seçimleri yanıtı değiştirebilir.