Etik Hacker Nasıl Tutulur? Kapsam, Yetki ve Sözleşme Rehberi

Etik hacker tutmak, çoğu kurumda "iyi bir firma bulalım" olarak başlıyor ve tam olarak bu yüzden bütçe çöpe gidiyor. Satın aldığınız şey bir firma değil, iki belge: imzalı bir yetkilendirme ve savunulabilir bir rapor. Firmayı bu iki belgeyi üretebilenler arasından seçersiniz; tersi sırada gidince, seçtiğiniz firmanın metodolojisine göre kapsamı yeniden yazmak zorunda kalırsınız.

Bu rehber satın alma tarafındaki soruyu cevaplıyor: kapsamı kim yazar, yazılı izni kim imzalar, teklifi neye çevirip karşılaştırırsınız, raporda neyi arayacaksınız, sözleşmede hangi on iki madde olmadan teste başlanmaz, ve Türkiye'de hangi düzenleme hangi sektörde bu işi zorunlu kılıyor. Ürün ya da sağlayıcı sıralaması yok; çünkü bir sızma testinin değeri araçtan değil, kapsam kararından ve kanıt standardından geliyor.

Baştan bir uyarı: bu sayfa hiçbir firmayı "en iyi" olarak sunmuyor ve hiçbir sıralama garantisi vermiyor. Verdiği şey, iki teklifi aynı ölçeğe indirip karşılaştırmanızı sağlayan aritmetik ve sözleşmede eksik olduğunda başınıza iş açacak maddeler.

Önce kapsam, sonra firma: ters sırada yapılan hata

Kapsam yazılmadan teklif istendiğinde, her firma kendi kapsamını icat ediyor. Gelen üç teklif aslında üç farklı işi fiyatlıyor; karşılaştırma fiyat üzerinden yapılıyor ve kazanan genellikle en dar kapsamı en düşük rakama yazan oluyor. Bu yüzden ilk adım, test edilecek varlıkların listesi ve her varlık için hangi standardın geçerli olduğu.

Varlık sınıfı, standardı ve süreyi belirliyor. Aşağıdaki tablo, hangi işin hangi standarda dayandığını ve neyi kapsamadığını gösteriyor. "Neyi kapsamıyor" kolonu en az diğerleri kadar önemli: kapsam dışı kalan her yüzey, raporda görünmediği için yok sayılıyor.

İş türü	Dayandığı standart	Tipik süre	Neyi kapsamıyor
Web uygulaması testi	OWASP WSTG	5-8 gün	Mobil istemci, iç ağ, sosyal mühendislik
API güvenlik testi	OWASP API Security Top 10	3-6 gün	Arayüzde görünmeyen iş akışları, üçüncü taraf entegrasyonlar
Mobil uygulama testi	OWASP MASVS / MASTG	6-15 gün	Sunucu tarafı testin kendisi, mağaza hesabı güvenliği
Dış ağ testi	PTES, NIST SP 800-115	3-5 gün	İç ağ, kimlik doğrulamalı zafiyetler, uygulama mantığı
İç ağ testi	PTES, MITRE ATT&CK	5-10 gün	Fiziksel erişim, tedarikçi ağları
Active Directory değerlendirmesi	MITRE ATT&CK, Microsoft tier modeli	4-8 gün	Bulut kimlik sağlayıcısı, uç nokta tespit olgunluğu
Kablosuz ağ denetimi	IEEE 802.11 test pratiği	2-4 gün	Kablolu ağ, misafir ağı politikası, fiziksel yerleşim
Red team tatbikatı	MITRE ATT&CK, TIBER benzeri çerçeve	15-40 gün	Kapsamlı zafiyet envanteri; amaç tespit ve müdahale ölçümü
Oltalama simülasyonu	Farkındalık programı çerçevesi	1-2 gün kurulum	Teknik sızma; sonuç eğitim verisi, güvenlik açığı değil

Tablo bir menü değil, bir karar ağacı. Sorulacak ilk soru "neyi test ettirmek istiyorum" değil, "hangi kararı vereceğim". Bir ödeme akışını yayına almadan önceki karar web ve API testidir; mevcut bir olayın nasıl fark edilmediğini öğrenme kararı red team tatbikatıdır. İkisi aynı bütçe kalemi değil, aynı takvimde de yapılmaz. Red team tatbikatının kapsam ve ölçüm mantığı ayrı bir rehber konusu; burada yalnızca karar ayrımını not ediyoruz: red team değerlendirmesinde ölçüm protokolü.

Yetki: yazılı izni kim imzalar

Türkiye'de sızma testini yasal yapan şey sözleşmenin varlığı değil, sözleşmeyi imzalayan kişinin o sistemi test ettirme yetkisine sahip olması. 5237 sayılı TCK'nın 243. maddesi bilişim sistemine hukuka aykırı girişi suç olarak tanımlıyor: temel fiil bir yıla kadar hapis veya adli para cezası; giriş sonucunda verilerin yok olması veya değişmesi hâlinde ceza altı aydan iki yıla kadar hapse çıkıyor. Hukuk literatüründe ve uygulamada yerleşik olan nokta şu: iyi niyet, "zarar vermedim", "açığı bildirdim" savunmaları fiili hukuka uygun hâle getirmiyor. Ayrımı yapan tek şey, sistem sahibinin önceden verdiği ve kapsamı belirlenmiş yazılı izin.

