Cyber Resilience Act'in bildirim yükümlülüğü yürürlükte. Çoğu üreticinin süreçleri hâlâ bir tiyatrodan ibaret.

Bugün, 11 Eylül 2026’da, Cyber Resilience Act’in bildirim yükümlülüğü Avrupa Birliği genelinde yürürlüğe giriyor. Aralık 2027’de değil; yani temel ürün gereksinimlerinin devreye gireceği ve herkese asıl hesaplaşmanın o zaman geleceğinin söylendiği tarihte değil. Bugün. Dijital unsurlar içeren bir ürün üretiyor ve bunu AB’ye satıyorsanız, kuruluşunuz bu tarihi takvimine işlemiş olsun ya da olmasın, ilk bildiriminizin geri sayımı bu andan itibaren başlıyor.

Temmuz ayında Cyber Resilience Act’in kimsenin yeterince yakından izlemediği düzenleme olduğunu; arkasındaki şirkete sadece ceza kesmek yerine bir ürünü doğrudan piyasadan çekebilen düzenleme olduğunu yazmıştım. O yazı büyük uyum tablosuna odaklanıyordu: kapsam, sınıflandırma, NIS2 ile ilişki. Bu yazı ise henüz yürürlüğe giren çok daha dar, çok daha keskin yükümlülüğe dair; ve kaç üreticinin bundan haberdar olduğunu söylediği ile kaçının yasanın tanıdığı saatler içinde gerçekten harekete geçebileceği arasındaki o rahatsız edici uçuruma dair.

Kimsenin izlemediği tarih

CRA’ye ilişkin haberlerin çoğu hâlâ Aralık 2027’nin etrafında dönüyor ve bu anlaşılır bir durum; çünkü temel siber güvenlik gereksinimleri ile uygunluk değerlendirmesi yükümlülükleri tam olarak o tarihte geçerli oluyor. Ancak düzenlemenin Madde 14’ü, özellikle bildirim için ayrı ve daha erken bir tarih belirledi: 11 Eylül 2026 itibarıyla üreticiler, ürünlerini etkileyen aktif olarak istismar edilen güvenlik açıklarını ve ciddi olayları bildirmek zorunda; ve bu yükümlülük yalnızca yeni piyasaya sürülenlere değil, hâlihazırda piyasada bulunan ürünlere de uygulanıyor.

Avrupa Komisyonu bu konudaki uygulama rehberini, tarihin yürürlüğe girmesinden yalnızca haftalar önce, 27 Temmuz 2026’da yayımladı. Bu, 24 saatlik ilk son tarihe bağlı bir yükümlülük için oldukça dar bir zaman aralığı. Aralık 2027’deki temel gereksinimler üreticilere bu andan itibaren aşağı yukarı on beş aylık bir hazırlık süresi tanıyor. Bildirim yükümlülüğü çok daha azını tanıdı.

Tam olarak neyi bildirmek zorundasınız?

İnsanların ayağını kaydıran soru bu ve buna genel ifadelerle değil, kesin bir dille yanıt vermeye değer.

Aktif olarak istismar edilen bir güvenlik açığını bildirirsiniz; yani birinin şu anda bunu ürününüze karşı kullandığına dair güvenilir kanıt bulunması durumunu. Ciddi bir olayı bildirirsiniz; yani yalnızca teorik bir zayıflığı değil, ürününüzün güvenliğini fiilen tehlikeye atan bir durumu. Bildirmediğiniz şey ise, fiilen istismar edildiğine dair kanıt olmadığı sürece, kod tabanınıza atanan her CVE, kendi sızma testinizden çıkan her bulgu ya da sorumlu açıklama programınız veya bug bounty’niz üzerinden gelen her başvurudur. Hollanda Ekonomik İşler ve İklim Politikası Bakanlığı ile Ulusal Siber Güvenlik Merkezi’nin (NCSC) 27 Ağustos’ta düzenlediği webinar bu ayrım konusunda açık sözlüydü ve bunun iyi bir nedeni var: bu ayrım olmadan üreticiler ya ulusal CSIRT’lerini gürültüye boğar ya da daha kötüsü, her güvenlik açığı bildiriminin aynı 24 saatlik aciliyeti gerektirdiğini varsayarak, asıl önemli olanları ele alması gereken ekibi tüketirdi.

