Kayıt Listesi ve Saklama Süreleri: BGYS Kayıtları Nasıl Yönetilir?

Denetçi “bu kontrolü uyguluyor musunuz?” diye sorduğunda prosedürü değil, kaydı ister. Prosedür ne yapılacağını söyler; kayıt yapıldığını kanıtlar. Bir BGYS’nin çalıştığını gösteren şey budur. Kayıtların nerede tutulduğu, ne kadar saklandığı ve süresi dolunca nasıl imha edildiği tanımlı değilse iki sorun birden çıkar: denetimde kanıt bulunamaz, gereğinden uzun saklanan kişisel veriler ise ayrı bir uyum riskine dönüşür. Aşağıda kayıt listesinin alanlarını, saklama süresinin nasıl belirleneceğini ve imha kaydının nasıl tutulacağını anlatıyoruz.

Doküman ile kayıt farkı

ISO/IEC 27001:2022 ikisini de “dokümante bilgi” başlığı altında toplar. Yönetim biçimleri ise farklıdır.

Özellik	Doküman	Kayıt
Amaç	Ne yapılacağını tanımlar	Ne yapıldığını gösterir
Değişiklik	Revize edilir, sürümlenir	Oluştuktan sonra değiştirilmez
Kontrol odağı	Onay, sürüm, dağıtım	Bütünlük, erişim, saklama, imha
Örnek	Yedekleme prosedürü	Geri yükleme test formu, yedekleme iş raporu

Kayıt değiştirilmez. Yanlış girilmiş bir kayıt düzeltilecekse düzeltme ayrı bir giriş olarak yapılır ve kimin, ne zaman yaptığı görünür kalır. Sahada en sık gördüğümüz hata, paylaşılan bir Excel tablosunda geçmiş satırların sessizce üzerine yazılmasıdır; bu durumda tablonun kanıt değeri kalmaz. Dokümanların sürüm ve onay yönetimi doküman kontrolü rehberinde anlatılıyor; burada yalnız kayıtlara odaklanıyoruz.

Kayıt listesinin alanları

Kayıt listesi, kuruluşun hangi kayıtları ürettiğini ve her biri için yaşam döngüsü kararlarını tek tabloda toplar. Standart bu listeyi adıyla istemez. Ama ISO 27001 dokümantasyonunda Madde 7.5.3’ün saklama ve elden çıkarma gerekliliğini ve Annex A 5.33’ün kayıtların korunması beklentisini göstermenin en düzenli yolu budur. Önerdiğimiz alanlar:

• Kayıt adı ve kaynak süreç: kaydı üreten prosedür veya kontrol.
• Kayıt sahibi: kaydın doğruluğundan ve saklanmasından sorumlu rol.
• Ortam ve konum: sistem adı, klasör, arşiv odası; elektronik mi basılı mı.
• Format: sistem kaydı, PDF, imzalı form, log dosyası.
• Sınıflandırma ve kişisel veri içeriği: kişisel veri barındırıp barındırmadığı, özel nitelikli veri olup olmadığı.
• Erişim yetkisi: kim okuyabilir, kim ekleyebilir; silme yetkisi kimde.
• Saklama süresi ve başlangıç anı: süre ve sürenin neyle başladığı (kaydın oluşması, sözleşmenin bitmesi, yıl sonu).
• Saklama dayanağı: yasal, sözleşmesel veya operasyonel gerekçe ve referansı.
• İmha yöntemi: silme, üzerine yazma, fiziksel imha, anonimleştirme.

Listelerde en sık eksik kalan alan başlangıç anıdır. “5 yıl” tek başına uygulanamaz. Kaydın oluşturulduğu günden mi, ilgili çalışanın ayrılışından mı, takvim yılı sonundan mı sayılacağı yazılmadıkça imha günü gelen kaydı kimse silmeye cesaret edemez ve kayıt sonsuza kadar kalır.

Saklama süresinin dayanakları

Her kaydın saklama süresi üç kaynaktan birine veya birkaçına dayanır. Birden fazla dayanak varsa en uzun zorunlu süre geçerli olur. Ama kişisel veri içeren kayıtlarda gereğinden uzun saklamanın da hukuki sonucu var. Uzun süre her zaman güvenli seçenek değildir.

Yasal dayanak

Mevzuat belirli kayıtlar için asgari süre öngörür. Örneğin Türk Ticaret Kanunu’nun 82. maddesi ticari defterler ve dayanak belgeler için on yıllık, Vergi Usul Kanunu’nun 253. maddesi vergi kayıtları için beş yıllık saklama yükümlülüğü getirir. İnternet ortamındaki erişim ve trafik kayıtlarına ilişkin yükümlülükler 5651 sayılı Kanun ve ikincil düzenlemelerinde yer alır. Mevzuat değişebilir ve sürenin başlangıç anı maddeye göre farklılaşır; bu yüzden kayıt listesindeki her yasal süreyi hukuk birimi güncel metinden doğrulamalı ve madde numarasıyla birlikte yazmalıdır.

