DÖF’te Kök Neden Analizi: 5 Neden ve Balık Kılçığı Uygulaması

Aynı bulgu bir sonraki denetimde yeniden yazılıyorsa, düzeltici faaliyet semptomu kapatmış ama nedeni yerinde bırakmıştır. Bilgi güvenliği uygunsuzluklarında bu döngünün en sık sebebi, kök neden alanına “personel dikkatsizliği” veya “eğitim eksikliği” yazılıp geçilmesidir. Aşağıda önce düzeltme, düzeltici faaliyet ve kök neden ayrılıyor; sonra 5 Neden ve balık kılçığı (Ishikawa) yöntemleri gerçekçi bir erişim gözden geçirme bulgusu üzerinde adım adım uygulanıyor ve etkinliğin nasıl ölçüleceği gösteriliyor.

Düzeltme, düzeltici faaliyet ve kök neden farkı

ISO/IEC 27001:2022 Madde 10.2, uygunsuzluk oluştuğunda kuruluştan önce tepki vermesini (kontrol altına alma, düzeltme, sonuçlarıyla ilgilenme), ardından tekrarlanmaması veya başka yerde oluşmaması için nedenleri belirleyip ortadan kaldırma ihtiyacını değerlendirmesini, gerekli faaliyeti uygulamasını ve etkinliğini gözden geçirmesini ister. Uygunsuzluğun niteliği, alınan faaliyetler ve düzeltici faaliyetin sonuçları dokümante bilgi olarak saklanır.

Kavram	Soru	Örnek
Düzeltme	Bu uygunsuzluğu şimdi nasıl gideririz?	Açık kalan ayrılan personel hesaplarını kapatmak
Kök neden	Bu neden oldu ve neden fark edilmedi?	Ayrılış bildirimi ERP’ye ulaşmıyor, kontrol mekanizması yok
Düzeltici faaliyet	Tekrarını nasıl önleriz?	İK–BT bildirimini zorunlu iş akışına bağlamak, haftalık mutabakat
Etkinlik doğrulaması	Faaliyet işe yaradı mı?	Sonraki iki çeyrekte mutabakatta istisna çıkmaması

Madde 10.2’nin en sık atlanan parçası, benzer uygunsuzluğun başka yerde de olup olmadığının değerlendirilmesidir. Bulgu tek uygulamada tespit edildiyse, aynı sürecin beslediği diğer uygulamalara da bakılır. Denetçi tek bir örnek bulur. Siz tüm sistemi tararsınız.

Kök neden analizi için doğru problem tanımı

Analizin kalitesi problem tanımıyla sınırlıdır. “Erişim kontrolü yetersiz” gibi genel bir tanım her yöne çekilir; analiz de genel kalır. İyi bir problem tanımı ölçülebilir, tarihli ve kapsamı belli olur. Örnek senaryodaki bulgu şöyle olsun:

Denetimde incelenen son altı ayda ayrılan 14 personelin 3’ünün ERP hesabının ayrılış tarihinden sonra 30 günden uzun süre aktif kaldığı görülmüştür. Active Directory hesaplarının tamamı zamanında devre dışı bırakılmıştır. Çeyreklik ERP yetki gözden geçirmesi son iki çeyrekte yapılmamıştır.

Bu tanım üç bilgi taşır: sorun AD’de değil ERP’de, sorun sürekli değil belirli bir dönemde ve tespit edici kontrol (gözden geçirme) de çalışmamış. Yani analizin iki kolu vardır: neden oluştu ve neden fark edilmedi. İki soruyu ayrı sormak, yalnız önleyici ya da yalnız tespit edici çözüme sıkışmayı engeller. Senaryodaki rakamlar bu örneğe özgüdür, yöntemi göstermek için kullanılmıştır.

5 Neden yöntemi: örnek bulgu üzerinde uygulama

5 Neden, her cevaba yeniden “neden?” diye sorarak semptomdan sürece inmeyi hedefler. Beş bir kural değil, yaklaşık bir derinliktir; cevap bir süreç veya yönetim sistemi boşluğuna ulaştığında durulur. Her cevap varsayıma değil, kanıta dayanmalıdır. Bilet kuyruğu, e-posta dağıtım listesi, prosedür revizyon tarihi — hepsi açılıp bakılır.

Kol A: Hesap neden açık kaldı?

1. Neden ERP hesapları kapanmadı? ERP yöneticisine kapatma talebi gitmedi. (Kanıt: ilgili üç ayrılış için ERP kuyruğunda bilet yok.)
2. Neden talep gitmedi? İK’nın ayrılış bildirimi yalnız AD ekibine e-postayla gidiyor; ERP ayrı bir ekip tarafından yönetiliyor.
3. Neden ERP ekibi dağıtım listesinde yok? ERP yönetimi bir yıl önce dış kaynak firmaya devredildi; ayrılış prosedürü bu değişiklikten sonra güncellenmedi.
4. Neden prosedür güncellenmedi? Hizmet devri bir değişiklik olarak ele alınmadı; BGYS’ye etkisi değerlendirilmedi.
5. Neden etkisi değerlendirilmedi? Tedarikçi değişiklikleri için BGYS etki değerlendirme adımı tanımlı değil.

