Sızma testi sıklığı, bütçe toplantılarında en çok tartışılan ama en az veriye dayandırılan güvenlik kararlarından biridir. Tipik hikâye şöyle ilerler: kurum ocakta kapsamlı bir test yaptırır, kritik bulguları kapatır, raporu denetim klasörüne koyar. Martta kimlik doğrulama altyapısı yeni bir sağlayıcıya taşınır, mayısta ödeme akışı için üçüncü bir API yayına alınır, temmuzda uzaktan çalışan ekip için ikinci bir VPN havuzu açılır. Kasımda yaşanan olayın giriş noktası ocakta test edilen bileşenlerden biri değildir; mart ile temmuz arasında sisteme giren ve hiç test edilmemiş yüzeydir.

Bu yüzden doğru soru “yılda kaç kez” değil, “hangi değişiklikten sonra” sorusudur. Test periyodunu takvime değil kurumun değişim hızına bağlayan şirketler hem daha az sürprizle karşılaşır hem de aynı bütçeyle çok daha geniş bir yüzeyi kapsar. Aşağıda periyodu belirleyen somut tetikleyicileri, kurum profillerine göre asgari aralıkları ve yıllık bir test takviminin adım adım nasıl kurulacağını bulacaksınız.

Yılda tek test modeli nerede kırılıyor

Yıllık tek test yaklaşımı, altyapının test tarihinden sonra sabit kaldığı varsayımına dayanır. Bu varsayım, sürekli teslimat (CI/CD) kullanan hiçbir kurumda geçerli değildir. Test raporunun tarihi ile bir sonraki testin tarihi arasında geçen sürede aşağıdakiler değişir:

• Kod tabanı: Haftada birkaç kez üretime çıkan bir ekipte, altı ay sonunda test edilen uygulamanın önemli bir bölümü artık aynı kod değildir.
• Dış yüzey: Yeni alan adları, geçici demo ortamları, kapatılmayı unutulan yönetim panelleri envantere girmeden internete açılır.
• Kimlik ve yetki: İşten ayrılan personelin servis hesapları, geçici olarak verilip geri alınmayan yönetici yetkileri birikir.
• Bağımlılıklar: Uygulamanın kullandığı kütüphanelerde yeni açıklıklar yayımlanır; testin yapıldığı gün güvenli olan sürüm üç ay sonra istismar edilebilir hale gelir.
• Tedarikçi entegrasyonları: Yeni bir iş ortağıyla kurulan doğrudan bağlantı, kurumun güven sınırını sessizce genişletir.

Testler arasındaki bu boşluk, saldırganın çalıştığı zaman aralığıdır. Periyot kararı da tam olarak bu boşluğu ne kadar dar tutmak istediğinizle ilgilidir.

Periyodu belirleyen tetikleyiciler: takvim değil değişim

Olgun kurumlarda test planı iki koldan yürür: sabit bir taban periyot ve olaya bağlı ek testler. Taban periyot denetim ve regülasyon gereksinimini karşılar; tetikleyiciye bağlı testler ise gerçek riski yönetir. Aşağıdaki durumlar, takvimde sıra beklemeden test gerektirir:

• Kimlik doğrulama, oturum yönetimi veya yetkilendirme mantığında yapılan her değişiklik.
• İnternete açık yeni bir servis, API veya yönetim arayüzünün yayına alınması.
• Veri merkezinden buluta ya da bulut sağlayıcıları arasında yapılan taşımalar.
• Şirket birleşmesi veya satın alma sonrası iki ağın birbirine bağlanması.
• Uzaktan erişim, VPN veya sıfır güven (zero trust) mimarisinde yapılan yapısal değişiklikler.
• Kritik bir güvenlik olayı sonrası, kök neden giderildikten sonraki doğrulama.

Değişiklik yönetimi kayıtlarını güvenlik takvimiyle eşleştirmek, kurumsal siber güvenlik danışmanlığı kapsamında en hızlı geri dönüş veren düzenlemelerden biridir; çünkü ek maliyet yaratmadan hangi testin ne zaman gerektiğini kurum içinde görünür kılar.

Kurum profiline göre asgari test aralıkları

Aşağıdaki tablo, sektör ve saldırı yüzeyi büyüklüğüne göre yaygın uygulamayı özetler. Rakamlar birer taban değerdir; tetikleyici bazlı testler bunların üzerine eklenir.

Düzenlemeye tabi sektörlerde taban periyot genellikle mevzuatla belirlenir: kart verisi işleyen ortamlar ve bankacılık bilgi sistemleri için yılda en az bir test ve “önemli değişiklik sonrası tekrar” şartı standart uygulamadır. ISO 27001 belirli bir sıklık dayatmaz; teknik açıklıkların yönetildiğini ve kontrollerin düzenli doğrulandığını kanıtlamanızı ister. KVKK tarafında da sabit bir periyot yoktur, ancak idari ve teknik tedbirlerin düzenli olarak sınanması beklenir.

Kapsamı daraltıp sıklığı artırmak mantıklı mı

Sabit bütçeyle daha sık test yapmanın en pratik yolu, her testte tüm envanteri taramak yerine kapsamı katmanlara bölmektir. Yılda bir kez yapılan 400 IP’lik geniş bir test yerine; dış yüzeyi üç ayda bir, iç ağı yılda bir, kritik uygulamayı her büyük sürümde test etmek aynı adam/gün ile çok daha güncel bir risk tablosu verir.

Bu modelde dikkat edilmesi gereken tek şey, hiçbir varlığın rotasyon dışında kalmamasıdır. Kapsam dışı bırakılan sistemler için “bu dönem kapsam dışı” notunun kayıt altına alınması, bir sonraki denetimde açıklanamayan boşlukları önler.

Yıllık test takvimi adım adım nasıl kurulur

1. Varlık envanterini güncelleyin. Alan adları, dış IP blokları, bulut hesapları, mobil uygulamalar ve internete açık yönetim arayüzlerini tek listede toplayın. Envanteri olmayan kurum, sıklık değil kapsam sorunu yaşar.
2. Varlıkları iş etkisine göre sınıflayın. Gelir üreten, kişisel veri işleyen ve operasyonu durdurabilecek sistemleri birinci katman olarak işaretleyin.
3. Taban periyodu regülasyondan türetin. Mevzuatın asgari gereğini takvime sabit olarak yerleştirin; bu, denetim kanıtınızın omurgasıdır.
4. Tetikleyici listesini yazılı kurala bağlayın. “Kimlik doğrulama değişirse test” gibi maddeleri değişiklik yönetimi sürecine gömün ki karar kişiye bağlı kalmasın.
5. Yeniden test penceresini sözleşmeye yazın. Kritik ve yüksek bulgular kapatıldıktan sonra doğrulama testinin kaç gün içinde ve hangi ücretle yapılacağı baştan netleşmelidir.
6. Ölçüm eşiği tanımlayın. Her döngüde kritik bulgu sayısı, ortalama kapatma süresi ve tekrar eden bulgu oranını izleyin. Bu üç sayı düşmüyorsa sorun test sıklığında değil, düzeltme sürecindedir.

Testler arasındaki boşluk hangi kontrollerle kapanır

Sızma testi bir fotoğraftır; aradaki filmi başka kontroller çeker. Periyot ne olursa olsun aşağıdaki katmanlar sürekli çalışmalıdır:

• Dış yüzey için otomatik zafiyet taraması ve yeni açılan servisleri yakalayan varlık keşfi.
• Yapı hattına gömülü bağımlılık ve konfigürasyon denetimi.
• Kayıt toplama ve korelasyonun MITRE ATT&CK teknikleriyle eşlenmesi; böylece tespit boşlukları teste kadar beklemeden görünür olur.
• Tespit ve yanıt sürelerinin (MTTD ve MTTR) düzenli raporlanması.

