KVKK Teknik Tedbirler: 17 Satır, Kanıt ve Cezanın Aritmetiği

6698 sayılı Kanun'un 12. maddesi veri sorumlusuna ne alacağını söylemiyor: "uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak zorundadır" diyor. Tedbirin adı yok, sayısı yok, eşiği yok. Cümle bilinçli olarak soyut; çünkü aynı hüküm hem üç kişilik bir muhasebe ofisini hem 4.000 çalışanlı bir üretim tesisini bağlıyor.

Bu soyutluğu Kurum iki araçla somutlaştırıyor. Birincisi Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler): 2018'deki basımının ardından Nisan 2025'te KVKK Yayınları No: 72 olarak yenilendi ve 5 idari, 6 teknik başlık ile 17 satırlık özet tablo veriyor. İkincisi ihlal kararları: Kurul, verdiği cezalarda hangi tedbirin eksik olduğunu Rehber'in bölüm numarasıyla yazıyor. "3.3'ü tutmadınız" cümlesi bir görüş değil, gerekçenin kendisi.

Bu iki kaynağı yan yana koyduğunuzda işin rengi değişiyor. Rehber "şifreleme" diyor; karar "yedekleriniz de şifreli miydi" diye soruyor. Rehber "log kayıtları" diyor; karar "bu logu kim, hangi sıklıkta okudu" diye soruyor. Yani uyumun ölçüsü politika klasörünün kalınlığı değil, her tedbirin arkasında duran tarihli, sahipli, sonuç gösteren belge. Aşağıdaki metin tam olarak o dosyayı kuruyor.

Kanunun cümlesi: üç fiil, iki sorumlu, bir ceza bandı

Madde 12'nin ilk fıkrası üç ayrı fiil sayıyor ve üçü farklı kontrol ailelerine karşılık geliyor. Ayrımı kaçırmak, bütçeyi yanlış yere harcamanın en yaygın sebebi.

"Veri sorumlusu; a) Kişisel verilerin hukuka aykırı olarak işlenmesini önlemek, b) Kişisel verilere hukuka aykırı olarak erişilmesini önlemek, c) Kişisel verilerin muhafazasını sağlamak amacıyla uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak zorundadır."

Hukuka aykırı işlemeyi önlemek verinin niteliğiyle ilgili: hangi veriyi, hangi amaçla, ne kadar süre tuttuğunuz. Buradaki tedbirler daha çok idari tarafta; veri envanteri, amaç sınırlaması, veri minimizasyonu, imha takvimi. Teknik karşılığı maskeleme ve erişim sınırı.

Hukuka aykırı erişimi önlemek kimlik ve ağ tarafı: kimin hangi kayda ulaşabildiği, ulaşımın nereden yapılabildiği, ulaşımın kaydedilip kaydedilmediği. Yetki matrisi, çok faktörlü doğrulama, segmentasyon, loglama burada.

Muhafazayı sağlamak ise verinin bozulmadan ve kaybolmadan durması: şifreleme, anahtar yönetimi, yedekleme, geri dönme testi. Üç fiilden en çok atlanan bu; çünkü ihlal olmadığı sürece yedeğin çalışıp çalışmadığını kimse merak etmiyor.

İkinci fıkra sorumluluğu paylaştırıyor: veri işleyen, güvenliğin sağlanmasında veri sorumlusuyla müştereken sorumlu. Yani hizmet aldığınız bulut sağlayıcısı, çağrı merkezi veya muhasebe yazılımı sizin yerinize sorumlu olmuyor; sizin yanınıza ekleniyor. Beşinci fıkra ayrı bir saat başlatıyor: verilerin kanuni olmayan yollarla başkaları tarafından elde edildiğini öğrendiğinizde bunu en kısa sürede ilgilisine ve Kurula bildirmek zorundasınız. Kurul bu "en kısa süre"yi 24.01.2019 tarih ve 2019/10 sayılı kararıyla 72 saat olarak okuyor ve bu okuma o günden beri uygulamada yerleşmiş durumda.

Yükümlülük	Dayanak	2026 ceza bandı (TL)
Veri güvenliğini sağlama (teknik ve idari tedbirler)	md.12/1, ceza md.18/1(b)	256.357 - 17.092.242
İhlali ilgiliye ve Kurula bildirme	md.12/5, ceza md.18/1(b)	Aynı bant: 256.357 - 17.092.242
Aydınlatma yükümlülüğü	md.10, ceza md.18/1(a)	85.437 - 1.709.200
VERBİS'e kayıt ve bildirim	md.16, ceza md.18/1(ç)	341.809 - 17.092.242
Yurt dışına aktarım bildirimi	md.9/5, ceza md.18/1(d)	90.308 - 1.806.177