Kişisel veriler tarafında 6698 sayılı KVKK’nın 4. maddesi, verilerin ilgili mevzuatta öngörülen veya işlendikleri amaç için gerekli olan süre kadar muhafaza edilmesini ilke olarak belirler. Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik; VERBİS’e kayıt yükümlüsü veri sorumluları için kişisel veri saklama ve imha politikası hazırlanmasını, periyodik imhanın altı ayı geçmeyen aralıklarla yapılmasını ve imha işlemlerine ilişkin kayıtların diğer hukuki yükümlülükler hariç en az üç yıl saklanmasını öngörür. Güncel metinler için KVKK resmi sitesi ve Mevzuat Bilgi Sistemi esas alınmalıdır.

Sözleşmesel dayanak

Müşteri sözleşmeleri, bilgi güvenliği ekleri veya sektör gereklilikleri belirli kayıtların saklanmasını isteyebilir: erişim logları, olay kayıtları, test raporları gibi. Bu süreler kayıt listesine sözleşme referansıyla yazılır; sözleşme bittiğinde ilgili kaydın süresi yeniden değerlendirilir. Üretim kalite kayıtlarına özgü gereklilikler için PPAP ve kalite kayıtlarının arşivlenmesi yazısına bakabilirsiniz.

Operasyonel dayanak

Mevzuat veya sözleşme süre koymuyorsa süre, kaydın kullanım amacından türetilir. Soru şu: bu kayıt hangi karar veya doğrulama için gerekli ve o ihtiyaç ne zaman ortadan kalkıyor? Erişim gözden geçirme kayıtları en az bir sonraki belgelendirme veya gözetim denetiminin kapsadığı dönemi karşılamalıdır. Olay soruşturmasında geriye dönük inceleme gerektiren sistem logları ise tehdit tespit ve müdahale ihtiyacına göre belirlenir. Bir saldırı haftalar sonra fark edildiğinde, o haftaların logu yoksa soruşturma orada biter. Log saklamanın teknik mimarisi için merkezi log saklama mimarisi yazısı tamamlayıcıdır.

Örnek BGYS kayıt listesi

Aşağıdaki tablo yapıyı göstermek için hazırlanmış bir örnektir. Sürelerin her biri kurumun kendi yasal, sözleşmesel ve operasyonel analizine göre belirlenmelidir; tablodan kopyalanmaz.

Kayıt	Sahip / Ortam	Örnek süre ve dayanak	İmha
Erişim talep ve onay kayıtları	BT / ITSM aracı	Hesap kapanışından itibaren belirlenen süre; operasyonel	Sistemden silme
Yetki gözden geçirme tutanakları	Uygulama sahibi / BGYS klasörü	En az bir belgelendirme döngüsü; operasyonel	Silme
Bilgi güvenliği olay kayıtları	BGYS sorumlusu / olay kaydı	Olay kapanışından itibaren; sözleşme ve operasyonel	Silme veya anonimleştirme
Geri yükleme test formları	Sistem yöneticisi / BGYS klasörü	En az bir belgelendirme döngüsü; operasyonel	Silme
Eğitim katılım kayıtları	İK / eğitim platformu	Çalışma ilişkisi süresi + belirlenen süre; yasal ve operasyonel	Silme
Ziyaretçi giriş kayıtları	İdari işler / ziyaretçi sistemi	Saklama ve imha politikasındaki süre; KVKK	Periyodik imha
İç denetim raporları, YGG tutanakları	BGYS sorumlusu	Birden fazla denetim döngüsü; operasyonel	Silme

Yedekleme ve geri yükleme kayıtlarının denetimde nasıl sunulacağı için yedekleme denetim kanıtları rehberi ayrıntılı örnekler içerir.

Kayıtların korunması ve erişimi

Annex A 5.33, kayıtların kayba, imhaya, sahteciliğe, yetkisiz erişime ve yetkisiz ifşaya karşı korunmasını ister. Kaydın tutulduğu ortama göre önlemler değişir:

• Bütünlük: oluşturulduktan sonra değiştirilemeyen ya da değişikliği iz bırakan sistemleri tercih edin; kritik logları ayrı bir log sunucusuna veya değiştirilemez depolamaya aktarın. Logu üreten sunucuda duran log, o sunucuyu ele geçiren saldırganın elindedir.
• Erişim: okuma yetkisi geniş, silme yetkisi dar tutulur. Kaydı üreten kişinin kaydı silememesi, görevler ayrılığının en basit uygulamasıdır.
• Okunabilirlik: uzun saklanan elektronik kayıtlarda dosya formatının ileride açılabilir olmasını planlayın; kapanan bir uygulamanın kayıtlarını, uygulama kaldırılmadan önce okunabilir formata aktarın.
• Yedek ve bulut kopyaları: birincil ortamdan silinen kayıt yedekte durmaya devam eder. Yedek saklama süreleri kayıt listesindeki sürelerle uyumlu olmalı ya da yedekten geri dönüşte süresi dolmuş verinin yeniden imhası tanımlanmalıdır.

