Çağrı Ağacı ve Acil İletişim Listesi Nasıl Kurulur ve Test Edilir?

Kesintinin ilk saatinde en kıt kaynak çoğu zaman sistem değil, doğru kişiye ulaşabilmektir. Kurumsal e-posta, Teams veya IP santral çöktüğünde ekipleri haberdar etmenin yolu önceden kurulmamışsa kriz ekibi toplanamaz, kurtarma ekibi saatler sonra işe başlar. Aşağıda çağrı ağacının yapısını, kurumsal altyapıdan bağımsız iletişim kanallarını, listedeki kişisel verinin korunmasını ve ağacın nasıl test edilip ölçüleceğini anlatıyoruz.

Çağrı ağacının amacı ve yapısı

Çağrı ağacı (call tree), bir olay bildirildiğinde kimin kimi, hangi sırayla ve hangi kanaldan arayacağını tanımlayan hiyerarşik bildirim yapısıdır. İşi yalnız haber vermek değildir. Mesajın alındığını teyit etmek ve ulaşılamayan kişiyi yukarı raporlamak da ağacın işidir. İyi bir çağrı ağacı iki yönlü çalışır: bildirim aşağı iner, teyit yukarı çıkar. Teyit yoksa ağaç yoktur.

Tasarımda şu kuralları uygulayın:

• Dal genişliği: Bir kişinin arayacağı kişi sayısını sınırlı tutun. Elle yapılan aramalarda kişi başına 4–6 kişiyi aşan dallar yavaşlar; ilk halka telefonda takılı kalır, alttaki dal bekler.
• Yedek arayan: Her düğümün bir yedeği olur. Ekip sorumlusu izindeyse veya ulaşılamıyorsa dalın tamamı kopmamalıdır.
• Atlama kuralı: Belirli bir sürede (örneğin 15 dakika) ulaşılamayan kişinin altındaki dalı arayan kişi kendisi üstlenir veya yedek düğüme devreder. Süre yazılı değilse herkes “biraz daha bekleyelim” der.
• Rol bazlı yapı: Ağacı kişi adıyla değil rolle kurun (BT nöbetçisi, tesis sorumlusu, finans süreç sahibi); kişi–rol eşlemesini ayrı tutun. Personel değiştiğinde yapı bozulmaz, yalnız eşleme güncellenir.
• Ayrı ağaçlar: Kriz yönetim ekibi, teknik kurtarma ekipleri ve tüm çalışanlar için ayrı ağaçlar veya listeler gerekir. Tüm çalışanlara ulaşmak, kriz ekibini toplamaktan farklı bir iştir ve genellikle toplu bildirim aracıyla çözülür.

Aşağıda küçük bir örnek yapı var; gerçek planda her düğümün yanında birincil ve yedek kanal bilgisi de bulunur.

Olay bildirimi (BT nöbetçisi / güvenlik görevlisi)
└── İş sürekliliği koordinatörü  [yedek: BT müdürü]
    ├── Kriz ekibi başkanı (genel müdür)  [yedek: genel müdür yardımcısı]
    │   ├── İletişim sorumlusu
    │   └── Hukuk / KVKK sorumlusu
    ├── BT kurtarma sorumlusu  [yedek: sistem yöneticisi]
    │   ├── Sistem ekibi (2 kişi)
    │   └── Network ekibi (2 kişi)
    └── Süreç sahipleri koordinatörü
        ├── Üretim planlama
        ├── Satış / sipariş
        └── Finans
Teyit akışı: her dal sorumlusu, dalındaki ulaşılan / ulaşılamayan listesini
koordinatöre bildirir; koordinatör T+30 dk’da toplam durumu kriz ekibi
başkanına raporlar. (Ağaç bildirim sırasını gösterir, yetki hiyerarşisini değil.)

Birincil ve yedek iletişim kanalları

Kanal seçerken tek ölçüt şudur: bu olay türünde bu kanal hâlâ çalışır mı? Aşağıdaki tablo yaygın kanalları bağımlılıklarıyla birlikte karşılaştırıyor.

Kanal	Bağımlılık	Güçlü yanı	Sınırlaması
Kurumsal e-posta / Teams	Kimlik altyapısı, internet, bulut hizmeti	Kayıt tutar, grup iletişimi kolay	Siber olayda ilk kaybedilen kanal olabilir
IP santral / masa telefonu	Yerel ağ, santral sunucusu, enerji	Tanıdık kullanım	Bina veya ağ kaybında çalışmaz
Mobil sesli arama	Mobil operatör	Kurumsal BT’den bağımsız	Bölgesel afette şebeke yoğunluğu
SMS	Mobil operatör	Düşük bant genişliğinde iletilir	Teslim teyidi ve yanıt toplama sınırlı
Harici toplu bildirim hizmeti	Hizmet sağlayıcı, internet veya operatör	Sesli/SMS/uygulama, teyit raporu	Sözleşme ve veri işleme şartları gerekir
Telsiz / uydu telefonu	Kendi ekipmanı	Şebekeden bağımsız	Maliyet, eğitim, sınırlı kişi