Kol B: Durum neden fark edilmedi?

1. Neden çeyreklik gözden geçirme yakalamadı? Son iki çeyrekte yapılmadı.
2. Neden yapılmadı? Gözden geçirmeyi yapan kişi görev değiştirdi; görev kimseye atanmadı.
3. Neden atanmadı? Gözden geçirme sorumluluğu kişi adıyla tanımlı, rolle değil; takvimde hatırlatma yok.

Kol B üçüncü adımda bir yönetim sistemi boşluğuna ulaştığı için orada durur. “Personel unuttu” cevabında durmak yerine, unutmayı mümkün kılan yapıya (kişiye bağlı sorumluluk, otomatik takibin olmaması) inilmiştir. Sahada en sık gördüğümüz tablo budur: AD tarafı otomatik işler, iş uygulamaları ayrı ekipte kalır ve ayrılış zinciri orada kopar.

Balık kılçığı (Ishikawa) ile çok faktörlü analiz

5 Neden tek bir zincir izler. Sorun birden fazla faktörün birleşiminden doğduğunda zincir eksik kalır. Ishikawa diyagramı olası nedenleri kategorilere ayırır ve ekibin tüm alanları taramasını sağlar. Üretimdeki klasik 6M kategorileri bilgi güvenliğine şöyle uyarlanabilir:

Kategori	Örnek senaryodaki olası neden	Kanıtla doğrulandı mı?
Yöntem (süreç)	Ayrılış prosedürü ERP’yi kapsamıyor	Evet, prosedür revizyonu incelendi
İnsan (rol)	Gözden geçirme sorumlusu kişiye bağlı	Evet, RACI’de rol tanımı yok
Sistem (araç)	İK sistemi ile ERP arasında entegrasyon yok	Evet
Veri	ERP kullanıcı adları personel sicil numarasıyla eşleşmiyor	Kısmen; bazı hesaplar ortak kullanıcı
Ölçüm (izleme)	Ayrılış–kapatma süresi ölçülmüyor	Evet
Çevre (organizasyon)	Dış kaynak devrinde BGYS etki değerlendirmesi yok	Evet

Tablodaki “veri” satırı 5 Neden zincirinde çıkmamıştı: ERP’de sicil numarasıyla eşleşmeyen ortak hesaplar, ayrılan kişinin hesabını bulmayı da zorlaştırıyor. Ishikawa’nın değeri tam olarak budur. Her kılçıktaki neden, doğrulanana kadar hipotezdir. DÖF kaydına kök neden olarak yalnız kanıtla doğrulananlar yazılır.

Düzeltici faaliyet planı ve sorumluluklar

Her doğrulanmış kök nedene en az bir faaliyet karşılık gelir. Faaliyetler rol, tarih ve tamamlanma kanıtıyla tanımlanır; “ilgili birimler gerekli önlemleri alacaktır” gibi cümleler plan değildir.

• Ayrılış iş akışı: İK sistemindeki ayrılış kaydı, AD ve ERP için ayrı görevler açan bir iş akışına bağlanır. Sahip: BT süreç sorumlusu. Kanıt: iş akışı tanımı ve ilk üç ayrılışın görev kayıtları.
• Rol bazlı gözden geçirme sorumluluğu: ERP yetki gözden geçirmesi RACI’de role atanır; takvim hatırlatması ve yedek sorumlu tanımlanır.
• Ortak hesapların temizlenmesi: Kişiye ait olmayan ERP hesapları envantere alınır, gerekmeyenler kapatılır, kalanlara sahip atanır.
• Haftalık mutabakat: İK’nın ayrılan listesi ile aktif hesaplar arasında otomatik karşılaştırma yapılır.
• Tedarikçi değişikliği adımı: Tedarikçi devirlerinde BGYS etki değerlendirmesi prosedüre eklenir.
• Yaygınlık kontrolü: Aynı açığın ERP dışındaki uygulamalarda (ör. bulut tabanlı CRM) olup olmadığı incelenir.

Mutabakat adımı AD tarafında basit bir betikle başlar. Aşağıdaki PowerShell örneği, İK’dan alınan ayrılan listesindeki kullanıcı adlarından hâlâ etkin olanları listeler (ActiveDirectory modülü gerekir):

Import-Module ActiveDirectory
Import-Csv .\ayrilanlar.csv | ForEach-Object {
    Get-ADUser -Filter "SamAccountName -eq '$($_.SamAccountName)'" -Properties LastLogonDate
} | Where-Object { $_.Enabled } |
    Select-Object SamAccountName, Name, LastLogonDate |
    Export-Csv .\ayrilan-ama-etkin.csv -NoTypeInformation -Encoding UTF8