Tutarlar 31 Aralık 2025'te yayımlanan tablodan; yeniden değerleme oranı yüzde 25,49 (585 sıra numaralı Vergi Usul Kanunu Genel Tebliği, 27 Kasım 2025 Resmî Gazete) ve 1 Ocak 2026'dan itibaren geçerli. Tablodaki en dar bant ile en geniş bant arasındaki fark 66,7 kat: aynı madde, aynı ihlal türü, ama ceza 256 bin ile 17 milyon arasında bir yerde. Bu aralığı belirleyen şey ihlalin büyüklüğü, kusurun ağırlığı ve veri sorumlusunun ekonomik durumu. Yani "kaç TL ceza yerim" sorusunun tek bir cevabı yok; ama hangi uçta duracağınızı belirleyen şey tedbirlerin varlığı.

Rehber'in mimarisi: 11 bölüm, 17 satır, iki farklı iş

Rehber'in en kullanışlı tarafı, içindekiler sayfasının aynı zamanda bir denetim planı olması. Beş idari başlık belge istiyor, altı teknik başlık yapılandırma istiyor. Karıştırıldığında iki klasik hata çıkıyor: yapılandırması olmayan politika ("şifreleme politikamız var" ama diskler açık) ve sahibi olmayan yapılandırma ("yedek alınıyor" ama kimin ne zaman test ettiği belli değil).

Bölüm	Başlık	İstediği şey	Kanıt olarak ne durur
2.1	Mevcut risk ve tehditlerin belirlenmesi	Kendi ortamınıza ait risk listesi	Tarihli risk analizi; varlık envanteriyle eşleşen tehdit satırları
2.2	Çalışanların eğitilmesi ve farkındalık	İlk müdahaleyi yapabilecek personel	Eğitim içeriği, sınav sonucu, oltalama simülasyonu tıklama eğrisi
2.3	Politika ve prosedürlerin belirlenmesi	Yazılı, onaylı, sürümlü kurallar	Onay kaydı, sürüm numarası, yürürlük tarihi, gözden geçirme periyodu
2.4	Verilerin mümkün olduğunca azaltılması	Toplamadığınız veri risk taşımaz	Envanterdeki her alan için amaç ve saklama süresi gerekçesi
2.5	Veri işleyenler ile ilişkilerin yönetimi	Tedarikçide de sizin seviyeniz	Sözleşme ekleri, denetim hakkı, son denetim raporu
3.1	Siber güvenliğin sağlanması	Yetki, parola, erişim sınırı	Yetki matrisi çıktısı, çok faktörlü doğrulama kapsam raporu, parola politikası kaydı
3.2	Kişisel veri güvenliğinin takibi	Log tutmak ve loga bakmak	Merkezi log kaynağı, alarm kuralları, okuma tutanağı
3.3	Veri içeren ortamların güvenliği	Ağ bileşenlerinin ayrılması	Segment şeması, kural seti, segmentler arası akış testi
3.4	Verilerin bulutta depolanması	Bölge, anahtar, log sahipliği	Bulut sözleşmesi, bölge ayarı, anahtar yönetimi kaydı
3.5	BT sistemleri tedariki, geliştirme, bakım	Tedarikte güvenlik şartı	Şartname maddesi, destek ömrü tarihi, yama SLA kaydı
3.6	Kişisel verilerin yedeklenmesi	Yedeğin geri dönmesi	Geri dönme test tutanağı, süre ölçümü, şifreleme durumu

Dördüncü bölümdeki iki tablo (4.1 teknik, 4.2 idari) bu başlıkların satır satır dökümü. Teknik tabloda 17 satır var: yetki matrisi, yetki kontrol, erişim logları, kullanıcı hesap yönetimi, ağ güvenliği, uygulama güvenliği, şifreleme, sızma testi, saldırı tespit ve önleme sistemleri, log kayıtları, veri maskeleme, veri kaybı önleme yazılımları, yedekleme, güvenlik duvarları, güncel anti virüs sistemleri, silme/yok etme/anonim hale getirme, anahtar yönetimi.

Bu 17 satırın pratik değeri şu: her biri tek tek "var / yok / kısmi" diye işaretlenebilir ve her işaretin yanına bir belge adı yazılabilir. Ortaya çıkan sayfa, Rehber'i okumayan bir yöneticinin de anlayacağı tek sayfalık durum tablosu oluyor. Yazının sonunda bu tabloyu kanıt sütunuyla birlikte veriyorum.

Kararlarda bölüm numarası yazıyor: iki dosya, iki ders

Kurul'un ihlal kararları üç adımda ilerliyor: olayı tespit ediyor, olayı Rehber'in belirli bir başlığına bağlıyor, sonra md.18/1(b)'yi uyguluyor. Bu yüzden karar özetleri, Rehber'in hangi cümlesinin hangi olayda karşılık bulduğunu gösteren en somut kaynak.

Karar	Olay	Atıf yapılan bölüm	Ceza
2024/415, 06.03.2024	Fransa'daki ortak sunuculara Lockbit; kiralık Metro Ethernet hattı üzerinden Türkiye'deki 8 sunucuya yayıldı; 43 kişi ve 100.000'den fazla kayıt etkilendi; ihlal öncesi sızma testi yapılmamış, sistem takibine dair tarama raporu sunulmamış	3.3 (ortam güvenliği), 3.2 (güvenliğin takibi)	430.000 TL
2022/1375, 23.12.2022	Çalışanın indirdiği programla 797 sunucuya fidye yazılımı; 4.885 kişi etkilendi; dosya sunucusunda sistem şifrelerini içeren bir metin dosyası; destek ömrü bitmiş işletim sistemi; ihlal öncesi sızma testinde 3 Acil, 2 Kritik, 2 Yüksek, 1 Düşük bulgu, düzeltme kaydı yok	3.1, 3.3, 3.5, 2.5, 2.2	800.000 TL + 200.000 TL = 1.000.000 TL

