İçindekiler
- Bildirim sayaçları gerçekte ne gerektiriyor
- Bir bildirim süresi neden aslında bir uyanma sorunudur
- Hafta sonu size ek süre kazandırır mı?
- Bildirim akışınızın önüne çalan bir telefon nasıl konur
- Adım 1 — Bildirime konu olaylara ayrılmış bir Arama kanalı oluşturun
- Adım 2 — Tespit yığınınızı bu webhook'a yönlendirin
- Adım 3 — Yalnızca gerçekten aday olanlar çalsın diye koşullar kullanın
- Adım 4 — Yalnızca e-posta gönderen sistemleri de yakalayın
- Adım 5 — Sayacın sahibi olan kişileri aynı kanala alın
- Adım 6 — Rahatsız Etmeyin açıkken test edin
- Echobell'in yapmadıkları
- SSS
- Echobell kullanmak bizi DORA veya NIS2 uyumlu yapar mı?
- DORA'nın 4 saatlik sayacı tam olarak ne zaman başlar?
- NIS2 erken uyarısı olayın tüm ayrıntılarını içermeli mi?
- İzlememiz nöbetçi mühendise zaten e-posta gönderiyor. Bu yetmez mi?
- Uyum ve mühendislik aynı uyarıyı alabilir mi?
- Arama gerçekten Rahatsız Etmeyin'i aşar mı?
- Bu yalnızca iOS için mi?
- Webhook yüküne hangi verileri koymalıyız?
- İlgili içerikler
AB'deki her olay bildirimi süresi, bir makinenin fark ettiği bir şeyle işlemeye başlar ve ekibiniz uyurken de işlemeye devam eder. Sayacı başlatan uyarı, pazar günü 02.40'ta sessiz bir push bildirimi olarak geldiyse, tek bir insan onu okumadan önce DORA bildirim pencerenizin dörtte birini çoktan yakmışsınızdır. Bu kılavuz, bildirim akışınızın önüne gerçekten çalan bir telefon aramasını Echobell ile nasıl koyacağınızı gösteriyor — böylece sayaç ile müdahaleniz aşağı yukarı aynı anda başlar.
Bunun ölçeği artık tahmin değil, ölçüm. 3 Haziran 2026'da üç Avrupa Denetim Otoritesi, DORA kapsamında bildirilen büyük BİT kaynaklı olaylara dair AB genelindeki ilk genel görünümü yayımladı: 2025'te 3.383 büyük olay, kapsamdaki finansal kuruluş başına ortalama 0,18 ve yaklaşık üçte biri sınır ötesi etkiye sahip (EBA, ESMA). Uyarı düzeninizi şekillendirmesi gereken ayrıntı ise şu: bunların yalnızca %10'u siber güvenlikle ilgiliydi. Başlıca etkenler sistem arızaları ve dış olaylardı.
Başka bir deyişle, mevzuat sayacını başlatan olaylar ezici çoğunlukla sıradan olanlardır — başarısız bir dağıtım, ölü bir bağımlılık, bir sağlayıcı kesintisi. Yani izlemenizin gece 3'te zaten yakaladığı ve Rahatsız Etmeyin modundaki bir telefona ilettiği şeyler.
Bildirim sayaçları gerçekte ne gerektiriyor
Üç rejim, üç farklı başlangıç işareti — ve hepsi gerçek zamanlı işliyor. Güncel metinlerin söyledikleri şöyle.
| Rejim | İlk süre | Ardından | Son olarak |
|---|---|---|---|
| DORA (AB finansal kuruluşları) | Olayın büyük olarak sınıflandırılmasından itibaren 4 saat içinde, olaydan haberdar olunmasından itibaren ise en geç 24 saat içinde ilk bildirim | İlk bildirimden en geç 72 saat sonra ara rapor | (En son) ara rapordan en geç bir ay sonra nihai rapor |
| NIS2 (AB'deki temel ve önemli kuruluşlar) | Gereksiz gecikme olmaksızın ve her hâlükârda önemli olaydan haberdar olunmasından itibaren 24 saat içinde erken uyarı | Haberdar olunmasından itibaren 72 saat içinde olay bildirimi | Olay bildiriminden en geç bir ay sonra nihai rapor |
| SEC Madde 1.05 (ABD'de halka açık şirketler) | Bir olayın önemli olduğuna karar verilmesinden sonra genel olarak dört iş günü içinde Form 8-K | — | — |
DORA'nın süreleri, olay bildiriminin içeriği ve süre sınırlarına ilişkin düzenleyici teknik standart olan ve 20 Şubat 2025'te yayımlanarak (AB) 2022/2554 sayılı Tüzüğü tamamlayan (AB) 2025/301 sayılı Komisyon Yetki Devrine Dayanan Tüzük'ten geliyor (Avrupa Komisyonu, Madde 5 metni). DORA'nın kendisi 17 Ocak 2025'ten beri uygulanıyor (ESMA).
NIS2'nin süreleri (AB) 2022/2555 sayılı Direktifin 23(4). maddesinde yer alıyor; Üye Devletlerin bunu 17 Ekim 2024'e kadar iç hukuka aktarması gerekiyordu (Avrupa Komisyonu). SEC süresi ise 26 Temmuz 2023'te kabul edilen siber güvenlik açıklama kurallarından geliyor (SEC).
Bir bildirim süresi neden aslında bir uyanma sorunudur
Çünkü bu sayaçların hiçbiri sizin çalışma saatlerinize bağlı değil. DORA süreyi sınıflandırmadan ve kuruluşun haberdar olmasından itibaren ölçüyor. NIS2 kuruluşun haberdar olmasından itibaren ölçüyor. SEC ise önemlilik kararından itibaren. Belirli bir anın "haberdar olma" sayılıp sayılmadığı, uyum biriminizin verdiği hukuki bir değerlendirmedir — ama bu metinlerin hiçbirinde, uyarıyı ilk gören kişi uyuduğu için sayacın yeniden başlaması diye bir şey yoktur.
DORA'nın en dar yolunda hesabı tersten yapın. Bir olay büyük olarak sınıflandırıldığı andan itibaren 4 saatiniz var ve sınıflandırma, bir insan olaya bakmadan gerçekleşemez. Tespit 02.40'ta olur, kimse 08.00'e kadar uyarıyı almazsa ve sınıflandırma 90 dakikalık bir inceleme daha alırsa, ilk bildirimi 11.00 civarında gönderirsiniz — 24 saatlik dış sınırın içinde, ama 24 saatlik tavanın sekiz saatten fazlası yalnızca uykuya harcanmış olarak. Uyarının alınma boşluğunu daraltın; sonraki her adım nefes alacak yer bulur.
Bu, daha fazla şey için uyarı kurun demek değildir. Bu, çok özel ve dar bir uyarı sınıfının — bildirime konu olma ihtimali gerçekten bulunanların — uykuda kaçırılmasının fiziksel olarak imkânsız olması gerektiği anlamına gelir. Geri kalan her şey sessiz kalmalıdır. (Ekibiniz zaten boğuluyorsa, daha gürültülü bir kanal eklemeden önce uyarı yorgunluğunu gidermekle başlayın.)
Hafta sonu size ek süre kazandırır mı?
DORA kapsamında biraz — ve büyük ihtimalle size değil. (AB) 2025/301 sayılı Yetki Devrine Dayanan Tüzük, süresi kendi Üye Devletinde bir hafta sonu gününe ya da resmî tatile denk gelen finansal kuruluşun bildirimi bir sonraki iş gününün öğlenine kadar sunmasına izin veriyor. Ancak aynı madde bu uzatmayı kredi kuruluşlarından, merkezî karşı taraflardan, işlem platformu işletmecilerinden ve NIS2 kapsamında temel ya da önemli sayılan kuruluşlardan esirgiyor. Yetkili otoriteler bunu sistemik açıdan önemli diğer kuruluşlar için de kaldırabilir (Madde 5, Advisera özeti).
Yani pazar gecesi olay yaşama olasılığı en yüksek kuruluşlar, tam da hafta sonu rahatlaması olmayanlardır. NIS2'nin 23. maddesinde hafta sonu uzatması hiç yok. Sayacın cumartesi de salı günkü gibi işlediğini varsayarak planlayın; hak ettiğiniz her uzatmayı da tampon değil, ikramiye olarak görün.
Bildirim akışınızın önüne çalan bir telefon nasıl konur
Echobell tek bir iş yapar: bir webhook'u veya e-postayı telefon aramasına dönüştürür — bir aile üyesinin araması gibi iOS Odak Modu'nu ve Rahatsız Etmeyin'i aşan, gerçekten çalan ve titreşen bir arama (bkz. kritik uyarılar için iOS Odak Modu'nu aşmak). Olayı tespit eden sistemle sayacı başlatması gereken insan arasında durur.
Adım 1 — Bildirime konu olaylara ayrılmış bir Arama kanalı oluşturun
Echobell'de bir kanal oluşturun ve bildirim türünü Arama olarak ayarlayın. Sessiz bir push göndermek yerine telefonu çaldıran ayar budur (bildirim türleri). Ona kuşkuya yer bırakmayan bir ad verin — "Bildirime konu olay — uyan" — ve başka hiçbir şey için kullanmayın. Kanalın webhook URL'sini kanal ayrıntılarından kopyalayın; şuna benzer: https://hook.echobell.one/t/<channel-token>. Bunu bir sır gibi saklayın.
Adım 2 — Tespit yığınınızı bu webhook'a yönlendirin
Olayı fark eden her ne ise, kanal URL'sine bir HTTP isteği gönderir. Echobell'in Grafana, Prometheus Alertmanager, Uptime Kuma ve UptimeRobot için doğrudan kılavuzları var; JSON POST edebilen diğer her şey webhook kılavuzu üzerinden çalışır. İşe yarar bir yük, dizüstü bilgisayarı açmadan ilk sınıflandırma kararını verecek kadar bilgi taşır:
{
"title": "Reportable candidate: {{service}}",
"message": "{{service}} down since {{started_at}} — client-facing: {{client_impact}}",
"externalLink": "https://status.internal.example/incident/{{id}}"
}
externalLink değişkeni bildirim kaydında tıklanabilir bir bağlantıya dönüşür; böylece aramayı yanıtlayan kişi doğrudan olayın üzerine düşer.
Adım 3 — Yalnızca gerçekten aday olanlar çalsın diye koşullar kullanın
Her uyarıda tetiklenen bir telefon araması, telefon araması olmaktan çıkıp arka plan gürültüsüne dönüşür. Echobell koşulları, değişken değerlerini AND/OR mantığıyla filtreler; örneğin kanalın birini araması için severity == "critical" ve client_impact == true koşulunu şart koşabilirsiniz. Bu çıtanın altındaki her şeyi ayrı bir Zaman Duyarlı veya Normal kanala yönlendirin. Bildirime konu olay kanalınız haftada bir değil, yılda birkaç kez çalmalıdır.
Adım 4 — Yalnızca e-posta gönderen sistemleri de yakalayın
Pek çok satıcı durum akışı, dolandırıcılık izleme aracı ve üçüncü taraf sağlayıcı yalnızca e-postayla bildirim yapar — ki sağlayıcı kaynaklı arızaların doğrudan kapsamda olduğu DORA açısından bu önemlidir. Her Echobell kanalının kendi adresi olabildiği için, bir yönlendirme kuralı bu mesajları aramaya dönüştürür (e-posta tetikleyicileri, e-postadan aramaya kurulumu).
Adım 5 — Sayacın sahibi olan kişileri aynı kanala alın
Olayı mühendislik bulur; süreyi ise uyum birimi, nöbetçi görevli ya da veri koruma sorumlusu sahiplenir. Kanalı paylaşın; her abone kendi aciliyetini seçsin, böylece nöbetçi mühendis arama alırken ikinci müdahaleci zaman duyarlı bir uyarı alsın. Odak Modu'nun engellediği bir aramanın yeniden denenmesi için Başarısız Aramayı Yeniden Dene'yi etkinleştirin.
Adım 6 — Rahatsız Etmeyin açıkken test edin
En az üç ayda bir, önemli olan her telefonda Rahatsız Etmeyin açıkken bir test webhook'u gönderin. Test edilmemiş bir eskalasyon yolu bir varsayımdır ve olay sonrası incelemeler tam da varsayımlardan doğar.
Echobell'in yapmadıkları
Burada net olmak, düzenlemeye tabi bir akışta her yerden daha önemlidir.
Echobell şunları yapar: bir webhook'u veya e-postayı çalan bir aramaya, zaman duyarlı bir uyarıya ya da normal bir push bildirimine dönüştürür; Arama uyarılarında iOS Odak Modu'nu ve Rahatsız Etmeyin'i aşar; koşullar ve şablonlarla filtreler; aynı uyarıyı paylaşılan bir ekip kanalına iletir.
Echobell şunları yapmaz:
- Olayları sınıflandırmaz. Bir şeyin DORA'ya göre "büyük", NIS2'ye göre "önemli" ya da SEC kurallarına göre "önemli/materyal" olup olmadığına dair bir görüşü yoktur. Bunlar, ilgili metinlerdeki ölçütlere göre sizin insanlarınızın verdiği takdir kararlarıdır.
- Hiçbir yere bildirim yapmaz. Yetkili bir otoriteye, bir CSIRT'e veya SEC'e sunum yapmaz. Yalnızca bir insanı bunu yapabileceği noktaya getirir.
- Kayıt tutma veya GRC sisteminiz olmaz. Bu rejimler; bir uyarı uygulamasının üretmediği belgeler, kayıt defterleri ve kanıtlar gerektirir. Echobell, bildirim içeriğini ve geçmişini bilinçli olarak yalnızca cihazınızda saklar; sunucuda yalnızca hesaplar, kanallar ve abonelikler bulunur (gizlilik modeli) — veri asgariliği için iyi, denetim izi olarak işe yaramaz.
- Uyum beyanıyla gelmez. Ona bağlı bir sertifikasyon, denetim raporu veya sözleşmesel SLA yoktur. Düzenlemeye tabi bir akışa dahil edecekseniz, diğer her araç gibi kendi BİT üçüncü taraf risk sürecinizden geçirin ve ona bağlı olmayan bir kanalı da elde tutun.
- İletimi garanti etmez. Bir arama; push altyapısına, ağa ve şarjı olan bir telefona bağlıdır. Onu, uyarının alınma süresini çarpıcı biçimde kısaltan katman olarak görün; denetimde gösterebileceğiniz bir kontrol olarak değil.
Dürüst çerçeve şu: telefonunuzu hangi uygulamanın çaldırdığı, mevzuattan doğan yükümlülüğünüzü değiştirmez. Bir telefon aramasının değiştirdiği şey, bir makinenin fark etmesiyle bir insanın karar vermesi arasındaki saat sayısıdır — ve 4 saatlik bir sayaçta bu saatler bütçenin neredeyse tamamıdır.
SSS
Echobell kullanmak bizi DORA veya NIS2 uyumlu yapar mı?
Hayır. Uyum; yönetişiminize, sınıflandırma sürecinize, belgelendirmenize ve yetkili otoritenize ya da CSIRT'e yaptığınız gerçek sunumlara bağlıdır. Echobell yalnızca tespit ile insanın uyarıyı alması arasındaki boşluğu kısaltır. Sürecin kendisi değil, sürece giren bir girdidir.
DORA'nın 4 saatlik sayacı tam olarak ne zaman başlar?
Sınıflandırmada. (AB) 2025/301 sayılı Yetki Devrine Dayanan Tüzük uyarınca ilk bildirim, bir olayın büyük olarak sınıflandırılmasından itibaren dört saat içinde ve her hâlükârda kuruluşun olaydan haberdar olduğu andan itibaren en geç 24 saat içinde yapılmalıdır. Bunlar iki ayrı kısıttır ve ikisini birden karşılamanız gerekir — hızlı bir sınıflandırma kararının en az hızlı bir uyarı kadar önemli olmasının nedeni budur.
NIS2 erken uyarısı olayın tüm ayrıntılarını içermeli mi?
Hayır. (AB) 2022/2555 sayılı Direktifin 23(4). maddesi, 24 saatlik erken uyarıyı bilinçli olarak geçici tutar: olayın hukuka aykırı veya kötü niyetli eylemlerden kaynaklandığından şüphelenilip şüphelenilmediği ve sınır ötesi etkisi olup olmayacağı. Daha bütünlüklü tablo 72 saatlik bildirimde, kök neden analizi ise bir ay sonraki nihai raporda gerekir.
İzlememiz nöbetçi mühendise zaten e-posta gönderiyor. Bu yetmez mi?
Biri uyanıksa ve bakıyorsa yeter. E-posta ve standart push bildirimleri; Odak modları, Rahatsız Etmeyin ve uyku programları tarafından susturulur — yani sayacın en affetmez olduğu gecelerde ve hafta sonlarında geçerli olan tam da bu koşullardır. Sorun tespitte değil, uyarının alınmasındadır.
Uyum ve mühendislik aynı uyarıyı alabilir mi?
Evet. Kanalı paylaşın; abone olan herkes tetikleyiciyi alır ve her biri kendi bildirim türünü seçer. Yaygın bir kurulum: nöbetçi mühendis Arama olarak abone olur; nöbetçi uyum görevlisi, bildirime konu olay kanalı için Arama, diğer her şey için Zaman Duyarlı olarak.
Arama gerçekten Rahatsız Etmeyin'i aşar mı?
Echobell'in Arama bildirim türü iOS Odak Modu'nu ve Rahatsız Etmeyin'i aşacak şekilde tasarlandı; Başarısız Aramayı Yeniden Dene ayarı da Odak Modu'nun engellediği aramaları yeniden dener. Ona güvenmeden önce her müdahalecinin gerçek cihazında doğrulayın — işletim sistemi ayarları ve sürümleri değişkenlik gösterir.
Bu yalnızca iOS için mi?
Hayır. Echobell iOS'ta ve Google Play üzerinden Android'de kullanılabilir (bkz. Android sürüm duyurusu). Arama tarzı uyarıların davranışı platformlar arasında farklılık gösterir; bu yüzden müdahalecilerinizin gerçekten taşıdığı cihazlarda test edin.
Webhook yüküne hangi verileri koymalıyız?
Mümkün olduğunca az. Müşteri bilgileri veya olay ayrıntıları yerine bir tanımlayıcı ve bir bağlantı gönderin — externalLink değişkenini kullanarak, bu bilgiyi tutmak için tasarlanmış bir sistemde duran olay kaydınıza işaret edin. Uyarının görevi birini uyandırmaktır, ona brifing vermek değil.