Buradan çıkan pratik sonuç, izin belgesinin bir formalite olmadığı. İmza yetkisi olmayan birinin imzaladığı belge, test sırasında ortaya çıkan bir uyuşmazlıkta sizi korumuyor. Aşağıdaki tablo, kimden imza alınması gerektiğini varlık türüne göre ayırıyor.

Test edilecek varlık	İmza yetkisi kimde	Yanlış imzada ne olur
Kuruma ait kendi sunucu ve uygulamaları	Şirket tüzel kişiliği adına imza yetkili yönetici	Yetki devri belgesi yoksa izin tartışmalı hâle gelir
Bağlı ortaklık veya iştirak sistemleri	O tüzel kişiliğin yetkilisi	Ana şirketin izni kardeş şirketi kapsamaz
Müşteri verisi işleyen SaaS kiracısı	Kiracı kurum + sağlayıcı sözleşmesindeki test maddesi	Sağlayıcı sözleşmesi testi yasaklıyorsa izin ihlal olur
Bulut altyapısı (IaaS)	Kurum + sağlayıcının test politikasına uyum	Sağlayıcı politikası ihlali hesabın kapatılmasına yol açar
Tedarikçinin ürünü	Tedarikçi yazılı onayı	Kurumun satın alma sözleşmesi test hakkı vermez
Bağlı çalışanın kendi cihazı	Çalışanın yazılı rızası + kurum politikası	Kişisel cihazda test, kişisel veri işleme sorunudur
Alan adı ve DNS	Alan adı sahibi kayıt sahibi	Alt alan adı sahibi ana alan adını kapsamaz

İkinci katman, izin belgesinin içeriği. Belgede hangi sistemlerin test edileceği, hangi tekniklerin kullanılabileceği, testin tarih ve saat aralığı, veriye erişim hâlinde ne yapılacağı ve raporun kime teslim edileceği yazılı olmalı. Kapsam dışına çıkan her işlem artık sözleşme değil ceza hukuku konusudur; bu yüzden belgede "kapsam dışı" listesi, kapsam listesi kadar açık olmak zorunda. Sözlü onay, e-posta ile "tamam" demek, ya da toplantı notunda geçen bir cümle, sonradan doğan bir uyuşmazlıkta ispat aracı olarak zayıf kalıyor.

Yetkilendirme belgesinin bir kopyası test ekibinde, bir kopyası kurumun hukuk biriminde olmalı ve test penceresi boyunca erişilebilir olmalı. Test sırasında bir sistem yöneticisi ya da barındırma sağlayıcısı "bu trafik nedir" diye sorduğunda gösterilecek belge budur; o an belgeyi aramak, testin durması demek.

Angajman kuralları: on iki alan

Angajman kuralları (rules of engagement), testin nasıl yapılacağını değil, neyin yapılmayacağını tanımlayan belge. Türkçe satın alma pratiğinde en sık atlanan belge bu, çünkü teklif aşamasında kimse "yasaklar listesi" yazmak istemiyor. Atlanınca ne olduğu öngörülebilir: testin ilk günü iki taraf farklı varsayımlarla başlıyor, üretim veritabanına dokunuluyor, ya da tam tersi, testin en değerli kısmı "kapsam dışı" sayılıp yapılmıyor.

#	Alan	Neyi karara bağlar	Varsayılan öneri
1	Taraflar ve imza yetkisi	Kim izin veriyor, kim test ediyor	Yetki belgesi ekinde imzalı
2	Kapsam listesi	IP, alan adı, uygulama, API, hesap türleri	Varlık listesi ek olarak
3	Kapsam dışı listesi	Dokunulmayacak sistemler	Üretim veritabanı, ödeme geçidi, üçüncü taraf
4	İzinli teknikler	Neyin denenebileceği	Manuel test + doğrulanmış otomasyon
5	Yasak işlemler	Hizmet kesintisi riski taşıyan fiiller	Yük testi, DoS, yıkıcı yazma işlemleri yasak
6	Test penceresi	Tarih, saat, kara liste zamanı	İş saatleri dışı, yazılı onayla genişletme
7	Veri çekme sınırı	Ne kadar veri kanıt olarak alınabilir	Kayıt başına en fazla 10 satır, maskelenmiş
8	Durdurma koşulları	Testi kim, hangi durumda durdurur	Kritik bulgu veya kesinti hâlinde anında
9	Acil iletişim	Yedi gün yirmi dört saat ulaşılacak kişi	İki isim, iki telefon, iki taraf
10	Kimlik bilgisi yönetimi	Test hesapları, parola devri, kapatma	Test sonunda parola sıfırlama zorunlu
11	Kanıt saklama	Ekran görüntüsü ve kayıtların yeri ve süresi	Şifreli, 90 gün, sonra imha
12	Bildirim yükümlülüğü	Kritik bulgunun ne kadar sürede bildirileceği	Rapor teslimini beklemeden 4 saat içinde

Dördüncü ve beşinci alan birlikte okunmalı. "Manuel test" ifadesi tek başına bir taahhüt değil; hangi tekniklerin izinli olduğu yazılmadığında, test eden kişi sertifika sabitleme atlatmak, zayıf parola denemek veya sosyal mühendislik yapmak gibi kararları kendi takdirine göre veriyor. Bu kararların bazıları sözleşmenin diğer maddeleriyle çelişebiliyor: zayıf parola denemesi hesap kilitleme politikasını tetikler, sosyal mühendislik testi çalışanların kişisel verisini işler. Altıncı alan da sadece takvim değil, bir kara liste penceresi: yedekleme, ay sonu kapanışı ve denetim dönemleri test dışı tutulmazsa, test sırasında oluşan bir yavaşlama güvenlik olayı gibi görünür ve olay müdahale ekibi boşa çalışır. Olay müdahale tarafındaki hazırlık ayrı bir rehberde: siber olay müdahale planı hazırlama rehberi.

