TR / EN

Endüstriyel IoT Projelerinde Veri Sorumlusu ve Veri İşleyen Rolleri

Personel tag’lerinden oluşan konum olayları merkezi uygulamada görünmeye başladığında teknik ekip sistemi çalışır kabul edebilir. Sözleşme ekine gelindiğinde ise “müşteri veri sorumlusudur, tedarikçi veri işleyendir” cümlesi tek başına yetersiz kalır. Uygulama üreticisi bulut telemetrisi alıyor, entegratör uzaktan destek veriyor ve başka bir sağlayıcı yedek tutuyorsa gerçek veri zinciri daha uzundur.

9 Temmuz 2026 tarihinde anonim bir endüstriyel IoT projesi için yaptığımız çalışmada hukuki unvanları varsayımla değil, fiili karar ve veri akışıyla eşleştirdik. Bu yazı hukuki görüş yerine geçmez; hukuk, bilgi güvenliği, operasyon ve tedarik ekiplerinin aynı soruları sormasını sağlayan pratik bir çerçevedir. Kesin yükümlülükler ilgili mevzuat ve sözleşme bağlamında uzmanlarla doğrulanmalıdır.

Sorunun ortaya çıkışı

Müşteri saha ihtiyacını tanımlıyor, üretici yazılımı sağlıyor, uygulayıcı cihazları kuruyor ve destek ekibi sisteme erişiyordu. Taslak DPA yalnızca iki taraf içerdiği için alt yüklenici, barındırma ve uzaktan destek rolleri görünmüyordu. Hangi tarafın hangi veri kategorisine eriştiği, veriyi ne kadar tuttuğu ve sözleşme bittiğinde nasıl sileceği açık değildi.

Personel kimliği ile tag eşleştirmesi işveren sisteminden geliyor, konum olayları IoT platformunda işleniyor ve raporlar başka kurumsal uygulamalara aktarılıyordu. Teknik mimari diyagramı cihaz bağlantısını gösterse de hukuki veri akışını göstermiyordu. Projenin canlıya geçiş tarihi yaklaşırken ihlal bildirimi, ilgili kişi talebi ve veri dışa aktarımı için kimin ne yapacağı cevaplanamıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım yazılım üreticisinin otomatik olarak veri sorumlusu olduğuydu. Rol, ürün sahipliğinden çok kişisel veri işleme amaç ve vasıtaları üzerindeki fiili karara bağlıdır. Başka bir yanlış varsayım verinin cihaz seri numarasından oluştuğu için kişisel olmadığıydı. Tag bir çalışanla eşleştirildiğinde ve konum/zaman olayı üretildiğinde veri bağlamı kişiyi belirlenebilir kılabilir.

DPA imzalanınca tüm yükümlülüklerin tamamlandığı düşüncesi de sorun yarattı. Sözleşmedeki silme süresi uygulamada bir iş akışına bağlanmamış, yedeklerden silmenin teknik sınırları açıklanmamıştı. Alt işleyen değişikliğinde bildirim yöntemi yoktu. Destek hesapları ortak kullanılıyor ve erişim kayıtları kişi bazında tutulamıyordu. Kâğıt üzerindeki kontrol, operasyonel karşılık bulmadığında güvence sağlamaz.

Teknik analiz

Önce veri envanteri oluşturuldu: personel kimliği veya takma kimlik, tag eşleştirmesi, zaman ve bölge olayı, araç ilişkisi, cihaz telemetrisi, destek kaydı ve kullanıcı günlükleri. Her veri için kaynak, amaç, işleme işlemi, erişen taraf, barındırma yeri, aktarım ve saklama süresi yazıldı. Bu tablo, taraf rollerini sözleşme başlığından daha doğru biçimde görünür kıldı.

Karar matrisiyle işleme amacını, zorunlu alanları, saklama süresini ve raporlama kullanımını kimin belirlediği incelendi. Yalnızca talimatla hizmet veren taraf veri işleyen olarak, kendi bağımsız amacı için karar alan faaliyet ise ayrıca değerlendirildi. Alt işleyen listesi, veri merkezleri, uzaktan destek konumları ve yedekleme zinciri doğrulandı. Hukuk ekibi teknik akışı bu envanter üzerinden yorumladı.

Uygulanan çözüm veya önerilen mimari

Müşteri tarafında işleme amacı ve saha politikası için hesap verebilir veri sahibi belirlendi. Teknoloji sağlayıcı ile uygulayıcının hangi faaliyetlerde talimatla hareket ettiği sözleşme ekinde ayrıştırıldı; onaylı alt işleyenler listeye alındı. DPO veya ilgili gizlilik irtibatı, güvenlik olay kontağı ve operasyon sorumlusu isim yerine rol bazında tanımlandı; personel değişiminde süreç kesilmedi.

Teknik mimaride veri minimizasyonu uygulandı. Gereksiz kimlik alanları IoT platformuna taşınmadı, rol bazlı erişim ve kişi bazlı yönetici hesapları kullanıldı. Saklama süreleri uygulama, rapor, log ve yedek için ayrı yapılandırıldı. İlgili kişi talebi, düzeltme, dışa aktarma ve sözleşme sonu silme senaryoları masa başı tatbikatla test edildi; mümkün olmayan adımlar şeffaf biçimde kayda alındı.

Alternatifler ve karar gerekçesi

Tüm veriyi müşteri ortamında tutmak aktarım zincirini sadeleştirebilir; üretici desteği, güncelleme ve yedekleme yine erişim yaratabilir. SaaS modelinde işletim kolaylığı ve ölçek sağlanabilir, fakat alt işleyen, veri konumu ve çıkış planı daha ayrıntılı incelenmelidir. On-premises etiketi tek başına hukuki rolü veya güvenliği belirlemediği için fiili erişim üzerinden değerlendirme yaptık.

Personel adını sistemde tutmak raporlamayı kolaylaştırır; takma kimlik kullanmak gereksiz ifşayı azaltır fakat yetkili eşleştirme hizmeti gerektirir. Operasyon ekranında açık kimliğin gerçekten gerekli olduğu roller ayrıştırılarak çoğu görünümde minimizasyon tercih edildi. Saklama süresini “sözleşme boyunca” bırakmak kolaydı; iş güvenliği, operasyon, talep ve yasal ihtiyaçlara göre veri türü bazında süre belirlemek daha savunulabilir oldu.

Güvenlik ve operasyonel riskler

Ortak destek hesapları, kontrolsüz uzak erişim ve üretim verisinin test ortamına kopyalanması başlıca risklerdir. Tedarikçi erişimi talep, onay, süre, MFA ve kayıtla yönetilmeli; testte anonim veya sentetik veri kullanılmalıdır. Güvenlik yükümlülükleri “uygun önlem alınır” gibi belirsiz ifadelerle bırakılmamalı; erişim, şifreleme, yama, yedek ve olay işbirliği sorumlulukları doğrulanabilir olmalıdır.

Sınır ötesi veri aktarımı yalnızca ana uygulama barındırmasına bakılarak değerlendirilemez; telemetri, destek, log analizi ve yedekleme de zincire dahildir. Alt işleyen değişiklikleri izlenmezse onaylı mimari fark edilmeden değişebilir. Sözleşme sonundaki silme belgesi teknik doğrulamayla desteklenmeli, yedeklerdeki gecikmeli silme açıklanmalıdır. Mevzuat değişiklikleri için dönemsel hukuk ve envanter gözden geçirmesi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi