Cyber Resilience Act Bildirim Yükümlülükleri Başladı: AB Pazarına Dijital Ürün Sunan Üreticiler İçin Ne Değişti?

Resmî kaynaklar son kontrol edildi: 13 Eylül 2026.

11 Eylül 2026 itibarıyla, AB pazarına dijital ürün sunan üreticiler için Cyber Resilience Act bildirim yükümlülükleri uygulanmaya başladı. Aktif olarak istismar edilen bir güvenlik açığı veya ürün güvenliğini etkileyen ciddi bir olay öğrenildiğinde, teknik müdahalenin yanında 24 ve 72 saatlik bildirim akışının da yürütülmesi gerekiyor.¹

Avrupa Birliği Siber Güvenlik Ajansı ENISA, 11 Eylül 2026’da Single Reporting Platform’un (SRP) ilk operasyonel sürümünü devreye aldığını açıkladı. Aynı gün üreticilerin CRA kapsamındaki bildirim yükümlülükleri de uygulanmaya başladı. Bu iki gelişmeyi birlikte okumak gerekiyor: Hem hukuki yükümlülük başladı hem de bildirimin yapılacağı ortak elektronik kanal kullanıma açıldı.²

Bunun bir şirketin günlük işi bakımından anlamını varsayımsal bir örnekle düşünelim. Türkiye’deki bir üretici, Almanya ve Hollanda’daki fabrikalara uzaktan yönetilebilen endüstriyel bağlantı cihazları satıyor. Bir müşteriden gelen teknik kayıtlar, cihazdaki bir açığın saldırganlar tarafından izinsiz erişim için kullanıldığını güvenilir biçimde gösteriyor. Üreticinin kendi ofis sistemlerinde sorun yok; kişisel veri çalındığı da henüz tespit edilmiş değil. Buna rağmen, ürün kapsam içindeyse ve aktif istismar eşiği oluşmuşsa, CRA bakımından bildirim yükümlülüğü doğabilir.³

Dolayısıyla şirketin önündeki soru yalnızca “Açığı nasıl kapatacağız?” değildir. “Bu durum bildirime tabi mi, ne zaman öğrendik, kime hangi bilgileri vereceğiz ve müşteriye ne söyleyeceğiz?” sorularının da cevaplanması gerekir. Bu çalışma, söz konusu kararların hangi sırayla alınacağını ve Türkiye’den AB pazarına ürün sunan şirketlerin yeni dönemi nasıl değerlendirmesi gerektiğini açıklıyor.

Temel sonuç: Cyber Resilience Act bildirim yükümlülükleri 11 Eylül 2026’dan beri uygulanıyor. 24 ve 72 saatlik süreler aynı öğrenme anından başlıyor; nihai rapor süresi olayın türüne göre değişiyor. SRP ortak kanaldır, hukuki değerlendirmeyi üretici adına yapmaz.

1. CRA neyi değiştiriyor: şirket güvenliğinden ürün güvenliğine

Cyber Resilience Act, hukuki adıyla 2024/2847 sayılı AB Tüzüğü, dijital unsurlar içeren ürünlerin siber güvenliğine ilişkin ortak bir çerçeve kuruyor. Düzenlemenin odağında, bir şirketin kendi bilgisayarlarını korumasından daha farklı bir mesele var: Piyasaya sunduğu yazılım veya donanımın kullanıcılar açısından güvenli olması ve ürünün yaşam döngüsü boyunca ortaya çıkan güvenlik risklerinin yönetilmesi.⁴

Bu ayrım önemlidir. Bir üreticinin kurumsal ağına saldırı düzenlenmesi ile sattığı üründeki açığın bir müşterinin sisteminde kullanılması aynı olay değildir. CRA’nın 14. maddesi açısından, üreticinin kendi sistemleri saldırıya uğramasa da ürünün içindeki aktif olarak istismar edilen açık veya ürün güvenliğini etkileyen ciddi olay bildirim değerlendirmesi gerektirebilir. İlk örnekteki Türk şirketinin muhatap olmasının nedeni de budur.³

Ancak CRA tek tarihte bütünüyle uygulanmaya başlamıyor. 11 Eylül 2026, üreticilerin 14. maddede düzenlenen bildirim yükümlülüklerinin başlangıcıdır. Ürünün tasarımı, uygunluğunun gösterilmesi ve teknik dokümantasyonu gibi ana yükümlülüklerin büyük bölümü ise 11 Aralık 2027’de uygulanacaktır. Bu nedenle “CRA için 2027’ye kadar vaktimiz var” demek bildirim bakımından yanlış; bütün ürün uygunluk gereklerinin Eylül 2026’da başladığını söylemek de aynı ölçüde yanıltıcıdır.¹

Eski ürünler için de ayrı bir geçiş hükmü bulunuyor. 69(3). madde, 14. maddedeki bildirim yükümlülüklerini 11 Aralık 2027’den önce piyasaya arz edilmiş kapsam içindeki ürünlere de uyguluyor. Daha önce satılan bir ürün, yalnızca satış tarihi nedeniyle bildirim rejiminin dışında kalmıyor. Bununla birlikte bu hüküm, eski ürünlere CRA’nın bütün gereklerinin aynı şekilde geriye dönük uygulanması anlamına gelmiyor.⁵

2. Türkiye’deki bir şirket ne zaman bu düzenlemenin muhatabı olur?

Başlangıç noktası şirketin merkez adresi değil, hangi ürünün hangi pazara, kimin adı altında sunulduğudur. CRA, ticari faaliyet kapsamında AB piyasasında bulundurulan ve düzenlemenin ürün tanımına giren yazılım ve donanımlar bakımından değerlendirilir. Türkiye’de kurulmuş olmak, AB’ye sunulan bir ürün için kendiliğinden muafiyet sağlamaz.⁶

“Dijital unsurlar içeren ürün” ifadesi yalnızca akıllı ev cihazlarını veya internete bağlanan makineleri kapsamaz. Ayrı olarak piyasaya sunulan yazılımlar ve bileşenler de kapsamda olabilir. Ürünün amaçlanan veya makul olarak öngörülebilir kullanımında bir cihaz ya da ağa doğrudan veya dolaylı veri bağlantısı bulunması temel ölçütlerdendir. Bu nedenle değerlendirme, “Biz donanım üretmiyoruz” denilerek kapatılamaz.⁶

Üretici sıfatı da yalnızca fabrikası olan işletmelere ait değildir. Ürünü geliştiren veya geliştirilmesini sağlayan ve kendi adı ya da markası altında pazarlayan şirket bu sıfatı taşıyabilir. Bir yazılımın dışarıdaki geliştiriciye hazırlatılması, markası altında satış yapan şirketin üretici niteliğini kendiliğinden ortadan kaldırmaz. Buna karşılık, başka bir üreticinin ürününü yalnızca satın alan veya dağıtan şirketin rolü aynı değildir; sözleşme ve fiilî faaliyet birlikte incelenmelidir.⁶

SaaS etiketi tek başına cevap vermiyor

Bulut üzerinden sunulan yazılımlar için “SaaS hizmetlerinin hepsi kapsamda” veya “SaaS tamamen kapsam dışında” şeklindeki iki genelleme de sorunludur. CRA, ürünün belirli bir işlevini yerine getirebilmesi için gerekli olan ve üretici tarafından ya da onun sorumluluğu altında geliştirilen uzaktan veri işleme çözümlerini ürünün bir parçası olarak ele alır.⁷

Örneğin, ilk örnekteki cihazların uzaktan yönetilmesini sağlayan üretici kontrollü bulut bileşeni bu değerlendirmeye dahil olabilir. Buna karşılık, herhangi bir kapsam içi ürünün işlevini desteklemeyen bağımsız bir çevrim içi hizmet sırf abonelikle satılıyor diye CRA ürünü hâline gelmez. Burada hukuk ekibinin satış sunumuna değil, ürünün nasıl çalıştığını gösteren teknik açıklamaya ihtiyacı vardır: Bulut bileşeni kaldırıldığında ürün hangi işlevini kaybediyor ve bu bileşen kimin sorumluluğunda geliştiriliyor?⁷

Açık kaynak kullanımı ve sektörel düzenlemeler de sonucu değiştirebilir. Ticari faaliyet dışında geliştirilen veya sağlanan serbest ve açık kaynak yazılım için kapsam istisnası vardır; ancak ticari bir üründe açık kaynak bileşen kullanılması ürünün tamamını muaf kılmaz. Ayrıca bazı tıbbi cihazlar ve ulaşım ürünleri gibi özel AB mevzuatına tabi ürünler için ayrı istisnalar bulunur. “Open-source software steward” statüsündeki kuruluşların 24(3). madde kapsamındaki özel bildirim yükümlülüklerinin tarihi ise 11 Aralık 2027’dir; bu statü, açık kaynak kullanan her şirketle aynı anlama gelmez.⁸

Bu nedenle ilk hukuki çalışma, bütün şirket için tek cümlelik bir kapsam kararı vermek yerine, AB’ye sunulan ürünleri ve şirketin her üründeki rolünü belirlemek olmalıdır.

3. Bildirim gerektiren iki durum: açık ile olay aynı şey değil

Kapsama giren bir ürün bulunması, keşfedilen her teknik sorunun SRP’ye bildirilmesi gerektiği anlamına gelmez. CRA’nın 14. maddesi iki ayrı eşik kurar. Bunları ayırmak, hem eksik bildirim hem de gerekçesiz bildirim riskini azaltır.³

Aktif olarak istismar edilen güvenlik açığı

Güvenlik açığı, üründe kötüye kullanılabilecek bir zayıflık bulunmasıdır. Aktif olarak istismar edilen açık ise daha ileri bir durumu ifade eder: Kötü niyetli bir aktörün bu açığı sistem sahibinin izni olmadan kullandığına ilişkin güvenilir kanıt vardır. Tüzüğün 3(42). maddesi bu ayrımı esas alır.⁹

Böylece bir testte açığın keşfedilmesi, teorik bir saldırı yönteminin gösterilmesi veya açığa yüksek bir teknik önem derecesi verilmesi, tek başına aktif istismar bildiriminin koşullarını karşılamaz. İlk örnekte müşteri kayıtlarının önemi de buradadır: Kayıtlar yalnızca bir zayıflığın bulunabileceğini değil, gerçekten izinsiz kullanıldığını gösteriyorsa hukuki değerlendirme değişir. Bildirim için ayrıca üreticinin kendisinin saldırıya uğraması veya kişisel veri kaybı yaşanması aranmaz.³⁹

Ürünün güvenliğini etkileyen ciddi olay

İkinci kategori, ürünün güvenliğini etkileyen ciddi olaydır. 14(5). madde, hassas veya önemli veri ve işlevlerin erişilebilirliğini, aslına uygunluğunu (authenticity), bütünlüğünü ya da gizliliğini koruma kabiliyetini olumsuz etkileyen veya etkileyebilecek olayları kapsar. Ürüne ya da kullanıcının ağ ve bilgi sistemlerine kötü amaçlı kod eklenmesine veya çalıştırılmasına yol açan ya da açabilecek olaylar da bu çerçevededir.¹⁰

Örneğin üreticinin güncelleme mekanizmasının ele geçirilmesi ve cihazlara zararlı yazılım gönderilebilmesi, yalnızca müşteri verisinin çalınıp çalınmadığı sorusuyla değerlendirilemez. Ürünün güvenilir biçimde çalışması ve kullanıcı sistemlerini koruması bakımından ciddi bir güvenlik sorunu söz konusudur. Bunun tersine, ürün güvenliğiyle ilgisiz kısa bir kurumsal e-posta kesintisi otomatik olarak aynı kategoriye girmez.¹⁰

Bir olay iki kategori açısından da inceleme gerektirebilir. Doğru yaklaşım, önce mevcut teknik bulguları ortaya koymak, ardından hangi hukuki eşiğin neden oluştuğunu kaydetmektir. “Henüz her şeyi bilmiyoruz” ile “Bildirime tabi bir durumdan henüz haberdar değiliz” aynı ifade değildir.

4. İlk 24 ve 72 saatte ne bekleniyor?

CRA, şirketin ilk saatlerde tamamlanmış bir adli bilişim raporu sunmasını bekleyen tek aşamalı bir sistem kurmuyor. Önce erken uyarı, ardından daha ayrıntılı bildirim ve sonrasında nihai rapor öngörüyor. Böylece yetkili makamlar başlangıçta mevcut bilgilerle haberdar olurken, inceleme ilerledikçe dosya tamamlanabiliyor.¹¹

