Politika İstisnası Nasıl Yönetilir? Talep, Risk ve Süre Sınırı

Desteği bitmiş işletim sistemiyle çalışan bir ölçüm cihazı. MFA desteklemeyen eski bir uygulama. Müşterinin dayattığı bir dosya aktarım yöntemi. Her politika er ya da geç uygulanamadığı bir durumla karşılaşır. Bunlar e-postayla verilen “şimdilik açalım” onaylarıyla geçiştirildiğinde, birkaç yıl içinde kimsenin sahiplenmediği kalıcı açıklar birikir: firewall’da kimin açtığı bilinmeyen kurallar, parolası hiç değişmeyen servis hesapları. Aşağıda politika istisnasını uygunsuzluktan ayırmayı, talep formunu, risk ve telafi edici kontrol değerlendirmesini, onay yetkisini, süre sınırını ve istisna kaydının izlenmesini anlatıyoruz.

İstisna ile uygunsuzluk arasındaki fark

İkisi de politikadan sapmadır. Fark, sapmanın bilinçli olarak, yetkili kişi tarafından, risk değerlendirilerek ve süreli olarak kabul edilip edilmediğindedir.

Özellik	İstisna	Uygunsuzluk
Ortaya çıkış	Önceden talep edilir	Denetim, olay veya kontrolde tespit edilir
Risk değerlendirmesi	Onaydan önce yapılır	Tespitten sonra yapılır
Onay	Yetki matrisine göre verilir	Onay yoktur; düzeltici faaliyet açılır
Süre	Bitiş tarihi zorunlu	Kapanış tarihi DÖF ile belirlenir
Standart karşılığı	Risk işleme ve risk kabulü (6.1.3, 8.3)	Uygunsuzluk ve düzeltici faaliyet (10.2)

Denetimde karşılığı şudur: onaysız sapma uygunsuzluk olarak yazılır. Aynı sapma kayıtlı ve geçerli bir istisnayla kapsanıyorsa denetçi genellikle istisna sürecinin işleyişini ve telafi edici kontrollerin gerçekten uygulanıp uygulanmadığını sorgular. Süresi geçmiş istisna yeniden uygunsuzluktur. Bulguların nasıl sınıflandığı majör ve minör uygunsuzluk farkı yazısında ele alınıyor.

Bir ayrım daha var: istisna ile politikada zaten öngörülmüş durumlar. Politika “servis hesapları için MFA yerine parola uzunluğu ve kısıtlı oturum açma uygulanır” diyorsa bu bir istisna değil, politika kuralıdır. Aynı istisna her çeyrek yeniden açılıyorsa sorun talepte değil, politikadadır. Politikayı güncelleyin.

İstisna talep formunun alanları

Form, onay verecek kişinin başka bir kaynağa bakmadan karar verebileceği bilgiyi taşımalıdır. Asgari alanlar:

• Talep eden ve iş sahibi: Talebi açan kişi ile riskin sahibi olacak yönetici ayrı yazılır.
• İlgili politika maddesi: Doküman kodu, sürüm ve madde numarası (örn. “BG-POL-04 v3.1, madde 6.2 – MFA zorunluluğu”).
• Kapsam: Etkilenen sistemler, hesaplar veya kullanıcılar; varlık envanteri kimlikleriyle.
• İş gerekçesi: Politikaya neden uyulamadığı ve uyulmaya çalışılırsa ortaya çıkacak etki.
• Değerlendirilen alternatifler: Neden uygulanamadıkları.
• Telafi edici kontroller: Ne yapılacağı, kimin sorumlu olduğu, nasıl doğrulanacağı.
• Kalan risk seviyesi: Kuruluşun risk metodolojisine göre.
• Talep edilen bitiş tarihi ve kalıcı çözüm planı: İstisnanın neyle sona ereceği.

Formda “süresiz” seçeneği olmaz. Kalıcı çözümü bulunmayan bir durum ya politikaya yazılı kural olarak eklenir ya da risk kabulü olarak risk kaydında yönetilir. Sahada en çok gördüğümüz eksik “kapsam” alanıdır: “üretim makineleri” yazılır, hangi IP’ler, hangi hesaplar olduğu yazılmaz. Kapsamı belirsiz istisna, zamanla her şeyi kapsar.

Risk değerlendirmesi ve telafi edici kontroller

İstisna için ayrı metodoloji kurmayın. BGYS risk değerlendirmesindeki olasılık–etki ölçeğini ve kabul kriterlerini kullanın; istisna kararları risk kaydıyla karşılaştırılabilir kalsın. Kabul kriterlerinin nasıl belirleneceği risk kabul kriterleri ve risk iştahı rehberinin konusu.