Bulut, barındırma ve üçüncü taraflar

Kendi sunucunuzda çalışan bir uygulamayı test etmek için tek izin yeterli; bulutta çalışan bir uygulama için yetmiyor. Altyapı sağlayıcısının kabul edilebilir kullanım politikası, izin verilmeyen testleri tanımlıyor ve kurumun izni o politikayı geçersiz kılmıyor. Bu, satın alma aşamasında sorulması gereken somut bir soru: test edilecek her varlık için, altyapı sağlayıcısının test politikası okundu mu, ve test kapsamı o politikayla uyumlu mu.

Pratik ayrım şu: kiracı olduğunuz katmanı test edebilirsiniz, sağlayıcının altyapısını test edemezsiniz. Uygulamanızın kiracı yapılandırması, kimlik doğrulama akışı, yetkilendirme mantığı ve veri erişim kuralları sizin sorumluluğunuzda; hipervizör, yönetim düzlemi ve sağlayıcının kendi API'leri değil. Karıştırıldığında iki şey birden oluyor: test kapsamı sağlayıcının politikasını ihlal ediyor, ve raporda sizin düzeltemeyeceğiniz bulgular birikiyor.

Senaryo	Ek izin gerekir mi	Gerekçe
Kendi hesabınızdaki sanal sunucu	Hayır, sağlayıcı politikasına uyum yeterli	Kiracı katmanı sizin sorumluluğunuzda
Sağlayıcının yönetim API'si	Evet, yazılı izin	Kiracı katmanının dışında
Müşterinizin barındırdığı uygulama	Evet, müşteriden	Sistem sahibi müşteri
Ortak kullanılan yük dengeleyici	Evet, sağlayıcıdan	Diğer kiracıları etkiler
CDN ve WAF arkasındaki uygulama	Kaynağa doğrudan test için ayrıca izin	Kenar katmanı testi kaynak testi sayılmaz
Üçüncü taraf ödeme entegrasyonu	Evet, sağlayıcıdan	Kart verisi sağlayıcının kapsamında

Tedarikçi tarafındaki risk yönetimi, sızma testi satın almanın en sık gözden kaçan gerekçesi. Kendi uygulamanız test edilmiş olsa bile, entegre olduğunuz tedarikçideki bir yetki hatası sizin verinize erişim demek. Bu yüzden kapsam yazılırken "hangi tedarikçiler bizim verimize erişiyor" listesi, test edilecek varlık listesinin yanına konmalı; tedarikçi tarafındaki değerlendirme çerçevesi ayrı bir sayfada: tedarik zinciri siber güvenlik ve tedarikçi risk rehberi.

Teklifi saate ve uç noktaya çevirmek

Üç teklif geldiğinde ilk bakılan rakam toplam tutar oluyor, oysa toplam tutar karşılaştırılabilir tek rakam değil. Karşılaştırılabilir hâle getirmenin yolu, her teklifi aynı iki ölçeğe indirmek: beyan edilen gün sayısından çıkan saat, ve kapsamdaki uç nokta sayısı. Beyan edilen gün sayısı bir taahhüt değil, bir plan; ama planla fiyat arasındaki oran, teklifin ne kadar gerçekçi olduğunu gösteriyor.

Aşağıdaki örnek, aynı kapsam için üç teklifi (kurgusal rakamlar, aynı 100 uç nokta) bu ölçeklere indiriyor. Net çalışma saati varsayımı gün başına 6,5 saat; toplantı, raporlama ve idari süre düşüldükten sonra kalan süre.

Teklif	Toplam	Beyan edilen gün	Net saat (6,5 × gün)	TL / saat	TL / uç nokta	Uç nokta / gün	Fiilî dakika / uç nokta
A	180.000 TL	8	52	3.462	1.800	12,5	31,2
B	240.000 TL	12	78	3.077	2.400	8,3	46,8
C	320.000 TL	15	97,5	3.282	3.200	6,7	58,5

Tablo tek başına hangisinin doğru olduğunu söylemiyor, ama bir şeyi söylüyor: en pahalı teklifin saat ücreti en yüksek değil. C, A'dan yüzde 78 daha pahalı; saat başına ise yalnızca yüzde 5 daha pahalı. Fark, saat ücretinde değil, ayrılan saatte. Bu yüzden "bizim saat ücretimiz şu" cümlesi bir teklifi diğerinden ayırmıyor; ayıran şey o saat ücretiyle kaç saat satın aldığınız.

İkinci ölçek, uç nokta başına ayrılan süre, teklifin iç tutarlılığını sınıyor. Manuel bir testte bir uç nokta için harcanan gerçekçi süre 20-30 dakika bandında; oturum, rol ve yetki matrisi karmaşıklaştıkça bu süre artıyor. Yüz uç nokta için 30 dakikalık varsayımla gereken süre 50 saat, yani 6,5 saatlik günlerde 7,7 iş günü. Buna göre 8 günlük bir teklif bu varsayımla tutarlı. Dört günlük bir teklif ise aynı kapsamda uç nokta başına 15,6 dakika bırakıyor; bu süre elle doğrulama için değil, tarama çıktısını gözden geçirmek için yeterli. Teklif "manuel test" diyorsa ve aritmetik 15 dakika diyorsa, teklif kendi içinde çelişiyor.

