KVKK Teknik Uyum: Kişisel Veri Güvenliği Tedbirleri

Bir otelin vestiyerine paltonuzu bıraktığınızda ortada bir satış yoktur. Palto hâlâ sizindir. Otel onu giymez, başkasına vermez, siz isteyince geri verir ve siz otelden ayrıldıktan sonra dolabında tutmaya devam etmez. Bunların hiçbiri otelin cömertliği değildir; emanet almanın tanımıdır.

Kişisel veri de böyle bir emanettir. Müşterinizin telefon numarası, çalışanınızın kimlik fotokopisi, ziyaretçinizin kamera görüntüsü: bunlar sizin kayıtlarınızda durur ama size ait değildir. 6698 sayılı Kanun’un yaptığı şey, bu emanetin kurallarını yazmaktır. KVKK teknik uyum ise o kuralların sistem tarafındaki karşılığıdır: vestiyerin kilidi, defteri ve kapanış saati.

Bu ayrım önemli, çünkü KVKK denince akla önce hukuk gelir ve haklı olarak gelir. Ama bir denetimde sorulan sorular çoğunlukla hukuki değil, tekniktir: bu veriye kim erişti, erişim kaydı var mı, saklama süresi dolan kayıt gerçekten silindi mi. Bu rehber BT danışmanlık hizmetimizin uyum tarafına odaklanıyor ve tam olarak bu soruların cevabının nasıl kurulacağını anlatıyor.

KVKK Teknik Uyum Nedir, Hukuki Uyumdan Farkı Ne?

KVKK teknik uyum, kanunun getirdiği yükümlülüklerin sistem ve altyapı üzerinde uygulanabilir hale getirilmesidir. Hukuki uyum “ne yapılması gerektiğini” belgeye döker; teknik uyum onu sunucuda, dizinde, kamera kayıt cihazında ve log sunucusunda çalışır hale getirir.

Kanunun teknik tarafı 6698 sayılı Kanun’un 12. maddesinde toplanır. Madde, veri sorumlusuna üç şeyi güvence altına almasını yükler:

1. Kişisel verilerin hukuka aykırı olarak işlenmesini önlemek
2. Kişisel verilere hukuka aykırı olarak erişilmesini önlemek
3. Kişisel verilerin muhafazasını sağlamak

Bunlar için “uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri almak” zorunludur. Kurum, bu tedbirlerin neler olabileceğini Kişisel Veri Güvenliği Rehberi (PDF) ile ayrıca yayımlamıştır; rehber teknik ve idari tedbirleri ayrı ayrı ele alır.

Hukukçu Ne Yapar, BT Ekibi Ne Yapar?

İki tarafın işi birbirinin yerine geçmez ve bir tarafı eksik bırakmak diğerini de geçersiz kılar.

Sağ sütun olmadan sol sütun bir taahhüttür. Ve bir denetimde taahhüt değil, kanıt istenir.

Kanıtlanamayan Tedbir Alınmamış Sayılır

Buradaki asıl mesele şudur: teknik tedbirlerin çoğu, alındığını gösteremediğiniz sürece işe yaramaz.

Bunu somutlaştıralım. “Kişisel veri içeren klasöre sadece yetkili personel erişiyor” cümlesi bir iddiadır. Bu iddianın kanıtı, o klasörün yetkilerinin ekran görüntüsü ve kimlerin ne zaman eriştiğini gösteren kayıttır. Kayıt yoksa, klasör bugün doğru yapılandırılmış olsa bile geçen yıl ne durumda olduğunu kimse bilemez.

Bu yüzden KVKK teknik uyumunda her tedbirin bir de kayıt tarafı vardır ve rehberin geri kalanında bunu tekrar tekrar göreceksiniz: yetki verilir ve kaydedilir, veri silinir ve kaydedilir, erişim olur ve kaydedilir.

Kişisel Veri Envanteri: Neyi Nerede Tuttuğunuzu Bilmeden Koruyamazsınız

Emanetin ilk kuralı, ne emanet aldığınızı bilmektir. Kişisel veri envanteri de tam olarak budur: hangi kişisel verinin, hangi sistemde, hangi amaçla, ne kadar süreyle tutulduğunun kaydı.

Envanter çoğu kurumda hukuk tarafında bir tablo olarak hazırlanır ve orada kalır. Teknik tarafta karşılığı olmayan bir envanter ise ilk denetimde çöker, çünkü beyan ile gerçek birbirini tutmaz.

Envanterde Gerçekten Cevaplanması Gereken Sorular

Her veri kalemi için sorulacaklar:

• Hangi veri? Ad soyad, TC kimlik numarası, telefon, adres, sağlık verisi, kamera görüntüsü, parmak izi
• Nerede duruyor? Sunucu, paylaşım klasörü, veritabanı, bulut hizmeti, kayıt cihazı, yedek ünitesi, çalışanın dizüstü bilgisayarı
• Kim erişebiliyor? Rol bazında, kişi bazında değil
• Hangi amaçla işleniyor? Bu, saklama süresini de belirleyen sorudur
• Ne kadar süre saklanacak? Ve süre dolduğunda ne olacak
• Dışarı çıkıyor mu? Muhasebeciye, bulut sağlayıcısına, kargo firmasına aktarılıyor mu

Bu listedeki en çok atlanan iki madde ikinci ve altıncıdır. Kişisel veri nadiren tek bir yerde durur: aynı müşteri listesi hem veritabanında, hem birinin masaüstünde bir tablo dosyasında, hem de üç aylık bir yedek setinde bulunur. Yedeği envantere yazmayan kurum, veriyi sildiğini sanır.

Aynı sorunun daha zor görülen hâli, verinin kurumun hiç bilmediği bir araca gitmesidir: onaysız bir bulut hesabı, kişisel bir mesajlaşma uygulaması, bir yapay zekâ aracına özetlensin diye yapıştırılmış müşteri listesi. Bu, envanterin tamamen dışında kalan gölge BT meselesidir ve veri sorumlusu sıfatını değiştirmez: aracı çalışan seçmiş olsa bile sorumluluk kurumda kalır.

Envanteri Elle Değil, Sistemden Çıkarın

Elle hazırlanan envanterin en büyük sorunu bayatlamasıdır: hazırlandığı gün doğrudur, altı ay sonra yanlıştır. Sunucu eklenir, klasör taşınır, yeni bir uygulama devreye alınır ve envanter bunları görmez.

Bunun panzehiri, envanterin dayandığı temel bilgiyi otomatik toplamaktır. Hangi makinede hangi yazılım var, hangi paylaşım kime açık, hangi sunucu ne zaman devreye girdi gibi sorular BT envanter yönetimi tarafında zaten toplanır. Kişisel veri envanteri bu teknik envanterin üstüne kurulduğunda kendini güncel tutar.

Erişim Yetkilendirme ve Yetki Matrisi: Emanete Kim Dokunabilir?

Envanter neyi koruyacağınızı söyledi; bunun sonucunda ikinci karar verilebilir hale geldi: kim erişecek? KVKK teknik uyumunun en somut ve denetimde en çok sorulan başlığı budur.

Temel ilke en az yetki ilkesidir: bir kullanıcı, işini yapmak için gereken en az yetkiye sahip olmalıdır. Kulağa açık gelir, sahada nadiren uygulanır. Sebep de bellidir: yetki vermek kolay, geri almak zahmetlidir ve kimse çalışan şikâyet etmesin diye fazladan yetkiyi geri almaya uğraşmaz.

Yetki Matrisi Nedir, Nasıl Kurulur?

Yetki matrisi, hangi rolün hangi veriye hangi düzeyde erişeceğini gösteren tablodur. Kişi adına göre değil, rol adına göre kurulur; çünkü kişiler değişir, roller kalır.

