Silme talebi bir tablo ismiyle başlamaz
Bir kullanıcı veya müşteri veri silme talebi ilettiğinde ilk refleks ilgili kullanıcı satırını bulup silmek olabilir. Bu çoğu sistemde eksik kalır. Aynı kişiye ait veri siparişlerde, loglarda, destek kayıtlarında, fatura tarafında, yedeklerde ve analitik eventlerde farklı biçimlerde bulunabilir.
Bu yazı hukuki yorum yapmaz; her şirket kendi hukuk/uyum danışmanıyla saklama gerekçelerini netleştirmelidir. Teknik tarafta yapmanız gereken şey, veri alanlarını envantere bağlamak ve talebin hangi sistemlerde hangi aksiyona dönüştüğünü kanıtlamaktır.
- Önce veri envanteri çıkarılır: hangi domain, hangi veri tipi, hangi saklama gerekçesi.
- Canlı veride silme, anonimleştirme veya saklama kararı domain bazında verilir.
- Yedekler için retention ve geri yükleme davranışı ayrıca yazılır.
- Her aksiyon denetim ile izlenir; talep kapandığında kanıt paketi oluşur.
Canlı veri, yedek ve denetim aynı şekilde davranmaz
Canlı veritabanında bir kaydı silebilirsiniz; ancak aynı kayıt yedeklerde retention süresi boyunca bulunabilir. Denetim kayıtları ise çoğu zaman silme kanıtının parçasıdır ve ayrı saklama politikasına tabidir. Bu ayrım açık yazılmadığında ekip yanlış beklenti üretir.
İyi süreç, “nerede fiziksel silme, nerede maskeleme, nerede retention sonuna kadar saklama?” sorusunu domain bazında cevaplar. Örneğin uygulama profili ile fatura kaydı aynı karara tabi olmayabilir.
Veri domain karar tablosu
account_profile -> canlı veride sil/anonimleştir support_exports -> süreli linki iptal et, dosya retention kontrolü billing_records -> saklama gerekçesi ve erişim sınırıyla değerlendir denetim_logs -> silme talebinin kanıtı olarak retention politikasına bağla yedek_objects -> retention sonuna kadar izlenir, geri yükleme sonrası yeniden işlenir analytics_events -> mümkünse kişiyle bağını kopar veya anonimleştir
Silme kuyruğu kullanıcıya ve ekibe görünür olmalı
Silme talebi bazı sistemlerde hemen kapanmaz. Onay, export, bekleme penceresi, yedek saklama süresi ve fiziksel temizlik adımları olabilir. Bu yüzden silme kuyruğu hem müşteri iletişimi hem teknik takip için önemlidir.
TürkDB tarafında deletion queue gibi bir yaklaşım, süreci kaybolan ticket olmaktan çıkarır. Hangi tenant, hangi talep, hangi aşama, hangi tarih ve hangi kanıt var soruları tek yerde takip edilir.
Silme talebi izleme akışı
turkdb compliance inventory --tenant acme turkdb compliance export request --tenant acme --subject user_123 turkdb compliance deletion request --tenant acme --subject user_123 turkdb compliance deletion-status --tenant acme --subject user_123 turkdb audit list --tenant acme --filter deletion --limit 50
Komut isimleri ürün yüzeyine göre değişebilir; önemli olan akışın envanter, export, silme durumu ve denetim kanıtı üretmesidir.
Geri yükleme sonrası silme talebi yeniden uygulanmalıdır
Bir yedekten geri dönüldüğünde daha önce silinmiş veya anonimleştirilmiş veriler tekrar görünür hale gelebilir. Bu nedenle silme talepleri sadece canlı tablodaki DELETE işlemi olarak değil, geri yükleme sonrası yeniden uygulanacak bir kayıt olarak düşünülmelidir.
Bu detay genellikle tatbikatlarda ortaya çıkar. Geri yükleme testleri yalnızca uygulama ayağa kalkıyor mu diye bakmamalı; açık silme talepleri ve veri yaşam döngüsü kuralları geri yükleme hedefinde yeniden uygulanıyor mu diye de kontrol etmelidir.