Konsolda ilk bakılacak yer CSV’deki kullanıcı adı sütununun AD’deki SamAccountName ile birebir aynı olup olmadığıdır; İK listesi çoğu zaman ad–soyad ya da sicil numarası taşır ve eşleşmeyen satırlar sessizce boş döner. ERP tarafında aynı karşılaştırma uygulamanın kullanıcı raporu dışa aktarılarak yapılır. Çıktı dosyası tarihlenip saklandığında hem işletim kanıtı hem de etkinlik ölçümünün veri kaynağı olur. Bu kanıtın periyodik gözden geçirme içinde nasıl belgeleneceği erişim gözden geçirme kanıtı yazısında anlatılıyor.

Etkinlik doğrulaması nasıl yapılır?

Faaliyetin tamamlanması ile etkili olması ayrı şeylerdir. Tamamlanma, iş akışının devreye alındığını gösterir; etkinlik, problemin bir süre boyunca tekrarlanmadığını. Etkinlik kriteri DÖF açılırken, faaliyet planıyla birlikte yazılmalıdır:

• Doğrulama dönemi: faaliyetin tamamlanmasından sonraki iki çeyrek.
• Ölçü 1: haftalık mutabakat raporlarında ayrılış tarihinden sonra bir iş gününü aşan aktif hesap sayısı sıfır.
• Ölçü 2: iki çeyreklik ERP yetki gözden geçirmesinin planlanan tarihte tamamlanmış ve onaylanmış olması.
• Ölçü 3: yaygınlık kontrolünde incelenen diğer uygulamalarda benzer bulgu çıkmaması veya çıkanların ayrı DÖF ile kayda alınması.

Doğrulamayı faaliyeti uygulayan kişi değil, bağımsız biri (genellikle iç denetçi veya BGYS yöneticisi) yapar ve kanıtlarıyla DÖF kaydına ekler. Kriter karşılanmazsa DÖF kapatılmaz. Analiz yeniden açılır. Kontrolün yalnız tasarlanması ile dönem boyunca işletilmesi arasındaki fark kontrol etkinliği testi yazısında ayrıntılı ele alınıyor.

Denetçinin reddettiği tipik DÖF kayıtları

• Kök neden = bulgunun tekrarı: “Hesaplar kapatılmamış çünkü kapatma yapılmamış.”
• Düzeltici faaliyet = düzeltme: Yalnız bulgudaki üç hesabın kapatılması; tekrarı önleyen bir değişiklik yok.
• “Personele eğitim verilecek”: Nedenin eğitim eksikliği olduğu kanıtlanmadan, ölçülebilir hedefi olmadan yazılmış faaliyet.
• Etkinlik kriteri yok: DÖF, faaliyet tamamlandığı gün kapatılmış.
• Yaygınlığa bakılmamış: Aynı süreçteki diğer sistemler incelenmemiş.

Bulgunun majör ya da minör sınıflanması kök neden analizinin mantığını değiştirmez; değişen, belgelendirme kuruluşunun doğrulamayı ne zaman ve nasıl yapacağıdır. Sınıfların anlamı için majör ve minör uygunsuzluk farkı yazısına bakabilirsiniz. Belgelendirme denetimi sonrası açılan bulguların analizinde destek için denetim sonrası uygunsuzluk kapatma ve DÖF danışmanlığı, iç denetim döngüsünün DÖF süreciyle bütünleşmesi için iç denetim ve düzeltici faaliyet yönetimi hizmetlerimizi inceleyebilirsiniz.

Sık sorulan sorular

Her uygunsuzluk için kök neden analizi yapmak gerekir mi?

ISO/IEC 27001:2022 Madde 10.2, her uygunsuzlukta nedenlerin belirlenip ortadan kaldırılması ihtiyacının değerlendirilmesini ister. Analizin derinliği bulgunun etkisine göre ayarlanır; tekil bir hata için kısa bir 5 Neden yeterliyken sistematik bulgularda Ishikawa ile çok faktörlü analiz uygundur.

5 Neden yönteminde mutlaka beş kez mi sormak gerekir?

Hayır. Beş yaklaşık bir derinliktir. Cevap değiştirilebilir bir süreç veya yönetim sistemi boşluğuna ulaştığında durulur. Her cevabın kanıtla desteklenmesi, soru sayısından daha önemlidir.

DÖF ne zaman kapatılabilir?

Faaliyetler tamamlandıktan ve önceden tanımlanan etkinlik kriteri doğrulama döneminde karşılandıktan sonra. Faaliyetin tamamlandığı gün kapatılan DÖF’ler etkinliği gösterilmediği için denetimde sorgulanır.

Kök neden olarak eğitim eksikliği yazılabilir mi?

Yazılabilir, ama kanıtla doğrulanmalıdır: kişinin ilgili sorumluluğu bilmediği ve eğitim kaydının bulunmadığı gösterilmelidir. Çoğu durumda hatayı mümkün kılan süreç veya rol tanımı eksikliği daha doğru bir kök nedendir.