Rol              Personel özlük   Müşteri veritabanı   Kamera kayıtları
---------------  ---------------  -------------------  ----------------
İnsan Kaynakları  Okuma+Yazma      Yok                  Yok
Satış             Yok              Okuma+Yazma          Yok
Güvenlik          Yok              Yok                  Okuma
BT Yöneticisi     Yok              Yönetim (içerik yok) Yönetim

Son satır dikkat ister ve sahada en çok tartışılan yerdir. BT yöneticisinin sistemi yönetmesi, içeriği okuması anlamına gelmez. Bir sistem yöneticisinin veritabanı sunucusunu yönetmesi gerekir, ama içindeki müşteri kayıtlarını okuması gerekmez. Bu ayrımı teknik olarak kurmak her zaman mümkün değildir; mümkün olmadığı yerde çözüm, erişimin kayıt altına alınması ve o kaydın yöneticinin kendisi tarafından silinememesidir.

Bu, ilk bakışta bir insan yönetimi hikâyesi gibi durur. Değildir: o müdürün elindeki şey bir yönetim aracı değil, yetki matrisinde kimsenin sınırlamadığı bir erişimdi. Kurul’un kamera duyurusu tam olarak bunu kapsıyor; çalışanın nerede olduğunu ve verimli çalışıp çalışmadığını izlemek meşru amaç sayılmıyor, ses kaydı ise ayrıca gerekçe istiyor. Yani anlatılan davranış yalnızca kırıcı değil, aynı zamanda mevzuata aykırı.

İşveren tarafındaysanız şunu net söylemekte fayda var: BT yöneticinize verdiğiniz erişim, kurumdaki en geniş erişimdir ve doğası gereği denetlenmesi en zor olandır. O yetkinin güvenlik olayları ve rutin kontroller dışında kullanılmayacağını açıkça konuşun. Sonra da teknik tarafını kurun: kamera kayıtlarına kimin ne zaman baktığı da kayıt altına alınsın ve bu kayıt, sistemi yöneten kişinin silemeyeceği bir yerde dursun. İnsanları yönetmeye, kendinizi kabul ettirdiğinizde değil onlar sizi kabul ettiğinde başlarsınız; kamerayla kurulan otorite, otorite değil gözetimdir.

Yetkilendirmenin dizin tarafındaki uygulaması, kullanıcıların ve grupların nasıl yapılandırıldığına bağlıdır; Active Directory kullanıcı, grup ve OU yönetimi rehberimizde anlatılan grup temelli yaklaşım, yetki matrisinin sistemdeki tam karşılığıdır.

Yetkiler Periyodik Olarak Gözden Geçirilir

Bir yetki matrisi kurulduğu gün doğrudur. Onu doğru tutan şey periyodik gözden geçirmedir ve bu gözden geçirmenin çıktısı bir kayıt olmalıdır.

En sık kaçırılan senaryo çalışan ayrılışıdır. Bir çalışan ayrıldığında hesabı kapatılır, ama şunlar çoğu zaman kalır:

• Paylaşım klasörlerindeki kişisel yetkileri
• Bulut hizmetlerindeki ayrı hesapları
• Ortak kullanılan uygulamalardaki tanımları
• Şirket telefonundaki ve dizüstü bilgisayarındaki yerel veriler
• VPN erişim tanımı

Ayrılan çalışan senaryosunun KVKK açısından ağırlığı şudur: bu bir “ihmal” değil, hukuka aykırı erişimin önlenmemesidir ve Kanun m.12’nin ikinci fıkrasına doğrudan girer.

Loglama ve İzlenebilirlik: Log’un Kendisi de Kişisel Veridir

Yetkiler verildi. Ama yetki vermek, o yetkinin nasıl kullanıldığını bilmek anlamına gelmez; bu yüzden erişimin kaydı gerekir. Loglama, KVKK teknik uyumunda tedbirin kendisi olduğu kadar, diğer tedbirlerin kanıtıdır.

