Veriyi sonsuza dek saklamadan uyumu kanıtlamanızı sağlayan, silme takvimlerini denetim ihtiyaçlarıyla birleştiren pratik bir veri saklama ve yasal bekletme iş akışını öğrenin.
Çoğu ekip, verinin artık gerekmediğinde silinmesi gerektiği konusunda hemfikirdir. Bu, riski azaltır, depolamayı küçültür ve gizlilik kurallarına uyumu kolaylaştırır. Sorun, daha sonra biri “Ne olduğunu kanıtlayabiliyor musunuz?” diye sorduğunda başlar. Bu soru bir denetçiden, bir müşteri şikayetinden veya bir davadan gelebilir.
Sağlam bir veri saklama yasal bekletme iş akışı zor bir gerilimi çözer: takvime göre silme, ama altta yatan veri artık yokken bile kararları, erişimleri ve eylemleri gösterebilme.
Saklama, bir veri kategorisini iş veya hukuki sebeple ne kadar süre tuttuklarınızdır. Silme, o süre dolduğunda kopyaların ve yedeklerin tanımlı bir pencere içinde kaldırılması da dahil olmak üzere yaptığınız işlemdir. Yasal bekletme ise belli kayıtların bir ihtilaf, soruşturma veya düzenleme nedeniyle korunmasını gerektirdiği için silmeyi geçici olarak durdurmaktır.
“Delil tutmak” her zaman tam veriyi sonsuza dek saklamak anlamına gelmez. Çoğunlukla, orijinal kişisel veriyi yeniden oluşturmadan denetimi destekleyen daha küçük, daha güvenli bir kanıt seti tutmak demektir. Örneğin elinizde bulunabilir:
Amaç, neyin silineceğine, neyin duraklatılacağına ve hangi hafif denetim kanıtlarının kalacağına karar veren tekrarlanabilir bir süreç oluşturmaktır.
Bu operasyonel bir rehberdir, hukuki tavsiye değildir. Saklama süreleri ve bekletme tetikleyicileri hukuk danışmanınızla gözden geçirilmeli ve sektör kurallarına uygun hale getirilmelidir.
Eğer ne tuttuğunuzu bilmiyorsanız temiz bir silme takvimi veya yasal bekletme yürütemezsiniz. Topladığınız veri türlerini listeleyerek başlayın, sonra bunları depolayan veya kopyalayan her sistemi not edin.
“Sadece veritabanı”nın ötesini düşünün. Müşteri profilleri uygulama veritabanınızda olabilir, ama aynı bilgiler destek ticket’larında, e-posta dizilerinde, sohbet araçlarında, dışa aktarılan hesap tablosu dosyalarında ve ek dosyalarda da görünebilir. Günlükler, yedekler ve analiz sistemleri sıklıkla unutulan ekstra kopyalar tutar.
Basit bir yol, her veri kümesini yazıp üç soruyu yanıtlamaktır: nerede oluşturuluyor, nereye kopyalanıyor ve kim silebiliyor?
Sürprizlere yol açma eğiliminde olan kaynaklara odaklanın:
Her şeyin aynı muameleyi ilk günden almasına gerek yok. İş akışının şu an neleri kapsadığını ve sonradan nelerin ekleneceğini tanımlayın.
Pratik bir ilk kapsam genellikle kontrolünüzde olan sistemleri (takvime göre silebileceğiniz), yasal bekletme sırasında aranması gereken sistemleri ve silmeden sonra yalnızca denetim kanıtı tutan sistemleri içerir.
Ayrıca kapsam dışını da yazın (örneğin dizüstülerde kişisel notlar). Bu boşluklar “her şeyi sonsuza dek tutma” eğiliminin başladığı yerlerdir.
Karışıklık genellikle aynı kelimelerin farklı anlamlarda kullanılmasından kaynaklanır. İş akışı daha kolay çalışsın ve savunulabilir olsun diye baştan tanımlarda anlaşın.
Bir saklama takvimi tek bir soruyu cevaplar: her veri türünü ne kadar süre tutuyoruz? Genellikle kanunlar, sözleşmeler veya iş ihtiyaçları tarafından belirlenir. Spesifik olmalıdır (örneğin: destek ticket'ları 2 yıl, faturalar 7 yıl, uygulama günlükleri 30 gün).
Silme takvimi ise uygulama planıdır. Ne zaman silme gerçekleşir ve nasıl çalışır? Bazı ekipler gecelik toplu silme yapar, bazıları sürekli siler, birçok ekip de olay bazlı silme kullanır (örneğin “hesap kapandıktan 30 gün sonra”). Saklama takvimi kuraldır; silme takvimi kuralı uygulayan rutindir.
Yasal bekletme, bir dava, şikayet, soruşturma veya dava ile bağlantılı hedefe yönelik bir silme duraklamasıdır. Kapsamı (hangi kişiler, hesaplar, sistemler veya tarih aralığı) ve sahipliği (kimin onayladığı) içermelidir. Yasal bekletme “her yerde silmeyi durdur” anlamına gelmemelidir. Sadece etkilenen kayıtlarda silmeyi durdurur.
Denetim gereksinimleri, daha sonra neyi göstermeniz gerektiğidir: kim ne yaptı, ne zaman oldu ve neden izin verildi. Denetimler genellikle her kaydı sonsuza dek tutmaktan ziyade tutarlı bir sürecin kanıtını görmekle ilgilenir.
Dili basit tutun:
Bir saklama takvimi yasa kitabı gibi okunduğunda veya kimsenin neye karar verdiğini bilmediğinde başarısız olur. Her veri türü için neden saklandığını, ne kadar süreyle saklandığını, saatin ne zaman başladığını ve kuralın sahibinin kim olduğunu yazın.
Veriyi sistemde nerede durduğuna göre değil, iş amacıyla gruplandırın. “Faturalar” tablo X’teki satırlardan daha net bir kategoridir. Kategoriler sayısını meşgul bir kişinin hızlıca göz atabileceği kadar az tutun.
Sahipliği açıkça belirleyin. Finans, Destek’in neye ihtiyacı olduğunu tahmin etmemeli; Destek de İK kurallarını belirlememelidir. Her kategoriye bir sahibi atayın; değişiklikleri onaylayan ve soruları cevaplayan bir kişi olsun.
Tetikleyiciler zaman kadar önemlidir. “7 yıl” demek, saatin ne zaman başladığı tanımlanmadan bir anlam ifade etmez: hesap kapanışı, sözleşmenin bitişi, son giriş, son ödeme, son ticket güncellemesi. Mümkünse her kategori için bir tetik seçin.
Son olarak, istisnaları açıkça yazın. Bunlar silmenin durduğu nedenlerdir: ihtilaflar, chargeback’ler, dolandırıcılık incelemesi ve aktif yasal bekletmeler. İstisna belirsizse insanlar her şeyi istisna sayma eğiliminde olur.
Takımın gerçekten kullandığı basit bir tablo formatı şöyle olabilir:
| Veri kategorisi | İş amacı | Saklama süresi | Saat başlatıcı (tetik) | Sahip | İstisnalar (silmeyi duraklatır) |
|---|---|---|---|---|---|
| Müşteri faturaları | Vergi ve muhasebe | 7 yıl | Fatura ödendi/çıktı | Finans | Vergi denetimi bildirimi, ihtilaf |
| Destek ticket'ları | Müşteri hizmet geçmişi | 24 ay | Ticket kapandı | Destek | Açık ihtilaf, dolandırıcılık incelemesi |
| Kullanıcı hesap profili | Hizmeti sağlama | 30 gün | Hesap kapatma | Ürün | Aktif yasal bekletme, chargeback süresi |
| Erişim günlükleri | Güvenlik izleme | 90 gün | Günlük oluşturuldu | Güvenlik/BT | Olay soruşturması |
İyi bir veri saklama yasal bekletme iş akışının bir hedefi vardır: varsayılan olarak zamanında silmek, ancak yalnızca korunması gereken belirli kayıtları duraklatmak. En güvenilir yaklaşım, saklama, silme ve bekletmeleri tek bir denetim günlüğünü paylaşan ayrı olaylar olarak ele almaktır.
Bir saklama kuralı oluşturun veya güncelleyin (bir sahibiyle). Veri kümesini, nedeni (sözleşme, vergi, destek) ve saklama süresini tanımlayın. Kim onayladığını ve yürürlük tarihini kaydedin.
Tanımlı kapsamla silme işleri çalıştırın. Kuralları belirli alanları, tabloları, dosyaları ve arama dizinlerini silen veya anonimleştiren otomatik işlere dönüştürün. Organizasyonunuzda “silindi”nin ne anlama geldiğini açıkça belirtin (kalıcı silme, yumuşak silme veya geri alınamaz anonimleştirme) ve hangi sistemlerin dahil olduğunu belirtin.
Yasal bir bekletme yerleştirin (sadece ilgili olanı dondurun). Bir ihtilaf, soruşturma veya düzenleyici talep ortaya çıktığında, bir kişinin, hesabın, dava kimliğinin, tarih aralığının ve veri türlerinin hedeflendiği bir bekletme kaydı oluşturun. Silme işi sadece eşleşen kayıtları atlamalı, tüm veritabanını değil.
Bekletmeyi serbest bırakın (sonra silmeyi güvenle yeniden başlatın). Hukuk bekletmenin sona erdiğini onayladığında, bekletmeyi serbest olarak işaretleyin. Silme yeniden başlamadan önce kapsamın doğru olduğunu ve yeni bekletmelerin örtüşmediğini doğrulayın.
Her eylemi kaydedin. Saklama değişiklikleri, silme çalışmaları, yerleştirilen bekletmeler, serbest bırakılan bekletmeler ve manuel istisnalar. Her giriş zaman damgası, aktör, onaylayan, kapsam ve sonuç (başarılı veya başarısız) içermelidir.
Onaylar iş akışlarının genellikle bozulduğu yerdir. Rolleri net tutun:
Örnek: bir destek müdürü sohbet transkriptlerinin saklama süresini 24 aydan 12 aya düşürür, onay alır. Haftalık silme işi 12 aydan eski transkriptleri kaldırır. İki ay sonra Hukuk, bir müşterinin hesabı için ihtilaf nedeniyle bekletme koyar; böylece sadece o müşterinin transkriptleri donmuş olur; diğer herkes takvime göre devam eder.
Yasal bekletme yalnızca önemli olan kayıtlar için silmeyi durdurmalıdır ve sadece gerekli olan süre için. Bir bekletme “her yerde silmeyi durdur” haline gelirse, maliyet, risk ve karışıklık yaratırsınız.
Kapsamla başlayın. Bir bekletme belirli kullanıcılarla, siparişlerle, destek ticket'larıyla, projelerle, posta kutularıyla, klasörlerle veya "1 Mart ile 15 Nisan arasındaki mesajlar" gibi bir tarih aralığıyla sınırlanabilir. Ne kadar dar kapsam olursa hem savunması o kadar kolay hem de tutulan veri o kadar az olur.
Kazara silmeyi önlemek için bekletmeyi makine tarafından okunabilir hale getirin. Bu genellikle her kayıtta bir bekletme bayrağı ve bir bekletme kimliği anlamına gelir (veya kaydı yöneten vaka ya da sipariş nesnesinde). Silme işinizde tek katı kural şu olsun: HoldActive = true ise silmeyi atla ve bunun bekletme nedeniyle atlandığını kaydet.
Bekletme başladıktan sonra ortaya çıkan yeni veriler sıkça sorun olur. Bekletmenin:
olduğuna baştan karar verin.
İhtilaflarda, sürekli bekletmeler genellikle daha güvenlidir (örneğin “dava açıkken Müşteri X için tüm yeni ticket’lar”).
İki saat gibi düşünün. Saklama saati verinin ne zaman silinebilir hale geldiğini tanımlar. Bekletme saati ise şimdi silmeye izin verilip verilmediğini belirler. Saklama arka planda yaşlanmaya devam eder, ama bekletme son silme eylemini engeller. Bekletme bittiğinde, saklama süresini geçmiş olan her şey hemen silinebilir hale gelir.
Bekletmeyi dokümante ederken "neden"i açıklayacak kadar yazın ama fazla bilgi paylaşmayın. Kısa tutun: talep eden, tarih, kapsam ve "fatura ihtilafı" veya "işe itiraz" gibi basit bir neden.
Denetçiler genellikle silinmiş verinin kendisine ihtiyaç duymazlar. Sürecinizin kontrol edildiğini kanıtlayan belgelere ihtiyaçları vardır: kim neyi kararlaştırdı, ne silindi, ne zaman oldu ve neden izin verildi.
Silme olaylarını bir finansal işlem kaydı gibi günlüğe kaydedin. Kayıtlar aylar sonra bile, ekibinizde olmayan birinin bile anlayabileceği şekilde anlamlı olmalıdır.
Her silme (veya anonimleştirme) olayı için temel bilgileri yakalayın:
Ayrıca işin çalıştığına dair operasyonel kanıtları saklayın, içerik saklamadan:
“İleride işimize yarar” diye denetim veritabanına tam kayıtların kopyasını koymaktan kaçının. Bu, ayrıca silinmesi gereken ikinci bir sistem oluşturur.
Denetim günlükleri için de net bir saklama süresi ve erişim kuralları koyun. Birçok ekip ayrıntılı günlükleri 12–24 ay saklar, sonra gerekirse daha küçük aylık özetleri daha uzun tutar. Erişimi küçük bir grupla sınırlayın (güvenlik, uyumluluk ve sınırlı bir yönetici seti) ve günlüklere erişimi de kaydedin.
Denetimleri kolaylaştırmak için hızlıca üretebileceğiniz birkaç basit rapor hazırlayın: aylık silme özeti, istisna listesi (aktif bekletmeler, engellenen işler, çözülmemiş hatalar) ve en yaygın silme nedenlerinin dökümü.
Örnek: Temmuz ayında 1.240 kapatılmış hesap silindiyse, kanıt olarak kimin çalıştırdığını onayladığı, kullanılan saklama kuralı, adet, tamamlanma durumu ve aktif yasal bekletme nedeniyle engellenen 12 hesabın istisna listesi tek bir iş çalıştırma kaydı olabilir.
Çoğu saklama programı tek bir nedenle başarısız olur: bir şey riskli hissettirdiğinde insanlar silmeyi bırakır. Sonra “geçici” istisnalar birikir ve hiçbir şey ayrılmaz.
En büyük kör noktalarından biri yedekler, kopyalar ve arşivlenmiş depolamadır. Ekipler ana kaydı siler ama anlık görüntülerde veya okuma replikalarında kalan eski kopyaları unuturlar. Politikada “silme”nin ne anlama geldiğini netleştirin: genellikle üretim kopyası hızlıca kaldırılır ve yedekler ayrı, sabit bir zaman çizelgesinde yaşlanır.
Bir diğer yaygın hata, tüm sistemi “her ihtimale karşın” bekletmeye almak. Bu, alakasız verileri dondurur ve gelecekteki her silmeyi tehlikeli gösterir. Bekletmeler belirli kişilere, tarih aralıklarına, kayıt türlerine ve gerçekten ilgili verileri içeren sistemlere göre sınırlandırılmalıdır.
Sahiplik boşlukları da kalıcı bekletmelere yol açar. Bekletmeyi onaylayacak, belgeleyip serbest bırakacak sorumlu kimse yoksa, bekletme asla sona ermez. Bekletmeleri adlandırılmış rollere sahip kontrollü bir değişiklik gibi ele alın.
Dışa aktarımlar sessiz saklama katilleridir. Uygulamadaki veriyi silebilirsiniz ama bu veriler hâlâ hesap tablolarında, e-posta eklerinde, paylaşılan sürücülerde veya ad-hoc BI dışa aktarımlarında yaşayabilir.
“Her şeyi tutma” davranışını engelleyen birkaç pratik düzeltme:
Günlükleme bir denge işidir: çok az ise sürecin çalıştığını kanıtlayamazsınız; çok fazla ise günlükleriniz yeni bir gizlilik sorunu olur.
Bir silme takvimine gerçek hayatta güvenmeden önce “kanıtlayabiliyor muyuz” testini çalıştırın. İş akışı en zayıf devrinize kadar dayanır: eksik sahip, sessiz yedek veya yanlış şeyi silen iş.
Süreci kullanacak kişilerle (hukuk, güvenlik, BT ve verinin sahibi iş takımı) kısa bir masa başı egzersizi yapın.
Herhangi bir maddeye cevap vermek zorsa, düzenleyici, denetçi veya mahkeme tarafından sınanmadan önce iş akışını sıkılaştırın.
Gerçek bir veri nesnesi seçin (örneğin bir müşteri profili) ve baştan sona takip edin: nerede oluşturuldu, nereye kopyalandı ve nasıl kaldırıldı. Sonra bir vaka ID'sine bağlı yasal bekletme koyun, bir silme işi çalıştırın, bekletmeyi serbest bırakın ve silmeyi tekrar çalıştırın. Raporu kaydedin ve ekip dışından birinin okuyup anlayıp anlayamayacağını kontrol edin.
Bir müşteri 1 Mart'ta hesabını kapatır. Politikanız der ki: profil verilerini 30 gün sonra silin, destek konuşmalarını 90 gün sonra silin ve faturaları 7 yıl saklayın (vergi ve finansal kurallar genellikle bunu gerektirir).
20 Nisan'da aynı müşteri Şubat ayına ait bir fatura için bir fatura ihtilafı açar. İşte iş akışının hassas değil de kesin hissettirmesi gereken yer burasıdır.
Eş zamanlı iki şey yaparsınız. İhtilafa ilişkin olmayan her şey için normal silme devam eder. Aynı zamanda ne olduğunu kanıtlayan küçük bir kayıt setinde yasal bekletme koyarsınız.
İhtilafa konu olmayan ve takvime göre silinecek olanlar pazarlama tercihleri, fatura ile ilgili olmayan eski sohbetler, analiz pencerenizin ötesindeki ürün kullanım olayları ve faturalama kararının bir parçası olmayan dahili notlar olabilir.
Delil olarak tutulacak ve yasal bekletmeye alınacak olanlar:
Bekletme hedeflenmiş olmalıdır: sadece faturalar ve ilgili destek ticket'ları. Müşterinin tüm hesabı yalnızca gerekliyse dondurulmalıdır.
İhtilaf çözüldüğünde, bekletmeyi serbest bırakın, sonucu kaydedin (onaylandı, reddedildi, kısmi iade) ve bekletilen öğeler için duraklatılan silmeleri yeniden başlatın.
Bir denetçinin soruları genellikle temel olur: ne silindi, neden ve ihtilaf kayıtlarının silinmesini nasıl engellediniz. Saklama kurallarını, bekletme başlangıç ve bitiş tarihlerini, bekletilen kayıt ID listesini ve her şeyin zamanında silindiğini gösteren bir olay zincirini gösterebilmelisiniz.
Bir saklama politikası ancak rutine dönüştüğünde işe yarar. Küçük başlayın, kanıtlayın, sonra genişletin. Bir veri türü seçin (örneğin destek ticket'ları), bir sistem ve silinen, bekletilen ve nedenleri gösteren bir rapor belirleyin.
2–4 haftalık kısa bir pilot çalıştırın ve sürtünme noktalarını arayın: belirsiz sahipler, eksik onaylar ve çok geç gelen bekletme istekleri. Bunları ölçeklendirmeden önce düzeltin.
Baskı altında ayakta kalacak bir yayılma planı:
Bekletme prosedürünü insanların kullanacağı kadar kısa tutun. Kim bekletme isteyebilir, kim onaylar, nelerin dahil olması gerektiği (kapsam, gerekçe, başlangıç tarihi) ve bitince ne olacağına yanıt veriyorsa bir sayfa yeterlidir.
Bekletmelerin varsayılan olarak açık kalmasına izin vermeyin. Karar vermeyi zorunlu kılan hatırlatıcılar ekleyin: bekletmeyi gerekçeyle yenile, daralt veya kapat.
Onayları, denetim günlüklerini ve silme çalışmalarını e-postalar ve tablolarla yönetiyorsanız, süreci tutarlı kılmak için dahili bir uygulamaya koymayı düşünün. Ekipler bazen bu tür saklama ve bekletme takipçisini AppMaster (appmaster.io) üzerinde kurar, böylece kurallar, bekletmeler ve denetim günlükleri tek bir yerde yaşar ve silme işleri bekletilen kayıtları atlayarak geri kalan her şeyi temizleyebilir.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
