“Takma adlaştırılmış” ifadesi, şeffaflık yükümlülükleri açısından otomatik olarak “güvenli” anlamına gelmediğinde

AB Mahkemesi netleştirdi: takma adlaştırılmış veri ≠ anonimleştirilmiş veri
Masoud Salmani
•

Neden önemli?

Uyum dünyasında (ister Genel Veri Koruma Tüzüğü (GDPR) ister AB kurumları için 2018/1725 sayılı (AB) Tüzük kapsamında olsun), en çetrefilli sorulardan biri şudur: “Takma adlı” (pseudonymised) veriler tam olarak ne zaman kişisel veri sayılmaya devam eder ve ne zaman anonimleştirilmiş veya bu kuralların kapsamı dışında kabul edilebilir?
C-413/23 P sayılı dava kararı, taze ve somut bir açıklık getiriyor; bu karar, Boşluk Analizi (Gap Analysis), Hizmet Olarak Veri Koruma Görevlisi (DPO-as-a-Service), çerez denetimleri ve otomatik PrivacyOps panelleri gibi hizmetlerinizi nasıl yapılandıracağınız konusunda doğrudan önem taşıyor.

Özetle dava

  • Veri sorumlusu: Tek Çözüm Kurulu (SRB) – bir banka çözümleme bağlamında hissedarlardan/alacaklılardan görüş toplayan bir AB organı.
  • Veri: İlgili kişilerden alınan (kimlikleri SRB tarafından bilinen) ve daha sonra takma adlarla (alfanümerik kodlar) kodlanarak değerleme amacıyla üçüncü taraf bir firmaya (danışman) aktarılan geri bildirimler/yorumlar.
  • Uyuşmazlık: Avrupa Veri Koruma Denetçisi (EDPS), SRB'nin veri sahiplerini (takma adlı) verilerinin paylaşılacağı konusunda bilgilendirmediğini tespit etti. Genel Mahkeme, verinin alıcı tarafında kişisel veri olmadığı yönünde SRB'nin tarafını tutmuştu; ancak ABAD'ın bu kararı konuyu yeniden değerlendiriyor.

Bilmeniz gereken temel çıkarımlar

  1. Görüşler/yorumlar = kişisel veri
    Mahkeme, bir bireyin kişisel görüşlerinin veya yorumlarının prensipte o kişiyle “ilişkili bilgi” olduğunu ve dolayısıyla kişisel veri kavramı kapsamına girdiğini yineliyor. Bunu belirlemek için her zaman “amaç, etki, içerik” konularında derinlemesine inceleme yapmanıza gerek yoktur.
    → Müvekkilleriniz için: Geri bildirim formları, anketler, sesli notlar ve kullanıcı yorumları bile kişisel veri yükümlülüklerini tetikleyebilir.
  2. Takma adlandırma (pseudonymisation) yükümlülüklerden kurtulmak için bir bilet değildir
    Karar, takma adlı verilerin hala kişisel veri olabileceğini netleştiriyor; ancak en önemlisi, bu verilerin bağlamsal: bu, alıcının (üçüncü taraf) veri sahibini yeniden tanımlamak için "makul ölçüde kullanılması muhtemel araçlara" sahip olup olmadığına bağlıdır.
    → Hizmetleriniz için: Bir PrivacyOps paneli veya otomatik Çerez Yönetim Platformu (CMP)/çerez takibi tasarlarken, "isimleri çıkardık, kodlarla değiştirdik, yani sorun yok" varsayımında bulunamazsınız. Zincirin devamındaki herhangi bir aktörün bireyleri yeniden tanımlayıp tanımlayamayacağını değerlendirmeniz gerekir.
  3. Bakış açısı önemlidir: veri sorumlusu ve alıcı
    Mahkeme önemli bir ayrım yapıyor: Veri sahibinin kimliğinin belirlenebilirliği veri toplama anında ve veri sorumlusunun bakış açısından değerlendirilmelidir (burada SRB) – sadece alıcının değil. Ancak, alıcı için veriler, kimliğin belirlenebilirliğine bağlı olarak kişisel veri olabilir veya olmayabilir.
    → Çıktılarınız için: Boşluk analizi veya dokümantasyon şablonlarınız bu ikili bakış açısını yansıtmalıdır: "veri sorumlusunun toplama anındaki riskleri ve yükümlülükleri nelerdir" ve "paylaşım/alıcı tarafı ne görüyor".
  4. Şeffaflık yükümlülükleri hala geçerlidir
    Alıcı bireyi tanımlayamasa bile, veri sorumlusu toplama anında veri sahiplerini üçüncü taraflara aktarım/açıklama olasılığı konusunda bilgilendirmelidir (şeffaflık görevleri kapsamında) — çünkü anahtarı elinde tutan taraf veri sorumlusudur.
    → Uygulamada: "KVKK Startup Başlangıç Paketi" veya "Sürekli Uyum Yönetimi" paketlerinizde, gizlilik bildiriminin/açık rıza mekanizmasının (takma ad kullanılmış alıcılara yapılanlar dahil) bu tür aktarımların açıklanmasını içerdiğinden emin olun.