Tutulması beklenen kayıtlar genellikle şunlardır: kimin, ne zaman, hangi kayda, hangi işlemi yaptığı. Özellikle okuma işleminin kaydı önemlidir ve çoğu kurumda eksiktir; çünkü silme ve değiştirme kayıtları uygulamalarda varsayılan olarak tutulurken, sadece bakma işlemi çoğu zaman iz bırakmaz.

Log Sunucusu Neden Ayrı Bir Makinede Durur?

Logun tek bir teknik şartı vardır ve bu şart onun bütün değerini belirler: kayıt, kaydı üreten kişi tarafından değiştirilememelidir.

Bir sunucudaki logu o sunucunun yöneticisi silebiliyorsa, o log bir kanıt değildir. Bu yüzden loglar üretildikleri makinede bırakılmaz, merkezi bir log sunucusuna gönderilir ve o sunucuya erişim ayrı bir yetki setiyle sınırlanır.

Buraya kadarki mekanizma kurum içi bir disiplindir ve KVKK’nın istediği ölçüde iş görür. Ama bir kaydın hukuki delil sayılması için gereken standardı KVKK değil, 5651 sayılı kanun koyar ve orada çıta daha yüksektir: kaydın değiştirilmediğini kurumun kendi beyanı değil, bağımsız bir taraf doğrulamalıdır.

Mekanizma sahada sık yanlış anlatılır, çünkü “şifreleme” diye özetlenir. Yapılan şey şifreleme değildir: kaydın özeti (hash) alınır ve bu özet, yetkili bir Elektronik Sertifika Hizmet Sağlayıcısı tarafından zaman damgasıyla mühürlenir. Kayıt sonradan tek bir karakteriyle bile oynanırsa özeti değişir, mühürlenmiş değerle tutmaz ve değişiklik kimsenin beyanına gerek kalmadan ortaya çıkar. Şifreleme ayrı bir yükümlülüktür ve gizliliği sağlar, bütünlüğü değil; ikisi aynı cümlede anılınca karışır.

Bunun pratik sonucu şudur: 5651 kapsamındaki loglama kurum içi bir log sunucusuyla bitmez, zaman damgasını dışarıdan ve yetkilendirilmiş bir sağlayıcıdan almanız gerekir. Kendi ürettiğiniz hash zinciri ile nitelikli zaman damgası arasındaki farkı ve hangi sağlayıcının neyi kanıtladığını kaydın tarihini üçüncü tarafa kanıtlamak bölümünde ayrıntılı ele aldık.

Merkezi loglamanın ikinci şartı zamandır. Farklı sistemlerden gelen kayıtların bir olayı birlikte anlatabilmesi için hepsinin saatinin aynı olması gerekir. Saatleri kayan iki sunucunun logu yan yana konduğunda hangi olayın önce olduğu anlaşılamaz. Bu yüzden ağ genelinde saat senkronizasyonu bir konfor ayarı değil, kanıt zincirinin ön koşuludur.

Log Tutmak da Bir Veri İşleme Faaliyetidir

Burada döngüsel ama önemli bir nokta var: erişim logu da kişisel veri içerir. Kimin ne zaman hangi kayda baktığını gösteren bir kayıt, o çalışan hakkında bir veridir.

Bunun iki pratik sonucu var:

1. Log da envantere girer. Ne kadar saklandığı, kimin eriştiği ve ne zaman imha edileceği yazılır.
2. Log çalışan takibine dönüşemez. Erişim kaydı, güvenlik ve hukuki uyum amacıyla tutulur; çalışanın verimliliğini ölçmek için kullanılması, işleme amacının dışına çıkmaktır.

Bu ayrım, 5651 log yönetimi tarafında da aynen geçerlidir: 5651 erişim kaydını zorunlu kılar, KVKK ise o kaydın da korunması gereken bir kişisel veri olduğunu söyler. İki yükümlülüğü birlikte kurgulamayan kurum, birini yerine getirirken diğerini ihlal edebilir.

Saklama Süresi ve İmha: Silmemek de Bir İhlaldir

