NIS2 Article 21 Siber Risk Yönetimi 2026: Zorunlu 10 Güvenlik Tedbiri
| Article 21(2) alanı | Hukuki hedef | Örnek kanıt |
|---|---|---|
| Risk analizi | Riskleri sistematik belirlemek ve yönetmek | Risk envanteri, politika, risk kabul kararları |
| Olay yönetimi | Olayı tespit, sınıflandırma, müdahale ve bildirim | IR planı, loglar, tatbikat |
| İş sürekliliği | Kritik hizmetleri sürdürebilmek | BCP/DR, yedek dönüş testi |
| Tedarik zinciri | Üçüncü taraf risklerini yönetmek | Due diligence, güvenlik ekleri |
| Güvenli geliştirme | Zafiyetleri yaşam döngüsünde azaltmak | SDLC, yama ve disclosure kayıtları |
| Kimlik ve erişim | Yetkisiz erişimi önlemek | MFA, RBAC, hesap gözden geçirmesi |
NIS2 Article 21’in temel hukuki kuralı nedir?
Directive (EU) 2022/2555 Article 21, essential ve important kuruluşların ağ ve bilgi sistemlerine yönelik riskleri yönetmek ve olayların hizmet alıcıları ile diğer hizmetler üzerindeki etkisini önlemek veya en aza indirmek amacıyla uygun ve orantılı teknik, operasyonel ve organizasyonel tedbirler almasını ister. Tedbirlerin “state of the art” ve uygulanabilir standartları dikkate alması; mevcut risk derecesiyle orantılı olması gerekir.
Orantılılık değerlendirmesinde kuruluşun riske maruz kalma derecesi, büyüklüğü, olayların gerçekleşme olasılığı, olayın ciddiyeti ve toplumsal/ekonomik etkisi dikkate alınır. Bu nedenle NIS2, her şirkete aynı marka güvenlik ürününü satın alma zorunluluğu getirmez. Hukuki zorunluluk, riskle uyumlu güvenlik seviyesinin kurulmasıdır.
Article 21 aynı zamanda “all-hazards approach” benimser. Yalnız kötü niyetli hacker saldırıları değil; insan hatası, tedarikçi arızası, fiziksel olay, sistem hatası, doğal afet veya iletişim kesintisi gibi ağ ve bilgi sistemlerinin güvenliğini etkileyebilecek nedenler de risk analizine alınmalıdır.
1. Risk analizi ve bilgi sistemi güvenliği politikaları
Article 21(2)(a), risk analizi ve bilgi sistemi güvenliğine ilişkin politikaları ilk zorunlu alan olarak sayar. Kuruluşun hangi varlıkları koruduğu, hangi tehditlere maruz kaldığı, hangi zafiyetlerin bulunduğu ve risklerin kabul/azaltma/transfer/kaçınma yöntemlerinden hangisiyle yönetildiği belgelenmelidir.
Risk analizi bir kez yapılan Excel çalışması değildir. Yeni hizmet, satın alma, birleşme, bulut geçişi, kritik tedarikçi değişikliği, önemli güvenlik olayı veya altyapı değişikliği sonrasında risk kaydı güncellenmelidir. Kritik varlık envanteri ile risk kaydının aynı varlık kimliklerini kullanması izlenebilirliği artırır.
Güvenlik politikası, sorumluları, onay yetkisini, istisna sürecini ve gözden geçirme periyodunu içermelidir. Article 20 yönetim organı sorumluluğu nedeniyle temel kontrol çerçevesinin yönetim organı tarafından onaylanması gerekir.
2. Olayların ele alınması: tespit, müdahale ve kayıt
Article 21(2)(b), olayların ele alınmasını bağımsız bir risk yönetimi alanı olarak düzenler. Kuruluşun olay tespitinden kapatmaya kadar tüm süreci yazılı olmalıdır: alarmın alınması, triage, önem derecesi, teknik müdahale, delillerin korunması, yönetimin bilgilendirilmesi, hukuki değerlendirme, müşteri iletişimi ve resmi bildirim.
Bu süreç Article 23 ile doğrudan bağlantılıdır. “Significant incident” niteliği taşıyan bir olayda 24 saatlik erken uyarı ve 72 saatlik olay bildirimi takvimi, teknik ekip ile hukuk/uyum ekibinin aynı anda çalışmasını gerektirir. Bildirim kararını yalnız olay sonunda vermek NIS2 sistemine uymaz.
Olay kayıtlarında başlangıç zamanı, tespit zamanı, etkilenen hizmet, kullanıcı etkisi, alınan aksiyon, kullanılan göstergeler, üçüncü taraf bağlantıları ve kök neden gibi alanlar bulunmalıdır. Tatbikatlar bu kayıt formu üzerinden yürütülürse gerçek olay hazırlığı güçlenir.
3. İş sürekliliği, yedekleme ve felaket kurtarma
Article 21(2)(c), yedekleme yönetimi ve felaket kurtarma dahil iş sürekliliğini ve kriz yönetimini açıkça sayar. Yalnız “backup alıyoruz” demek yeterli değildir. Kritik hizmet için kabul edilebilir kesinti süresi, kurtarma noktası, kurtarma zamanı ve bağımlılıklar belirlenmelidir.
Yedeklerin gerçekten geri yüklenebilir olduğu test edilmelidir. Fidye yazılımı senaryolarında çevrim içi yedeğin de şifrelenmesi önemli bir risktir; yedek mimarisi değiştirilemez/offline kopya, erişim ayrımı ve geri dönüş testi gibi kontrollerle tasarlanmalıdır.
İş sürekliliği planı tedarikçileri de kapsamalıdır. Tek bulut bölgesi, tek telekom hattı veya tek kimlik sağlayıcısına bağımlılık kritik hizmetin sürekliliğini etkiliyorsa alternatif senaryo ve sözleşmesel çıkış düzeni planlanmalıdır.
4. Tedarik zinciri güvenliği
Article 21(2)(d), kuruluş ile doğrudan hizmet sağlayıcıları veya tedarikçileri arasındaki güvenlik boyutunu kapsayan tedarik zinciri güvenliğini zorunlu tutar. Kuruluş, tedarikçinin yalnız fiyatını ve hizmet seviyesini değil, siber güvenlik uygulamalarını, zafiyetlerini ve ürün/hizmet kalitesini de değerlendirmelidir.
Her tedarikçiye aynı inceleme uygulanması gerekmeyebilir. Kritik verilere erişen, üretim sistemine bağlanan, uzak yönetim yapan, bulut barındırma sağlayan veya önemli hizmetin tek tedarikçisi olan taraflar daha yoğun incelemeye tabi tutulabilir.
Sözleşmelerde olay bildirimi, zafiyet yönetimi, alt yüklenici, denetim, log, erişim, veri iadesi/silme, iş sürekliliği ve sözleşme sonlandırma maddeleri açık olmalıdır. Tedarik zinciri konusunu ayrı rehberde ayrıca derinleştiriyoruz.
5. Güvenli edinim, geliştirme, bakım ve zafiyet yönetimi
Article 21(2)(e), ağ ve bilgi sistemlerinin edinimi, geliştirilmesi ve bakımında güvenliği; zafiyetlerin ele alınması ve açıklanması süreçleri dahil olmak üzere zorunlu kılar. Bu hüküm Secure SDLC, bağımlılık yönetimi, kod incelemesi, test, yama, değişiklik yönetimi ve vulnerability disclosure süreçlerini doğrudan ilgilendirir.
Yeni yazılım satın alınırken güvenlik gereksinimleri satın alma dokümanına yazılmalıdır. “Güvenli olmalı” şeklindeki genel ifade yerine destek süresi, kritik yama süresi, MFA, şifreleme, log, SBOM imkânı, olay bildirimi ve penetrasyon testine ilişkin somut gereklilikler belirlenebilir.
Zafiyet araştırmasının hukuki yetki sınırı önemlidir. Türk şirketleri kendi veya müşteri sistemlerinde test yaparken bug bounty ve yetkilendirilmiş güvenlik testi açısından TCK 243–244 risklerini de dikkate almalıdır.
6. Tedbirlerin etkinliğini değerlendirme
Article 21(2)(f), siber güvenlik risk yönetimi tedbirlerinin etkinliğini değerlendiren politika ve prosedürleri zorunlu alan olarak sayar. Kontrolün varlığı ile çalışması farklı şeylerdir. MFA politikası yazılı olup kritik yönetici hesaplarında MFA kapalıysa kontrol etkili değildir.
Etkinlik; iç denetim, teknik test, güvenlik ölçümleri, masa başı tatbikat, penetrasyon testi, zafiyet taraması, yedek dönüş testi ve tedarikçi denetimleriyle ölçülebilir. Bulguların sahibi ve kapanış tarihi belirlenmeli, tekrar eden yüksek riskler yönetim organına raporlanmalıdır.
Kontrol testleri bağımsızlık ihtiyacına göre iç veya dış kaynakla yapılabilir. Test metodolojisi, kapsamı, sonucu ve düzeltici faaliyet kaydı denetim dosyasında saklanmalıdır.
7. Temel siber hijyen ve siber güvenlik eğitimi
Article 21(2)(g), temel siber hijyen uygulamalarını ve siber güvenlik eğitimini açıkça kapsar. Çalışanlar için kimlik avı, güçlü kimlik doğrulama, cihaz güvenliği, veri sınıflandırma, olay bildirimi ve sosyal mühendislik eğitimleri göreve göre planlanmalıdır.
Eğitim yalnız yıllık video izletme değildir. Kritik rollerdeki geliştiriciler güvenli kodlama; sistem yöneticileri ayrıcalıklı erişim; hukuk ve iletişim ekipleri olay bildirimi ve kriz iletişimi; yönetim organı üyeleri ise Article 20 yönetişim sorumluluğu konusunda ayrı eğitim almalıdır.
Başarı ölçümü yapılmalıdır: eğitim tamamlama oranı, simülasyon sonuçları, yanlış bildirim ve gerçek olay davranışları, tekrar eğitim ihtiyacını gösterir.
8. Kriptografi ve şifreleme politikaları
Article 21(2)(h), kriptografi ve uygun olduğunda şifreleme kullanımına ilişkin politika ve prosedürleri sayar. Hangi verinin aktarımda ve depolamada şifreleneceği, anahtarların kim tarafından yönetileceği, eski algoritmaların nasıl kaldırılacağı ve istisnaların kimce onaylanacağı belirlenmelidir.
Şifreleme yalnız kişisel veri için düşünülmemelidir. Kimlik bilgileri, yedekler, ticari sırlar, API anahtarları, yönetim trafiği ve kritik yapılandırma verileri de risk bazlı olarak korunmalıdır.
Anahtar yönetimi şifrelemenin ayrılmaz parçasıdır. Aynı anahtarı sınırsız kullanmak, anahtarı şifrelenmiş verinin yanında kontrolsüz saklamak veya ayrılan personelin erişimini kapatmamak şifrelemenin etkisini azaltır.
9. İnsan kaynakları güvenliği, erişim kontrolü ve varlık yönetimi
Article 21(2)(i), insan kaynakları güvenliği, erişim kontrol politikaları ve varlık yönetimini birlikte ele alır. Kuruluş kimin hangi sisteme neden eriştiğini bilmeli; yetki en az ayrıcalık prensibine göre verilmeli ve düzenli gözden geçirilmelidir.
İşe giriş, rol değişikliği ve işten ayrılma süreçleri kimlik yaşam döngüsüne bağlanmalıdır. Ayrılan çalışanın hesabının açık kalması, hizmet hesabının sahibinin bilinmemesi veya ortak yönetici hesabı kullanılması NIS2 kontrol olgunluğunu zayıflatır.
Varlık yönetiminde donanım kadar yazılım, bulut kaynağı, sertifika, veri deposu, ağ bağlantısı ve dış hizmetler de kayda alınmalıdır. Bilinmeyen varlık korunamaz ve olay anında etki analizi yapılamaz.
10. MFA, sürekli kimlik doğrulama ve güvenli iletişim
Article 21(2)(j), uygun olduğunda çok faktörlü kimlik doğrulama veya sürekli kimlik doğrulama çözümleri ile güvenli ses, video ve metin iletişimleri ve güvenli acil iletişim sistemlerinin kullanımını öngörür.
MFA önceliği yönetici hesapları, uzaktan erişim, bulut kontrol panelleri, kod depoları, kritik finansal işlemler ve hassas verilere erişen hesaplardan başlamalıdır. Risk, kullanıcı kolaylığı gerekçesiyle belgesiz olarak kabul edilmemelidir.
Acil iletişim sistemi normal kurumsal ağın çökmesi halinde de çalışacak biçimde planlanmalıdır. Fidye yazılımı sırasında e-posta ve kimlik sistemi devre dışı kalabiliyorsa kriz ekibinin alternatif ve önceden test edilmiş kanalı bulunmalıdır.
Article 21 uyumu nasıl kanıtlanır?
NIS2 denetiminde yalnız “politikamız var” demek yeterli değildir. Her Article 21 alanı için politika + uygulama + test + düzeltme kanıtı oluşturulmalıdır. Örneğin tedarik zinciri için politika, tedarikçi risk anketi, sözleşme güvenlik eki, değerlendirme sonucu ve açık bulgu takibi birlikte tutulmalıdır.
Article 20 uyarınca bu çerçeve yönetim organı tarafından onaylanmalı ve gözetime konu edilmelidir. Genel NIS2 kapsam ve bildirim yapısını NIS2 2026 ana rehberimizde açıklıyoruz. Türkiye’deki ayrı yükümlülükler için 7545 sayılı Siber Güvenlik Kanunu rehberi de kontrol edilmelidir.
Sık sorulan sorular
Article 21 kaç güvenlik alanı sayıyor?
Article 21(2), on temel tedbir alanını açıkça sayar; her alan kuruluşun riskine göre somut kontrollere dönüştürülmelidir.
Article 21 yalnız teknik tedbir mi istiyor?
Hayır. Teknik, operasyonel ve organizasyonel tedbirler birlikte gerekir.
ISO 27001 varsa Article 21 tamamlanmış sayılır mı?
Hayır. ISO kontrolleri güçlü bir temel olabilir; fakat NIS2’nin yönetim, olay bildirimi, tedarik zinciri ve diğer hukuki gerekleri ayrıca eşleştirilmelidir.
Yedek almak tek başına yeterli mi?
Hayır. Article 21 iş sürekliliği, yedek yönetimi, felaket kurtarma ve kriz yönetimini birlikte ele alır. Geri dönüş testleri gerekir.
MFA zorunlu mu?
Article 21 uygun olduğunda MFA veya sürekli kimlik doğrulama çözümlerini açıkça sayar. Risk bazlı gerekçe ve uygulama belgelenmelidir.
Tedarikçi güvenliği NIS2’nin açık hükmü mü?
Evet. Article 21(2)(d) tedarik zinciri güvenliğini açıkça zorunlu risk yönetimi alanı olarak düzenler.
Zafiyet yönetimi Article 21’de var mı?
Evet. Article 21(2)(e), zafiyetlerin ele alınması ve açıklanması dahil güvenli edinim, geliştirme ve bakım süreçlerini kapsar.
Article 21 kontrollerini kim onaylar?
Article 20 uyarınca essential ve important kuruluşların yönetim organı Article 21 tedbirlerini onaylar ve uygulanmasını gözetir.
Politika yazmak NIS2 uyumu için yeterli mi?
Hayır. Tedbirlerin fiilen uygulanması, etkinliğinin test edilmesi ve bulguların giderilmesi gerekir.
Bakırcı & Keskin Hukuk Bürosu
Bu yazı genel hukuki bilgilendirme amacı taşır; Article 21 tedbirleri kuruluşun hizmeti, büyüklüğü, risk profili ve tabi olduğu ulusal NIS2 mevzuatına göre somutlaştırılmalıdır.
Hukuki konu hakkında iletişim
İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.
