Veri Erişim Talepleri ve Gizlilik İçin Web Uygulaması Nasıl Oluşturulur

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)