Vestiyer örneğine dönelim: otel, siz ayrıldıktan sonra paltonuzu saklamaya devam ederse bu bir hizmet değil, bir sorundur. Kişisel veride de durum aynıdır ve bu, KVKK’nın en çok gözden kaçan tarafıdır: veriyi gereğinden uzun saklamak, başlı başına bir ihlaldir.

Çoğu kurumun refleksi tersidir. “Ne olur ne olmaz, dursun” yaklaşımı depolama ucuzladıkça daha da yaygınlaştı. Ama Kanun açısından elinizde tuttuğunuz her kayıt, korumakla yükümlü olduğunuz bir emanettir; sakladığınız veri arttıkça yükümlülüğünüz artar, riskiniz artar ve bir ihlal anında etkilenen kişi sayısı artar.

Süre Belirlemenin Ölçütü Amaçtır

Kanun kalem kalem süre saymaz. Ölçüt şudur: veri hangi amaçla işleniyorsa, o amacın ortadan kalkmasıyla birlikte saklama gerekçesi de ortadan kalkar. Bazı verilerde süreyi başka mevzuat belirler (ticari defterler, bordro kayıtları gibi), bazılarında ise süreyi siz belirler ve gerekçelendirirsiniz.

Pratikte sürecin şöyle işlemesi beklenir:

1. Her veri kategorisi için saklama süresi belirlenir ve saklama ve imha politikasına yazılır
2. Süre, envanterde o veri kaleminin yanında durur
3. Sürenin dolduğu sistem tarafından tespit edilir
4. Veri imha edilir: silinir, yok edilir veya anonim hale getirilir
5. İmha işlemi kayıt altına alınır

İmhanın Unutulan Yeri: Yedekler

Beşinci adımı yaptığınızı varsayalım. Üretim sistemindeki kayıt silindi. Peki üç ay önceki tam yedekte duran kopyası?

Bu, saklama ve imha politikalarının en zayıf noktasıdır ve teknik bir çözüm gerektirir. Yedekten seçmeli silme çoğu yedekleme mimarisinde mümkün değildir; bu durumda uygulanan yaklaşım, yedeklerin kendi saklama süresini kısa ve tanımlı tutmak ve bu süreyi politikada açıkça belirtmektir. Yani yedekteki kayıt silinmez, yedeğin kendisi süresi dolduğunda döngüden çıkar.

Bunun yedekleme ve felaket kurtarma tarafındaki karşılığı, saklama döngüsünün KVKK politikasıyla birlikte tasarlanmasıdır. Sonsuza kadar saklanan bir arşiv yedeği, iyi bir yedekleme pratiği gibi görünüp uyum tarafında sorun üretebilir.

Şifreleme: Duran Veri ve Giden Veri

Saklanan veri korunmalıdır ve korumanın en doğrudan aracı şifrelemedir. KVKK teknik uyumunda şifreleme iki ayrı yerde karşınıza çıkar ve ikisi farklı sorunları çözer.

Duran veri (at rest): diskte, veritabanında, yedek ünitesinde ve taşınabilir bellekte duran veri. Buradaki tehdit, cihazın fiziksel olarak ele geçirilmesidir. Çalınan bir dizüstü bilgisayar, diski şifreliyse bir donanım kaybıdır; şifreli değilse bir veri ihlalidir. Aradaki fark tam olarak budur ve bildirim yükümlülüğünü doğuran şey ikincisidir.

İletimdeki veri (in transit): ağ üzerinden giden veri. Buradaki tehdit araya girmedir ve çözüm TLS ile şifreli iletimdir. Kurum içi uygulamalarda hâlâ şifresiz protokol kullanmak yaygındır ve “zaten iç ağdayız” gerekçesiyle savunulur; oysa iç ağ, ziyaretçi kablosuyla, kablosuz ağla ve yanlış yapılandırılmış bir portla dışarı açılabilir.

Şifrelemenin türleri, simetrik ve asimetrik yöntemlerin farkı ve özet fonksiyonlarının nerede kullanıldığı şifreleme rehberimizde ayrıntılı anlatılıyor.

