KVKK açısından hosting yedekleri ne kadar süre saklanmalı?

Web sitenizin yedeklerini düzenli almak iş sürekliliği açısından kritik bir güvenlik önlemidir; ancak yedeklerin içinde kişisel veri bulunuyorsa, bu kayıtların ne kadar süre tutulacağı KVKK bakımından ayrıca değerlendirilmelidir. Buradaki temel soru yalnızca “yedek alıyor muyuz?” değil, “yedekleri hangi amaçla, hangi süreyle ve hangi erişim kurallarıyla saklıyoruz?” olmalıdır.

KVKK’da yedek saklama süresi için temel yaklaşım

KVKK, kişisel verilerin işlendikleri amaç için gerekli olan süre kadar muhafaza edilmesini öngörür. Bu nedenle tüm kurumlar için geçerli, tek ve değişmez bir “yedek saklama süresi” yoktur. Süre; veri türüne, işleme amacına, kanuni yükümlülüklere, sektör risklerine ve operasyonel ihtiyaçlara göre belirlenmelidir.

Hosting yedekleri genellikle veritabanı, e-posta kayıtları, dosyalar, form gönderimleri, müşteri hesapları, sipariş bilgileri veya log kayıtları içerebilir. Bu nedenle yedekleme politikası hazırlanırken yedeğin teknik bir kopya olduğu düşünülüp kişisel veri içermediği varsayılmamalıdır.

Uygulamada makul yedek saklama süresi nasıl belirlenir?

Kurumsal pratikte web sitesi ve uygulama yedekleri için sık görülen yaklaşım, kısa dönem operasyonel geri dönüş ihtiyacına göre 7, 14, 30 veya 90 günlük saklama periyotları belirlemektir. Ancak bu süreler otomatik olarak KVKK’ya uygun kabul edilmez; her biri gerekçelendirilmelidir.

Örneğin içerik sitesi için 14 veya 30 günlük yedekleme süresi yeterli olabilirken, e-ticaret sisteminde sipariş, iade, fatura ve müşteri destek süreçleri nedeniyle daha farklı veri setleri ve saklama gerekçeleri gündeme gelebilir. Burada önemli olan, yedeklerin sınırsız veya belirsiz süreyle tutulmamasıdır.

Süre belirlerken sorulması gereken pratik sorular

• Yedekten geri dönüş ihtiyacı en fazla kaç gün geriye dönük ortaya çıkıyor?
• Yedeklerde özel nitelikli kişisel veri veya hassas müşteri bilgisi var mı?
• Kanuni saklama yükümlülüğü yedeğin tamamı için mi, yoksa belirli kayıtlar için mi geçerli?
• Eski yedekler otomatik olarak siliniyor mu, yoksa manuel müdahaleye mi bağlı?
• Yedeklere kimler erişebiliyor ve erişimler kayıt altına alınıyor mu?

Yedekler ile arşiv kayıtları karıştırılmamalı

En sık yapılan hatalardan biri, yedekleri arşiv veya yasal kayıt saklama alanı gibi kullanmaktır. Yedek, sistemin arıza, silinme, saldırı veya hatalı işlem sonrası geri yüklenmesi için tutulur. Arşiv ise belirli hukuki veya ticari kayıtların düzenli, erişilebilir ve sınıflandırılmış biçimde saklanmasıdır.

Bu ayrım yapılmazsa, tüm sistem kopyaları yıllarca tutulabilir ve bu durum veri minimizasyonu ilkesine aykırı risk oluşturabilir. Kanunen saklanması gereken kayıtlar varsa, bunlar mümkünse ayrı bir arşivleme yapısında, erişim yetkileri sınırlandırılarak ve saklama-imha politikasına uygun şekilde yönetilmelidir.

Sunucu yedeklerinde silme ve imha süreci

KVKK açısından yalnızca saklama süresi belirlemek yeterli değildir; süre dolduğunda yedeklerin nasıl silineceği de planlanmalıdır. Otomatik rotasyon, şifreli yedekleme, erişim kayıtları ve güvenli imha mekanizmaları bu sürecin parçasıdır. Özellikle bulut ortamlarında, farklı lokasyonlarda çoğaltılan yedeklerin ne zaman ve nasıl temizlendiği hizmet sağlayıcı sözleşmelerinde açıkça yer almalıdır.

Bir diğer kritik konu, silme talebi gelen kişisel verilerin yedeklerdeki durumudur. Aktif sistemden silinen bir veri, geçmiş yedeklerde teknik olarak bir süre daha bulunabilir. Bu durumda kurum, yedeklerin geri yüklenmesi halinde ilgili verinin yeniden aktif hale gelmesini önleyecek prosedür oluşturmalıdır.

Veri sorumlusu ve hizmet sağlayıcı rolleri

Web sitesini yöneten şirket çoğu durumda veri sorumlusu konumundadır. Hizmet alınan altyapı firması ise sunduğu modele göre veri işleyen rolünde olabilir. Bu nedenle hosting hizmeti alınırken yedekleme sıklığı, saklama süresi, veri merkezi konumu, erişim yetkileri, şifreleme ve imha süreçleri yazılı olarak netleştirilmelidir.

Sözleşmede “günlük yedek alınır” ifadesi tek başına yeterli değildir. Yedeğin kaç gün saklandığı, müşteri talebiyle silinip silinemediği, hizmet sona erdiğinde ne kadar sürede imha edildiği ve olağanüstü durumlarda geri yükleme prosedürünün nasıl işleyeceği açık olmalıdır.

Kurumsal yedekleme politikası için önerilen yapı

KVKK uyumu için yedekleme politikası kısa, uygulanabilir ve denetlenebilir olmalıdır. Politika içinde veri kategorileri, yedekleme periyotları, saklama süreleri, yetkili kişiler, şifreleme yöntemi, test geri yükleme sıklığı ve imha adımları tanımlanmalıdır. Ayrıca bu politikanın çalışanlar ve teknik ekip tarafından anlaşılabilir olması gerekir.

Pratik bir yaklaşım olarak kritik sistemler için günlük yedek, 7 ila 30 gün arası operasyonel saklama, daha uzun süre gerektiren kayıtlar için ayrı arşivleme modeli değerlendirilebilir. Daha uzun süreli tutma ihtiyacı varsa, bunun hukuki dayanağı ve teknik gerekçesi yazılı hale getirilmelidir.

Yanlış karar riskini azaltan kontrol listesi

• Saklama süresi “alışkanlık” yerine belgelenmiş ihtiyaçla belirlenmeli.
• Yedeklerdeki kişisel veri kapsamı düzenli olarak gözden geçirilmeli.
• Eski yedeklerin otomatik silindiği periyodik olarak test edilmeli.
• Geri yükleme testlerinde gereksiz kişisel verinin tekrar yayına alınması engellenmeli.
• Hizmet sağlayıcı değişiminde eski yedeklerin imhası yazılı teyit edilmeli.

Doğru süre, her kurumun veri işleme envanteri ve teknik ihtiyacına göre değişir. Bu nedenle KVKK açısından güvenli yaklaşım; yedekleri mümkün olan en kısa makul süreyle tutmak, daha uzun saklama gerektiren verileri ayrı yönetmek ve tüm süreci yazılı politika, sözleşme ve teknik kontrollerle desteklemektir.