Daha düşük önem derecesine sahip durumları yine de gönüllü olarak bildirebilirsiniz ve bu alışkanlığı geliştirmek için iyi nedenler var. Ancak yasal yükümlülük özellikle aktif istismar ve ciddi olaylar üzerine oturuyor; bu çizginin nereye düştüğünü bilmek, olay müdahale sürecinizin doğru yapması gereken ilk şey.

Saat, olay müdahale toplantınız için durmuyor

Bir kez öğrendiğinizde, zaman çizelgesi aşamalı ve affetmez. Bir erken uyarı, durumdan haberdar olduktan sonraki 24 saat içinde gönderilir. Daha kapsamlı bir bildirim 72 saat içinde takip eder; bu bildirim, o ana kadar durumun niteliği, etkisi ve hafifletici önlemler hakkında bildiklerinizi kapsar. Bir nihai rapor işi kapatır: Avrupa Komisyonu’nun rehberine göre, bir güvenlik açığı için düzeltici bir önlem kullanıma sunulduktan on dört gün sonra ya da ciddi bir olay için bir ay sonra.

Freshfields’in yeni yükümlülüğe ilişkin analizi, üzerinde durmaya değer bir noktaya işaret ediyor: bildirim süreleri, durumdan haberdar olduğunuz anda başlar ve saat hafta sonları ya da resmi tatillerde durmaz. Güvenlik sorumlunuzun bir konferansta olması ya da olayın bir cuma akşamı meydana gelmiş olması için tanınan bir ödem süresi yoktur. Kuruluşunuzda halihazırda bir bildirimi kimin değerlendireceğine, eşiği aştığına kimin karar vereceğine ve bildirimi kimin göndereceğine dair tanımlı bir süreç yoksa, bu süreci ilk kez, yürürlükteki 24 saatlik bir son tarihin baskısı altında kuruyorsunuz demektir; ki bu da herhangi bir şey kurmak için tam olarak yanlış an.

Bildirimin kendisi, Hollanda’da NCSC olan ulusal CSIRT’iniz ve ENISA tarafından işletilen AB genelindeki Single Reporting Platform üzerinden yürür; dolayısıyla Belçika, Almanya ya da AB’nin başka herhangi bir yerindeki bir üretici de aynı aşamalı zaman çizelgesini kendi ulusal irtibat noktası üzerinden takip eder. Mekanizma üye devletlere göre biraz farklılık gösterir; yükümlülük ve son tarihler ise göstermez.

Hazırlık rakamları neden bu kadar kötü?

“Çoğu üreticinin süreçleri bir tiyatrodan ibaret” iddiasının hakkını vermesi gereken yer burası; ve anket verileri bunu beklediğimden daha çarpıcı biçimde destekliyor.

ENISA’nın 13 Temmuz 2026’da yayımlanan ve 31 ülkede 194 kuruluşla yapılan saha çalışmasına dayanan SME Cyber Resilience Maturity Assessment Model’i, CRA’ye yönelik yüksek farkındalık ama sürekli biçimde zayıf pratik hazırlık buldu; olay müdahale ve ürün yaşam döngüsü yönetimi genel olarak en zayıf iki alan olarak öne çıktı. Bir yasanın var olduğunun farkında olmak, 24 saatlik bir zaman aralığı içinde harekete geçebilecek bir sürece sahip olmakla aynı şey değil.

Linux Foundation ve OpenSSF’in 843 katılımcıdan derlenen 2026 CRA hazırlık araştırması, benzer bir hikâyeyi farklı bir açıdan anlatıyor. Katılımcıların yüzde altmış altısı uyum sağlamak için gerçekte ne yapmaları gerektiğini hâlâ bilmiyordu; bu rakam bir önceki yılın yüzde 62’sinden neredeyse hiç kımıldamamıştı. Üreticilerin yalnızca yüzde 41’i Aralık 2027 son tarihine kadar tam uyuma ulaşmayı bekliyordu ve yalnızca yüzde 34’ü bu tarihi ilk elde doğru biçimde tanımlayabildi. CRA’den herhangi bir şekilde haberdar olan katılımcılar arasında yüzde 54’ü bir üreticinin yükümlülükleri ile bir emanetçinin (steward) yükümlülükleri arasında hâlâ net bir ayrım yapamıyordu.

Bunların hiçbiri herhangi bir uyum ekibine yönelik bir eleştiri değil. Bu tablo, çoğu kurumsal sürecin takip edebileceğinden daha hızlı biçimde soyuttan operasyonele geçen bir düzenlemeyi yansıtıyor. Ancak bu tablo, bunu okuyan üreticilerin kayda değer bir kısmının 11 Eylül çizgisini arkalarında test edilmiş hiçbir süreç olmadan geçtiği anlamına da geliyor; ki bu da bildirim yükümlülüğünün açığa çıkarmak üzere tasarlandığı senaryonun ta kendisi.