Bir uyarı: şifreleme bir erişim kontrolü değildir. Yetkili kullanıcı için veri zaten çözülmüş haldedir. Şifreleme cihaz kaybını ve hat dinlemesini çözer; yetkisiz personelin yetkili bir hesapla veriye bakmasını çözmez. Onun çözümü yetki matrisi ve logdur.

Kamera Sistemlerinde KVKK: En Görünür Uyum Alanı

Buraya kadarki tedbirler çoğunlukla sunucu odasında ve yazılımda kalır. Kamera ise KVKK’nın gözle görülen tarafıdır: binaya giren herkes onu görür, çalışanlar her gün altından geçer ve şikâyetlerin büyük kısmı buradan doğar.

Kişisel Verileri Koruma Kurumu, iş yerlerinde kameraların amaç dışı ve ölçüsüz kullanımına ilişkin artan şikâyetler üzerine 8 Haziran 2026 tarihinde iş yerlerinde güvenlik kamerası sistemi kullanımına dair bir kamuoyu duyurusu yayımladı.

Duyurunun Getirdiği Somut Sınırlar

• Meşru amaçlar sınırlıdır: iş sağlığı ve güvenliğinin sağlanması, iş kazalarının önlenmesi, iş yeri güvenliği, suçun önlenmesi ve tespiti. Çalışanın verimli çalışıp çalışmadığını görmek veya disiplin sağlamak meşru amaç sayılmaz.
• Bazı alanlara kamera yerleştirilemez: tuvalet, soyunma odası, mescit ve dinlenme alanı gibi özel alanlar.
• Ölçülülük aranır: kamera yerleşimi, görüş açısı, kayıt kapsamı ve izleme sıklığı ölçülü olmalı, çalışanın makul mahremiyet beklentisi gözetilmelidir.
• Aydınlatma tabelayla bitmez: Kanun’un 10. maddesi gereği bilgilendirme yapılır; girişteki “kamera ile izlenmektedir” ibaresi tek başına yeterli sayılmaz.
• Kayıtlar süresiz saklanmaz: mümkün olan en kısa süre tercih edilir ve sistemde otomatik imha mekanizması bulunması beklenir.
• Ses kaydı ayrı değerlendirilir: ses kayıt özelliği, hukuki gerekçesi açıkça ortaya konmadan kullanılmamalıdır.

Duyurunun hukuki değerlendirmesini okumak isterseniz, konuyu ele alan hukukçu yorumlarından biri Erdem & Erdem’in kamuoyu duyurusu değerlendirmesidir.

Bu Maddelerin Teknik Karşılığı Nedir?

Duyurudaki her madde, kayıt cihazında veya kablolamada bir ayara karşılık gelir:

Tablodaki ilk satır özel bir öneme sahip, çünkü diğerlerinden farklı olarak sonradan düzeltilmesi ucuz değildir. Kamera kablosu duvarın içindedir; yanlış konumlandırılmış bir noktayı taşımak bir ayar değişikliği değil, tadilattır. Bu yüzden kamera yerleşimi, yapısal kablolama ve zayıf akım projesinin keşif aşamasında, bu ölçütler masadayken kararlaştırılır.

Kamera tarafında saatin doğruluğu da ayrı bir konudur: bir olay kaydının delil değeri taşıyabilmesi için görüntünün üzerindeki zaman damgasının güvenilir olması gerekir. 500 kameralık bir kurulumda NTP, isimlendirme ve KVKK uyumunu nasıl birlikte ele aldığımızı vaka çalışmamızda anlatıyoruz; orada ses kaydı almadan görüntü kaydı prensibi de uygulanmış bir karardır.

Veri İhlali Olursa: 72 Saat Kuralı ve Bildirim Yükümlülüğü

Buraya kadarki tedbirlerin hepsi doğru kurulmuş olsa bile ihlal ihtimali sıfırlanmaz. Bu yüzden KVKK teknik uyumunun son halkası, ihlal gerçekleştiğinde ne olacağıdır.