2024/415'in en öğretici yanı, Kurul'un ceza gerekçesinde uç nokta tespit ve yanıt çözümlerini adıyla anması. Rehber'de "EDR alın" yazan bir satır yok; ama "sistemin düzenli takip ve kontrolünün sağlanması" var ve Kurul bunun pratikte zafiyet taraması, sızma testi ve anomali tespitiyle yapılabileceğini yazıyor. Yani standart sabit bir ürün listesi değil, olayın kendisinden türetilen bir beklenti. Rehber'i ezberleyip ürün almak, bu kararı okumadan yapılan bir yatırım.

Kararın bir başka satırı tek başına yeterince düşündürücü: veri sorumlusu "sızma testi yaptırmadığını" kendisi bildiriyor ve sistemin kontrolünü sağladığını gösterir herhangi bir güvenlik tarama raporunu da gönderemiyor. Cezanın dayanağı bir açığın bulunmuş olması değil, hiçbir testin bulunmaması. Bu ayrım savunma stratejisini belirliyor: "açık yoktu" demek işe yaramıyor, "şu tarihte şu kapsamda test ettirdim, şu bulgular çıktı, şunları kapattım" demek gerekiyor.

Sızma testi yaptırmak kanıt değil: 2022/1375'in asıl dersi

2022/1375 bu yazının en sert bulgusu. Veri sorumlusu ihlalden önce iç sızma testi yaptırmış. Rapor gelmiş. Raporda 3 Acil, 2 Kritik, 2 Yüksek ve 1 Düşük seviyede bulgu var. Sonra ihlal oluyor ve Kurul'un baktığı şey raporun varlığı değil, bulguların kapatıldığına dair belge oluyor. Belge yok. Karar metni bunu "ihlale kadar geçen sürede ve ihlal sonrasında bu eksikliklerin giderildiğine dair bilgi veya belgenin sunulmadığı" diye yazıyor.

Yani test bir kanıt değil, bir başlangıç. Kanıt zinciri dört halka: bulgu, sahip, düzeltme, yeniden test. Halkalardan biri eksikse test yapılmamış sayılıyor. Aynı dosyada daha da çıplak bir ayrıntı var: dosya sunucusunda, çeşitli sistemlere giriş için kullanıcı adı ve şifrelerin bulunduğu bir "şifreler.txt" dosyası. Kurul bunu parola politikasının hazırlanmadığı ve uygulanmadığı sonucuna bağlıyor ve 3.1'e atıf yapıyor.

Üçüncü ayrıntı eğitim tarafında. Veri sorumlusu farkındalık ve bilgi güvenliği eğitimi verdiğini katılımcı listesiyle belgeliyor; Kurul yine de eğitimin uygun ve yeterli olmadığı sonucuna varıyor, çünkü ihlali başlatan şey bir çalışanın internetten indirdiği programı sistem içine kurması. Katılım listesi "eğitim yapıldı"yı gösteriyor, "eğitim işe yaradı"yı göstermiyor. Fark, 2.2'nin istediği şey.

Bu üç ayrıntı birlikte tek bir cümleye iniyor: denetimde belgenin varlığı değil, belgenin sonucu okunuyor.

Ceza aritmetiği: bant, gün ve ikiye katlanma süresi

Rakamları yerine koymak, "uyum pahalı" cümlesini test etmenin en hızlı yolu. Üç hesap yeterli.

Bir: gecikmenin günlük fiyatı. 2022/1375'te ihlal, tespit edildiği tarihten 23 gün sonra Kuruma bildirilmiş; karar bunu 20 günlük gecikme olarak okuyup md.12/5 ihlali için 200.000 TL ceza vermiş. 200.000 / 20 = gün başına 10.000 TL. Aynı dosyada 23 gün, 552 saat demek; 72 saatlik beklenti penceresinin 7,67 katı. Bildirim prosedürünüzdeki her eksik gün bu fiyatla ölçülüyor.

İki: bandın neresinde duruyorsunuz. 2024/415'te 43 kişi ve 100.000'den fazla kayıt için verilen ceza 430.000 TL. 2026 tabanı 256.357 TL olduğuna göre o ceza bugünün tabanının 1,68 katıydı; yani Kurul dosyada ağırlaştırıcı bir şey görmediğinde bile taban artık o seviyede başlıyor.

Üç: bandın kendisi büyüyor. Yeniden değerleme oranı yüzde 25,49. Bu oran sabit kalırsa taban her 3,05 yılda ikiye katlanıyor; üç yılda yüzde 97,6 artışla 256.357 TL yaklaşık 506.600 TL oluyor. Yani ertelemek, cezayı faiziyle beklemek demek: bir yıllık gecikmenin maliyeti almaktan vazgeçtiğiniz tedbirden değil, bandın kendisinden geliyor.