İmha ve imha kaydı

Süresi dolan kaydın imhası, saklanması kadar planlı olmalıdır. Annex A 8.10 artık ihtiyaç duyulmayan bilginin silinmesini, 7.10 ve 7.14 ise depolama ortamlarının ve ekipmanın güvenli şekilde elden çıkarılmasını ele alır. Medya temizleme yöntemi seçerken NIST SP 800-88’deki temizleme (clear), arındırma (purge) ve imha (destroy) ayrımı yaygın bir referanstır; yöntemi verinin hassasiyeti ve ortamın yeniden kullanılıp kullanılmayacağı belirler. Sahaya dönecek bir diskle parçalanacak bir disk aynı işlemi görmez.

İmha işleminin kendisi de bir kayıttır. İmha kaydında bulunması gereken asgari alanlar:

1. İmha edilen kayıt türü ve kapsamı (tarih aralığı, kayıt sayısı veya ortam seri numarası).
2. İmha gerekçesi: saklama süresinin dolması ve kayıt listesindeki referans.
3. Uygulanan yöntem: mantıksal silme, üzerine yazma, kriptografik silme, fiziksel imha, anonimleştirme.
4. İşlemi yapan ve onaylayan roller, tarih.
5. Dış hizmet alındıysa hizmet sağlayıcının imha sertifikası veya tutanağı.

Kişisel veri içeren kayıtlarda bu imha kaydı, KVKK kapsamındaki periyodik imhanın kanıtıdır. Kayıt listesinde “kişisel veri içerir” işaretli satırlar, saklama ve imha politikasındaki süre tablosuyla birebir tutarlı olmalıdır. İki belge iki farklı süre söylüyorsa denetçinin ilk soracağı yer orasıdır.

Uygulamaya geçiş adımları

1. Tüm prosedürlerin “Kayıtlar” bölümünü tarayarak kayıt envanterini çıkarın.
2. Her kayıt için sahip, ortam ve kişisel veri içeriğini belirleyin.
3. Hukuk birimiyle yasal ve sözleşmesel dayanakları, süreç sahipleriyle operasyonel ihtiyacı netleştirin.
4. Kayıt listesini onaylatın ve KVKK saklama ve imha politikasıyla süreleri eşleştirin.
5. Sistemlerde otomatik saklama kurallarını (log rotasyonu, arşiv politikaları, yedek saklama) listeye göre yapılandırın. Kâğıttaki süre ile sistemdeki rotasyon ayarı çoğu kurumda birbirini hiç görmemiştir.
6. İlk periyodik imhayı yapın ve imha kaydını oluşturun.

Kişisel veri saklama ve imha tarafını BGYS kayıt düzeniyle birlikte kurgulamak KVKK teknik ve idari tedbirler çalışmasının parçası olarak ele alınabilir.

Sık sorulan sorular

BGYS kayıtları için ISO 27001 belirli bir saklama süresi öngörür mü?

Hayır. ISO/IEC 27001 saklama ve elden çıkarmanın kontrol edilmesini ister ama süre vermez. Süreler kurumun yasal, sözleşmesel ve operasyonel ihtiyaçlarına göre belirlenir ve kayıt listesinde gerekçesiyle yazılır.

Bir kayıt için birden fazla saklama süresi çıkarsa hangisi uygulanır?

Genellikle en uzun zorunlu süre uygulanır. Kişisel veri içeren kayıtlarda ise amaç için gerekli olandan uzun saklamak da risktir; uzun sürenin gerçekten zorunlu bir dayanağa bağlı olduğunu doğrulayın.

İmha kaydı ne kadar süre saklanmalı?

Kişisel verilerin imhasına ilişkin kayıtlar için ilgili yönetmelik, diğer hukuki yükümlülükler hariç en az üç yıllık saklama öngörür. Diğer imha kayıtları için süreyi kurumun kayıt listesi belirler; güncel mevzuatı hukuk birimiyle doğrulayın.

Yedeklerde kalan eski kayıtlar ne olacak?

Yedek saklama süreleri kayıt listesindeki sürelerle uyumlu planlanmalıdır. Uyumlu değilse, yedekten geri dönüş yapıldığında süresi dolmuş kayıtların yeniden imha edileceği bir adım prosedüre eklenir.