Kanun, kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâlinde veri sorumlusunun en kısa sürede ilgili kişiye ve Kurula bildirimde bulunmasını ister. Kurul, “en kısa süre” ifadesini bir karara bağlamıştır: veri sorumlusu ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurula bildirimde bulunur. Bu süre içinde bildirim yapılamıyorsa, gecikmenin gerekçesi bildirimle birlikte açıklanır. İlgili kişilere yapılacak bildirimin taşıması gereken asgari unsurlar da ayrı bir Kurul kararıyla belirlenmiştir.

72 Saat, Aslında Bir İzleme Yükümlülüğüdür

Bu maddenin teknik tarafı çoğu kurumda gözden kaçar ve gözden kaçtığı yer şurasıdır: süre, ihlali öğrendiğiniz andan itibaren başlar.

Yani asıl soru “72 saat yeter mi” değil, “ihlali kaç günde fark edersiniz” sorusudur. Dışarıdan sızdırılan bir müşteri veritabanı, çoğu zaman kurumun kendi izlemesiyle değil, veri bir yerde ortaya çıktığında fark edilir. O noktada geçen süre haftalarla ölçülür ve bildirim yükümlülüğü zaten ihlal edilmiş olur.

Bunun karşılığı, buraya kadar anlattığımız tedbirlerin birlikte çalışmasıdır:

• Merkezî log, olağandışı erişimi görünür kılar
• Yetki matrisi, olağandışının ne olduğunu tanımlar
• Saat senkronizasyonu, olayların sırasını kurar
• Sistem sıkılaştırması, ihlalin gerçekleşme ihtimalini düşürür

İhlal Anında Hazır Olması Gerekenler

Bildirim süresi kısa olduğu için, ihlal anında toplanacak bilgilerin önceden hazır olması gerekir:

1. Hangi veri kategorileri etkilendi? Envanter bunu dakikalar içinde cevaplayabilmeli.
2. Kaç kişi etkilendi? Yaklaşık sayı bile olsa bildirimde istenir.
3. İhlal ne zaman başladı, ne zaman fark edildi? Log olmadan bu soru cevaplanamaz.
4. Hangi önlemler alındı? Sistemin kapatılması, parolaların sıfırlanması, erişimin kesilmesi.
5. İlgili kişilere nasıl ulaşılacak? İletişim bilgisi olmayanlar için duyuru yöntemi.

Üçüncü madde, bu rehberde loglamanın neden bu kadar yer kapladığının cevabıdır. Log yoksa ihlalin kapsamı bilinemez; kapsamı bilinmeyen bir ihlalde ise etkilenen herkese en kötü senaryoyu bildirmek zorunda kalırsınız.

Sonuç: Emanetin Kaydını Tutmak

KVKK teknik uyumu, tek bir ürün alarak ya da tek bir belge imzalayarak tamamlanan bir iş değildir. Yaptığı şey daha sade: elinizdeki emanetin ne olduğunu, nerede durduğunu, kimin dokunduğunu ve ne zaman iade edileceğini kayıt altına almanızı ister.

Pratikte üç şey akılda kalsın. Birincisi, kanıtlanamayan tedbir alınmamış sayılır: her teknik önlemin bir de kayıt tarafı vardır ve denetimde sorulan şey taahhüt değil kanıttır. İkincisi, gereğinden uzun saklamak da bir ihlaldir ve imhanın en çok unutulan yeri yedeklerdir. Üçüncüsü, 72 saatlik bildirim süresi aslında bir izleme yükümlülüğüdür: ihlali fark edemeyen kurum, süreyi zaten kaçırmıştır.

Uyum tarafını bir bütün olarak ele almak isterseniz, 5651 log yönetimi yasal kayıt yükümlülüğünü, ISO 27001 ise aynı disiplinin belgelendirilmiş halini anlatıyor. Bu üç başlık birlikte kurulduğunda, denetimde sorulan soruların cevabı çoğunlukla zaten sistemde hazır durur.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.