Dayanak: CRA m. 14(2) ve 14(4). İlgili bilgilerin daha önce verilmiş olmasına ilişkin hükümler saklıdır; koordinatör CSIRT gerekli hâllerde ara rapor da isteyebilir.¹¹

24 ve 72 saatlik süreler birbirine eklenmez. İkisi de bildirime tabi durumun öğrenilmesinden itibaren hesaplanır. Erken uyarıyı göndermek yeni bir 72 saat başlatmaz. Ayrıca “en geç” ifadesi, sebepsiz yere son saate kadar bekleme hakkı tanımaz; her iki aşamada da gereksiz gecikme olmaksızın hareket edilmelidir.¹¹

Varsayımsal örneğimizde şirketin aktif istismarı 14 Eylül 2026 saat 10.00’da öğrendiğini kabul edelim. Bütün saatler Türkiye saatiyle gösterilmek üzere erken uyarının üst sınırı 15 Eylül saat 10.00, ayrıntılı bildirimin üst sınırı 17 Eylül saat 10.00 olur. Şirket erken uyarıyı 14 Eylül saat 12.00’de gönderirse ikinci son tarih değişmez. Bu örnek, bildirime tabi durumun belirtilen anda öğrenildiği varsayımına dayanır; gerçek dosyada başlangıç anının ayrıca belirlenmesi gerekir.

Öğrenme anı, yönetimin toplantı yaptığı veya hukuk biriminin metni onayladığı saatle özdeşleştirilmemelidir. İlk şüpheli sinyal ile aktif istismara ilişkin güvenilir kanıtın elde edilmesi farklı zamanlarda gerçekleşebilir. Şirket, hangi bilginin ne zaman geldiğini ve o bilgiyle hangi değerlendirmeye ulaşıldığını gösterebilmelidir. Sırf iç onay mekanizması tamamlanmadığı için kanuni başlangıç anının ileri taşındığı varsayılamaz.⁹¹¹

Raporlar hangi bilgiyi vermeli?

Erken uyarının işlevi, makamı durumdan süratle haberdar etmektir. Ürünün sunulduğu bilinen üye devletler, uygulanabildiği ölçüde bildirilir; ciddi olayda hukuka aykırı veya kötü niyetli fiil şüphesinin bulunup bulunmadığı da belirtilir. Ayrıntılı aşamada ürün, açık veya olayın niteliği, mevcut ilk değerlendirme, alınan önlemler ve kullanıcıların uygulayabileceği tedbirler daha belirgin hâle gelir. Sunulan bilginin hassasiyeti de gerektiğinde açıklanır.¹¹

Nihai rapor ise yalnızca “Sorun çözüldü” cümlesinden ibaret değildir. Açık bakımından önem derecesi ve etki, mevcutsa istismarı gerçekleştiren aktöre ilişkin bilgi ve sunulan düzeltmeler; ciddi olay bakımından olayın ayrıntıları, muhtemel tehdit veya kök neden ile uygulanan ve devam eden risk azaltıcı önlemler ele alınır.¹¹

Buradaki 14 gün, açığı gidermek için tanınmış genel bir bekleme süresi değildir. Düzeltici veya risk azaltıcı önlem hazır olduğunda başlayan nihai rapor süresidir. Kullanıcıların uygulayabileceği geçici bir önlemin ortaya çıkması da önem taşıyabilir; kalıcı yama henüz yayımlanmadı diye sürenin başlamadığı peşinen kabul edilmemelidir. Ciddi olay içinse düzenlemedeki ifade “30 gün” değil, ilgili olay bildiriminin sunulmasından itibaren “bir ay”dır.¹¹

5. SRP’de “tek bildirim” tam olarak ne demek?

SRP, aynı bilgilerin ilgili ulusal makamlara ve ENISA’ya ortak bir kanal üzerinden ulaştırılmasını sağlar. Buradaki “tek”, tek seferde bütün işin bitmesini değil, ilgili makamlara ayrı ayrı başvuru yapılmasını azaltan ortak bildirim yolunu anlatır. Erken uyarı, ayrıntılı bildirim ve nihai rapor aşamaları devam eder.¹²

Muhatap, ilgili üye devletin koordinatör olarak belirlenmiş bilgisayar güvenliği olaylarına müdahale ekibidir (CSIRT). Kural olarak bildirim ENISA’ya da eş zamanlı açılır; ilk alan CSIRT, ürünü ilgilendiren diğer üye devletlerin koordinatör CSIRT’leriyle paylaşımı yürütür. Hangi ülkenin seçileceği, 14(7). maddeye göre belirlenir.¹²

AB’de ana kuruluşu bulunan üretici açısından, ürün siber güvenliği kararlarının ağırlıklı olarak alındığı yer önemlidir; bu yer belirlenemiyorsa AB’de en fazla çalışanın bulunduğu kuruluş esas alınır. AB’de ana kuruluşu bulunmayan üreticide ise mevcut bilgiye göre sırasıyla, en fazla sayıdaki ürünü için hareket eden yetkili temsilcinin, en fazla ürününü piyasaya arz eden ithalatçının, en fazla ürününü piyasada bulunduran dağıtıcının bulunduğu üye devlet ve son olarak en fazla kullanıcının bulunduğu üye devlet dikkate alınır. Son kullanıcı ölçütüne göre yapılan ilk bildirimden sonra aynı CSIRT’ye başvurmaya devam edilebilmesine ilişkin özel hüküm de vardır.¹²

Bu nedenle örneğimizde Almanya’daki müşterinin ilk ihbarı yapmış olması, Almanya’yı kendiliğinden doğru muhatap hâline getirmez. Şirketin temsilci ve dağıtım düzeni de incelenmelidir.

Platforma girmek ile bildirimi göndermek farklı işlemler

ENISA’nın kayıt rehberine göre erişim için çok faktörlü kimlik doğrulama etkinleştirilmiş bir EU Login hesabı gerekir. Temsil yetkisinin CSIRT tarafından doğrulanması ilk bildirimi bekletmez; doğrulama bildirim süreciyle paralel ilerleyebilir. ENISA, SRP kaydının ve doğrulama sürecinin somut bildirim ihtiyacı ortaya çıktığında başlatılmasını, ihtiyaten ön kayıt yapılmamasını tavsiye ediyor.¹³

Bu, şirketin hazırlıksız kalması gerektiği anlamına gelmez. Bildirimi yapacak kişi, yedeği, erişim hesabı ve gerekli bilgiler önceden belirlenebilir. Ancak formu taslak olarak kaydetmekle göndermek farklıdır: Gönderim durumu, bildirim kimliği ve teyit kayıtları kontrol edilmelidir. Platformdaki süre göstergeleri de kanuni sürenin yerine geçen bir hukuki hesaplama olarak kabul edilmemelidir.¹⁴

6. Yetkili makama bildirmek, müşteriyi bilgilendirmek ve kamuya açıklamak aynı şey değil

Bir açığın teknik ayrıntılarının erken yayılmasının yeni saldırıları kolaylaştırabileceği kaygısı anlaşılabilir. Ancak bu kaygı, üreticinin yasal bildirimi kendi kararıyla erteleyebilmesi anlamına gelmez.

CRA’nın 16. maddesi ve Komisyon Yetki Devrine Dayanan Tüzüğü (AB) 2026/881, haklı siber güvenlik gerekçeleriyle makamlar arasındaki paylaşımın belirli koşullarda geciktirilmesine ilişkin kurallar içerir. Paylaşımı sınırlama veya erteleme mekanizması ile üreticinin ilk bildirim yükümlülüğü farklı şeylerdir. Özellikle istisnai durumlarda ENISA’nın tam içeriğe hemen erişiminin sınırlanabildiği düzenleme de genel bir ticari sır itirazı değil, belirli şartlara bağlı dar bir mekanizmadır.¹⁵

Öte yandan, 14(8). madde etkilenen kullanıcıların ve uygun olduğunda bütün kullanıcıların bilgilendirilmesini de öngörür. Gerektiğinde kullanıcıların uygulayabileceği düzeltici ve risk azaltıcı önlemler aktarılmalıdır. Bu nedenle SRP bildirimi, müşteriye hiçbir şey söylenmeyeceği anlamına gelmez.¹⁶