Hesap	Girdi	Sonuç
Gecikmenin günlük bedeli	200.000 TL / 20 gün	10.000 TL/gün
Gecikmenin saat cinsinden büyüklüğü	23 gün = 552 saat; beklenti 72 saat	7,67 kat
2026 bandının genişliği	17.092.242 / 256.357	66,7 kat
2024 cezasının bugünkü tabana oranı	430.000 / 256.357	1,68 kat
Tabanın ikiye katlanma süresi	iki katına çıkma süresi, yıllık yüzde 25,49 artış	3,05 yıl

Şifreleme ve anahtar yönetimi: 10 karakter ne satın alıyor

Tablo 4.1'de şifreleme ile anahtar yönetimi ayrı iki satır. Bu ayrım kasıtlı: şifreleme bir işlem, anahtar yönetimi bir süreç. Diski şifreleyip anahtarı aynı sunucuda saklayan kurum, ilk satırı işaretleyip ikincisini boş bırakmış oluyor; saldırgan veriyi aldığında anahtarı da alıyor.

Kurum'un kullanıcı güvenliğine ilişkin kamuoyu duyurusu bu satırı somut tavsiyelere çeviriyor: iki kademeli doğrulama, yeni cihazdan girişte bildirim, HTTPS, güncel ve güvenli karma algoritması, IP başına başarısız giriş sınırı, kullanıcının son beş giriş denemesini görebilmesi, aynı parolanın birden fazla platformda kullanılmaması, son üç parolanın tekrarının engellenmesi, güvenlik kodu veya IP kısıtı, en az 10 karakter ve büyük-küçük harf, rakam, özel karakter birlikteliği.

"En az 10 karakter" tavsiyesinin arkasındaki matematiği göstermek, politika metnine ikna edici bir gerekçe ekliyor. Aşağıdaki hesap, sızdırılmış bir parola özetinin çevrimdışı kırılması varsayımıyla, saniyede 10 milyar deneme hızında:

Parola yapısı	Arama uzayı	10 milyar deneme/saniye
8 karakter, yalnız küçük harf	26 üzeri 8 = 2,09 x 10^11	21 saniye
8 karakter, harf ve rakam	36 üzeri 8 = 2,82 x 10^12	4,7 dakika
10 karakter, dört karakter sınıfı	72 üzeri 10 = 3,74 x 10^18	11,9 yıl
12 karakter, dört karakter sınıfı	72 üzeri 12 = 1,94 x 10^22	yaklaşık 61.500 yıl

Buradaki ders "uzun parola" değil, üstel fark: 8'den 10'a çıkmak arama uzayını yaklaşık 1.300 kat büyütüyor. Aynı hesap, parolanın özetlenmesinde yavaş bir algoritma kullanıldığında (bcrypt, argon2 gibi) sabit çarpanı milyonlarca kat değiştiriyor. Yani iki değişken var: uzunluk ve özet fonksiyonunun hızı. Kurum'un duyurusu ikisini de istiyor.

Anahtar yönetimi tarafında üç soru yeterli: anahtar nerede duruyor, kimin erişimi var, ne sıklıkla dönüyor. Bu üç soruya yazılı cevap veremeyen bir kurumda şifreleme satırı kısmi sayılmalı; çünkü olay anında "veri şifreliydi" savunması, anahtarın da ele geçip geçmediğine bakılmadan kabul edilmiyor.

Erişim: yetki matrisi kâğıtta değil, dizinde

Rehber 3.1'in cümlesi kısa ve sert: "kişisel veri içeren sistemlere erişimin de sınırlı olması gerekmektedir. Bu kapsamda çalışanlara, yapmakta oldukları iş ve görevler ile yetki ve sorumlulukları için gerekli olduğu ölçüde erişim yetkisi tanınmalı ve kullanıcı adı ve şifre kullanılmak suretiyle ilgili sistemlere erişim sağlanmalıdır." Devamında parola oluşturma kuralı geliyor: kolay tahmin edilecek rakam ya da harf dizileri yerine büyük-küçük harf, rakam ve sembol kombinasyonları.

2022/1375'te bu başlığın altına düşen iki bulgu var. Birincisi, sıradan bir alan kullanıcısının ağdaki birçok paylaşım klasörüne ulaşabilmesi; Kurul bunu "bu hesap ele geçirilirse birçok kişisel veriye rahatça ulaşılır" diye okuyor. İkincisi, saldırganın beş geçerli alan yöneticisi hesabı kullanması ve bunun destek ömrü bitmiş işletim sistemiyle ilişkilendirilmesi.

Yetki matrisi bir tablo değil, bir çıktı. Denetimde işe yarayan şey, dizin servisinden alınmış tarihli üyelik dökümü ile uygulama içi rol listesinin aynı kişileri göstermesi. Üç pratik kural: her kritik sistem için iki isimli sahip, üç ayda bir tarihli erişim gözden geçirmesi ve onaylayanın adı, ayrıcalıklı hesapların sayısının yazılı olması (sayı beş ise beşinin de adı), acil erişim hesaplarının ayrı ve izlenir tutulması.

