Saklama ve İmha Politikası — Periyodik İmha ve Süre Yönetimi (KVKK)

Denetimde en sık duyulan cevaplardan biri şudur: “Saklama süremiz yasal zorunluluk kadardır.” Sorulduğunda hangi yasa, hangi madde, hangi veri kategorisi ve hangi sistem için geçerli olduğu netleşmiyorsa, politika kağıt üzerinde kalmış demektir. KVKK kapsamında kişisel veriyi süresiz tutmak yalnızca “gereksiz depolama” değildir; m.4/2-d ilkesine aykırılık, m.12 güvenlik riski artışı ve ilgili kişi başvurularında cevaplanması gereken veri hacminin büyümesi anlamına gelir.

Saklama ve imha politikası, veri minimizasyonunun operasyonel yüzüdür: hangi verinin ne kadar süre tutulacağı, süre dolduğunda ne yapılacağı ve bunun nasıl kanıtlanacağı yazılı ve uygulanabilir olmalıdır. Bu rehber, periyodik imha takvimi, imha tutanağı ve silme ile anonimleştirme ayrımını pratik adımlarla açıklar.

KVKK’da saklama süresi: m.4/2-d ve m.5 bağlantısı

6698 sayılı Kanun’un 4. maddesinde veri sorumlularına yüklenen genel yükümlülükler arasında (d) bent şöyle düzenlenir: kişisel veriler, ilgili mevzuatta öngörülen veya işlendikleri amaç için gerekli olan süre kadar muhafaza edilir. Bu ilke, 5. maddenin işleme şartlarıyla birlikte okunmalıdır:

• Amaçla sınırlılık (m.4/2-c): Veri, toplandığı amacın ötesinde tutulmamalıdır.
• Ölçülülük (m.4/2-ç): Amaç için gerekenden fazla veri saklanmamalıdır.
• Doğruluk ve güncellik (m.4/2-b): Süresi dolmuş, güncelliğini yitirmiş veri aktif sistemlerde durmamalıdır.

Kişisel Verileri Koruma Kurulu rehberlerinde de vurgulandığı üzere saklama süresi belirlenirken üç kaynak birlikte değerlendirilir:

1. Özel mevzuat — Vergi Usul Kanunu, İş Kanunu, TTK, SGK mevzuatı gibi kanuni saklama yükümlülükleri
2. İşleme amacı — Sözleşmenin ifası, dava zamanaşımı, meşru menfaat süresi
3. İlgili kişi beklentisi — Aydınlatmada taahhüt edilen süre (m.10)

“Yasal zorunluluk kadar” ifadesi tek başına yeterli değildir; hangi kanunun hangi maddesinin hangi veri seti için geçerli olduğu envanter ve politika kaydında açıkça yazılmalıdır.

Saklama süresi tablosu (retention schedule) nasıl kurulur?

Saklama süresi tablosu, her işleme faaliyeti veya veri kategorisi için süreyi, dayanağını ve imha yöntemini tek satırda gösteren operasyonel belgedir. Envanter kaydıyla birebir eşleşmelidir; aksi halde aydınlatma metni ile fiili uygulama arasında tutarsızlık oluşur.

Tablo oluştururken dikkat edilmesi gerekenler:

• Faaliyet bazlı ayrıştırma: “Müşteri verileri — 10 yıl” gibi geniş satırlar denetimde yetersiz kalır.
• Sistem eşlemesi: Her satırda verinin tutulduğu sistem (CRM, ERP, dosya sunucusu, yedek) belirtilmelidir.
• Yedek ve arşiv: Birincil sistemden silinen verinin yedekte veya soğuk arşivde kalması periyodik imhayı etkisiz kılar; yedek politikası tabloya dahil edilmelidir.
• Veri işleyenler: Tedarikçide tutulan kopyalar için sözleşmede imha yükümlülüğü ve süresi tanımlanmalıdır.

Saklama süresi tablosunun kaynağı veri işleme envanteri olmalıdır; envanterde “saklama süresi” sütunu boş bırakılan faaliyetler politika kapsamı dışında sayılır ve bu başlı başına uyum açığıdır.

Periyodik imha: ne zaman, kim, nasıl?

Periyodik imha, saklama süresi dolan kişisel verilerin belirli aralıklarla sistematik olarak silinmesi, yok edilmesi veya anonimleştirilmesi sürecidir. KVKK’da “periyodik imha” ifadesi tek bir madde numarasıyla tanımlanmamış olsa da m.4/2-d ve m.12 (veri güvenliği) birlikte değerlendirildiğinde periyodik imha fiilen zorunlu bir operasyonel yükümlülüktür.

Periyodik imha takvimi örneği

Periyodik imha sürecinin adımları:

1. Tespit: Saklama süresi dolmuş kayıtların listesi çıkarılır (manuel rapor veya otomatik sorgu).
2. Doğrulama: Hukuk veya uyum ekibi, listedeki kayıtların gerçekten imha edilebilir olduğunu onaylar (devam eden dava, aktif sözleşme istisnası).
3. Uygulama: Silme, yok etme veya anonimleştirme işlemi gerçekleştirilir.
4. Kanıt: İmha tutanağı düzenlenir ve arşivlenir.
5. Yedek kontrolü: Yedekleme sistemlerinde aynı verinin kaldığı doğrulanır; gerekirse yedek rotasyonu planlanır.