Kamuya açıklama ise ayrı bir karardır. CRA’nın 17(2). maddesine göre, kamuoyunun bilgilendirilmesi ciddi olayın önlenmesi veya etkisinin azaltılması için gerekliyse ya da açıklama kamu yararına hizmet ediyorsa, koordinatör CSIRT kamuoyunu bilgilendirebilir veya üreticiden bunu yapmasını isteyebilir. Bu yetki, üreticinin her bildirimi kendiliğinden kamuya açıklaması gerektiği anlamına gelmez.²⁰

Örneğimizde yetkili makama ürün sürümleri ve istismar bulguları anlatılırken, müşterinin ihtiyaç duyduğu bilgi daha uygulamaya dönük olabilir: Hangi cihazlar etkileniyor, hangi uzaktan erişim işlevi kapatılmalı, mevcut önlem nasıl uygulanmalı? Bildirime eklenecek teknik raporla müşteri güvenlik duyurusunun aynı metin olması gerekmez. Buna karşılık kapsam, etki ve alınan önlemler konusunda birbirleriyle çelişmemeleri gerekir.

7. KVKK, GDPR, NIS2 ve DORA bakımından ne değişmiyor?

CRA, diğer bildirim rejimlerini tek bir başvuruya dönüştürmez. Aynı olay, farklı hukuki sorular doğurabilir. CRA ürünün güvenliğine bakarken, GDPR kişisel veri ihlalini ve kişilerin hak ve özgürlükleri bakımından riskini değerlendirir. NIS2, kapsamındaki kuruluşların hizmet sunumuna önemli etkisi olan olayları ele alır. DORA ise ilgili finansal kuruluşlar için büyük bilgi ve iletişim teknolojisi olaylarına ilişkin ayrı hükümler içerir. Her rejimin kapsamı ve aralarındaki özel hüküm ilişkisi ayrıca incelenmelidir.¹⁷

Türkiye’de kişisel verilerin hukuka aykırı şekilde başkalarınca elde edilmesi söz konusuysa, KVKK’nın 12(5). maddesi ve Kurulun 2019/10 sayılı kararı ayrıca değerlendirilir. Karar, Kurula bildirimin öğrenmeden itibaren gecikmeksizin ve en geç 72 saat içinde yapılmasını öngörür. CRA kapsamında SRP’ye gönderilen bildirim bu yükümlülüğün yerine geçmez.¹⁸

Örnekte başlangıçta kişisel veri ihlali tespit edilmemesi, CRA değerlendirmesini ortadan kaldırmaz. İnceleme ilerledikçe müşteri verisine yetkisiz erişim de ortaya çıkarsa, şirketin veri sorumlusu veya veri işleyen olarak rolü ve ilgili bildirim rejimi ayrıca değerlendirilir. Bir olay dosyası tutulabilir; fakat bütün mevzuat için tek eşik ve tek süre varmış gibi davranılamaz.

Türkiye’deki diğer siber güvenlik ve sektörel yükümlülükler de CRA’dan bağımsız olarak incelenmelidir. Bu daha geniş çerçeve, Bir Siber Olayın İlk 24 Saati başlıklı çalışmada ayrıca ele alınıyor.

8. Şirketin hazırlığı bir formdan ibaret olmamalı

Şirket açısından uygulanabilir hazırlık, ilk olay yaşanmadan önce üç konuyu birbirine bağlamaktır: ürün bilgisi, karar yetkisi ve delillendirilebilir zaman çizelgesi. Aşağıdaki yaklaşım, mevzuatta bu adlarla zorunlu kılınmış bir organizasyon şeması değil; bildirim yükümlülüğünü zamanında yerine getirmeye yönelik uygulama önerisidir.

Önce AB’ye sunulan ürünlerin, önemli sürümlerin, ürün içindeki bileşenlerin ve uzaktan veri işleme bağımlılıklarının görünür olması gerekir. Teknik ekip hangi ürünün etkilendiğini hızla belirleyemiyorsa, hukuk ekibinin bildirimin kapsamını doğru kurması da güçleşir. Aynı dosyada şirketin üretici rolü ve seçilecek CSIRT’nin gerekçesi bulunmalıdır.