Gün sayısı ile uç nokta sayısı çelişiyor mu

Bu kontrolü satın alma masasında yapmak için güvenlik uzmanı olmak gerekmiyor; dört işlem yeterli. Kapsamdaki uç nokta sayısını, teklifin beyan ettiği gün sayısına bölün. Çıkan sayı 15'in üzerindeyse test büyük olasılıkla otomasyon ağırlıklı; 8'in altındaysa saat ücreti yüksek ya da kapsam fazla geniş yazılmış; 8-15 bandı, elle doğrulama ile otomasyonun birlikte kullanıldığı normal aralık.

Aynı kontrolü rol ve oturum sayısı için de yapabilirsiniz. Üç rolün olduğu bir uygulamada her uç nokta üç kez, farklı yetkiyle denenmek zorunda; yani 100 uç nokta ve 3 rol, 300 deneme demek. Teklifte tek rol yazıyorsa ve kapsam listesinde üç rol varsa, iki rolün yetki testi kapsam dışında kalmış oluyor. Yetki hataları, yani bir kullanıcının başka bir kullanıcının nesnesine erişebilmesi, en sık bulunan ve en yüksek etkili sınıf olduğu için bu eksiklik raporun en değerli kısmını siliyor.

Kapsam	Gün	Uç nokta	Rol	Toplam deneme	Deneme / saat
Tek rol, API yok	8	100	1	100	1,9
Üç rol, API yok	8	100	3	300	5,8
Üç rol + 60 API uç noktası	12	160	3	480	6,2

Son kolon, bir saatte kaç deneme yapıldığını gösteriyor ve teklifler arasındaki farkı görünür kılıyor. Aynı gün sayısıyla üç rol eklemek, işi üç katına çıkarıyor; teklif üç rolü kapsadığını söyleyip gün sayısını değiştirmiyorsa ya rolleri yüzeysel test ediyor ya da bir şeyi kapsam dışında bırakmış. Bu soruyu sormak, teklifi veren kişiyi köşeye sıkıştırmak değil; iki tarafın aynı işi konuştuğunu doğrulamak.

Puanlama tablosu: kararı tekrarlanabilir yapmak

Teklifleri karşılaştırırken en sık yapılan şey, her kriteri kafada tartıp bir hisse varmak. His kötü bir karar aracı değil ama tekrarlanabilir değil; aynı teklifleri iki kişi farklı puanlıyor ve toplantıda tartışma kriterlere değil kişilere dönüyor. Ağırlıklı bir tablo bu tartışmayı bitiriyor, çünkü karar toplanabilir hâle geliyor.

Aşağıdaki ağırlıklar toplamı 100. Her kriteri 1-5 arasında puanlayıp ağırlıkla çarpıyorsunuz; kriter sayısı dokuz, toplam ağırlık 100 olduğu için sonuç doğrudan 100 üzerinden bir sayı çıkıyor. Ağırlıklar bir öneri, kuruma göre değiştirilebilir; değiştirilmemesi gereken şey, ağırlıkların toplamının 100 olması ve puanlamanın teklif geldikten sonra değil, teklifler istenmeden önce kararlaştırılması.

Kriter	Ağırlık	5 puan neye benzer
Test eden kişinin kimliği ve yetkinliği	20	İsim ve teknik özgeçmiş yazılı, doğrulanabilir
Manuel test derinliği	18	Bulgular teslimattan önce elle doğrulanmış
Örnek rapor	16	Maskelenmiş gerçek rapor, şablon değil
Kapsam netliği	14	Kapsam dışı listesi de yazılı
Yeniden test	10	Kapsama dahil, tarih taahhütlü
Metodoloji izlenebilirliği	8	Her bulgu standart maddesine bağlı
Kanıt standardı	6	Yeniden üretilebilir istek-yanıt
Kritik bulgu bildirim süresi	4	Raporu beklemeden saatlik bildirim
Sorumluluk ve sigorta	4	Mesleki sorumluluk poliçesi var

Aynı tabloyu iki teklife uygulayınca ne olduğu görülebilir. A teklifi, saat ücreti düşük olduğu için ilk bakışta avantajlı; ama kapsam dışı listesi yok, yeniden test ayrı ücretli, örnek rapor göndermiyor ve test eden kişiyi isimlendirmiyor. B teklifi saat başına daha pahalı, ama bu dört kalemde tam puan alıyor.

Kriter	Ağırlık	A puanı	A katkısı	B puanı	B katkısı
Test eden kişinin kimliği	20	4	16,0	5	20,0
Manuel test derinliği	18	2	7,2	5	18,0
Örnek rapor	16	3	9,6	4	12,8
Kapsam netliği	14	3	8,4	4	11,2
Yeniden test	10	1	2,0	5	10,0
Metodoloji izlenebilirliği	8	3	4,8	4	6,4
Kanıt standardı	6	3	3,6	4	4,8
Kritik bulgu bildirimi	4	3	2,4	4	3,2
Sorumluluk ve sigorta	4	2	1,6	3	2,4
Toplam (ağırlık 100, puan / 5)	100		55,6		88,8

Fark, fiyat farkından çok daha büyük: A'nın toplam tutarı B'nin dörtte üçü, ama puanı üçte ikisi bile değil. Bu tablo bir firmayı "en iyi" ilan etmiyor; yalnızca sizin ağırlıklarınızla, sizin gerekçelerinizle bir sayı üretiyor ve o sayının arkasında durmanızı sağlıyor. Bir teklifi reddetmenin gerekçesi "pahalı" değil, "beş kriterde iki puan aldı" oluyor.