En az iki bağımsız kanal tanımlayın: biri normal günde kullanılan, kurumsal altyapıya bağlı kanal; diğeri kurumsal altyapıdan tamamen bağımsız kanal. Kanal sırası olay türüne göre değişebilir. Fidye yazılımı olayında saldırganın kurumsal mesajlaşma platformunu ve e-postayı okuyor olma ihtimali vardır. Kriz ekibi iletişimi o durumda baştan bağımsız kanala taşınır. Saldırgana plan okutulmaz.

Kurumsal sistemler çöktüğünde iletişim

Sahada en sık gördüğümüz tasarım hatası, acil iletişim listesinin yalnız kurumsal sistemlerde durmasıdır: liste SharePoint’te, telefonlar IP santralde, kişiler Entra ID’de. Kimlik altyapısı düştüğünde ne listeye ulaşılır ne kanala. Şu önlemleri alın:

• Çevrimdışı kopya: Kriz ekibi üyelerinin her birinde, şifreli bir mobil cihazda veya mühürlü zarfta basılı olarak güncel listenin bir kopyası bulunur. Kopyalar sürüm tarihi taşır; eski kopyayı toplatmak böylece kolaylaşır.
• Kurumsal hesaptan bağımsız grup: Kriz ekibi için kurumsal kimlikten bağımsız çalışan bir iletişim grubu önceden kurulur ve kuralları (hangi bilgi paylaşılabilir) yazılı belirlenir. Kişisel mesajlaşma uygulaması kullanılacaksa hangi bilginin bu kanaldan geçmeyeceği açıkça tanımlanmalı; müşteri verisi veya teknik ayrıntı buraya taşınmamalıdır.
• Toplanma noktası ve zamanı: Hiçbir kanal çalışmıyorsa ne yapılacağı da plandadır: “İletişim kurulamazsa kriz ekibi olayın fark edilmesinden sonraki ilk iş saatinde X adresinde toplanır” gibi.
• Kurtarma ekibinin erişimi: BT ekibi acil durum (break-glass) hesaplarına, parola kasasına ve dokümantasyona kurumsal sistemlerden bağımsız bir yoldan ulaşabilmelidir. Aksi halde çağrı ağacı ekibi toplar ama ekip konsola giremez; parola kasası şifrelenmiş sunucudaysa iş orada biter.

Microsoft 365 kullanan kuruluşlarda Teams ve e-postanın hangi bağımlılıklarla çalıştığını ve bulut tarafında neyin planlanması gerektiğini Microsoft 365 ve bulut altyapısında süreklilik yazısı ayrıntılı anlatıyor.

Liste güncelliği ve kişisel veri koruması

Acil iletişim listesi; çalışanın kişisel cep telefonu, ev telefonu, acil durumda aranacak yakın bilgisi gibi kişisel veriler içerebilir. Bu veriler 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındadır (kanun ve Kurum rehberleri için kvkk.gov.tr). Listeyi hazırlamak bir uyum işidir:

• Veri minimizasyonu: Listede yalnız ulaşmak için gereken bilgi bulunur. Ev adresi, kimlik numarası gibi alanlar çağrı ağacı için gerekmez.
• Hukuki dayanak ve aydınlatma: Kişisel numaraların hangi işleme şartına dayanılarak işlendiğini hukuk birimiyle belirleyin ve çalışana aydınlatma metniyle bildirin. Yakın bilgisi gibi üçüncü kişi verilerini ayrıca değerlendirin.
• Erişim ve dağıtım kontrolü: Ağacın tamamı herkese dağıtılmaz; her dal sorumlusu kendi dalını görür. Basılı kopyaların sayısı ve kimde olduğu kayıt altındadır.
• Toplu bildirim hizmeti: Harici bir hizmet kullanıyorsanız sağlayıcıyla veri işleme sözleşmesi yapın, verinin nerede saklandığını ve yurt dışına aktarım durumunu değerlendirin.
• İşten ayrılanlar: İşten ayrılış sürecine, kişinin acil iletişim listesinden ve toplu bildirim hizmetinden silinmesi adımını ekleyin.

Bilgi güvenliği ve süreklilik uyumu açısından güncelliği korumanın en etkili yolu, listeyi insan kaynakları kayıtlarına bağlamak ve periyodik doğrulamayı kişinin kendisine yaptırmaktır: çeyrekte bir, çalışandan bilgilerini teyit etmesi istenir. İşe giriş, rol değişikliği ve ayrılış listeyi güncelleme tetikleyicisi olmalıdır. Elle tutulan Excel listesi altı ay içinde eskir.

Çağrı ağacı testi ve ulaşılabilirlik ölçümü

Çağrı ağacı testi, ISO 22301 iş sürekliliği yönetimi kapsamındaki en ucuz ve en az riskli fonksiyonel tatbikattır; bu yüzden diğer tatbikatlardan daha sık yapılabilir. Testi şu adımlarla kurun:

1. Test mesajını standartlaştırın: Mesaj “TEST” ifadesiyle başlar ve alıcıdan net bir teyit ister (“Bu bir tatbikattır. Mesajı aldıysanız 1 yazarak yanıtlayın”).
2. Zamanlamayı çeşitlendirin: Mesai içi test listeyi doğrular; gerçek ulaşılabilirliği mesai dışı, hafta sonu veya tatil öncesi test gösterir. Mesai dışı testten önce yönetim onayı alın.
3. Zaman damgası tutun: Her düğüm için arama/bildirim zamanı, teyit zamanı ve kullanılan kanal kaydedilir.
4. Kanal arızası simüle edin: Bazı testlerde birincil kanalı “çalışmıyor” kabul edin ve yedek kanalın gerçekten kullanılabildiğini doğrulayın.
5. Sonucu raporlayın: Ulaşılan kişi oranı, son teyide kadar geçen süre, hatalı veya güncel olmayan kayıt sayısı ve düzeltme aksiyonları.

Kayıt için aşağıdaki gibi basit bir tablo yeterli; toplu bildirim hizmeti kullanıyorsanız bu veriler genellikle hizmetin raporundan gelir.

Rol / düğüm	Bildirim	Teyit	Kanal	Not
BT kurtarma sorumlusu	22:04	22:07	Mobil arama	—
Network ekibi 1	22:09	22:31	SMS	Arama yanıtsız
Finans süreç sahibi	22:06	—	Mobil arama	Numara güncel değil

Ölçüm için iki gösterge yeterlidir: hedef süre içinde teyit veren kişi oranı ve son kritik rolün teyit süresi. Hedef süreyi, planda kriz ekibinin toplanması için öngörülen süreden türetin. Testten çıkan hatalı kayıtlar düzeltilmeden test kapatılmaz. Tablodaki “numara güncel değil” satırı tek başına bulgudur. Çağrı ağacının diğer tatbikatlarla birlikte yıllık programa nasıl yerleşeceği için iş sürekliliği tatbikat türleri yazısına bakabilirsiniz.

Kontrol listesi

• Ağaç rollere göre kurulmuş, her düğümün yedeği tanımlı.
• Dal genişliği sınırlı, atlama kuralı ve süresi yazılı.
• Kurumsal altyapıdan bağımsız en az bir kanal tanımlı ve test edilmiş.
• Listenin çevrimdışı kopyası kriz ekibi üyelerinde, sürüm tarihiyle birlikte mevcut.
• Hiçbir kanal çalışmadığında toplanma noktası ve zamanı belirlenmiş.
• Acil durum hesaplarına ve dokümantasyona kurumsal sistemlerden bağımsız erişim var.
• Kişisel veriler minimize edilmiş, aydınlatma yapılmış, erişim sınırlı.
• İşe giriş, rol değişikliği ve ayrılış süreçleri listeyi güncelliyor.
• Mesai dışı test dahil düzenli test yapılıyor, sonuçlar ve düzeltmeler kayıtlı.

Çağrı ağacı, iş sürekliliği planının aktivasyon bölümünün sahada uygulanan halidir. Planı, rolleri ve iletişim yapısını birlikte kurgulamak için iş sürekliliği planı ve iş etki analizi çalışmasından yararlanabilirsiniz.

Sık sorulan sorular

Çağrı ağacı yerine toplu SMS göndermek yeterli mi?

Tüm çalışanlara bilgi vermek için toplu bildirim uygun bir yöntemdir. Kriz ve kurtarma ekiplerinde ise mesajın alındığının teyidi, ulaşılamayan kişinin yerine yedeğin devreye alınması ve kimin hangi görevi üstlendiğinin netleşmesi gerekir. Kritik ekipler için teyitli bir çağrı ağacı veya teyit toplayabilen bir bildirim hizmeti kullanın.

Çalışanların kişisel telefon numaraları acil iletişim listesinde tutulabilir mi?

Tutulabilir; ama bu bir kişisel veri işleme faaliyetidir. Hukuki dayanak belirlenmeli, çalışan aydınlatılmalı, yalnız gerekli veri tutulmalı ve listeye erişim sınırlanmalıdır. Uygulama detaylarını kuruluşun hukuk birimi veya KVKK sorumlusuyla netleştirin.

Çağrı ağacı ne sıklıkla test edilmeli?

Kesin bir sıklık yoktur; çağrı ağacı düşük riskli olduğu için diğer tatbikatlardan daha sık test edilebilir. Yaygın yaklaşım, liste doğrulamasını çeyrekte bir yapmak ve yılda en az bir kez mesai dışı, teyitli bir ulaşılabilirlik testi yürütmektir.

Teams veya e-posta çağrı ağacının birincil kanalı olabilir mi?

Normal operasyonda olabilir, tek kanal olamaz. Kimlik altyapısı, internet bağlantısı veya bulut hizmeti kesildiğinde bu kanallar da gider. Siber olayda kurumsal kanalların izlenme ihtimali de vardır. Kurumsal altyapıdan bağımsız en az bir yedek kanal tanımlayın ve test edin.