Sonra karar yolu netleştirilmelidir. İlk teknik bulguyu kim değerlendirecek, hukuk birimi ne zaman devreye girecek, bildirimi kim gönderecek ve bu kişiye ulaşılamazsa kim hareket edecek? Bildirim metninin doğruluğu önemlidir; ancak şirket içindeki çok katmanlı onay zinciri, mevcut bilgilerin zamanında sunulmasını engellememelidir. Bir tatbikatta bu sorulara cevap verilemiyorsa yalnızca yazılı politika hazırlanmış olması yeterli bir operasyonel güvence oluşturmaz.

Tedarikçi ilişkileri de bu süreçten ayrı değildir. Açık bir üçüncü taraf bileşeninden kaynaklanıyorsa, üretici etkilenen sürümleri ve geçici önlemleri tedarikçiden öğrenmek zorunda kalabilir. Sözleşmede genel bir “güvenlikte iş birliği” maddesi bulunması yerine, teknik bilginin ne zaman, kime ve hangi kapsamda aktarılacağı açıklığa kavuşturulmalıdır. Başka bir şirketin bildirim yapacağını söylemesi, ürün üreticisinin kendi yükümlülüğünü değerlendirmesini gereksiz kılmaz.³

Son olarak olay dosyası, yalnızca teknik kayıtları değil kararların seyrini de göstermelidir. İlk bulgu ne zaman geldi? Aktif istismarı gösteren güvenilir bilgi ne zaman elde edildi? Hangi bilgi hangi rapora girdi? Düzeltici veya risk azaltıcı önlem ne zaman kullanılabilir oldu? Bu kayıt düzeni, sürelere uyumu ve sonraki açıklamaların tutarlılığını göstermek bakımından önemlidir.

Tedarikçinin olaya dahil olduğu durumlarda sorumluluğun ve sözleşmesel iş birliğinin nasıl ele alınacağına ilişkin daha geniş değerlendirme için bulut sağlayıcı veri ihlali ve sorumluluk başlıklı çalışma da okunabilir.

Para cezası tartışmasında tarih ayrımı korunmalı

CRA’nın 64. maddesindeki idari para cezası rejimi, Tüzüğün genel uygulama tarihi olan 11 Aralık 2027’den itibaren uygulanır. 2026–2027 ara dönemindeki sonuçlar ilgili üye devlet hukuku çerçevesinde ayrıca incelenmelidir. Bu zaman ayrımı, 11 Eylül 2026’da başlayan bildirim yükümlülüğünü ortadan kaldırmaz.¹⁹

64. madde uygulanmaya başladığında, 14. maddeye aykırılık için öngörülen idari para cezası üst sınırı 15 milyon avro veya teşebbüsler bakımından bir önceki mali yılın toplam dünya cirosunun yüzde 2,5’idir; hangisi yüksekse o esas alınır. Bu, her olayda otomatik uygulanacak sabit bir ceza değil, kanuni üst sınırdır.¹⁹

64. madde uygulanmaya başladığında, düzeltmeleri işlenmiş konsolide metindeki 64(10). madde mikro ve küçük işletme niteliğindeki üreticiler için yalnızca belirtilen 24 saatlik erken uyarı sürelerine ilişkin dar bir idari para cezası istisnası getirir. Bu, KOBİ’ler için genel bir bildirim muafiyeti değildir; 72 saatlik bildirimi ve nihai raporu ortadan kaldırmaz.¹⁹

Sonuç: Cyber Resilience Act bildirim yükümlülükleri ve ürün güvenliği

Başlangıçtaki Türk üretici örneğine dönersek, şirketin güvenlik açığını gidermesi gerekli teknik çalışmadır; fakat CRA bakımından dosyayı tek başına kapatmaz. Ürünün kapsamı, olayın bildirim eşiği, öğrenme anı, doğru makam, takip raporları ve kullanıcı iletişimi de değerlendirilmelidir.³¹¹¹⁶