Test eden kişi: sertifika neyi kanıtlar

Tekliflerde sertifika listesi var, ama sertifikalar aynı şeyi kanıtlamıyor. Bazıları uygulamalı sınavla veriliyor ve adayın gerçek bir sistemde bulgu ürettiğini gösteriyor; bazıları çoktan seçmeli bilgi sınavı ve yalnızca terminolojiye hâkimiyeti gösteriyor. İkisini aynı satırda saymak, satın alma kararını bilgi düzeyine göre vermek demek.

Sertifika	Tür	Neyi kanıtlar	Neyi kanıtlamaz
OSCP	Uygulamalı sınav, 24 saat	Sistem ele geçirme pratiği	Uygulama katmanı testi derinliği
OSWE	Uygulamalı sınav	Kaynak kod incelemesi ve web uygulama istismarı	Ağ ve Active Directory
OSEP	Uygulamalı sınav	Kaçınma ve gelişmiş istismar	Raporlama kalitesi
CRTO	Uygulamalı sınav	Red team operasyon pratiği	Uyum denetimi kanıtı
CEH	Bilgi sınavı	Terminoloji ve araç bilgisi	Elle bulgu üretme yetkinliği
CISSP	Bilgi sınavı + deneyim	Yönetişim ve program bilgisi	Teknik test derinliği
Sektör onayı (TSE, CREST benzeri)	Kurumsal akreditasyon	Kurumun süreç olgunluğu	Sizin sisteminizi test eden kişinin yetkinliği

Sertifika listesinden daha önemli iki soru var. Birincisi: testi kim yapacak, ismiyle. Firmaların yetkinlik havuzu ile size atanan kişi aynı şey değil; satış görüşmesinde konuşan kıdemli kişi ile testi yürüten kişi çoğu zaman farklı. Sözleşmeye "test eden kişi" maddesi koymak, teklifi veren kişinin taahhüdünü bağlıyor. İkincisi: o kişi benzer bir ortamı daha önce test etti mi? Bir e-ticaret uygulaması ile bir bankacılık uygulaması arasındaki fark, araç seti değil, iş mantığı: para hareketi, iade akışı, kupon istismarı, yarış koşulu. Bu akışları bilmeyen bir test, yalnızca bilinen desenleri arıyor.

Örnek rapor istemek: tek gerçek kanıt

Bir sızma testi satın alımında en belirleyici tek belge, maskelenmiş örnek rapor. Çünkü teslim edilen tek şey rapor; testin kendisi sizin ekranınızda olmuyor, üç hafta sonra elinizde kalan şey o dosya. Örnek rapor göndermeyen firma ile ilerlemek, kapanmamış bir ürünü satın almak gibi. Rapor istenecekse neye bakılacağı da belli olmalı:

Bölüm	Neyi arıyorsunuz	Kırmızı bayrak
Yönetici özeti	Teknik olmayan, karar verilebilir bir sayfa	Yalnızca bulgu sayısı ve grafik
Yöntem	Hangi standart, hangi test aralığı, ne kapsam dışı	"Özel metodoloji" ve ayrıntı yok
Bulgular	Her bulgu için yeniden üretilebilir adım	Ekran görüntüsü var, istek-yanıt yok
Önem derecesi	CVSS vektörü ve gerekçesi	Yalnızca "kritik/yüksek" etiketi
Düzeltme önerisi	Geliştiriciye yazılmış, uygulanabilir madde	Genel tavsiye ("girdi doğrulaması yapın")
Zincirleme	Tekil bulguların birleşince ne yaptığı	Bulgular birbirinden kopuk listelenmiş
Ekler	Kapsam, hesap listesi, araç sürümleri	Ek yok
Yeniden test	Tarih ve kapsam yazılı	"Talep üzerine"

Bu bölümlerin hepsini isteyen bir örnek rapor bulmak zor değil, çünkü iyi firmalar bunu satış malzemesi olarak hazır tutuyor. Bulunamıyorsa cevap da nettir. Rapordaki düzeltme önerisi kalitesi, satın aldığınız şeyin geliştirici ekibinize ne kadar iş çıkardığını belirliyor: "girdi doğrulaması yapın" cümlesi bir iş tanımı değil, bir hatırlatma; oysa hangi parametrenin, hangi uç noktada, hangi sunucu tarafı kontrolde doğrulanacağını söyleyen bir madde doğrudan iş kalemine dönüşüyor.

Bulgu başına maliyet yanılgısı

İki teklifi "kaç bulgu çıktı, kaça mal oldu" diye karşılaştırmak doğal geliyor ve neredeyse her zaman yanlış sonuç veriyor. Bulgu sayısı, test eden kişinin ne kadar konuşkan olduğuna da bağlı: aynı sistemde bir ekip 7 bulgu yazarken bir başkası 20 yazabiliyor, çünkü düşük etkili bilgi notlarını da bulgu sayısına ekliyor. Aşağıdaki örnek, aynı iki teklifi önce naif biçimde, sonra önem derecesine göre ağırlıklandırarak karşılaştırıyor.

Teklif	Tutar	Bulgu	Bulgu başına	Dağılım	Risk puanı	Puan başına
A	180.000 TL	20	9.000 TL	0 kritik, 1 yüksek, 6 orta, 13 düşük	29	6.207 TL
B	240.000 TL	7	34.286 TL	3 kritik, 3 yüksek, 1 orta, 0 düşük	38	6.316 TL

