GDPR Veri Haritalama Diyagramı: Kişisel Veri Akışlarını Sistemleriniz Boyunca Haritalamak

Bir gizlilik ekibine kişisel verilerin nerede durduğunu sorun, size bir elektronik tablo gelir. Mühendisliğe sorun, kişisel veriden hiç söz etmeyen bir mimari diyagram gelir. İkisi de eksiktir: tablo verinin nasıl hareket ettiğini gösteremez, mimari diyagram ise neyin ve neden hareket ettiğini söylemez.

GDPR veri haritalama diyagramı ikisinin buluştuğu yerdir. Bu rehber bir veri haritasının neleri kaydetmesi gerektiğini, onu oluşturmak için bir yöntemi ve tipik bir SaaS ürünü için çözümlü bir haritayı ele alıyor. Bu bir hukuki tavsiye değildir; hukuki dayanaklara, aktarım mekanizmalarına ve saklama sürelerine gizlilik sorumlunuz ya da hukuk danışmanınız karar verir.

Veri haritası ve işleme faaliyetleri kaydı

GDPR'ın 30. maddesi, her veri sorumlusunun şunları içeren bir işleme faaliyetleri kaydı tutmasını şart koşar:

• veri sorumlusunun ve varsa temsilcisinin ve veri koruma görevlisinin adı ve iletişim bilgileri;
• işlemenin amaçları;
• ilgili kişi kategorileri ve kişisel veri kategorileri;
• üçüncü ülkelerdeki alıcılar dahil alıcı kategorileri;
• üçüncü ülkelere aktarımlar ve bazıları için güvencelere ilişkin belgeler;
• mümkünse silme süreleri;
• mümkünse güvenlik önlemlerinin genel bir tanımı.

Veri işleyenler de her veri sorumlusu adına yaptıkları işleme için benzer bir kayıt tutar. 30. maddenin 5. fıkrası 250'den az çalışanı olan kuruluşları muaf tutar; ancak yalnızca işleme kişilerin hakları için risk doğurmuyorsa, arızi nitelikteyse ve özel kategorideki verileri ya da cezai mahkûmiyet verilerini içermiyorsa. Müşteri verisini her gün işleyen bir SaaS şirketi bu koşulları nadiren karşılar. AB'li yasa koyucular bu eşiği yükseltmeyi tartıştı; bu yüzden ona güvenmeden önce yürürlükteki metni kontrol edin.

Kayıt bir tablodur. Veri haritası ise tabloya neyin gireceğini bulmanın ve daha sonra hâlâ doğru olup olmadığını kontrol etmenin yoludur.

Her akış için neler kaydedilmeli

İşe yarayan bir yöntem

1. Sistemlerin envanterini çıkarın. Listeleyebildiğiniz şeylerden başlayın: bulut hesapları, veritabanları, tek oturum açma (SSO) sisteminden ve finans ekibinin tedarikçi ödemelerinden çıkan SaaS araçları. Gölge araçlar orada ortaya çıkar.
2. Her seferinde tek bir kullanıcı yolculuğunu izleyin. Kayıt, faturalama, günlük ürün kullanımı, bir destek talebi, bir pazarlama e-postası. Verinin nereden girdiğini, nerede saklandığını ve sonra nereye gittiğini çizin.
3. Sahiplerine sorun. Her sistem için: hangi alanlar, ne için, kimler alıyor ve ne kadar süre kalıyor.
4. Veri işleyenleri ve aktarımları işaretleyin. Her tedarikçinin veriyi nerede işlediğini, bir veri işleme sözleşmesi olup olmadığını ve AEA dışına yapılan her aktarımı hangi güvencenin kapsadığını not edin.
5. Saklama ve silmeyi ekleyin. Saklama süresi olmayan bir depo başlı başına bir bulgudur.
6. Gizlilik ekibiyle gözden geçirin ve 30. madde kaydını haritadan türetin.

AEA dışına aktarımlar

GDPR'ın V. Bölümü, yani 44 ile 49. maddeler arası, üçüncü ülkelere aktarıma yalnızca belirli gerekçelerle izin verir. Bir SaaS şirketi için yaygın olanlar şunlardır:

• Yeterlilik kararı. Avrupa Komisyonu, korumasını yeterli bulduğu ülkeleri listeler. ABD için Temmuz 2023 tarihli karar, AB-ABD Veri Gizliliği Çerçevesi'ne (Data Privacy Framework, DPF) katılan şirketleri kapsar. AB Genel Mahkemesi kararı Eylül 2025'te onadı ve Ekim 2025'te Adalet Divanı nezdinde itiraz yoluna gidildi; bu yüzden karara dayanmadan önce güncel durumunu kontrol edin.
• Standart sözleşme maddeleri. Komisyonun 2021 tarihli SCC'leri, yeterlilik kararı olmadığında kullanılan olağan sözleşmeye dayalı güvencedir.
• Diğer güvenceler ve istisnalar, örneğin bağlayıcı şirket kuralları veya açık rıza, daha dar durumlar içindir.

Haritada bir aktarım, bölgenizden çıkan ve hedefi ile güvencesiyle etiketlenen bir kenardır.

Çözümlü örnek: bir B2B SaaS ürünü

Ürün bir AB bulut bölgesinde çalışıyor: bir web uygulaması, bir PostgreSQL veritabanı ve bir analitik veri ambarı. Beş tedarikçi kişisel veri alıyor: AEA'da e-posta gönderimi ve ödemeler; ABD'de ürün analitiği, bir destek masası ve bir CRM.

Nasıl okunur:

• Giriş. Müşteri kullanıcıları hesap oluşturur, ödeme yapar, ürünü kullanır ve desteğe yazar. Web uygulamasından çıkan her akış, taşıdığı veri kategorileriyle etiketlidir.
• Kendi sistemleriniz, AB bölgesi. Uygulama veritabanı hesap ve çalışma alanı verilerini tutar. Veri ambarı kullanım olaylarını isimlerle değil, takma adlı kimliklerle alır.
• AEA'daki veri işleyenler. E-posta gönderimi isimleri, e-posta adreslerini ve mesaj içeriğini alır; ödemeler fatura iletişim bilgilerini ve faturaları alır. Ortada bir aktarım yoktur.
• ABD'deki veri işleyenler. Bu çerçeveye giren her kenar bir aktarımdır ve güvencesini taşır: çerçeve kapsamında sertifikalı tedarikçiler için DPF, sertifikalı olmayan tedarikçi için SCC.
• Gösterge, etiketleri açıklar ve her depo için örnek saklama sürelerini listeler.

İşe yarayan çizim kuralları

• Kenarları teknolojilerle değil, veri kategorileriyle etiketleyin. "Ad, e-posta, talep içeriği" gözden geçiren kişiye yardımcı olur; "REST API" olmaz.
• Kendi sistemlerinizin etrafına bir sınır çizin ve veri işleyenleri bölgelerine göre gruplayarak bu sınırın dışına koyun.
• Her aktarımı işaretleyin, hedefi ve güvencesiyle birlikte.
• Özel kategorideki verileri vurgulayın; bunun için tutarlı tek bir renk kullanın ve göstergede ne anlama geldiğini yazın.
• Saklama süresini her depoya yazın. İşleme faaliyetleri kayıtlarında en sık eksik kalan öğe budur.
• Amaçları ve hukuki dayanakları kayıtta tutun, diyagramın yanında. Diyagram verinin nerede olduğunu gösterir; kayıt nedenini belirtir.

Güncel tutun

Bir veri haritası, biri yeni bir tedarikçi eklediği gün eskir. Güncellemeleri haritayı değiştiren olaylara bağlayın: tedarikçi ekleme süreci, yeni veri toplayan yeni özellikler ve veri koruma etki değerlendirmeleri. 35. maddeye göre veri sorumlusu, yüksek risk doğurması muhtemel bir işlemeyi başlamadan önce değerlendirmek zorundadır ve harita bu değerlendirme için doğal başlangıç noktasıdır. Haritanın tamamını yılda bir kez gözden geçirin ve önceki sürümü saklayın. Eskimeyen mimari diyagramlar tam olarak bunun için bir iş akışı anlatıyor; canlı diyagramı gizlilik wiki'sine gömmek de herkesin aynı sürümü görmesini sağlar.

Harita ilgili kişi taleplerinde nasıl yardımcı olur

Bir erişim ya da silme talebi, kişinin verisinin bulunduğu her yeri kapsamalıdır: uygulama veritabanı, veri ambarı, yedekler ve her veri işleyen. Güncel bir haritayla yanıt vermek bir arama olmaktan çıkar, bir kontrol listesine dönüşür. Veri işleyenler bu taleplerde yardımcı olmakla sözleşme gereği yükümlüdür ve hangilerine sormanız gerektiğini harita söyler.

Aynı akışlara güvenlik açısından bakmak için tehdit modelleme için veri akış diyagramları yazısına göz atın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Müşteri kullanıcısı için C4 Modeli paketinden bir Kişi ekleyin.
3. AB bölgesindeki sistemleriniz için Temel paketinden bir Çerçeve ekleyin; içine web uygulaması için C4 Modeli paketinden bir Konteyner, uygulama veritabanı için Veri paketinden bir Postgres ve analitik için Veri paketinden bir Veri ambarı koyun.
4. Veri işleyenler için Temel paketinden iki Çerçeve daha ekleyin, biri AEA, biri ABD için; her tedarikçi rolü için içine C4 Modeli paketinden bir Harici sistem düğümü koyun.
5. Her kenarı taşıdığı veri kategorileriyle etiketleyin ve ABD çerçevesine giren her kenara güvenceyi ekleyin.
6. Gösterge ve saklama süreleri için Temel paketinden bir Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. GDPR veri haritalama kullanım senaryosu sayfası, bir haritayı yerleştirmenin başka yollarını gösteriyor.

SSS

GDPR veri haritasını zorunlu kılıyor mu? GDPR, 30. maddede bir diyagramı değil, işleme faaliyetleri kaydını zorunlu kılar. Çoğu ekip, akışları önce haritalamadan doğru bir kaydı oluşturamayacağını ya da güncel tutamayacağını fark eder.

Veri haritasının sahibi kim olmalı? Kaydın ve içindeki kararların sahibi gizlilik ekibidir; sistemlerin sahibi mühendislik. Diyagrama her iki taraftan birer sahip atayın ve birlikte gözden geçirin.

Harita tek tek veritabanı tablolarını göstermeli mi? Hayır. Depoları ve içlerindeki veri kategorilerini gösterin. Tablo düzeyindeki ayrıntı bir veri kataloğunda yer alır.

Hem veri işleyen hem veri sorumlusu olan bir tedarikçiyi nasıl gösteririm? Bir kez çizin ve rolünü her akış için ayrı etiketleyin. Ödeme sağlayıcıları gibi bazı sağlayıcılar, işlemelerinin bazı bölümlerinde veri sorumlusu olarak hareket eder; hangi bölümler olduğunu sözleşmeleri belirtir.

Diyagram 30. madde kaydının yerini tutabilir mi? Hayır. Kayıt, amaçlar ve güvenlik önlemleri dahil belirli bilgileri yazılı olarak içermelidir. Diyagramı kaydı oluşturmak ve kontrol etmek için kullanın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.