Yeni dönemin özü budur: AB pazarına dijital ürün sunan şirket, ürününde ciddi bir güvenlik sorunu ortaya çıktığında yalnızca çözüm üreten değil, bildirime tabi durumu zamanında tanıyıp doğru bilgiyi doğru muhataba ulaştırabilen bir organizasyona ihtiyaç duyar. SRP bu iletişimin aracıdır; hukuki değerlendirmeyi, teknik incelemeyi veya şirket içindeki karar düzenini onun yerine yapmaz.

Bu çalışma genel bilgilendirme amaçlıdır. Türkiye bağlantılı şirketler bakımından AB düzenlemesinin ürün ve bildirim boyutunu açıklar; belirli bir üye devlet hukukunda mesleki yetki veya somut olay hakkında hukuki görüş iddiası içermez. Ürün kapsamı, bildirim eşiği, süre ve yaptırımlar somut olayda ayrıca değerlendirilmelidir. Örnek olay ve tarihler açıklama amacıyla kurgulanmıştır.

Kaynaklar ve hukuki dayanaklar

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), m. 14 ve 71(2), EUR-Lex, düzeltmeleri işlenmiş konsolide metin.↩

2. ENISA, “The CRA Single Reporting Platform is launched”, 11 Eylül 2026; Avrupa Komisyonu, “Cyber Resilience Act – Reporting obligations”, erişim tarihi 13 Eylül 2026.↩

3. CRA, m. 14(1), 14(3) ve 14(5), konsolide metin. Örneğin hukuki değerlendirmesi bu hükümlere dayanmaktadır; gerçek bir olay aktarılmamaktadır.↩

4. CRA, m. 1, 13 ve Ek I; gerekçeler 1–4, Resmî Gazete metni.↩

5. CRA, m. 69(2)–(3), konsolide metin.↩

6. CRA, m. 2(1), 3(1), 3(6), 3(13), 3(21)–(22), konsolide metin.↩

7. CRA, m. 3(1)–(2), gerekçeler 11–12, Resmî Gazete metni; Avrupa Komisyonu, “The Cyber Resilience Act – Summary of the legislative text”, kapsam açıklaması.↩

8. CRA, gerekçe 18 (Resmî Gazete metni); m. 2(2)–(4), 3(14), 3(22), 24(3) ve 71(2), konsolide metin; ENISA, 11 Eylül 2026 tarihli SRP duyurusu, “Who is the platform for?” bölümü.↩

9. CRA, m. 3(40) ve 3(42), konsolide metin.↩

10. CRA, m. 14(5)(a)–(b), konsolide metin.↩

11. CRA, m. 14(2), 14(4) ve 14(6), konsolide metin.↩

12. CRA, m. 14(7) ve 16(1)–(2), konsolide metin.↩

13. ENISA, “CRA SRP Guidance – AR User Registration”, son güncelleme 12 Eylül 2026, “General Notes”.↩

14. ENISA, “CRA SRP Guidance – AR Notification submission and update”, son güncelleme 12 Eylül 2026; SRP Frequently Asked Questions, soru 26. Arayüz özellikleri değişebileceğinden kullanım anında güncel rehber kontrol edilmelidir.↩

15. CRA, m. 16(2); Commission Delegated Regulation (EU) 2026/881, m. 1, 3–5; ENISA, “Particular Exceptional Circumstances (PEC)”.↩

16. CRA, m. 14(8), konsolide metin.↩

17. Regulation (EU) 2016/679 (GDPR), m. 33–34; Directive (EU) 2022/2555 (NIS2), m. 4 ve 23; Regulation (EU) 2022/2554 (DORA), m. 1(2) ve 19.↩

18. Kişisel Verileri Koruma Kurulu, 24 Ocak 2019 tarihli ve 2019/10 sayılı karara ilişkin duyuru; 6698 sayılı Kanun, m. 12(5).↩

19. CRA, m. 64(2), 64(5), 64(10) ve 71(2), düzeltmeleri işlenmiş konsolide metin. 64(10). maddenin ilk cümlesi için 2 Temmuz 2025 tarihli C2 düzeltmesi dikkate alınmıştır. 2026–2027 döneminin üye devlet bazında yaptırım uygulaması bu çalışmada incelenmemektedir.↩

20. CRA, m. 17(2), düzeltmeleri işlenmiş konsolide metin.↩