Risk puanı, kritik 8, yüksek 4, orta 2, düşük 1 katsayısıyla hesaplanıyor. A için 0 × 8 + 1 × 4 + 6 × 2 + 13 × 1 = 29; B için 3 × 8 + 3 × 4 + 1 × 2 + 0 × 1 = 38. Naif ölçekte B, A'dan 3,81 kat pahalı görünüyor (34.286 / 9.000). Risk ağırlıklı ölçekte fark 1,02 kata iniyor (6.316 / 6.207). Yani "bulgu başına maliyet" karşılaştırması, gerçek farkı yaklaşık dört katına şişiriyor.

Katsayılar bir öneri, kurum kendi katsayısını seçebilir; ama ölçeğin kendisi şu soruyu sorduruyor: 20 bulgunun 13'ü düşük etkiliyse, o 13 satır geliştirici ekibinizin kaç saatini alacak ve hangi gerçek riski kapatıyor? Buna karşılık üç kritik bulgu, çoğu zaman birbirine zincirlenebilen üç adım demek: ilk bulgu bir oturum, ikincisi bir yetki atlaması, üçüncüsü tüm kiracının verisi. Zincirlenmiş bir bulgu, tek tek puanlandığında görünmüyor; bu yüzden raporda "zincirleme senaryo" bölümü ayrıca aranmalı.

Aynı ölçeğin ikinci kullanımı, kapatılmamış bulgunun maliyetini görünür kılmak. Bir yüksek bulgunun 12 ay boyunca açık kaldığını varsayalım; yıllık istismar olasılığı yüzde 8 ve ortalama ihlal maliyeti 4.000.000 TL ise beklenen yıllık kayıp 320.000 TL. Bu bir tahmin değil, iki parametreli bir model: 0,08 × 4.000.000. Parametreleri kendi ortamınıza göre değiştirdiğinizde sonuç da değişiyor (yüzde 5 olasılıkla 2.000.000 TL maliyet 100.000 TL beklenen kayıp; yüzde 12 olasılıkla 4.000.000 TL maliyet 480.000 TL). Modelin işlevi kesin bir sayı üretmek değil, 240.000 TL'lik bir testin neden "pahalı" olmadığını göstermek.

Yeniden test ve kapanış

Bir sızma testi, bulgular kapatılmadığı sürece bir envanter. Yeniden test bu yüzden kapsamın ayrılmaz parçası, opsiyonel bir ek hizmet değil; ve iki teklif arasındaki en gizli fiyat farkı genellikle burada. Teklif "yeniden test dahil" diyorsa üç şeyi sormalısınız: kaç bulgu için, hangi süre içinde, ve kapsam dışı kalan bulgular ne olacak.

Yeniden test kurgusu	Kapsam	Kapanış belgesi	Gizli maliyet
Dahil, tüm bulgular, 30 gün	Tam	Düzeltme doğrulama raporu	Yok
Dahil, yalnızca kritik ve yüksek	Kısmi	Kısmi doğrulama	Orta bulgular doğrulanmamış kalır
Ayrı ücretli, bulgu başına	Seçilebilir	Fatura karşılığı	20 bulguda maliyet iki katına çıkabilir
Dahil değil	Yok	Yok	Kapanış kanıtı üretilemez

Kapanış belgesi, denetim tarafında işe yarayan tek çıktı. ISO 27001 denetiminde ya da bir müşteri güvenlik anketinde "test yaptırdık" demek yetmiyor; bulguların kapatıldığını gösteren ikinci bir belge gerekiyor. Yeniden test kapsam dışıysa, ilk rapor bir yıl sonra hâlâ açık bulguları listeliyor olacak ve o liste sizin aleyhinize kanıt hâline geliyor. Uygulama katmanındaki bulguların kapatılma sırası ve kanıt standardı ayrı bir rehberde: API güvenlik testi rehberi.

Sözleşmenin on iki maddesi

Aşağıdaki liste, bir sızma testi sözleşmesinde bulunması gereken maddeleri sırayla veriyor. Eksik olan her madde, testin bir aşamasında tartışmaya dönüşen bir boşluk; ve tartışmalar genellikle test başladıktan sonra çıkıyor, yani en pahalı anda.

No	Madde	Neyi düzenler	Eksikse
1	Taraflar ve imza yetkisi	Kimin adına, kimin yetkisiyle	İzin tartışmalı, ceza riski doğar
2	Kapsam ve kapsam dışı	Varlık listesi, hariç tutulanlar	Kapsam test sırasında kayar
3	Angajman kuralları	İzinli ve yasak teknikler	Kesinti riski ve anlaşmazlık
4	Yazılı yetki belgesi	Tarih, kapsam, imza	Test suç teşkil eder
5	Test penceresi ve acil iletişim	Ne zaman, kimi arayacak	Olay anında kimse ulaşılamaz
6	Gizlilik ve NDA	Bulguların paylaşım sınırı	Bulgu sızıntısı sözleşme ihlali olmaz
7	KVKK ve veri işleme	Rol, tedbir, saklama, imha	Test verisi hukuka aykırı işlenmiş olur
8	Sorumluluk sınırı ve sigorta	Tazminat üst sınırı, poliçe	Kesinti hâlinde karşılıksız kalırsınız
9	Rapor teslimi ve bildirim	Biçim, süre, kritik bulguda anında bildirim	Kritik bulgu haftalar sonra öğrenilir
10	Yeniden test	Kapsam, süre, kapanış belgesi	Kapanış kanıtı üretilemez
11	Raporun mülkiyeti	Paylaşım hakkı, denetçiye verme	Raporu denetimde kullanamazsınız
12	Ücret, para birimi, ödeme	Avans, vade, kur, stopaj	Kur farkı ve stopaj sürprizi