Manuel Excel takibi küçük hacimlerde işe yarar; ancak on binlerce müşteri kaydı, çoklu veritabanı ve bulut depolama ortamında süresi dolmuş veriyi bulmak operasyonel olarak zorlaşır. Bu noktada kişisel veri keşfi ve PII tarama süreçleri, hangi sistemde hangi kişisel verinin ne kadar süredir durduğunu tespit etmek için kritik rol oynar.

İmha tutanağı: denetimde istenen kanıt

İmha tutanağı, kişisel verilerin silindiğini, yok edildiğini veya anonimleştirildiğini yazılı olarak belgeleyen kayıttır. Kurul denetimlerinde ve iç denetimlerde “süresi dolan veriyi gerçekten imha ettiniz mi?” sorusunun cevabı bu belgeyle verilir.

Asgari içerik:

Tutanak dijital imzalı PDF veya uyum sistemindeki değiştirilemez kayıt olarak saklanmalıdır. “E-posta ile bilgi verildi” veya “IT sildi” ifadesi, tutanaksız iddialar denetimde yetersiz kabul edilir.

Silme, yok etme ve anonimleştirme: hangisi ne zaman?

KVKK ve Kurul rehberlerinde kişisel verinin artık kimliği belirli veya belirlenebilir bir gerçek kişiyle ilişkilendirilemeyecek hale getirilmesi hedeflenir. Üç yöntem farklı teknik ve hukuki sonuçlar doğurur:

Silme ile anonimleştirme karar ağacı:

• Amaç tamamen sona erdi ve veriye hiçbir operasyonel ihtiyaç yok → silme
• Yasal saklama bitti, ancak toplu istatistik için sayısal veri gerekli → anonimleştirme (geri dönüşü olmayan teknik yöntemlerle)
• Fiziksel arşiv veya çıkarılmış medya → yok etme
• İlgili kişi silme talebinde bulundu (m.11) → öncelikle silme; istisnai durumlar hukuk analiziyle

Kısmi anonimleştirme (örneğin yalnızca ad-soyadın maskelenmesi, TCKN’nin kalması) çoğu senaryoda yeterli değildir; veri hâlâ kişisel veri sayılabilir. Anonimleştirme teknikleri (k-anonymity, veri perturbasyonu, hash + salt yok etme) IT ve uyum ekipleri tarafından birlikte seçilmelidir.

Saklama politikasının DSAR ve ihlal süreçleriyle ilişkisi

Süresi dolmamış gereksiz veri birikimi, ilgili kişi başvurusu 30 gün KVKK sürecini doğrudan zorlaştırır. Başvuru geldiğinde “veriniz nerede?” sorusuna cevap vermek için taranması gereken sistem sayısı arttıkça hem süre hem de hata riski büyür. Periyodik imha, DSAR envanterini sadeleştirir.

Benzer şekilde veri ihlali bildiriminde (m.12) ihlal kapsamındaki kayıt sayısı ve veri kategorisi değerlendirilir. On yıl önce silinmesi gereken müşteri listesinin hâlâ açık bir dosya sunucusunda durması, ihlalin kapsamını ve idari para cezası riskini artırır.

Sık yapılan hatalar

1. Tek politika, sıfır uygulama: PDF yazılıp IT’ye iletilmemesi.
2. Süresiz “meşru menfaat”: Aday CV’leri ve eski lead listelerinin yıllarca tutulması.
3. Yedekleri unutmak: Birincil DB temiz, yedekte eski veri.
4. Anonimleştirmeyi maskeleme sanmak: Kısmi gizleme ile anonimleştirmeyi karıştırmak.
5. Tedarikçi kopyaları: SaaS iptal edildi ama veri export’u arşivde duruyor.
6. Tutanaksız imha: Periyodik silme yapılıyor ama kanıt yok.

Lexidata ile saklama süresi ve periyodik imha takibi

Lexidata uyum paneli, saklama süresi tablosunu envanter kayıtlarıyla entegre tutar; hangi faaliyetin hangi süre ve imha yöntemiyle yönetildiğini tek ekranda izlemenizi sağlar. Periyodik imha takvimine yaklaşan kayıtlar için hatırlatma, imha tutanağı şablonu ve sürüm geçmişi operasyonel disiplini destekler.

LexiAgent (Data Discovery) ile SQL veritabanlarında PII metadata taraması yaparak süresi dolmuş veya envanterde tanımlanmamış kişisel veri alanlarını tespit edebilir; veri içeriği Lexidata’ya gitmez, yalnızca keşif metadata’sı aktarılır. Saklama politikasını kağıttan operasyona taşımak için platform.lexidata.io adresinden uyum panelini ve LexiAgent entegrasyonunu inceleyebilirsiniz.