Log: tutmak ve bakmak iki ayrı tedbir

Tablo 4.1'de "erişim logları" ile "log kayıtları" ayrı iki satır. Bu ayrım, uygulamada en çok yanlış anlaşılan nokta: log altyapısı kurmak bir satır, o altyapıya düzenli bakmak diğer satır. Rehber 3.2 ikincisini açıkça istiyor.

"Veri sorumlularının sistemleri çoğunlukla hem içeriden hem de dışarıdan gelen saldırılar ve siber suçlara veya kötü amaçlı yazılımlara maruz kalmakta olup çeşitli belirtilere rağmen bu durum uzun süre fark edilememekte ve müdahale için geç kalınabilmektedir. Bu durumun önüne geçebilmek için; bilişim ağlarında hangi yazılım ve servislerin çalıştığının kontrol edilmesi, bu yazılım ve servislerin güncel tutulması, tüm kullanıcıların işlem hareketleri kaydının düzenli olarak tutulması (log kayıtları gibi), güvenlik sorunlarının mümkün olduğunca hızlı bir şekilde raporlanması, çalışanların kişisel veri güvenliği konusunda farkındalığının artırılması ve resmi bir raporlama prosedürü oluşturulması gerekmektedir."

Bu paragrafta üç ayrı iş var: kaydetmek, raporlamak, prosedürü yazmak. Üçü de aynı cümlede olduğu için tek bir ürünle kapatılabileceği sanılıyor; kapanmıyor. Kaydetmek lisans ve disk meselesi, raporlamak kural yazma meselesi, prosedür ise "kim kimi ne zaman arıyor" meselesi.

2024/415'te Kurul'un aradığı belge tam olarak buydu: sistemin takip ve kontrolünün sağlandığına dair raporlar. Veri sorumlusu bunları sunamadı. Yani ihlalin büyüklüğü kadar, ihlali görüp görmediğiniz de cezanın gerekçesine giriyor.

Saklama süresi konusunda dürüst olmak gerekiyor: md.12 için kanunda sabit bir süre yazmıyor, Rehber de sayı vermiyor. Sektörel mevzuatta (elektronik haberleşme gibi) ayrı süreler var ama genel bir KVKK süresi yok. Bu yüzden süre, cevaplamanız gereken sorudan geriye hesaplanır: bir ihlal ortalama ne kadar süre fark edilmeden kalıyor, soruşturma ne kadar sürüyor, bildirim penceresi ne kadar. Aşağıdaki tablo bu mantıkla kurulmuş bir alt sınırdır, kanun hükmü değil:

Log türü	Neyi cevaplıyor	Önerilen alt sınır	Kim bakar
Kimlik doğrulama (başarılı ve başarısız)	Hangi hesap, nereden, ne zaman	12 ay	BT güvenlik, aylık
Yetki ve grup değişiklikleri	Kim ne zaman ayrıcalık kazandı	24 ay	BT güvenlik, çeyreklik
Uygulama düzeyinde veri erişimi	Hangi kayıt, hangi kullanıcı tarafından açıldı	12 ay	Veri sorumlusu, çeyreklik
Güvenlik cihazları (güvenlik duvarı, IPS, uç nokta)	Hangi trafik engellendi, hangi alarm çıktı	12 ay	BT güvenlik, haftalık alarm incelemesi
Yedekleme ve geri dönme işlemleri	Hangi yedek ne zaman alındı, geri döndü mü	12 ay	Sistem yöneticisi, aylık

Sürelerin yanına iki şey daha yazılmalı: logun bütünlüğü ve logun saati. Bütünlük için yaygın çözüm, logu yazıldıktan sonra değiştirilemeyen bir ortama (WORM) veya ayrı bir hesaba göndermek. Rehber'in istediği şey kaydın tutulması ve düzenli kontrolü; değiştirilemezlik ifadesi Rehber'de geçmiyor, tedarikçi metinlerinde geçiyor. Yine de pratikte en ucuz savunma bu: olay sonrası "bu kayıt sonradan üretilmedi" itirazını tek hamlede kapatıyor. Saat konusu ise daha sinsi; tüm cihazların aynı zaman kaynağına bağlı olmaması, olay yeniden kurgulanırken sıralamayı bozuyor.

Ağ: segmentasyon bir ürün değil, bir karar

Rehber 3.3'ün cümlesi teknik ama net: "Kişisel veriler elektronik ortamda ise, kişisel veri güvenliği ihlalini önlemek için ağ bileşenleri arasında erişim sınırlandırılabilir veya bileşenlerin ayrılması sağlanabilir." Devamında ağın izlenmesi, yetkisiz erişimin tespiti ve kayıt altına alınması geliyor.