Bunun Kooch'un hizmet kataloğuna uygulanması

  • Boşluk Analizi: İşleme envanterlerini gözden geçirirken şu soruyu sorun: Takma ad kullanılmış verileri harici danışmanlarla/işleyenlerle/analitik araçlarıyla paylaşıyor muyuz? Eğer paylaşıyorsak, bu harici tarafların yeniden tanımlama araçlarına sahip olup olmadığını belgeleyin ve bunu risk puanlamasına yansıtın.
  • ISO 27001 Hazırlığı ve Dokümantasyon: Ek A kontrolleri kapsamında (örneğin, A.18.1.4 Gizlilik, A.18.1.3 Uyumluluk) bu nüansı yakalamanız gerekir. Bu dava, "takma ad kullanılarak paylaşılan verilerin" hala tam kişisel veri kontrolleri gerektirebileceğini pekiştirmektedir.
  • Hizmet Olarak Veri Koruma Görevlisi (DPO) / Sürekli Uyum: Dış kaynak modellerinde, veri sorumlusunun şeffaflık yükümlülüklerinin ve buna bağlı sözleşmesel güvencelerin (işleyenin/alıcının yeniden tanımlama yapamaması vb.) titizlikle belgelendiğinden emin olun. Bunu standart operasyon prosedürlerinize (SOP) ve müşteri çıktılarınıza yansıtın.
  • Otomatik Uyumluluk Araç Setleri / PrivacyOps Panelleri: “Takma adlandırılmış aktarımları” takip eden paneller oluştururken şu uyarıyı eklemek isteyebilirsiniz: “Üçüncü taraf veri alıyor – yeniden tanımlama riskini ve şeffaflık yükümlülüğünü değerlendirin”. Bu vaka, söz konusu iş akışı için yasal dayanak sağlamaktadır.

Sizin veya müşterileriniz için pratik kontrol listesi

  • Veri toplama aşamasında:
    • Tüm potansiyel sonraki alıcıları (harici danışmanlar ve işleyiciler dahil) listelediniz mi?
    • Veri sahibini bu tür aktarımların olasılığı konusunda bilgilendirdiniz mi (şeffaflık bildirimi)?
  • Takma adlandırılmış verileri aktarmadan önce:
    • Alıcı, yeniden tanımlamaya olanak tanıyan herhangi bir ek bilgiye veya “anahtara” sahip mi (veya erişimi var mı)?
    • Alıcının makul bir şekilde yeniden tanımlama yapmasını engelleyecek teknik/idari önlemler mevcut mu?
  • Sözleşmelerde / veri işleme anlaşmalarında:
    • Geçerliyse, alıcının yeniden tanımlama yapamayacağını belirten bir madde ekleyin.
    • Yeniden tanımlama mümkün hale gelirse sorumluluğu tanımlayın.
  • Risk değerlendirmesinde / DPIA'da:
    • Yeniden tanımlama riskinin ihmal edilebilir olduğuna dair belgelenmiş kanıtınız yoksa, takma adlandırılmış aktarımları potansiyel bir kişisel veri işleme faaliyeti olarak ele alın.
    • Değerlendirmenizi belgeleyin ve gerekçelendirin (“makul ölçüde olası araçlar” eşiği).
  • Denetim / izleme aşamasında:
    • Alıcının ortamının veya dış koşulların (örneğin yeni veri setleri, yapay zeka yetenekleri) birinin makul bir şekilde yeniden tanımlama yapabileceği şekilde değişip değişmediğini periyodik olarak gözden geçirin.
    • Risk profili değişirse politikalarınızı güncelleyin.

Son düşünceler

Bu ABAD kararı, kesin ve net kurallar getirerek hayatı kolaylaştırmıyor. Bunun yerine, bağlamı, bakış açısını ve makullüğüvurguluyor. Bizim gibi uyum danışmanları için bu durum temel bir gerçeğin altını çiziyor: verilerin kişisel veya kişisel olmayan veri olarak hukuki sınıflandırması statik veya tamamen teknik bir konu değildir. Bu sınıflandırma, veriyi kimin elinde tuttuğuna, hangi erişim imkanlarına sahip olduğuna ve yeniden tanımlama riskinin ne olduğuna bağlıdır.

Kooch ve müşterilerimiz için bu şu anlama geliyor: hizmet paketleri, dokümantasyon, paneller ve iş akışları oluştururken bu esnekliği ve gerekçelendirilmiş değerlendirmeyi mutlaka dahil etmeliyiz. Takma adlaştırma (pseudonymisation) değerli bir risk azaltma aracı olmaya devam ediyor ancak genel bir muafiyet olarak görülemez.

Takma adlaştırılmış veri transferlerini gerektirdikleri incelikle ele almaya hazır mısınız? Bir sonraki müşterimizin “üçüncü taraflarla veri paylaşımı” kontrol listesinin yeni gerçeklikle uyumlu olduğundan emin olalım.

İlgili rehberler ve pratik sonraki adımlar

Masoud Salmani
İşinizi dönüştürmeye hazır mısınız?
Başlayın
Gizlilik ve Çerez PolitikalarıKVKKYasal UyarıBilgi Güvenliği PolitikasıKullanım KoşullarıLogos of payment methods: iyzico, Elo Débito, Mastercard, Visa, American Express, and Troy.