Savunma etkinliğini ölçmek isteyen kurumlar için ayrı bir başlık daha vardır: iki ila altı hafta süren ve keşiften raporlamaya kadar gerçek bir saldırı zincirini taklit eden red team hizmeti, teknik zafiyet listesi çıkarmak yerine ekibin bu zinciri fark edip edemediğini sınar. Bu nedenle sızma testiyle aynı sıklıkta tekrarlanması gerekmez; genellikle yılda bir kez, olgunluk arttıkça daha uzun aralıklarla planlanır.

Sıklık kararında en sık yapılan dört hata

• Raporu ürün sanmak: Testin çıktısı rapor değil, kapatılmış bulgudur. Kapatma hızı düşükken sıklığı artırmak yalnızca aynı bulguları yeniden satın almaktır.
• Her testi aynı ekibe yaptırmak: Aynı metodoloji ve aynı bakış açısı zamanla kör noktalar üretir. Birkaç döngüde bir tedarikçi değiştirmek kapsam çeşitliliği sağlar.
• Denetim tarihine göre planlamak: Testi denetimden iki hafta önce yaptırmak, bulguları kapatacak zamanı ortadan kaldırır.
• Yeniden testi unutmak: Doğrulanmamış düzeltme, kapatılmış bulgu sayılmaz; birçok kurumda kritik bulguların bir bölümü ilk düzeltmede eksik kapanır.

Sık sorulan sorular

Sızma testi yılda kaç kez yapılmalı?

Regülasyona tabi kurumlar için taban yılda bir testtir, ancak bu yalnızca asgari gerekliliktir. İnternete açık yüzeyi büyük ve sürekli değişen kurumlarda dış yüzey testinin üç ila altı ayda bir tekrarlanması, kritik uygulamaların ise büyük sürümlerde ayrıca test edilmesi yaygın uygulamadır.

Sızma testi ile kırmızı takım çalışması aynı sıklıkta mı tekrarlanır?

Hayır. Sızma testi belirli sistemlerdeki teknik zafiyetlere odaklanır ve tipik olarak bir ila iki hafta sürer; kırmızı takım çalışması ise tespit ve yanıt kabiliyetini ölçer, iki ila altı hafta sürer. Bu nedenle sızma testi daha sık, kırmızı takım tatbikatı daha seyrek planlanır.

Küçük bir şirket için yılda bir test yeterli mi?

Dış yüzeyi birkaç alan adı ve tek bir uygulamadan ibaret olan kurumlarda yılda bir test makul bir tabandır. Ancak yeni bir e-ticaret modülü, müşteri portalı veya uzaktan erişim çözümü devreye alındığında takvim beklenmemelidir.

Bulut altyapısına geçince test sıklığı değişir mi?

Değişir, çünkü bulutta risk çoğunlukla yazılım açıklığından değil yanlış yapılandırmadan doğar. Geçiş sonrası ilk üç ay içinde yapılandırma odaklı bir değerlendirme, sonrasında ise kimlik ve erişim yönetimi değişikliklerine bağlı tetikleyici testler önerilir.

Aynı bulgular her testte tekrar çıkıyorsa ne yapmalı?

Bu, sıklık değil süreç sorunudur. Bulguların sahibi, kapatma süresi ve doğrulama adımı tanımlı değilse test tekrarı yalnızca aynı listeyi üretir. Önce düzeltme akışını kurala bağlayın, sonra periyodu tartışın.

Sonuç

Sızma testinin doğru periyodu, kurumun ne kadar hızlı değiştiğiyle doğru orantılıdır: sabit bir taban periyodu regülasyondan, gerçek koruma değerini ise değişiklik tetikleyicilerinden almalısınız. Envanterinizi çıkarıp değişiklik kayıtlarınızı güvenlik takvimine bağladığınız gün, “yılda kaç kez” sorusunun cevabı tartışma konusu olmaktan çıkıp kurumunuzun kendi verisinden gelen bir plana dönüşür.

Bilgilendirme: Bu içerik genel bilgilendirme amaçlıdır; kurumunuzun risk profiline özel değerlendirme için uzman desteği alınmalıdır.