2024/415 bu başlığın nasıl bir olaya dönüştüğünü gösteriyor: Fransa'daki ortak sunucularda başlayan fidye yazılımı, kiralık bir Metro Ethernet hattı üzerinden Türkiye'deki sekiz sunucuya yayılmış. Kiralık bir katman-2 hattın iki ucu aynı yayın alanı gibi davrandığında, on bin kilometre uzaktaki bir sunucu ofisteki bir sunucu kadar yakın oluyor. Segmentasyonun önleyeceği tam olarak buydu.

2022/1375'te aynı eksiklik daha kaba biçimde görünüyor: 797 sunucunun tamamına yayılan bir fidye yazılımı, bir çalışanın indirdiği tek programla başlıyor. Düz bir ağda yayılma hızını belirleyen şey savunma değil, en zayıf makinenin açık kalma süresi.

Segmentasyon bir cihaz alımı değil, bir akış kararı: hangi sistem hangi sisteme, hangi porttan, hangi protokolle konuşacak. Bu karar kâğıda dökülmediğinde herkes her yere erişir, çünkü kimse hayır demediği için. Denetimde istenen kanıt da bu yüzden kural seti değil, akış matrisi: kaynak, hedef, port, gerekçe, onaylayan. Yanına bir de test: segmentler arasında yapılması gereken bir bağlantının gerçekten çalıştığı, yapılmaması gerekenin gerçekten engellendiği gösterilmedikçe matris bir niyet beyanı olarak kalıyor.

Bulut: 3.4'ün sorduğu üç soru

Rehber'in 2025 basımında ayrı bir başlık olan "kişisel verilerin bulutta depolanması", üç soruya indirgenebilir: veri hangi ülkede duruyor, anahtarı kim tutuyor, log kimin elinde.

Bölge. Veri yurt dışındaki bir bölgede duruyorsa md.9'un aktarım rejimi devreye giriyor; bu bir teknik ayar değil, hukuki bir işlem. Bölge ayarını kimin değiştirebildiği de aynı sorunun parçası: proje yöneticisinin tek tıkla bölge değiştirebildiği bir ortamda, aktarım kararı verilmemiş oluyor.

Anahtar. Sağlayıcının anahtar yönettiği modelde şifreleme sizin kontrolünüzde değil; kendi anahtarınızı getirdiğiniz modelde ise anahtarı kaybetmek veriyi kaybetmek demek. İkisinin de yazılı bir sahibi olmalı.

Log. Bulut sağlayıcısının erişim loglarını size verip vermediği, ihlal anında hangi kaydı görebileceğinizi belirliyor. 2024/415'te veri, ortaklardan biri tarafından depolanıyor ve yönetiliyordu; ihlal bu ortak ortamdan çıktı. Veri işleyenin ortamında tutulan veri, sizin denetim hakkınız yoksa sizin kontrolünüzde sayılmıyor.

Bu üç soruyu sözleşmeye yazmak, denetimde teknik ekibe en çok zaman kazandıran iş: bölge, anahtar sahipliği, log paylaşımı ve alt işleyen bildirimi maddeleri sözleşmede varsa, ihlal anında cevap vermek yerine maddeyi göstermek yeterli oluyor.

Tedarik ve bakım: 3.5'in tek cümlesi

Rehber'in bu başlıktaki cümlesi kısa: "Veri sorumlusu tarafından yeni sistemlerin tedariki, geliştirilmesi veya mevcut sistemlerin iyileştirilmesi ile ilgili ihtiyaçlar belirlenirken güvenlik gereksinimleri göz önüne alınmalıdır." Yani güvenlik, satın alma kararından sonra eklenen bir katman değil; ihtiyaç tanımının içinde olması gereken bir madde.

2022/1375'te bu başlığın altında iki bulgu var: destek ömrü sona ermiş bir işletim sisteminin hâlâ kullanımda olması ve sistemlerin güncel yamalarının uygulanmaması. Kurul bu ikisini "gerekli teknik tedbirlerin alınmadığı" sonucuna bağlıyor. Buradaki mesele bir bilgi eksikliği değil; çoğu kurum hangi işletim sisteminin ne zaman destek dışı kalacağını bilir, sadece takvimi kimse takip etmez.

Pratik çözüm bir envanter sütunu: her varlık için destek bitiş tarihi. Bu tarih bir yıl içindeyse bütçe planına, altı ay içindeyse değişim planına giriyor. İkinci çözüm, tedarik şartnamesine yazılan üç madde: destek ömrü taahhüdü, yama yayınlama süresi taahhüdü (kritik yamalar için gün sayısı), güvenlik açığı bildirim yükümlülüğü.

Yedekleme ve imha: iki uç, aynı dosya

Rehber 3.6 yedeklemeyi ayrı bir başlık olarak ele alıyor; Tablo 4.1'in son satırı ise silme, yok etme veya anonim hale getirmeyi istiyor. İkisi aynı dosyanın iki ucu: verinin bir kopyası yedekte dururken diğer kopyası imha edilmişse, imha tamamlanmış sayılmıyor.

Yedekleme tarafında denetimde en çok işe yarayan belge, yedeğin alındığını gösteren rapor değil, geri dönme testinin tutanağı. Üç şeyi yazması gerekiyor: hangi veri seti, ne kadar sürede geri döndü, kim doğruladı. Ölçülmemiş bir geri dönme süresi, olay anında ilk kez öğrenilen bir süre oluyor.