Yedinci madde, Türkiye'de en sık boş bırakılan madde. Bir sızma testi sırasında test ekibi gerçek kişisel veriye erişiyor: kullanıcı listesi, oturum kayıtları, ekran görüntüleri, istek-yanıt dosyaları. Bu, 6698 sayılı KVKK kapsamında bir veri işleme faaliyeti ve test firması bu veride veri işleyen rolünde. Sözleşmede veri işleyen sıfatı, uygulanacak teknik ve idari tedbirler, saklama süresi ve imha taahhüdü yazılı olmalı.

İki ayrıntı bu maddeyi kritik hâle getiriyor. Birincisi, test ekibi yurt dışındaysa veya bulgular yurt dışındaki bir platformda saklanıyorsa, kişisel verinin yurt dışına aktarımı gündeme geliyor ve KVKK'nın 9. maddesi devreye giriyor; bu, sözleşmenin "teknik" sayılan bir maddesi değil, ayrı bir hukuki işlem. İkincisi, test sırasında bir veri ihlali fark edilirse bildirim yükümlülüğü var; Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararı, ihlalin öğrenilmesinden itibaren 72 saat içinde bildirimi öngörüyor. Test sırasında erişilen ve dışarı sızdırılmış bir veri kümesi, tam olarak bu senaryo. Kanıt tarafındaki tedbirlerin nasıl belgeleneceği ayrı bir sayfada: KVKK teknik tedbirler ve kanıt rehberi.

Hangi düzenleme hangi sektörde testi zorunlu kılıyor

Sızma testi satın almanın bir nedeni risk, bir nedeni de uyum. Uyum gerekçesiyle alınan testlerde raporun biçimi, denetçinin kabul edeceği biçim olmak zorunda; aksi hâlde test yapılmış oluyor ama kanıtı olmuyor. Aşağıdaki tablo, sektöre göre hangi aracın devreye girdiğini özetliyor. Yürürlükteki metinlerin son hâli ve kuruma özgü ek şartlar için kendi denetim biriminize danışmanız gerekiyor; buradaki tablo bir yol haritası, hukuki görüş değil.

Sektör	Devreye giren araç	Sıklık	Raporu kim kabul eder
Bankacılık ve ödeme	BDDK bilgi sistemleri düzenlemeleri	Yıllık	Bankanın bilgi sistemleri ve denetim birimi
Kart verisi işleyenler	PCI DSS 11.3 ve 11.4	Yıllık	QSA veya akredite değerlendirici
Enerji	Sektörel siber güvenlik düzenlemeleri	Yıllık	Kurumun uyum birimi
Sağlık	KVKK md. 12 teknik tedbirler	Yıllık	Veri sorumlusu ve denetim
Tüm sektörler	ISO/IEC 27001 Ek A kontrol 8.8	Yıllık ya da risk bazlı	Belgelendirme denetçisi
Kamu ihaleleri	İdari şartname	Sözleşmede yazdığı gibi	İdare

Bu tablodan çıkan satın alma sonucu şu: raporun kim tarafından kabul edileceğini bilmeden test satın alınmaz. Bir QSA'nın kabul edeceği rapor ile bir ISO denetçisinin kabul edeceği rapor aynı biçimde değil; ikisi de aynı testten üretilebilir, ama raporun hangi standarda eşleneceği sözleşmede yazılı olmalı. Sonradan "raporu şu formatta yeniden düzenler misiniz" sorusu, çoğu zaman yeni bir iş kalemi ve yeni bir fatura demek.

Bütçe: neye para ödüyorsunuz

Bir sızma testinin bedeli dört kalemden oluşuyor: test günleri, yeniden test, raporlama ve proje yönetimi. Tekliflerde bunların bir kısmı görünür, bir kısmı gün sayısının içine gizlenir. Kalemleri ayrı ayrı istemek, hem fiyatı karşılaştırılabilir kılıyor hem de hangi işten vazgeçebileceğinizi gösteriyor: bütçe daraldığında kesilecek yer test günleri değil, genellikle raporun kapsamı ya da yeniden testin sıklığı olmalı.

Kalem	Tipik pay	Pazarlık payı	Kısılırsa ne kaybedilir
Test günleri	yüzde 65-75	Düşük	Doğrudan kapsam daralır
Yeniden test	yüzde 10-15	Orta	Kapanış kanıtı kaybolur
Raporlama	yüzde 8-12	Orta	Düzeltme kalitesi düşer
Proje yönetimi ve iletişim	yüzde 5-8	Yüksek	Kritik bulgu geç bildirilir

Son olarak, fiyatın kendisi hakkında dürüst bir not: sızma testi fiyatı bir piyasa rakamı değil, bir kapsam fonksiyonu. Aynı firmadan alınan iki teklif, kapsam farkı yüzünden üç katına çıkabilir. Fiyatlandırmanın ayrıntılı aritmetiği ve kapsam kalemlerinin nasıl fiyatlandığı başka bir rehberin konusu: sızma testi fiyatları nasıl belirlenir. Buradaki tek kural, iki teklifi asla toplam tutar üzerinden karşılaştırmamak.

Sık yapılan yedi hata