Aslında kimler bildirmek zorunda?

CRA kapsamında bildirim yükümlülüğü, dijital unsurlar içeren bir ürünü kendi adı veya markası altında AB pazarına süren tüzel kişi olan üreticiye aittir; ve kuruluş büyüklüğü sizi bu yükümlülükten muaf tutmaz. Bir ithalatçı veya distribütör, ürünü kendi markası altında satmadığı ya da üründe esaslı bir değişiklik yapmadığı sürece genellikle bağımsız bir bildirim yükümlülüğü taşımaz; bunları yaptığında ise o ürün için fiilen üretici konumuna geçer. Açık kaynak yazılım emanetçileri (steward), sürdürdükleri ürünlerle kurdukları farklı ilişkiyi yansıtan, aynı yükümlülüğün daha hafif bir sürümüyle karşı karşıyadır. Küçük ve mikro işletmeler de tümüyle kapsam içindedir; Hollanda NCSC’sinin teyit ettiği tek taviz, bu kategoride katı 24 saatlik süreyi kaçırmanın bir cezası olmamasıdır, ki bu bir hafifletmedir, bir muafiyet değil.

Gerçek bir kafa karışıklığına yol açtığı için işaret etmeye değer bir ayrıntı: CRA’nin kendisi, bildirim yapabilmeniz için önceden herhangi bir kayıt yaptırmayı gerektirmez. Bir bildirim göndermek için bir hesaba ya da oturum açmaya ihtiyacınız yoktur. Bu, aynı zamanda o yasa kapsamına da giren kuruluşlar için Cyberbeveiligingswet (Hollanda’nın NIS2 iç hukuka aktarımı) uyarınca var olan kayıt yükümlülüğünden ayrı, bilinçli bir tasarım tercihidir. İki yükümlülük tek bir birleşik süreç olarak değil, paralel biçimde işler; ve bunları birbirine karıştırmak kolay bir hata.

“Hazırlıklı olmak” gerçekte neye benzer?

CRA’nin bildirim yükümlülüğüne hazırlanmak prensipte karmaşık değildir. Pratikte zahmetlidir, ki bu farklı bir sorundur.

Ürünlerinizde gerçekte ne olduğuna dair dürüst bir envanterle başlayın, ideal olarak bir Software Bill of Materials (SBOM) aracılığıyla; çünkü hangi bileşenleri sevk ettiğinizi bilmiyorsanız, bildirilen bir güvenlik açığının sizi etkileyip etkilemediğini değerlendiremezsiniz. Neyin aktif istismar ya da ciddi olay sayıldığına dair kendi iç eşiklerinizi önceden belirleyin, böylece bu değerlendirme kararı ilk kez baskı altında verilmesin. Adlandırılmış rollerle bir tırmandırma yolu kurun: kim işaret verir, kim karar verir, kim gönderir. Erken uyarı, 72 saatlik bildirim ve nihai rapor için şablonları şimdi, kimse bir son tarihin baskısı altında değilken hazırlayın. Ve bunu, halihazırda başka hangi kapsamda bildirim yapıyorsanız onunla uyumlu hale getirin; çünkü bunu okuyan üreticilerin epeyce bir kısmı aynı zamanda Cyberbeveiligingswet ya da AVG kapsamındadır ve birbiriyle koordine olmayan üç ayrı bildirim sürecini yürütmek başlı başına bir risktir.

Bu, tesadüf değil, Temmuz ayında CRA’nin daha geniş uyum taleplerini yazarken savunduğum aynı disiplindir: elinizde ne olduğunu bilin, bunu dürüstçe sınıflandırın ve düzenleyici sizden istemeden önce evrak işini hazırlayın. Bildirim yükümlülüğü, bu argümanı sadece “eninde sonunda”dan “şimdi”ye taşıdı.

Bir müşteri bu sabah size ürününüzdeki bir güvenlik açığının birileri tarafından aktif olarak istismar edildiğini söyleseydi, kuruluşunuz o bildirimi tam olarak kimin devralacağını 24 saat içinde bilir miydi? Dürüst yanıt “bir şekilde çözerdik” ise, bildirim yükümlülüğü bugün boşuna yürürlüğe girmedi.

Kaynaklar

• European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
• Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
• Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
• Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.