Veri Erişim Talepleri ve Gizlilik İçin Web Uygulaması Nasıl Oluşturulur
Denetim günlükleri, sansürleme, dışa aktarmalar ve uyumluluk raporlaması ile veri erişim taleplerini almak, doğrulamak, yerine getirmek ve izlemek için bir web uygulaması nasıl tasarlanır ve inşa edilir öğrenin.
Uygulamanın Ele Alması Gerekenler (ve Neden)\n\nBir veri erişim talebi—çoğunlukla DSAR (Data Subject Access Request) veya SAR (Subject Access Request) olarak anılır—bir kişinin kuruluşunuzdan kendileri hakkında hangi kişisel veriye sahip olduğunuzu, nasıl kullandığınızı ve bir kopyasını almak isteyip istemediğini sormasıdır. İşiniz müşteri, kullanıcı, çalışan veya potansiyel müşteri verisi topluyorsa, bu taleplerin olacağını varsaymalısınız.\n\nBunları iyi yönetmek sadece cezalardan kaçınmakla ilgili değildir. Güvenle ilgilidir: açık, tutarlı bir yanıt veriyi anladığınızı ve insanların haklarına saygı duyduğunuzu gösterir.\n\n### Desteklemeniz Gereken Düzenlemeler ve Talep Türleri\n\nÇoğu ekip önce GDPR ve CCPA/CPRA etrafında tasarlar, ancak uygulama birden fazla yargı alanını ve iç politikayı destekleyecek kadar esnek olmalıdır.\n\nYaygın talep türleri şunlardır:\n\n- Erişim: verinin bir kopyasını ve gereken bağlamı sağlayın (kaynaklar, amaçlar, alıcılar, uygulanabiliyorsa saklama).\n- Silme: izin verilen durumlarda veriyi silin ve istisnaları belgeleyin (ör. dolandırıcılık önleme, yasal yükümlülükler).\n- Düzeltme: sistemlerdeki yanlış kişisel bilgileri düzeltin.\n- Taşınabilirlik: veriyi transfer için yeniden kullanılabilir bir formatta teslim edin.\n\nHatta “erişim” içinde kapsam değişebilir: bir müşteri “sahip olduğunuz her şey”i isteyebilir veya belirli bir hesap, zaman aralığı veya ürünle ilişkili verileri talep edebilir.\n\n### İş Akışına Kimler Dokunacak\n\nBir DSAR uygulaması birçok paydaşın kesişim noktasında durur:\n\n- Gizlilik/hukuk: politika, onaylar ve yanıt içeriğini tanımlar.\n- Destek: talepleri alır ve talep sahibiyle iletişim kurar.\n- Güvenlik: kimlik kontrolleri, günlükleme ve güvenli teslimatı sağlar.\n- Mühendislik/BT: bağlayıcıları, veri kaynaklarını ve güvenilirliği sürdürür.\n\n### "İyi yapılmış" neye benzer\n\nGüçlü bir DSAR web uygulaması her talebi zamanında, izlenebilir ve tutarlı hale getirir. Bu, net alınış, güvenilir kimlik doğrulama, sistemler arasında öngörülebilir veri toplama, belgelenmiş kararlar (reddetmeler veya kısmi yerine getirmeler dahil) ve kimin ne zaman ne yaptığını gösteren denetlenebilir bir kaydı içerir.\n\nAmaç, her talebi savunulabilir bir şekilde tekrar edilebilir bir sürece dönüştürmektir—içsel olarak ve düzenleyicilere karşı—her isteği yangın söndürücü haline getirmeden.\n\n## Temel Gereksinimlerinizi ve Başarı Ölçütlerinizi Tanımlayın\n\nEkranları tasarlamadan veya araçları seçmeden önce, kuruluşunuz için “tamamlanmış”ın ne anlama geldiğini netleştirin. Bir veri erişim talebi web uygulaması başarılı olduğunda, her talebi güvenilir şekilde alınıştan teslimata taşır, yasal zaman çizelgelerine (GDPR, CCPA süreçleri vb.) uyar ve savunulabilir bir iz bırakır.\n\n### Minimum uçtan uca iş akışıyla başlayın\n\nUygulamanızın ilk günden desteklemesi gereken çekirdek DSAR iş akışını belgeleyin:\n\n- Talep alma ve baştan sona izleme: talep türünü (erişim, silme, düzeltme, taşınabilirlik), yargı kurallarını, son tarih kurallarını ve durum değişikliklerini "alındı"dan "yerine getirildi/reddedildi"ye kadar yakalayın.\n- Kimlik doğrulama ve yetkilendirme kontrolleri: talep sahibinin iddia ettiği kişi olduğunu ve hareket etme yetkisine sahip olduğunu doğrulayın (ör. ebeveyn/vasi, yetkili temsilci).\n- Sistemler arası veri keşfi ve yapılandırılmış yanıt paketleme: öncelikli sistemlerde kişisel veriyi bulun, kopyaları uzlaştırın ve okunabilir, tutarlı bir dışa aktarma oluşturun.\n- Denetlenebilirlik: kim ne yaptı, ne zaman ve neden: her eylemi kaydedin (doğrulama sonuçları, çalıştırılan aramalar, onaylar, sansürlemeler, iletişimler) ki kararları gerekçelendirebilesiniz.\n\nPratik olun: hangi talep kanallarını kabul edeceğinizi belirleyin (sadece web formu mu yoksa e‑posta/manuel giriş de mi), hangi diller/yerellerin önemli olduğunu ve hangi "kenar durumları"nı (paylaşılan hesaplar, eski çalışanlar, reşit olmayanlar) erken ele alacağınızı tanımlayın.\n\n### Ölçülebilir başarı metrikleri belirleyin (böylece geliştirebilirsiniz)\n\nGereksinimleri haftalık takip edilebilecek KPI’lara dönüştürün:\n\n- Onaylama süresi (ör. gönderimden onaya medyan süre)\n- Tamamlama süresi ve SLA uyum oranı (yasal süreler içinde kapatılan yüzdelik)\n- Doğrulama sonuçları (geçme oranı, ortalama doğrulama süresi, manuel inceleme gerektiren yüzde)\n- Otomasyon kapsamı (anahtar sistemlerin bağlayıcılar aracılığıyla aranma yüzdesi vs. manuel çalışma)\n- Kalite metrikleri (eksik veri nedeniyle yeniden açılma oranı, sansür hata oranı, kapanışta müşteri memnuniyeti)\n- Denetim tamlığı (gerekli kanıtların ekli olduğu ve onayların kaydedildiği vaka yüzdesi)\n\n### Kapsamı ve sahipliği netleştirin\n\nHer adımın sahibi kim olduğunu yazın: gizlilik ekibi, destek, güvenlik, hukuk. Erişim kontrollerine ve denetim günlüklerine daha sonra çevireceğiniz roller ve izinleri şimdiden yüksek seviyede tanımlayın.\n\nİlerlemeyi paydaşlara raporlamayı standartlaştırıyorsanız, hangi kaynağın "tek gerçek kaynağı" olacağını (uygulama) ve neyin dahili raporlama araçlarına aktarılması gerektiğini kararlaştırın.\n\n## Uyumluluk Gereksinimleriyle Büyüyen Bir Mimari Seçin\n\nBir veri erişim talebi web uygulaması bir form ve bir dışa aktarma düğmesinden daha fazlasıdır. Mimarin, sıkı süreleri, denetçiler için kanıtı ve sık politika değişikliklerini desteklemeli—her talebi özel bir proje haline getirmeden.\n\n### Ayrı deneyimler: talep sahibi, gizlilik ekibi ve sistemler\n\nÇoğu ekip ürünün üç "yüzü" ile sonuçlanır:\n\n- Kullanıcı portalı (istek sahibi): talep gönderme, gerekirse belge yükleme, durumu izleme ve nihai paketi alma.\n- Yönetici portalı (gizlilik ekibi): triyaj, kimlik doğrulama, arama, inceleme/sansürleme, onaylama ve yanıtları yayımlama.\n- İç API’ler: sistemlerin (CRM, destek masası, veri ambarı) durum güncellemeleri ve kanıtları otomatik olarak değiş tokuş etmesini sağlar.\n\nBunları ayırmak (aynı kod tabanını paylaşsalar bile) izinler, denetim ve gelecekteki değişiklikleri çok daha kolay hale getirir.\n\n### Bağlayıcı ekledikçe sabit kalan çekirdek servisler\n\nÖlçeklenebilir bir DSAR iş akışı genellikle birkaç temel servis halinde ayrılır:\n\n- Alım (Ingestion): web formları, e‑posta veya ticketlardan talepleri yakalar.\n- Kimlik: doğrulama, yetki kontrolleri ve riske dayalı yükseltme.\n- Bağlayıcılar: dahili sistemlerden ve işlemcilerden veri çeker.\n- Yerine getirme (Fulfillment): sonuçları toplar, eşleştirme yapar ve yanıt paketini oluşturur.\n- Bildirimler: son tarih hatırlatmaları, talep sahibi güncellemeleri ve iç SLA’lar.\n\n### Uyumluluk gerçekleriyle eşleşen veri depolarını seçin\n\nŞunları kullanın:\n\n- Talep durumu ve görevler için bir operasyonel veritabanı.\n- Oluşturulan dışa aktarmalar ve ekler için nesne depolama (sıkı erişim kontrolleri ve sona erme ile).\n- Kim ne yaptı, ne zaman ve neden için değiştirilemez bir denetim günlüğü (sadece ekleme).\n\n### Tek uygulama vs modüler servisler\n\nEğer hacminiz düşük ve ekibiniz küçükse, tek dağıtılabilir uygulama ile başlayın—daha az parça, daha hızlı yineleme. Bağlayıcı sayısı, trafik veya denetim gereksinimleri arttığında modüler servislere geçin, böylece entegrasyonları güncellerken yönetici iş akışını riske atmazsınız.\n\n### Koder.ai nerede yardımcı olabilir (uyumluluk gereksinimlerini değiştirmeden)\n\nBunu kurum içinde inşa ediyorsanız, Koder.ai gibi araçlar yapılandırılmış bir konuşmadan React tabanlı bir yönetici portalı ve Go + PostgreSQL arka ucu üreterek ilk uygulamayı hızlandırabilir.\n\nİki platform özelliği uyumluluk ağırlıklı iş akışları için özellikle önemlidir:\n\n- Planlama modu: ekranları ve API’leri üretmeden önce roller, vaka durumları ve kanıt gereksinimlerini haritalamanıza yardımcı olur.\n- Snapshotlar ve geri alma (rollback): bağlayıcı değişiklikleri ve politika güncellemeleri, yerine getirmeyi etkilediğinde hızlıca geri alınabilir.\n\nHâlâ gizlilik/hukuk onayı ve güvenlik incelemesi gerekir, ancak "ilk kullanılabilir uçtan uca akışı" hızlandırmak ekiplerin gereksinimleri erken doğrulamasına yardımcı olur.\n\n## Giriş Akışını ve Vaka Yaşam Döngüsünü Tasarlayın\n\nGiriş deneyimi, çoğu DSAR ve gizlilik vakasının başarı veya başarısızlık noktasıdır. İnsanlar bir talebi kolayca gönderemiyorsa—veya ekibiniz hızlıca triyaj edemiyorsa—süreler kaçırılır, gereksiz veri toplanır veya verilen sözün takibi kaybolur.\n\n### Tek bir kuyruğa düşen üç giriş kanalı sunun\n\nPratik bir web uygulama birden fazla giriş noktasını destekler, ancak hepsini tek bir vaka kaydında normalleştirir:\n\n- Herkese açık talep formu hesabı olmayanlar için.\n- Kimlik doğrulanmış portal oturum açmış müşteriler için; bilinen ayrıntıları ön doldurur ve durum izlemeye izin verir.\n- E‑posta→ticket alımı böylece privacy@… veya support@… adresine gönderilen talepler otomatik olarak vaka haline gelir (ekler korunur).\n\nAnahtar nokta tutarlılıktır: hangi kanal kullanılırsa kullanılsın, sonuç aynı vaka alanları, aynı zamanlayıcılar ve aynı denetim izi olmalıdır.\n\n### Sadece ihtiyacınız olanı toplayın (fazladan hiçbir şey)\n\nGiriş formunuz kısa ve amaç odaklı olmalıdır:\n\n- Kimlik bilgileri (sonradan doğrulamak için yeterli): isim, iletişim yöntemi ve zaten kullandığınız hesap tanımlayıcıları.\n- Talep kapsamı: erişim, silme, düzeltme, taşınabilirlik, “satma/ paylaşmama” vb., artı isteğe bağlı serbest metin detaylar.\n- Yargı ve son tarihler: ülke/eyalet seçimi (veya adresten çıkarım) uygulamanın doğru yasal süreyi uygulamasını sağlar.\n\n"İhtimal olsun" diye hassas ayrıntılar sormaktan kaçının. Daha fazla bilgiye ihtiyacınız olursa, doğrulama adımı sırasında isteyin.\n\n### Ekibinizin takip edebileceği basit bir vaka yaşam döngüsü tanımlayın\n\nVaka durumlarını açık ve görünür yapın, hem personel hem de talep sahipleri için:\n\nalındı → doğrulanıyor → işleniyor → hazır → teslim edildi → kapatıldı\n\nHer geçişin net kuralları olmalı: kim taşıyabilir, hangi kanıtlar gerekir (ör. doğrulama tamamlandı), ve neyin kaydedildiği.\n\n### SLA’ları, hatırlatmaları ve yükseltmeleri otomatikleştirin\n\nBir vaka oluşturulduğu andan itibaren, ilgili düzenlemeye bağlı SLA zamanlayıcılarını başlatın. Son tarihler yaklaşırken hatırlatmalar gönderin, politika izin veriyorsa saatleri duraklatın (ör. doğrulamayı beklerken) ve yükseltme kuralları ekleyin (ör. vaka "doğrulanıyor" durumunda 5 gün kalırsa yöneticiyi uyar).\n\nİyi yapıldığında, giriş ve yaşam döngüsü tasarımı uyumluluğu gelen kutusu sorunundan öngörülebilir bir iş akışına çevirir.\n\n## Kimlik Doğrulama ve Yetki Kontrollerini Uygulayın\n\nKimlik doğrulama, gizlilik uyumluluğunun gerçekte uygulandığı yerdir: kişisel veriyi açıklamaya hazırlanıyorsunuz, bu yüzden talep sahibinin veri sahibi olduğunu (veya onlar adına hareket etmeye yasal hakkı olduğunu) kesin olarak bilmelisiniz. Bunu iş akışınıza öncelikli bir adım olarak ekleyin, sonradan düşünülmemeli.\n\n### Kullanıcı tabanınıza uyan doğrulama yöntemlerini seçin\n\nMeşru kullanıcıların engellenmemesi için birden fazla seçenek sunun, aynı zamanda süreç savunulabilir olsun:\n\n- E‑posta sihirli bağlantı (düşük riskli talepler için iyi bir temel)\n- SMS tek kullanımlık kodu (doğrulanmış numara varsa faydalı)\n- Hesap girişi (kullanıcının zaten doğrulanmış profili varsa güçlü)\n- Belge kontrolü (kimlik taraması + özçekim veya manuel inceleme, seyrek kullanın)\n\nArayüzün bir sonraki adımda ne olacağını ve nedenini açıkça belirtin. Mümkünse, oturum açmış kullanıcılar için bilinen verileri ön doldurun ve ihtiyacınız olmayan ekstra bilgileri sormayın.\n\n### Temsilcileri, ajanları ve reşit olmayanları destekleyin\n\nUygulamanız talep sahibinin veri sahibi olmadığı durumları ele alabilmelidir:\n\n- Yetkili ajan/temsilciler: yetki mektubu veya vekaletname toplayın ve hem temsilciyi hem veri sahibini doğrulayın.\n- Reşit olmayanların ebeveynleri/vasileri: gereken yerlerde velayet kanıtı isteyin ve yanıtların doğru kişiye gitmesini sağlayın.\n\nBunu veri şemanızda açıkça modelleyin (ör. “talep sahibi” vs “veri sahibi”) ve yetkinin nasıl kurulduğunu kaydedin.\n\n### Riske dayalı doğrulamayı kullanın (ve bunu açıklayın)\n\nHer talep aynı risk taşımaz. Aşağıdaki durumlarda otomatik olarak doğrulama seviyesini yükseltecek kurallar belirleyin:\n\n- Talep hassas veri içeriyorsa (sağlık, finans, kesin konum)
SSS
What is a DSAR/SAR, and what should a DSAR web app do?
Bir DSAR (bazı yerlerde SAR olarak da anılır), bir kişinin sizden hangi kişisel veriye sahip olduğunuzu, nasıl kullandığınızı ve bir kopyasını almak istediğini sormasıdır.
Bir DSAR web uygulaması, talepleri tutarlı ve zamanında almanızı, doğrulamanızı, aramanızı, incelemenizi ve teslim etmenizi sağlar—savunulabilir bir denetim izi ile.
Which request types should the app support from day one?
En azından şunları desteklemeyi planlayın:
Erişim (verinin bir kopyası + gereken bağlam)
Silme (izin verilen durumlarda silme; istisnaları belgeleyin)
Düzeltme (sistemler arası hatalı veriyi düzeltme)
Taşınabilirlik (JSON/CSV gibi yeniden kullanılabilir bir formatta teslim)
Hatta “erişim” talepleri dar (belirli zaman aralığı/ürün) veya kapsamlı (“sizin elinizdeki her şey”) olabilir.
What’s the minimum end-to-end DSAR workflow to implement first?
Pratik bir minimum iş akışı şudur:
Tüm kanallardan tek bir vaka kaydına giriş
Kimlik doğrulama + yetki kontrolleri
Öncelikli sistemler/bağlayıcılar aracılığıyla veri keşfi
İnceleme/sansürleme + onay
Güvenli teslim + kapanış
Bu adımlar boyunca eklenemez bir denetim günlüğü
Bu adımları uçtan uca tamamlayamazsanız, zaman sınırlamalarını tutarlı şekilde karşılamakta zorlanırsınız.
What success metrics (KPIs) should we track for DSAR handling?
Uyumluluk ve operasyonel sağlık açısından hem zamanlamayı hem de kaliteyi yansıtan ölçülebilir KPI’lar kullanın, örneğin:
Ortalama onaylama süresi
Tamamlama süresi ve SLA uyum oranı
Doğrulama geçiş oranı ve manuel inceleme oranı
Bağlayıcı otomasyon kapsamı vs. manuel iş
Yeniden açılma oranı (eksik veri), sansür hata oranı
How should we structure the app: requester portal vs. admin portal vs. APIs?
Çoğu ekip ayrıştırır:
İstek sahibi portalı: talep gönderme, belge yükleme, durum izleme, sonuç indirme
İç API’ler/webhook’lar: CRM/destek/veri ambarı ile durum ve kanıt senkronizasyonu
Bu deneyimleri ayırmak RBAC, denetim ve gelecekteki politika değişikliklerini çok daha kolay kılar.
How should identity verification and authority checks work?
Birden fazla yöntem sunun ve riske göre yükseltme yapın:
Düşük risk için e-posta sihirli bağlantısı, SMS tek seferlik kod veya hesap girişi
Hassas yanıtlar için nadiren belge kontrolü (kimlik+özçekim veya manuel inceleme)
Temsilciler ve reşit olmayanlar için yetkiyi modelleyin (istemci vs veri sahibi)
Ne kontrol edildiğini ve nedenini kaydedin, kanıtları güvenli saklayın ve tanımlı bir takvimde silin.
How do we map where personal data lives before building connectors?
Kişisel verinin nerede olduğunu gösteren "canlı" bir envanter oluşturun: üretim veritabanları, veri ambarı, CRM, fatura, destek transcriptleri, günlükler vb.
Her sistem için: sahip, amaç, saklanan veri kategorileri, kullanılabilir tanımlayıcılar (e‑posta, kullanıcı ID, cihaz ID), erişim yöntemi (API/SQL/dışa aktarma), oran sınırlamaları ve saklama kısıtları. Bu envanter, talepler geldiğinde operasyonel tek kaynak olur.
What makes a good connector design for DSAR data retrieval?
Güvenilirlik ve kapsamlı sorgular öncelikli olmalı:
SaaS araçlar için API çekimleri
Birinci taraf veritabanları için parametreli SQL sorguları
API yoksa satıcı dışa aktarımları
Bağlayıcıları uygulamanın geri kalanından izole edin, sonuçları tutarlı bir şemaya normalize edin ve kaynak, zaman damgası ile eşleme yöntemi/güven puanını saklayın ki sonuçlar savunulabilir olsun.
How do we avoid over-collecting data or disclosing the wrong person’s data?
Kasıtlı bir eşleştirme stratejisi kullanın:
Yüksek güvenilirlikli tanımlayıcılarla başlayın (e‑posta, telefon, müşteri ID)
Düşük güvenilirlikli tanımlayıcıları dikkatle ekleyin (çerezler/oturum ID’leri)
Bulanık eşleştirmeyi sadece inceleme gerektiren "adaylar" olarak değerlendirin
Aşırı toplama önlemek için önce hafif “var mı?” kontrolleri çalıştırın, ardından onaylanan eşleşmeler için tam kayıtları çekin—bağlayıcı katmanında tenant kapsamını her zaman uygulayın.
How should review, redaction, and response packaging work?
İncelemeyi çoğu kuruluş için zorunlu tutun:
Kaynak ve veri kategorisine göre gruplanmış derlenmiş veri kümesini gösteren bir inceleme alanı sağlayın
Yapısal kararlar (dahil et, sansürle, hariç tut, hukuka gönder) destekleyin
Hariç tutma gerekçelerini (üçüncü taraf verisi, ayrıcalık vb.) belgeli şekilde yakalayın
Hem insan tarafından okunabilir rapor (HTML/PDF) hem makine tarafından okunabilir dışa aktarım (JSON/CSV) oluşturun; e‑posta ekleri yerine zaman sınırlı, kimlik doğrulanmış indirme bağlantıları kullanın.
Veri Erişim Talepleri ve Gizlilik İçin Web Uygulaması Nasıl Oluşturulur | Koder.ai
Yanıt belgeler veya serbest metin notları içeriyorsa
Talep yeni bir cihazdan, olağandışı bir bölgeden veya şüpheli bir e‑posta alan adından geliyorsa\n\nDoğrulamayı yükselttiğinizde, bunun kısa ve yalın bir nedenini gösterin ki bu keyfi görünmesin.\n\n### Doğrulama kanıtlarını güvenli saklayın—sonra programlı olarak silin\n\nKimlik doğrulama kanıtları (kimlikler, yetki belgeleri, denetim olayları) şifrelenmiş, erişim kontrollü ve sınırlı rollere görünür olmalı. Sadece gerekli olanı saklayın, açık bir saklama süresi belirleyin ve silmeyi otomatikleştirin.\n\nDoğrulama kanıtlarını kendi başına hassas veri olarak ele alın; denetim izinde daha sonra uyumluluk kanıtı olarak görünmelidir.\n\n## Verilerinizi Haritalayın ve Sistem Bağlayıcıları Oluşturun\n\nBir veri erişim talebi uygulaması, kişisel verinin gerçekten nerede tutulduğuna dair görünürlüğünüz kadar iyidir. Tek bir bağlayıcı yazmadan önce sürdürülebilir bir sistem envanteri oluşturun.\n\n### Sürekli güncellenen bir sistem envanteri oluşturun\n\nKullanıcı tanımlayıcı bilgisi içermesi muhtemel sistemlerle başlayın:\n\n- Temel veritabanları (üretim, analiz, veri ambarı)\n- SaaS araçları (CRM, e‑posta pazarlama, faturalama, ürün analitiği)\n- Destek sistemleri (ticketing, sohbet transcriptleri, arama kayıtları)\n- Günlükler ve olay akışları (uygulama günlükleri, CDN/WAF günlükleri, kimlik doğrulama günlükleri)\n\nHer sistem için: sahibi, amacı, saklanan veri kategorileri, mevcut tanımlayıcılar (e‑posta, kullanıcı ID, cihaz ID), erişim yöntemi (API/SQL/dışa aktarma) ve kısıtlamalar (oran sınırlamaları, saklama, satıcı geri dönüş süresi) kaydedin. Bu envanter talepler geldiğinde sizin “gerçek kaynağınız” olur.\n\n### Kaynağa uygun bağlayıcılar oluşturun\n\nBağlayıcıların karmaşık olması gerekmez; güvenilir olmaları gerekir:\n\n- SaaS araçlar için API çekimleri (mümkünse artımlı senkronizasyon)
Birinci taraf sistemler için veritabanı sorguları (bilinen tanımlayıcılarla parametrelenmiş sorgular)
API olmayan araçlar için satıcı dışa aktarımları (belge biçimi, sıklık, kimin başlattığı)
\nBağlayıcıları uygulamanın geri kalanından izole tutun ki bunları güncellerken iş akışı bozulmasın.\n\n### İnceleme için veriyi normalize edin\n\nFarklı sistemler aynı kişiyi farklı şekilde tanımlar. Alınan kayıtları tutarlı bir şemaya normalize edin ki inceleyenler elma ile armut karşılaştırmasın. Basit bir model şunlar olabilir:\n\n- person_identifier (eşleştirdiğiniz değer)\n- data_category (profil, iletişimler, işlemler, telemetri)\n- field_name ve field_value\n- record_timestamp\n\n### Her alan için kökeni izleyin\n\nKöken, sonuçları savunulabilir kılan unsurdur. Her değerin yanında meta veriyi saklayın:\n\n- Kaynak sistem ve nesne/tablo\n- Alım zamanı ve orijinal zaman damgası\n- Eşleştirme yöntemi (tam, bulanık) ve güven skorunu\n\nBirisi "Bu nereden geldi?" diye sorduğunda, kesin bir cevap ve düzeltme/silme yolunuz olur.\n\n## Veri Getirme ve Eşleştirme Motorunu Oluşturun\n\nBu, "bu kişi hakkında her şeyi bul" kısmıdır—ve dikkatsizce yapılırsa gizlilik riski en yüksek olan bölümdür. İyi bir getirme ve eşleştirme motoru dikkatli olmalıdır: yeterince geniş arama yapıp eksiksiz olmalı, ama alakasız verileri çekmeyecek kadar dar olmalıdır.\n\n### Net bir arama stratejisiyle başlayın\n\nMotorunuzu girişte güvenilir şekilde toplayabildiğiniz tanımlayıcılar etrafında tasarlayın. Yaygın başlangıç noktaları e‑posta, telefon numarası, müşteri ID, sipariş numarası ve posta adresidir.\n\nArdından ürün ve analitik sistemlerde sık bulunan tanımlayıcıları genişletin:\n\n- Bağlantılı hesaplar (ebeveyn/çocuk hesaplar, hane profilleri, işyeri yöneticileri)\n- Cihaz ID’leri ve reklam/izleme tanımlayıcıları (uygulanabilir ve yasal olarak destekleniyorsa)\n- Oturum ID’leri ve çerez tanımlayıcıları (genellikle daha düşük güven)\n\nKararlı anahtar paylaşmayan sistemler için bulanık eşleştirme ekleyin (ör. normalleştirilmiş isim + adres) ve sonuçları inceleme gerektiren "aday" olarak ele alın.\n\n### Varsayılan olarak aşırı toplamayı azaltın\n\n"Tüm kullanıcı tablosunu dışa aktar" dürtüsünden kaçının. Bağlayıcıları mümkün olduğunca tanımlayıcıya göre sorgulayan ve yalnızca ilgili alanları döndüren şekilde oluşturun—özellikle günlükler ve olay akışları için. Daha az çekmek, inceleme süresini azaltır ve başkasının verisini ifşa etme olasılığını düşürür.\n\nPratik bir desen iki adımlıdır: (1) hafif "bu tanımlayıcı var mı?" kontrolleri çalıştırın, sonra (2) teyit edilen eşleşmeler için tam kayıtları çekin.\n\n### Çok kiracılı izolasyonu zorunlu kılın\n\nUygulamanız birden fazla marka, bölge veya iş birimine hizmet veriyorsa, her sorgu bir kiracı kapsamı taşımalıdır. Kiracı filtrelerini bağlayıcı katmanında uygulayın (sadece UI’da değil) ve çift kaçakları önlemek için testlerde doğrulayın.\n\n### Dağınık gerçek dünya kenar durumlarını ele alın\n\nÇoğaltıları ve belirsizlikleri planlayın:\n\n- Sistemler ve zaman içinde yinelenen profiller\n- Paylaşılan e‑postalar (aile posta kutuları, billing@ gibi rol adresleri)\n- Birleştirilmiş hesaplar ve tarihsel tanımlayıcılar\n\nEşleştirme güvenini, hangi tanımlayıcıyla eşleşildiğine dair kanıtı ve zaman damgalarını saklayın ki inceleyenler dahil/ hariç kararını açıklayabilsin ve savunabilsin.\n\n## İnceleme, Sansürleme ve Yanıt Paketleme Ekle\n\nGetirme motorunuz ilgili kayıtları derledikten sonra, bunları doğrudan talep sahibine göndermemelisiniz. Çoğu kuruluş, üçüncü şahıs kişisel verisinin, gizli ticari bilginin veya yasa/kontratla kısıtlı içeriğin yanlışlıkla ifşasını önlemek için insan inceleme adımına ihtiyaç duyar.\n\n### Gerçekten kullanılabilir bir inceleme kuyruğu oluşturun\n\nİnceleyenlerin yapmasını sağlayın:\n\n- Derlenmiş veri setini kaynak sistemine göre gruplandırılmış şekilde görme (CRM, destek, faturalama, ürün günlükleri)\n- Veri kategorisine göre filtreleme (tanımlayıcılar, iletişimler, işlemler, cihaz verileri)\n- Altta yatan kanıtlara erişim (kayıt ID’leri, zaman damgaları, kaynak sistem)\n- İç not ekleme ve bir şey eksik görünüyorsa yeniden çekme talep etme\n\nBurası aynı zamanda kararları standartlaştırdığınız yerdir. Az sayıda karar tipi (dahil et, sansürle, geri tut, hukuka gönder) yanıtları tutarlı ve denetlenebilir kılar.\n\n### Sansürleme ve hariç tutmayı birinci sınıf özellik olarak ele alın\n\nUygulamanız hem bir kaydın hassas kısımlarını kaldırmayı hem de ifşa edilmesi yasak olduğunda bütün kayıtları hariç tutmayı desteklemelidir.\n\nSansürleme şunları kapsamalıdır:\n\n- Üçüncü şahıs verileri (mesaj dizilerindeki isimler, e‑posta adresleri, telefon numaraları)\n- Gizli ticari bilgiler (iç araç detayları, güvenlikle ilgili tanımlayıcılar)\n- Hassas içeriğin sık saklandığı "serbest metin" alanları (notlar, transcriptler, ekler)\n\nHariç tutmalar, verinin açıklanamayacağı durumlarda mümkün olmalı ve yapılandırılmış gerekçelerle belgelemelidir (ör. hukuki ayrıcalık, ticari sırlar, üçüncü şahısların zarar görmesi).\n\nVeriyi sadece gizlemeyin—kararı savunabilmek için gerekçeyi yapılandırılmış şekilde yakalayın.\n\n### İnsanlar ve makineler için paketler hazırlayın\n\nÇoğu DSAR iş akışı iki teslimatla en iyi çalışır:\n\n- Bulduklarınızı ve sansürlediğiniz/ hariç tuttuğunuz şeyleri özetleyen insan-okunur rapor (HTML/PDF)\n- Açıklanan veriyi öngörülebilir bir şemada içeren makine-okunur dışa aktarma (JSON/CSV)\n\nTüm çıktılarda kaynaklar, ilgili tarihler, sansürleme/hariç tutma açıklamaları ve net sonraki adımlar (soru sorma, itiraz etme, veriyi düzeltme) gibi faydalı meta veriler ekleyin. Bu, yanıtı bir veri dökümü olmaktan anlaşılır bir sonuca dönüştürür.\n\nTutarlı bir his için yanıt şablonları kullanın ve bunları versiyonlayın ki hangi vakada hangi şablonun kullanıldığını gösterebilesiniz. Bunu denetim günlükleriyle eşleştirin ki pakete yapılan her değişiklik izlenebilir olsun.\n\n## Güvenlik Kontrolleri, İzinler ve Denetim Günlükleri\n\nGüvenlik, bir veri erişim talebi web uygulamasında "sonradan eklenen bir özellik" değildir—kişisel verinin sızmasını önleyen ve her talebin doğru şekilde işlendiğini kanıtlayan temeldir. Amaç basittir: sadece doğru kişiler doğru veriyi görebilsin, her işlem izlenebilir olsun ve dışa aktarılan dosyalar kötüye kullanılamasın.\n\n### Rol tabanlı izinler (RBAC)\n\nSorumlulukların bulanıklaşmaması için net rol tabanlı erişim kontrolü ile başlayın. Tipik roller şunlardır:\n\n- Gizlilik yöneticisi: politikaları, bağlayıcıları, şablonları ve yükseltmeleri yapılandırır.\n- İnceleyen: alınan kayıtları inceler, kenar durumları işaretler, sansür önerir.\n- Onaylayan: verinin yayınlanması öncesi son onayı verir.\n- Denetçi: vaka geçmişine, kanıtlara ve raporlara salt okunur erişim sağlar.\n\nİzinleri ayrıntılı tutun. Örneğin, bir inceleyen alınan verilere erişebilir ama son tarihleri değiştiremeyebilir; bir onaylayan yanıtı yayınlayabilir ama bağlayıcı kimlik bilgilerini düzenleyemez.\n\n### Değiştirilemez denetim izi (ne olduğunu kanıtlayın)\n\nDSAR iş akışınız şunları kapsayan sadece ekleme denetim günlüğü üretmelidir:\n\n- Kim bir şeyi görüntüledi, değiştirdi, dışa aktardı veya sildi\n- Hangi kayıtların erişildiği (en azından tanımlayıcılar ve kaynak sistem)\n- İşlemlerin ne zaman yapıldığı (zaman dilimi ile zaman damgaları)\n- Neden yapıldığı (vaka notları, karar kodları)\n\nDenetim girdilerinin değiştirilmesini zorlaştırın: uygulama servisine yazma erişimini sınırlayın, düzenlemeleri engelleyin ve günlük partilerini hash/İMZA ile saklamayı düşünün.\n\nDenetim günlükleri ayrıca kısmi ifşa veya reddetme gibi kararları savunurken kullanılır.\n\n### Şifreleme, anahtarlar ve sır yönetimi\n\nHem iletimde (TLS) hem de saklamada (veritabanları, nesne depolama, yedekler) şifreleyin. Gizli anahtarları (API tokenları, veritabanı kimlik bilgileri) kodda, yapılandırma dosyalarında veya destek ticketlarında değil, ayrı bir sır yöneticisinde saklayın.\n\nDışa aktarmalar için kısa ömürlü, imzalı indirme bağlantıları ve gerektiğinde şifreli dosyalar kullanın. Kim dışa aktarma oluşturabilir sınırlandırın ve otomatik sonlandırma ayarlayın.\n\n### Kötüye kullanımı önleme ve güvenli indirmeler\n\nGizlilik uygulamaları kazıma ve sosyal mühendislik girişimlerine hedef olur. Şunları ekleyin:\n\n- Portallar ve indirme uç noktalarında oran sınırları ve istek sınırlaması\n- Anomali tespiti (vaka sayısında ani artışlar, tekrarlayan başarısız doğrulamalar, olağandışı yönetici etkinliği)\n- Güvenli indirmeler (virüs taraması, watermarking ve dahili inceleme için "sadece görüntüleme" seçenekleri)\n\nBu kontroller gerçek müşteriler ve iç ekip için kullanılabilirliği korurken riski azaltır.\n\n## Bildirimler, Son Tarihler ve Müşteri İletişimi\n\nBir DSAR iş akışı, müşterilerin hemen fark ettiği iki şeye bağlı olarak başarılı olur veya başarısız olur: zamanında yanıt verip vermediğiniz ve güncellemelerinizin açık, güven verici hissedilip hissedilmediği. İletişimi birinci sınıf özellik olarak ele alın—sonunda eklenmiş birkaç e‑posta değil.\n\n### Şablon tabanlı mesajlar tutarlılığı sağlar\n\nKüçük bir set onaylı şablonla başlayın; bunları lokalize edin. Kısa, belirli ve hukuki ağırlıktan uzak tutun.\n\nYapılacak yaygın şablonlar:\n\n- "Doğrulama gerekli": neye ihtiyacınız olduğu, nasıl sağlayacakları ve sonraki adımlar\n- "Uzatma bildirimi": gerekçe, yeni son tarih ve hangi çalışmaların yapıldığı\n- "Tamamlama": nelerin sağlandığı, bunlara nasıl güvenli şekilde erişileceği ve takip soru/itiraz yolları\n\nDeğişkenler ekleyin (talep ID’si, tarihler, portal bağlantısı, teslimat yöntemi) ki uygulama ayrıntıları otomatik doldursun, ama hukuki/gizlilik onaylı metni korusun.\n\n### Yargı ve talep türüne göre son tarihler\n\nSon tarihler yasalara (ör. GDPR vs CCPA/CPRA), talep türüne (erişim, silme, düzeltme) ve kimlik doğrulamanın beklenip beklenmediğine göre değişebilir. Uygulamanız şunları hesaplamalı ve göstermelidir:\n\n- geçerli son tarih ve neden bu tarihin belirlendiği (kural + durum)\n- duraklatma koşulları (ör. doğrulamayı beklemek) ve bunların zamanlayıcıyı nasıl etkilediği\n- uzatma uygunluğu ve uzatma bildirimi gönderecek eylem (denetim izini damgalayan)\n\nSon tarihleri vaka listesinde, vaka detayında ve personel hatırlatmalarında görünür yapın.\n\n### Entegrasyonlar: e‑posta, ticketing ve mesajlaşma\n\nHer kuruluş başka bir gelen kutusu istemeyebilir. Güncellemelerin mevcut araçlara akması için webhook ve e‑posta entegrasyonları sağlayın (ör. yardım masası ticket sistemi veya iç sohbet).\n\ncase.created, verification.requested, deadline.updated ve response.delivered gibi olay temelli kancalar kullanın.\n\n### Müşteri portalı güncellemeleri ve güvenli teslim bağlantıları\n\nBasit bir portal karşılıklı iletişimi azaltır: müşteriler durumları görebilir ("alındı","doğrulanıyor","işleniyor","hazır"), belge yükleyebilir ve sonuçları alabilir.\n\nVeri teslim ederken ek kullanmaktan kaçının. Zaman sınırlı, kimlik doğrulanmış indirme bağlantıları sağlayın ve bağlantının ne kadar aktif olduğu ve süresi dolarsa ne yapılacağı konusunda net rehberlik verin.\n\n## Saklama, Raporlama ve Politika Hizalanması\n\nSaklama ve raporlama, bir DSAR aracını "bir iş akışı uygulaması" olmaktan çıkarıp uyumluluk sistemine dönüştürdüğü yerdir. Amaç basittir: saklamanız gerekeni tutun, gerekmediğini silin ve kanıtla ispatlayın.\n\n### Nesneye göre net saklama kuralları belirleyin\n\nSaklamayı yalnızca "vaka kapandı"ya göre değil, nesne türüne göre tanımlayın. Tipik bir politika şunları ayrır:\n\n- Vaka kaydı (talep ayrıntıları, son tarihler, alınan eylemler)\n- Kimlik doğrulama kanıtı (belgeler, canlılık kontrolleri, doğrulama tokenları)\n- Dışa aktarmalar ve yanıt paketleri (ZIP/PDF/JSON dosyaları)\n- Denetim günlükleri (değiştirilemez olay geçmişi)\n\nSaklama sürelerini yargıya ve talep türüne göre yapılandırılabilir tutun. Örneğin, denetim günlüklerini kimlik kanıtlarından daha uzun saklayabilir, dışa aktarmaları teslimattan kısa süre sonra silebilir ve gönderilen şeyin hash’i ile meta verisini saklayabilirsiniz.\n\n### Hukuki bekletmeler ve istisnalar (işlemeyi duraklatma veya sınırlama)\n\nSilme zamanlayıcılarını duraklatabilecek ve personelin sonraki eylemlerini kısıtlayabilecek açık bir hukuki bekletme durumu ekleyin. Bu şunları desteklemeli:\n\n- Gerekçe kodu (dava, soruşturma, sözleşmesel uyuşmazlık)\n- Kapsam (tüm vaka vs belirli veri kaynakları)\n- Onay ve inceleme tarihleri (bekletmelerin kazara kalıcı olmaması için)\n\nAyrıca muafiyetleri ve sınırlamaları (ör. üçüncü taraf verisi, ayrıcalıklı iletişimler) yapılandırılmış sonuçlar olarak modelleyin, serbest metin notu değil, böylece tutarlı raporlanabilir olsunlar.\n\n### Denetime dayanacak raporlar hazırlayın\n\nDüzenleyiciler ve iç denetçiler genellikle örnekler yerine eğilimler ister. Şunları kapsayan raporlar oluşturun:\n\n- Talep türüne göre hacimler (erişim, silme, düzeltme)\n- Yasal son tarihlere karşı yanıt süreleri\n- Sonuçlar (yerine getirildi, kısmen yerine getirildi, reddedildi)\n- Kullanılan muafiyetler ve sıklıkları\n\nRaporları yaygın formatlarda dışa aktarın ve rapor tanımlarını versiyonlayın ki sayılar açıklanabilir kalsın.\n\n### Politikalarla hizalanma (ve ürün içinden onlara referans)\n\nUygulamanız kuruluşunuzun yayımladığı kurallara atıfta bulunmalı. Yönetici ayarlarından ve vaka görünümlerinden /privacy ve /security gibi dahili kaynaklara doğrudan referans verin ki operatörler her saklama ve kararın "nedenini" doğrulayabilsin.