Aşağıdaki yedi hata, satın alma sürecinde en sık görülen ve en pahalıya mal olan hatalar. Hiçbiri teknik bilgi gerektirmiyor; hepsi süreç kararı.

• Kapsamı firmaya yazdırmak. Teklif isterken "bizim için bir kapsam çıkarın" demek, üç farklı işi fiyatlamak demek. Kapsamı siz yazın, aynı kapsamı herkese gönderin.
• Yazılı izni test günü imzalamak. Yetki belgesi testten önce imzalı olmalı; test sabahı imzalanan belge, ilk günün yarısını kaybettiriyor ve kapsam tartışmasıyla başlıyor.
• Toplam tutarı karşılaştırmak. Aynı kapsamda bile teklifler farklı iş kalemleri içeriyor. Ölçek: saat, uç nokta ve deneme sayısı.
• Yeniden testi ertelemek. Bulgular kapatılmadan yapılan test, bir yıl sonra açık bulgu listesi olarak elinizde kalıyor. Yeniden test kapsama dahil olmalı.
• Örnek rapor istememek. Rapor teslim edilen tek ürün. Maskelenmiş örnek göndermeyen firmayla ilerlemek, kapanmamış bir ürünü satın almak.
• Bulut sağlayıcı politikasını okumamak. Kiracı katmanını test etmek sizin hakkınız, sağlayıcının altyapısını test etmek değil. Politika ihlali hesabın kapatılmasına kadar gidebiliyor.
• Test sonrası düzeltme sahibini belirlememek. Rapordaki her bulgunun bir sahibi ve bir tarihi olmalı; sahipsiz bulgu, kapanmayan bulgu demek.

Kapsamı genişletmenin doğru yolu, test günlerini artırmak değil, doğru işi eklemek. Kablosuz ağ kapsama alınıyorsa saha protokolü ayrı bir iş kalemi: kablosuz ağ güvenlik denetimi saha protokolü. Mobil uygulama varsa test üç ayrı yüzeye bölünüyor ve süresi buna göre hesaplanıyor: mobil uygulama sızma testi rehberi. Çalışan davranışı da kapsama giriyorsa, oltalama simülasyonu teknik testten ayrı bir program: oltalama farkındalık eğitimi programı.

On iş gününde satın alma takvimi

Aşağıdaki takvim, süreci on iş gününe yayıyor. Toplam 65 saatlik bir efor; yani yarım zamanlı bir kişinin iki haftası. Süreyi kısaltmanın yolu adımları atlamak değil, paralel yürütmek: yetki belgesi taslağı ile angajman kuralları aynı hafta yazılabilir.

Gün	İş	Çıktı	Saat
1	Varlık envanteri ve paydaş görüşmesi	Test edilecek varlık listesi taslağı	6
2	Kapsam ve kapsam dışı dokümanı	İç onaylı kapsam dokümanı	6,5
3	Yetki belgesi taslağı ve hukuk incelemesi	İmzalanabilir yetki belgesi	6,5
4	Angajman kuralları ve acil iletişim planı	RoE taslağı	6,5
5	Aynı kapsamın üç firmaya gönderilmesi	Teklif talebi ve soru seti	6,5
6	Soru yanıtları ve örnek rapor incelemesi	Rapor kalite notu	6,5
7	Ağırlıklı puanlama ve referans araması	Puan tablosu ve kısa liste	6,5
8	Sözleşme müzakeresi, KVKK maddesi	Veri işleme eki	6,5
9	Test penceresi planı ve ekip bilgilendirmesi	Pencere takvimi, nöbet listesi	6,5
10	İmza, teyit ve bulgu takip planı	İmzalı sözleşme, takip tablosu	7
Toplam			65

Takvimin en çok atlanan günü dokuzuncu. Test başlamadan önce sistem yöneticilerine, yardım masasına ve olay müdahale ekibine haber verilmezse, testin ürettiği anormal trafik gerçek bir saldırı sanılıyor ve ekip saatlerce boşa çalışıyor. Bu, testin en pahalı üç saatini yakan senaryo: bir tarafta test eden kişi kapsamı genişletmeye çalışıyor, diğer tarafta olay müdahale prosedürü devreye giriyor.

Bu rehber neyi vaat etmiyor

Üç şeyi açıkça söylemek gerekiyor. Birincisi, doğru satın alma kararı bir sıralama garantisi değil: hiçbir sızma testi, hiçbir firma ve hiçbir sertifika, sisteminizin ihlal edilmeyeceğini garanti etmiyor. Test, belirli bir tarihte belirli bir kapsamda bulunan hataların listesini üretiyor; o listede olmayan bir hata, olmadığı anlamına gelmiyor.

İkincisi, bu sayfa bir sağlayıcı sıralaması değil. Hangi firmanın sizin için doğru olduğu, kapsamınıza, sektörünüze ve takviminize bağlı; aynı firma bir kurum için doğru, bir başkası için yanlış olabilir. Buradaki tablolar bir firmayı "en iyi" ilan etmiyor, kararı tekrarlanabilir hâle getiriyor.

Üçüncüsü, test kendi başına bir güvenlik programı değil. Bir yıllık tek test, 364 gün boyunca hiçbir şey söylemiyor. Testin değeri, çıkan bulguların kapatılmasına, kapatma kanıtının saklanmasına ve bir sonraki testin kapsamının bu bulgulara göre yazılmasına bağlı. Bu döngü kurulmadığında, her yıl aynı bulguları farklı bir firmadan satın alıyorsunuz.