- 01KVKK tüm kişisel veriler için tek bir saklama süresi belirlemez; süre işleme amacı, hukuki sebep ve ilgili mevzuata göre veri kategorisi bazında tanımlanmalıdır.
- 02Altı ay kişisel veri veya backup saklama üst sınırı değil, saklama ve imha politikası bulunan veri sorumlularında periyodik imha işlemleri arasındaki azami süredir.
- 03Saklama ve imha politikası hazırlama yükümlülüğü olmayan veri sorumlusu, imha yükümlülüğünün doğduğu tarihi takip eden üç ay içinde işlemi tamamlamalıdır.
- 04Eski backup geri yüklendiğinde daha önce silinmiş kişisel veri yeniden production ortamına dönebilir; restore runbook'unda yeniden silme/reconciliation adımı bulunmalıdır.
- 05Kişisel verilerin silinmesi, yok edilmesi veya anonim hale getirilmesi işlemlerine ilişkin kayıtlar diğer yükümlülükler hariç en az üç yıl saklanmalıdır.
Kısaca
KVKK kapsamında kişisel veriler için tek bir genel saklama süresi yoktur. Süre; işleme amacı, ilgili mevzuat ve veri kategorisine göre belirlenir. Yedekler de bu politikanın dışında değildir. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak yedekleme politikasını yalnızca retention günüyle değil; silme, yok etme, geri yükleme ve yeniden imha süreçleriyle birlikte tasarlar.
Kişisel veri saklama süresi nasıl belirlenir
KVKK tüm kişisel veriler için "3 yıl", "5 yıl" veya "10 yıl" gibi tek bir saklama süresi belirlemez.
Her veri kategorisi için şu üç soruya cevap verin:
- Bu veriyi hangi amaçla işliyoruz?
- Bu amaç için hangi hukuki sebebe dayanıyoruz?
- İlgili mevzuat bu veri için belirli bir saklama süresi öngörüyor mu?
Bu üç sorudan sonra veri kategorisi için azami saklama süresi belirlenir.
Örnek kategoriler:
- Müşteri sözleşme kayıtları
- Fatura ve muhasebe kayıtları
- Çalışan özlük verileri
- Destek kayıtları
- Kamera kayıtları
- Sistem logları
- Kullanıcı hesapları
- Yedek kopyalar
Aynı şirket içinde bu kategorilerin saklama süreleri farklı olabilir.
Altı ay kuralı saklama süresi değildir
KVKK uygulamasında en sık karıştırılan konu budur.
6 ay, kişisel veri saklama ve imha politikası hazırlayan veri sorumlularında periyodik imha işlemleri arasındaki azami süredir.
Bu kural:
- "Her kişisel veri en fazla 6 ay tutulabilir"
- "Yedekler 6 aydan uzun tutulamaz"
- "Tüm veriler 6 ay sonra silinmelidir"
anlamına gelmez.
Örneğin hukuki yükümlülük nedeniyle bir veri kategorisini 5 yıl saklamanız gerekiyorsa, bu veri 5 yıl boyunca saklanabilir. Ancak saklama süresi sona erdiğinde veri, ilk periyodik imha döngüsünde silinmeli, yok edilmeli veya anonim hale getirilmelidir.
Politika hazırlama yükümlülüğü olmayan veri sorumlularında üç aylık süre
Kişisel veri saklama ve imha politikası hazırlama yükümlülüğü olmayan veri sorumluları için farklı bir süre vardır.
Silme, yok etme veya anonim hale getirme yükümlülüğünün doğduğu tarihi takip eden 3 ay içinde imha işlemi gerçekleştirilmelidir.
Bu nedenle ilk kontrolünüz şu olmalıdır:
- Kuruluşunuzun saklama ve imha politikası hazırlama yükümlülüğü var mı?
- Politika varsa periyodik imha aralığınız kaç ay?
- Politika yoksa üç aylık operasyon süreci nasıl işletiliyor?
Bu ayrım yazılı süreçte net olmalıdır.
Yedeklerdeki kişisel veri de saklama politikasına dahildir
Kişisel verinin production database'den silinmesi, tüm kopyalarının otomatik olarak silindiği anlamına gelmez.
Aynı veri şuralarda kalabilir:
- VM snapshot
- Database backup
- Object storage backup
- Offsite backup
- Immutable copy
- Disaster recovery replica
- Test restore ortamı
- Arşiv
- Log sistemi
Bu nedenle veri silme süreci yalnızca ana uygulamayı değil, kopya zincirini de kapsamalıdır.
Yedekten tek kaydı hemen silmek her zaman teknik olarak mümkün değildir
Birçok backup formatı tek bir kişisel veri kaydını yerinde silmeye uygun değildir.
Örneğin:
- Full VM image
- Immutable object
- Database full backup
- Tape archive
- WORM storage
gibi yapılarda tek bir müşteri kaydını yedek dosyasının içinden anında çıkarmak teknik veya operasyonel olarak mümkün olmayabilir.
Bu durumda süreç şu şekilde tasarlanabilir:
- Production sistemde veri silinir veya anonim hale getirilir
- Yedek üzerindeki erişim sınırlandırılır
- Backup retention süresi belgelenir
- Yedek saklama süresi sonunda kopya yok edilir
- Eski yedek geri yüklenirse daha önce silinen veri yeniden silinir
Bu yaklaşım "yedekte veri sonsuza kadar kalabilir" anlamına gelmez. Yedek retention politikası da veri saklama amacı ve riskle uyumlu olmalıdır.
Eski yedek geri yüklendiğinde silinmiş veri yeniden gelebilir
En kritik operasyon riski budur.
Örnek:
- Bir müşterinin verisi 1 Haziran'da silindi
- 15 Mayıs tarihli backup hâlâ retention içinde
- Felaket sonrası 15 Mayıs backup'ı geri yüklendi
Müşterinin daha önce silinmiş verisi tekrar production ortamına dönebilir.
Bu nedenle restore runbook'unda post-restore deletion reconciliation adımı bulunmalıdır.
Basit model:
- Restore tamamlanır
- "Silinmiş veri listesi" veya tombstone kayıtları alınır
- Restore edilen ortam bu listeyle karşılaştırılır
- Daha önce silinmiş kayıtlar tekrar silinir
- İşlem loglanır
Dynamis'te restore planında bu adımı ayrı kontrol olarak tutuyoruz.
Saklama süresi ile backup retention aynı şey değildir
Bu iki kavram birbirine bağlıdır ama aynı değildir.
Kişisel veri saklama süresi: Verinin hukuken ve operasyonel olarak ne kadar süre işlenebileceğini belirler.
Backup retention: Yedek kopyanın ne kadar süre tutulacağını belirler.
Örnek:
- Müşteri verisi saklama süresi: 5 yıl
- Günlük backup retention: 30 gün
- Aylık arşiv backup retention: 12 ay
Burada yedekler 5 yıl tutulmak zorunda değildir. Ama 5 yıllık veri saklama yükümlülüğünü karşılayan production veya arşiv yapısı bulunmalıdır.
Tersi de risklidir:
- Veri kategorisinin saklama süresi 2 yıl
- Backup retention 7 yıl
Bu yapı kişisel verinin gereğinden uzun tutulmasına neden olabilir.
Saklama matrisi oluşturun
Tek bir "backup retention = 90 gün" politikası tüm sistemler için yeterli değildir.
Örnek matris:
| Veri kategorisi | İşleme amacı | Azami saklama | Backup retention | İmha yöntemi |
|---|---|---|---|---|
| Müşteri hesabı | Hizmet sunumu | Sözleşme + hukuki süre | 30-90 gün | Silme + backup expiry |
| Muhasebe kaydı | Yasal yükümlülük | İlgili mevzuata göre | Politika ile uyumlu | Süre sonunda imha |
| Destek kaydı | Hizmet ve uyuşmazlık | Politika ile belirlenir | 30 gün | Silme |
| Kamera | Güvenlik | Risk ve amaçla sınırlı | Kısa süre | Otomatik overwrite |
| Uygulama logu | Güvenlik/operasyon | Amaçla sınırlı | Ayrı log retention | Otomatik silme |
Gerçek süreler hukuk ve uyum ekibiniz tarafından veri kategorisi ve mevzuata göre belirlenmelidir.
Silme, yok etme ve anonim hale getirme aynı işlem değildir
KVKK uygulamasında üç farklı imha yöntemi vardır.
Silme
Kişisel veri ilgili kullanıcılar için hiçbir şekilde erişilemez ve tekrar kullanılamaz hale getirilir.
Yok etme
Veri hiç kimse tarafından hiçbir şekilde erişilemez, geri getirilemez ve tekrar kullanılamaz hale getirilir.
Anonim hale getirme
Veri, başka verilerle eşleştirilse dahi belirli veya belirlenebilir gerçek kişiyle ilişkilendirilemeyecek hale getirilir.
Teknik yöntem veri türüne ve depolama yapısına göre değişir.
Örneğin:
- Database satırı silme
- Storage encryption key destruction
- Secure erase
- Backup expiry
- Media destruction
- Anonimleştirme
farklı durumlarda kullanılabilir.
Immutable backup KVKK imha planından muaf değildir
Immutable backup fidye yazılımına karşı güçlü bir kontroldür. Ancak "değiştirilemez" olması saklama süresinin sınırsız olabileceği anlamına gelmez.
Immutable retention süresi belirlenirken:
- Ransomware recovery ihtiyacı
- Veri saklama süresi
- Hukuki yükümlülük
- Depolama maliyeti
- Silme/imha operasyonu
birlikte değerlendirilmelidir.
Örneğin 30 günlük immutable retention güvenlik için yeterliyse, 3 yıllık immutable retention gereksiz kişisel veri saklama riski yaratabilir.
İmha işlemlerinin kayıtlarını en az üç yıl saklayın
Kişisel verilerin silinmesi, yok edilmesi veya anonim hale getirilmesi işlemlerine ilişkin kayıtlar, diğer hukuki yükümlülükler hariç olmak üzere en az 3 yıl saklanmalıdır.
Bu kayıtlar şunları içerebilir:
- Veri kategorisi
- İmha tarihi
- İmha yöntemi
- İşlemi yapan sistem veya kişi
- Talep numarası
- Onay kaydı
- Backup expiry tarihi
- Restore sonrası yeniden silme kaydı
Bu evidence, iç denetim ve süreç doğrulaması için önemlidir.
İlgili kişinin silme talebini backup operasyonuna bağlayın
Bir ilgili kişi verisinin silinmesini istediğinde süreç yalnızca CRM veya uygulama kaydını silmekle tamamlanmamalıdır.
Operasyon akışı:
- Talebin hukuki olarak değerlendirilmesi
- Production verisinin silinmesi/yok edilmesi/anonimleştirilmesi
- Downstream sistemlerin güncellenmesi
- Backup retention etkisinin kaydedilmesi
- Restore halinde uygulanacak yeniden silme kaydının oluşturulması
- İşlemin evidence kaydının saklanması
Bu süreç ticket veya privacy request workflow içinde izlenebilir hale getirilmelidir.
Restore testinde kişisel veri yeniden oluşumunu kontrol edin
Yedek geri yükleme aylık test planında yalnızca RPO/RTO değil, kişisel veri lifecycle'ı da test edilmelidir.
Restore sonrası şu soruları sorun:
- Daha önce silinmiş kullanıcı geri geldi mi?
- Süresi dolmuş kayıt geri geldi mi?
- Test ortamına gereğinden fazla kişisel veri taşındı mı?
- Test verisi işlem sonunda temizlendi mi?
- Eski yetkiler yeniden aktif oldu mu?
Bu kontroller backup ve privacy operasyonunu birbirine bağlar.
Yurt dışı backup ayrıca değerlendirilmelidir
Backup başka ülkedeki bölge veya storage servisine kopyalanıyorsa bu durum yurt dışı veri aktarımı kapsamında değerlendirilmelidir.
Ana sistem Türkiye'de olsa bile:
- Offsite backup
- DR region
- Object storage
- SaaS backup platformu
yurt dışında olabilir.
Yurt dışı aktarım çerçevesini KVKK uyumlu bulut altyapısı rehberinde detaylandırıyoruz.
Dynamis'te yedek saklama ve imha modeli
Dynamis'in kurumsal altyapı hizmetinde backup retention'ı yalnızca teknik kapasiteye göre belirlemiyoruz.
Çalışma modeli:
- Veri kategorisi envanteri
- Saklama süresi matrisi
- Backup retention matrisi
- Immutable/offline retention
- Silme ve imha prosedürü
- Restore sonrası yeniden silme adımı
- Evidence kaydı
- Periyodik restore testi
Hukuki saklama süresini müşterinin hukuk/uyum ekibi belirler; Dynamis bu gereksinimi teknik backup ve imha akışına dönüştürür.
Sık yapılan hatalar
6 ayı backup saklama süresi sanmak: Altı ay periyodik imha aralığının üst sınırıdır.
Production verisini silip backup'ı unutmak: Restore sırasında veri yeniden aktif olabilir.
Backup retention'ı veri kategorisinden bağımsız belirlemek: Bazı kopyalar gereğinden uzun tutulabilir.
Immutable backup'ı sınırsız saklamak: Güvenlik kontrolü veri minimizasyonu yükümlülüğünü ortadan kaldırmaz.
İmha kayıtlarını tutmamak: Silme/yok etme işlemlerine ilişkin evidence en az üç yıl saklanmalıdır.
Restore sonrası yeniden silme prosedürü olmaması: Eski backup'tan daha önce silinmiş veri geri gelebilir.
Sırada ne var
-
Private Cloud hizmeti: veri konumu, erişim, saklama ve uyum gereksinimlerini altyapı modeliyle birlikte değerlendirin.
-
Veri yerelleştirme nedir? KVKK'da yurt dışı aktarım: yedeklerin hangi ülkeye aktarıldığını ve standart sözleşme gereksinimini veri akışı üzerinden değerlendirin.
-
KVKK uyumlu bulut altyapısı: erişim, yurt dışı aktarım ve teknik tedbirleri planlayın.
-
3-2-1 yedekleme kuralı: bağımsız ve immutable backup mimarisini kurun.
-
Yedek geri yükleme testi: restore sonrası kişisel veri lifecycle'ını doğrulayın.
-
Kurumsal altyapı hizmeti: retention, restore ve imha operasyonunu birlikte yönetin.
Kaynaklar
Kaynaklar
- 1.Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında YönetmelikKişisel Verileri Koruma Kurumu · 2026-09-19
- 2.KVKK Kişisel Veri Saklama ve İmha PolitikasıKişisel Verileri Koruma Kurumu · 2026-09-19
- 3.Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi RehberiKişisel Verileri Koruma Kurumu · 2026-09-19
Sık sorulan sorular
KVKK'da kişisel veri saklama süresi kaç yıldır?
KVKK tüm kişisel veriler için tek bir yıl sayısı belirlemez. Azami saklama süresi, verinin işlenme amacı ve ilgili mevzuattaki hukuki yükümlülüklere göre veri kategorisi bazında belirlenmelidir.
KVKK'da 6 ay kuralı nedir?
Altı ay, kişisel veri saklama ve imha politikası hazırlamış veri sorumlularında periyodik imha işlemleri arasındaki azami süredir. Bu süre, tüm kişisel verilerin veya yedeklerin altı ay tutulabileceği anlamına gelmez.
Yedeklerdeki kişisel veri saklama süresi dolunca ne olur?
İşleme şartları ortadan kalktığında yedekteki kişisel veri de imha planına dahil edilmelidir. Teknik yapı tek kaydı anında silemiyorsa erişim sınırlandırılmalı, yedek retention süresi sonunda kopya imha edilmeli ve eski yedek geri yüklendiğinde daha önce silinmiş kayıtların yeniden aktif olmaması sağlanmalıdır.
Kişisel veri silme ve imha kayıtları ne kadar saklanmalı?
Kişisel verilerin silinmesi, yok edilmesi veya anonim hale getirilmesi işlemlerine ilişkin kayıtlar, diğer hukuki yükümlülükler hariç olmak üzere en az üç yıl saklanmalıdır.
Saklama ve imha politikası olmayan veri sorumlusu veriyi ne zaman imha etmeli?
Kişisel veri saklama ve imha politikası hazırlama yükümlülüğü olmayan veri sorumlusu, silme, yok etme veya anonim hale getirme yükümlülüğünün doğduğu tarihi takip eden üç ay içinde işlemi gerçekleştirmelidir.