Değerlendirme iki aşamalıdır: önce kontrol hiç uygulanmazsa oluşacak risk, sonra telafi edici kontrollerle kalan risk. Telafi edici kontrol, asıl kontrolün azalttığı riski benzer düzeyde azaltmalıdır. Listeye ilgisiz bir kontrol eklemek değerlendirmeyi geçerli kılmaz; “antivirüs kurulu” ifadesi eksik MFA’nın telafisi değildir. Sahadan tipik bir senaryo:

Üretimdeki bir test standı, üreticinin desteğini sonlandırdığı bir işletim sistemiyle çalışıyor ve yazılım yeni sürümde çalışmıyor. Politika desteklenen işletim sistemi ve güncel yama ister. Telafi edici kontroller: cihazın yalnız gerekli portlara izin veren ayrı bir ağ segmentine alınması, internet erişiminin kapatılması, USB depolama erişiminin engellenmesi, yerel yönetici parolasının cihaza özgü tutulması ve aylık olarak segmentteki trafik kayıtlarının gözden geçirilmesi. Kalıcı çözüm: test standı yenileme yatırımının bir sonraki bütçe dönemine eklenmesi.

Buradaki her kontrol, yamalanmamış sistemin istismar yolunu (ağ, medya, kimlik) daraltır. Segmentasyonu doğrulamanın en kısa yolu, segmentin dışındaki bir istemciden cihazın portlarını taramak ve firewall kuralında “any” kalmadığını görmektir. Kâğıt üzerindeki VLAN yetmez. Yama yapılamayan sistemlerde teknik karar seçenekleri için OT zafiyet yönetimi rehberine bakılabilir.

Onay yetkisi matrisi

İstisnayı onaylayan kişi kalan riski kabul etme yetkisine sahip olmalıdır. ISO/IEC 27001:2022 madde 6.1.3, risk işleme planının ve kalan bilgi güvenliği risklerinin risk sahiplerince onaylanmasını ister; istisna onayı da bu yetki zincirine bağlanır. Tipik bir yetki matrisi:

Kalan risk	Onaylayan	Azami süre (örnek)
Düşük	Varlık/süreç sahibi + BGYS yöneticisi	12 ay
Orta	Birim direktörü + BGYS yöneticisi	6 ay
Yüksek	Üst yönetim veya bilgi güvenliği komitesi	3 ay
Kritik	İstisna verilmez; risk işleme zorunlu	–

Tablodaki süreler kuruluşa göre belirlenecek örnek değerlerdir. Değişmeyen iki ilke var. Talep eden kendi talebini onaylayamaz. BGYS yöneticisi istisnayı tek başına onaylamaz; onun işi değerlendirmenin doğruluğunu ve kaydın eksiksizliğini sağlamaktır. Rol dağılımı BGYS RACI matrisinde istisna satırı olarak gösterilmelidir.

Süre sınırı ve yenileme

İstisnayı istisna yapan şey bitiş tarihidir. Süre, kalıcı çözümün gerçekçi tamamlanma zamanına ve risk seviyesine göre belirlenir ve yetki matrisindeki azami süreyi aşamaz. Tarihsiz istisna, kalıcı açıktır.

Yenileme kurallarını baştan yazın:

• Yenileme talebi, bitiş tarihinden önce yeni bir talep olarak açılır; eski kayıt otomatik uzatılmaz.
• Yenilemede, önceki dönemde kalıcı çözüm için ne yapıldığı ve telafi edici kontrollerin çalıştığına dair kanıt istenir.
• Aynı istisnanın ardışık yenilenme sayısı sınırlanır; sınır aşıldığında karar bir üst onay seviyesine taşınır.
• Bitiş tarihinde kalıcı çözüm yoksa ve yenileme onaylanmadıysa durum uygunsuzluk olarak kaydedilir.

Yenilemede “kanıt” derken kastedilen somut çıktıdır: segment firewall kuralının dışa aktarımı, son ayın trafik incelemesi notu, USB engelleme politikasının uygulandığını gösteren rapor. “Kontroller devam ediyor” cümlesi kanıt değildir.

İstisna kaydının izlenmesi ve raporlanması

Tüm istisnalar tek bir kayıtta tutulur. Kayıt, onaylanan formlara bağlantı verir ve izleme için gerekli alanları içerir:

Alan	Örnek değer
İstisna no	IST-2026-014
Politika maddesi	BG-POL-04 v3.1 md. 6.2
Kapsam	AL-22 test standı
Kalan risk / onaylayan	Orta / Üretim Direktörü
Bitiş tarihi / durum	2027-03-31 / Aktif

Kayıt bir tabloda tutuluyorsa, bitişine 30 gün kalan istisnaları bulmak basit bir sorgudur. Aşağıdaki PowerShell örneği, BitisTarihi sütununun yyyy-MM-dd biçiminde tutulduğu bir CSV dışa aktarımını okur:

$sinir = (Get-Date).AddDays(30)
Import-Csv -Path .\istisna-kaydi.csv |
  Where-Object {
    $_.Durum -eq 'Aktif' -and
    [datetime]::ParseExact($_.BitisTarihi, 'yyyy-MM-dd', $null) -le $sinir
  } |
  Select-Object IstisnaNo, Kapsam, Onaylayan, BitisTarihi

Bu sorguyu zamanlanmış görev olarak haftalık çalıştırıp çıktıyı BGYS yöneticisine göndermek, hatırlatmayı kişinin hafızasından alır. Kayıt ister tabloda, ister iş akışı aracında dursun, düzenli rapor şu göstergeleri içermelidir: aktif istisna sayısı ve risk seviyesine göre dağılımı, önümüzdeki dönemde süresi dolacaklar, süresi geçmiş ama kapanmamış kayıtlar, birden fazla kez yenilenenler ve politika maddesine göre yoğunlaşma. Son gösterge, hangi politika maddesinin gerçeklikle uyuşmadığını gösterir ve politika gözden geçirmesinin doğrudan girdisidir.

Bu rapor yönetimin gözden geçirmesine girdi olarak sunulur; kabul edilmiş riskler böylece üst yönetimin önüne gelir. İstisna sürecinin politika setine nasıl yerleşeceği, bilgi güvenliği politikası yazım rehberinde anlatılan politika yapısıyla birlikte düşünülmelidir. Kalan risk değerlendirmesini kuruluşun risk metodolojisiyle tutarlı yürütmek için kurumsal bilgi güvenliği risk değerlendirmesi sayfası ilgili çerçeveyi açıklar.

Uygulamaya alma kontrol listesi

• İstisna süreci, politika setinde yazılı bir prosedür olarak yayımlandı mı?
• Talep formu “süresiz” seçeneği içermiyor ve politika maddesine atıf zorunlu mu?
• Onay yetkisi matrisi üst yönetim tarafından onaylandı mı?
• Mevcut gayriresmî onaylar (e-posta, sözlü) tek tek kayda alındı ya da kapatıldı mı?
• Süresi yaklaşan istisnalar için otomatik hatırlatma veya periyodik sorgu tanımlı mı?
• İstisna raporu yönetimin gözden geçirmesi gündemine eklendi mi?

Dördüncü madde en çok zaman alanıdır. Firewall kurallarındaki açıklama alanlarını ve eski onay e-postalarını taramak, kayıt dışı istisnaların büyük kısmını ortaya çıkarır. İstisna sürecini mevcut politika ve prosedür setiyle birlikte kurmak için bilgi güvenliği politika ve prosedür paketi sayfasına bakabilirsiniz.

Sık sorulan sorular

Politika istisnası ile risk kabulü aynı şey midir?

Yakın ama aynı değil. Risk kabulü, risk değerlendirmesinde belirlenen bir riskin işlem yapılmadan kabul edilmesidir. Politika istisnası ise belirli bir politika maddesinden sapmanın telafi edici kontrollerle ve süreli olarak onaylanmasıdır. İstisnanın kalan riski, kuruluşun risk kabul kriterlerine göre değerlendirilir.

İstisnayı kim onaylamalıdır?

Kalan riski kabul etme yetkisi olan kişi veya kurul. Kalan risk yükseldikçe onay seviyesi de yükselir. Talep eden kendi talebini onaylayamaz; BGYS yöneticisi değerlendirmeyi yapar ama tek başına onay makamı olmaz.

İstisnaların süresi ne kadar olmalıdır?

Standart bir süre vermez. Süre, kalıcı çözümün gerçekçi tamamlanma zamanına ve kalan risk seviyesine göre belirlenir ve kuruluşun yetki matrisindeki azami süreyi aşmaz. Süresiz istisna verilmez.

Süresi dolan istisna ne olur?

Bitiş tarihinden önce yenileme onaylanmadıysa ve kalıcı çözüm uygulanmadıysa sapma uygunsuzluk olarak kaydedilir ve düzeltici faaliyet süreci başlatılır.