İkinci nokta şifreleme: yedek, şifrelenmemişse şifreleme tedbiri yarım kalıyor. Fidye yazılımı olaylarında saldırganın ilk hedeflerinden biri yedek sunucusu; yedeğin çevrimdışı veya değiştirilemez bir kopyası yoksa, geri dönme planı da yok.

İmha tarafında md.7 ve ilgili yönetmelik devreye giriyor: silme, yok etme veya anonim hale getirme işleminin periyodik olarak yapılması ve tutanağa bağlanması. Tutanakta tarih, veri kategorisi, yöntem ve uygulayan kişi olmalı. Bu, denetimde en hızlı kontrol edilen belge; çünkü ya vardır ya yoktur ve içindeki tarihler envanterdeki saklama süreleriyle karşılaştırılabilir.

Eğitim: katılım listesi kanıt değil

2022/1375'in eğitimle ilgili bulgusu, bu yazının en çok tekrarlanması gereken kısmı: katılımcı listesi vardı, eğitim yine de yetersiz bulundu. Sebep basit; ihlali başlatan eylem bir çalışanın internetten indirdiği programı kurmasıydı.

Rehber 2.2'nin istediği şey de bu: çalışanın, sınırlı bilgisi olsa dahi ilk müdahaleyi yapabilmesi. Yani eğitimin çıktısı bilgi değil, davranış. Davranışı ölçmenin iki yolu var: oltalama simülasyonunda tıklama oranının zaman içindeki eğrisi ve çalışanların şüpheli e-postayı bildirme oranı. İkincisi daha değerli, çünkü bildirim oranı yükselirken tıklama oranı düşüyorsa eğitim gerçekten işliyor demektir.

Bunun için yazılı bir bildirim prosedürü gerekiyor: kime, hangi kanaldan, ne kadar sürede bildirilecek, bildirimden sonra ne olacak. Prosedür yoksa çalışan şüphelendiği e-postayı yöneticisine sözlü olarak söylüyor ve kayıt oluşmuyor. Oltalama farkındalığının nasıl kurulacağını oltalama farkındalık eğitimi programı yazısında adım adım anlattım; buradaki ölçü sadece çıktının belgelenmesi.

Veri işleyenler: 2.5, sizin tavanınız onların tabanı

Rehber 2.5'in cümlesi, tedarik ilişkisini bir uyum meselesine çeviriyor: "Veri sorumlularının, hizmet alırken söz konusu veri işleyenlerin kişisel veriler konusunda en az kendileri tarafından sağlanan güvenlik seviyesinin sağlandığından emin olmaları gerekmektedir. Zira Kanunun 12 nci maddesinin ikinci fıkrası gereği veri işleyenler de kişisel verilerin güvenliğinin sağlanması konusunda veri sorumlusuyla müştereken sorumludur." Devamında denetim hakkı geliyor: veri sorumlusu sistemi denetler veya denetim yaptırır, raporları inceler, hizmet sağlayıcıyı yerinde inceleyebilir. Bu denetim hakkının sözleşmede hangi maddeye karşılık geldiği ve tedarikçinin hangi puanla birinci kademeye alındığı ayrı bir dosya gerektiriyor: tedarik zinciri güvenliği ve tedarikçi riski rehberi.

2024/415 bu maddenin ne kadar somut olduğunu gösteriyor: ihlal, verinin ortaklardan biri tarafından depolandığı ve yönetildiği ortamda başladı. Sizin veriniz başkasının ortamındaysa, o ortamın güvenlik seviyesi sizin seviyeniz sayılıyor.

Sözleşmeye yazılması gereken altı madde: ihlal halinde bildirim süresi (saat cinsinden, 24 saat gibi), alt işleyen kullanımı için ön onay, erişim ve güvenlik loglarının paylaşımı, denetim ve sızma testi hakkı, iş bitiminde verinin iadesi ve imhası, uygulanacak teknik tedbirlerin asgari listesi. Bu altı madde yoksa md.12/2 pratikte sadece kâğıt üzerinde kalıyor; çünkü sorumluluk müşterek ama bilgi sizde değil.

Hangi tedbir önce: risk değil, kanıt maliyeti

Rehber'in ilk idari başlığı (2.1) risk ve tehditlerin belirlenmesi. Doğru sıra da buradan çıkıyor ama tek başına risk puanı yetmiyor; sıralamayı iki eksende yapmak gerekiyor: ceza riski (bu tedbir eksikse hangi bantla karşılaşırım) ve kanıt maliyeti (bu tedbiri belgelemek kaç adam-gün sürer). En kötü oran, ucuz kanıtı olan yüksek ceza riskli tedbirlerde çıkıyor ve bunların çoğu lisans gerektirmiyor.

