Personel verisi saklama, bir kaydın ne kadar süre tutulacağını ve bu sürenin sonunda ne olacağını tanımlayan kararlar bütünüdür. Bu yazıda test ortamındaki verinin üretim ortamından neden ayrı ele alındığını, saklama süresinin hangi etkenlere bağlı olduğunu ve silmenin neden tek bir adım olmadığını bulacaksınız.
Test ortamındaki personel verisi neden farklı ele alınır?
Test ortamının kuralları üretim ortamının kurallarıyla nadiren aynı düzeydedir. Deneme veritabanına daha geniş bir ekip erişir, yedekleri daha gevşek saklanır ve kurulum sırasında çoğu zaman gerçek kayıtlarla doldurulur. Bu farklar, üretimde korunan bir kaydın deneme ortamında korunmasız kalmasına yol açar.
İkinci neden, verinin amacıdır. Üretim ortamındaki kayıt bir kişiyi temsil eder ve o kişiyle ilgili işlemler için gereklidir; deneme ortamındaki kayıt ise yazılımın davranışını gözlemlemek için vardır. Amaç farklı olduğunda, kaydın taşıması gereken ayrıntı da farklıdır. Test için gereken alan sayısı genellikle üretimde tutulandan azdır.
Üçüncü neden, silmenin güçlüğüdür. Bir kaydı üretim ortamından silmek, aynı kaydın deneme ortamlarında, yedeklerde, günlük dosyalarında ve hata raporlarında bulunmadığı anlamına gelmez. Nerede olduğu bilinmeyen bir kopyayı silmek mümkün olmadığı için en güvenli yöntem, o kopyayı hiç oluşturmamaktır. Kurgusal kayıtlar bu sorunu baştan ortadan kaldırır; aynı yaklaşımı kariyer profili test kayıtları yazısında ayrıntılı ele alıyoruz.
Saklama süresi neye bağlıdır?
Saklama süresi tek bir sayıyla ifade edilemez. Süreyi belirleyen etkenler bir arada değerlendirilir ve bu etkenler yargı alanına göre değişir; kesin süreler ve koşullar ilgili mevzuata ve hizmet sağlayıcının kendi politikasına bağlıdır.
| Etken | Süreyi nasıl etkiler | Kaydın rolü |
|---|---|---|
| Verinin amacı | Amaç ortadan kalkınca süre kısalır | Amacı kayıtta tutmak |
| Yargı alanı | Zorunlu alt ve üst sınırlar koyabilir | Alanı ayrı tutmak |
| Sözleşme ilişkisi | Tarafların yükümlülükleri belirleyicidir | Durumu kayıtta göstermek |
| Uyuşmazlık olasılığı | Süreyi uzatan bir etkendir | Gerekçeyi kaydetmek |
| Veri türü | Bazı türler daha kısa tutulur | Türü alan olarak saklamak |
Tablodan çıkan sonuç şudur: saklama süresi bir yapılandırma değeri değil, gerekçesiyle birlikte saklanması gereken bir karardır. Süreyi yalnızca bir sayı olarak tutmak, sürenin neden o değere ayarlandığını sonradan açıklanamaz hâle getirir.
Silme ile anonimleştirme arasındaki fark nedir?
Silme, kaydın ortadan kaldırılmasıdır; anonimleştirme ise kaydın kişiyle bağının koparılmasıdır. İkisi farklı sonuçlar üretir ve farklı durumlarda tercih edilir.
Silmenin üstünlüğü, geri döndürülemez olmasıdır. Buna karşılık silme, kaydın bağlı olduğu istatistikleri de bozar; bir dönemin toplam sayıları geriye dönük olarak değişir. Anonimleştirme bu istatistikleri korur, ama bağın gerçekten koparıldığından emin olmak gerekir: yalnızca ad alanını boşaltmak, kalan alanların birleşimiyle kişiyi yeniden tanımlanabilir kılar.
Üçüncü bir yol, veriyi toplu hâle getirmektir. Tekil kayıtlar bir araya getirilip yalnızca sayısal özetler saklandığında, kişiye bağlanabilecek ayrıntı kalmaz. Bu yol, raporlama ihtiyacı olan sistemlerde sık başvurulan bir dengedir.
Hangi yolun seçileceği verinin amacına bağlıdır. Amaç ortadan kalktıysa silme; amaç sürüyor ama ayrıntı gerekli değilse anonimleştirme veya toplu hâle getirme uygun olur.
Silme süreci hangi adımlardan oluşur?
Silme, tek bir düğmeye basmak değil bir sıradır. Adımlar atlandığında kayıt görünürde yok olur ama bir kopyası geride kalır.
İlk adım, kaydın hangi sistemlerde bulunduğunu çıkarmaktır: ana veritabanı, arama dizini, önbellek, yedekler, günlük dosyaları ve raporlar. İkinci adım, her sistem için bir silme yolunun tanımlanmasıdır; bazı sistemlerde silme yerine süre aşımı uygulanır ve bu süre bilinmelidir.
Üçüncü adım, silmenin doğrulanmasıdır. Kaydın gerçekten gittiğini göstermek için aynı anahtarla arama yapılır ve sonuç boş dönmelidir. Dördüncü adım, silme işleminin kaydının tutulmasıdır: ne zaman, hangi kapsamda ve hangi gerekçeyle silindi. Bu kayıt, kişinin kaydı olmadan da tutulabilir; çünkü içinde kişisel veri bulunması gerekmez.
Beşinci adım, süreçlerin düzenli olarak gözden geçirilmesidir. Yeni bir sistem eklendiğinde silme listesine de eklenmelidir; aksi hâlde kapsam sessizce daralır.
Kurgusal kayıtlar saklama yükünü nasıl azaltır?
Kurgusal bir kaydın arkasında korunması gereken bir kişi yoktur; bu yüzden kayıt, silme ve saklama yükümlülüklerinin büyük kısmını doğurmaz. Deneme veritabanını kurgusal kayıtlarla doldurmak, gerçek veriyi deneme ortamına hiç taşımamayı mümkün kılar.
Bu yaklaşımın sınırı da vardır. Kurgusal kayıt, gerçek verinin bütün dağılımını temsil etmez; bu yüzden üretim verisinden türetilmiş istatistiklerle beslenmesi gerekebilir. Besleme yapılırken bile kaydın kişiye bağlanabilir olmaması korunmalıdır.
İkinci sınır, kaydın kurgusal olduğunun görünmesidir. Bir etiket veya sabit bir ön ek, veri yanlış ortama taşındığında kimsenin onu gerçek bir başvuru sanmasını engeller. Bu işaret, saklama politikasının bir parçası olarak ele alınmalıdır.
Silme işleminde en sık yapılan hatalar hangileridir?
Silme süreçleri çoğu zaman doğru niyetle ama eksik kapsamla kurulur. Sık görülen hatalar şunlardır:
- Yalnızca ana tabloyu silmek: Arama dizini ve rapor tabloları kaydın kopyasını taşımaya devam eder.
- Metin alanı üzerinden silmek: Ad veya e-posta ile yapılan silme, aynı değeri taşıyan başka kayıtları da etkiler.
- Yedekleri unutmak: Yedekten geri yükleme yapıldığında silinmiş kayıt yeniden ortaya çıkar.
- Günlükleri atlamak: Hata kayıtları ve erişim günlükleri, kaydın alanlarını düz metin olarak saklıyor olabilir.
- Silme kaydında kişisel veri tutmak: Süreci kanıtlamak için tutulan kayıt, yeni bir saklama yükümlülüğü doğurur.
Bu beş hatanın ortak sonucu, kaydın görünürde silinmesi ama bir kopyasının geride kalmasıdır. Bunu önlemenin yolu, silmeyi tanımlı bir liste üzerinden yürütmek ve her sistem için ayrı bir doğrulama adımı tanımlamaktır.
Geliştiriciler için: saklama politikasının kodlanması
İlk karar, silinecek kaydın nasıl bulunacağıdır. Silme, kaydın kimliği üzerinden yapılmalı; ad veya başka bir metin alanı üzerinden yapılan silme, aynı ada sahip farklı kayıtları etkiler. Kimlik tabanlı silme, işlemi hem güvenli hem tekrarlanabilir kılar.
İkinci karar, süresi geçen kayıtların nasıl işaretleneceğidir. Silme işlemini doğrudan veritabanında çalıştırmak yerine, önce işaretleyip sonra silmek iki fayda sağlar: yanlış eşleşme fark edilir ve silme kapsamı önceden görülebilir.
Üçüncü karar, türetilmiş verilerin ne olacağıdır. Arama dizinleri, önbellekler ve rapor tabloları ana kaydın kopyalarını taşır; ana kayıt silindiğinde bunların da güncellenmesi gerekir. Güncelleme bir kuyruk üzerinden yapılıyorsa, gecikmenin ne kadar sürebileceği ve bu süre boyunca kaydın görünür kalıp kalmayacağı tanımlanmalıdır.
Dördüncü karar, silme işleminin kendi kaydının nasıl tutulacağıdır. Bu kayıt kişisel veri içermemelidir; kaydın kimliği, işlem tarihi ve kapsamı yeterlidir. Ücret kayıtlarında olduğu gibi, hangi alanın kişiye bağlandığını bilmek saklama kararının önkoşuludur; bu ayrımı maaş para birimi dönem nasıl yazılır yazısında ele alıyoruz.
Sonraki adımlar
İlk adım, kaydın hangi sistemlerde kopyalandığını listelemek ve her biri için bir silme yolu tanımlamaktır. İkinci adım, saklama süresini gerekçesiyle birlikte kaydetmek ve sürenin sonunda ne olacağını yazılı hâle getirmektir. Üçüncü adım, deneme ortamlarını kurgusal kayıtlarla beslemeye geçmektir.
Kendi deneme kümenizi kurmak için kariyer profili üreticisinde ülke seçip kayıt üretebilir, aynı kimlik anahtarıyla aynı kaydı geri getirebilirsiniz. Ülkeye özgü alanların nasıl göründüğünü görmek için Türkiye sayfası kısa bir özet sunar.
Bu sayfadaki kayıtlar yalnızca yazılım denemeleri için üretilmiş sentetik örneklerdir; hiçbir gerçek çalışana ait değildir ve kişisel veri saklama yükümlülüklerinin yerine geçmez.