Dönem	İş	Bölüm	Çıktı
0-30 gün	Varlık ve veri envanteri, ayrıcalıklı hesap sayımı, çok faktörlü doğrulamanın yönetici hesaplarına açılması, logların tek noktada toplanması, yedekten geri dönme testi	2.1, 3.1, 3.2, 3.6	Envanter dosyası, hesap listesi, MFA kapsam raporu, test tutanağı
30-60 gün	Yetki matrisi ile dizin dökümünün karşılaştırılması, segment akış matrisi, destek ömrü envanteri, tedarik şartnamesine güvenlik maddeleri, veri işleyen sözleşme ekleri	3.1, 3.3, 3.5, 2.5	Tarihli gözden geçirme, akış matrisi, EOL listesi, sözleşme ekleri
60-90 gün	Sızma testi ve bulgu kapatma kaydı, oltalama simülasyonu, imha tutanağı, ihlal müdahale tatbikatı	3.4, 2.2, 4.1	Test raporu ve düzeltme kaydı, simülasyon eğrisi, tutanak, tatbikat notu

Bu sıralamanın mantığı şu: ilk otuz günde satın alınacak hiçbir şey yok, sadece sayım ve ayar var. Sızma testi en pahalı kalem ve en sona bırakılması tesadüf değil; çünkü test, kapatılacak bulguların sahibi belirlendikten sonra anlamlı. Sahipsiz bir test raporu, 2022/1375'te olduğu gibi, cezayı azaltmıyor.

Denetimde masaya koyacağınız dosya: 17 satır

Aşağıdaki tablo, Tablo 4.1'deki 17 teknik tedbirin her birini tek bir kanıtla eşleştiriyor. Sağdaki sütun "bu tedbir var" demenin en kısa yolu; denetimde istenen de bu.

#	Tedbir	Kanıt
1	Yetki matrisi	Rol-veri eşlemesi tablosu, onaylı ve tarihli
2	Yetki kontrol	Dizin grubu dökümü ile uygulama rol listesinin karşılaştırması
3	Erişim logları	Kim, nereden, ne zaman sorusunu cevaplayan kayıt örneği
4	Kullanıcı hesap yönetimi	İşe giriş-çıkış akışı, ayrılan hesabın kapatıldığına dair kayıt
5	Ağ güvenliği	Segment şeması ve akış matrisi
6	Uygulama güvenliği	Geliştirme ortamının ayrıldığına dair mimari not, kod inceleme kaydı
7	Şifreleme	Disk, yedek ve aktarım şifrelemesinin açık olduğunu gösteren ayar dökümü
8	Sızma testi	Rapor, bulgu listesi, düzeltme kaydı, yeniden test sonucu
9	Saldırı tespit ve önleme	Alarm kuralı listesi ve son dönemde kapatılan alarmlar
10	Log kayıtları	Merkezi log kaynağı, saklama süresi ayarı, okuma tutanağı
11	Veri maskeleme	Test ve analitik ortamda maskelenmiş alan örneği
12	Veri kaybı önleme	Kural seti ve engellenen olay örnekleri
13	Yedekleme	Geri dönme testi tutanağı ve ölçülen süre
14	Güvenlik duvarı	Kural seti sürümü ve gözden geçirme tarihi
15	Güncel anti virüs	Kapsam raporu: kaç uç nokta, kaçı güncel
16	Silme, yok etme, anonimleştirme	Periyodik imha tutanağı ve envanterdeki saklama süresiyle karşılaştırma
17	Anahtar yönetimi	Anahtarın tutulduğu yer, erişim listesi, dönüşüm takvimi

Bu 17 satırın üstüne altı belge koyduğunuzda dosya tamamlanıyor: veri envanteri, risk analizi, politika seti, yetki matrisi, test ve denetim raporları, ihlal bildirim prosedürü ve bildirim kayıtları. Hepsinin ortak özelliği aynı: tarih, sahip, sonuç. Üçü yoksa belge de yok sayılıyor.

Kapanış: Rehber'i ezberlemek yerine bir kez çevirmek

17 satırı kendi ortamınıza çevirmek yarım gün sürüyor. Karşılığında elinizde, dört ayrı politika klasöründen daha işlevsel bir şey oluyor: hangi tedbirin var olduğunu, hangisinin kısmi olduğunu ve her birinin hangi belgeyle kanıtlandığını gösteren tek sayfa. Kurul'un kararları da tam olarak bunu arıyor; 2022/1375'te bir sızma testi raporu varken ceza gelmesinin sebebi, dosyada o tek sayfanın olmamasıydı.

İhlal anında bu dosyanın ikinci yarısı devreye giriyor. Bildirim saatini doğru başlatmak, hangi verinin etkilendiğini envanterden okumak ve 72 saatlik pencereyi kaçırmamak için önceden yazılmış bir plan gerekiyor; o planın adımlarını siber olay müdahale planı rehberi yazısında saat saat ayırdım. Bir ihlalin nasıl başladığını ve ilk saatte ne yapılacağını ise ele geçirilmiş e-posta hesabı yazısında anlattım.

Kendi ortamınızda 17 satırın hangisinin kısmi olduğunu bilmiyorsanız, sızma testi ve olay müdahale hazırlığı için sızma testi hizmeti ve dijital adli inceleme kapsamlarımıza bakabilir, dosyayı birlikte kurmak için bize yazabilirsiniz.