DORA ICT Risk Yönetimi Çerçevesi 2026: Articles 6–15 Kontrol ve Belge Rehberi
| DORA maddesi | Kontrol alanı | Temel kanıt |
|---|---|---|
| Article 6 | ICT risk management framework | Framework, strategy, yıllık review |
| Article 7 | ICT systems/protocols/tools | Architecture, lifecycle, capacity |
| Article 8 | Identify/classify | Critical function + asset inventory |
| Article 9 | Protection/prevention | Access, network, change, patch controls |
| Article 10 | Detection | Monitoring, alerting, anomaly thresholds |
| Articles 11–12 | Response, recovery, backup | BCP/DR, RTO/RPO, restore tests |
| Articles 13–14 | Learning + communication | Post-incident review, training, crisis comms |
DORA Article 6 ICT risk management framework nedir?
Regulation (EU) 2022/2554 Article 6(1), finansal kuruluşların genel risk management system’larının parçası olarak sağlam, kapsamlı ve iyi belgelenmiş bir ICT risk management framework kurmasını zorunlu tutar. Bu çerçeve ICT riskini hızlı, etkili ve kapsamlı biçimde ele almalı ve yüksek dijital operasyonel dayanıklılık sağlamalıdır.
Article 6(2), framework’ün bilgi varlıkları ve ICT varlıklarını korumaya gerekli strateji, politika, prosedür, ICT protokolü ve araçları içermesini ister. Kapsam yalnız yazılım ve sunucu değildir; donanım, fiziksel bileşenler, tesisler, veri merkezleri ve hassas alanlar da dahildir. Bu nedenle DORA risk çerçevesi hem siber hem operasyonel ve fiziksel bağımlılıkları kapsar.
Microenterprise dışındaki finansal kuruluşlarda ICT riskinin yönetimi ve gözetimi uygun bağımsızlığa sahip control function’a atanmalı; ICT risk management, control ve internal audit fonksiyonları arasında three lines of defence veya eşdeğer kontrol modeliyle görev ayrılığı kurulmalıdır. Aynı kişinin riski işletip kendi kontrolünü bağımsız denetlemesi Article 6 yönetişim mantığıyla bağdaşmaz.
Article 7: ICT sistemleri, protokolleri ve araçları nasıl olmalı?
Article 7, finansal kuruluşun ICT sistem, protokol ve araçlarının operasyonlarının yürütülmesine uygun, güvenilir ve yeterli kapasitede olmasını; teknolojik olarak dayanıklı tutulmasını ve ICT riskine karşı uygun güvenlik sağlamasını hedefler. Kullanım ömrü bitmiş, kritik güvenlik güncellemesi alamayan veya kapasite olarak kritik fonksiyonu taşıyamayan sistemler risk yönetiminde özel takip gerektirir.
Kuruluş teknoloji yaşam döngüsü envanteri tutmalıdır. İşletim sistemi, veri tabanı, ağ cihazı, uygulama framework’ü, kriptografik bileşen, SaaS veya bulut servisi için owner, criticality, version, support end date ve dependency kayıtları tutulabilir.
Capacity management da dayanıklılığın parçasıdır. Kritik bir ödeme sisteminin normal günlük hacimde çalışması yeterli değildir; yoğun işlem, saldırı, failover veya veri kurtarma sırasında kapasite düşüşü planlanmalıdır. Performans ve kaynak eşikleri izlenmeli, otomatik alarm ve ölçekleme süreçleri test edilmelidir.
Article 8: kritik fonksiyonlar ve ICT varlıkları nasıl tanımlanır?
Article 8 “identification” alanını düzenler. Finansal kuruluş bilgi destekli business functions, görev ve sorumluluklar ile bu fonksiyonları destekleyen bilgi/ICT varlıklarını tanımlamalı, sınıflandırmalı ve dokümante etmelidir. Hangi sistemin hangi kritik veya önemli fonksiyona hizmet ettiği açık değilse riskin iş etkisi ölçülemez.
Envanter server listesiyle sınırlı olmamalıdır. Uygulama, veri tabanı, network, cloud resource, API, sertifika, service account, vendor connection, endpoint, fiziksel cihaz ve bilgi varlığı ilişkilendirilmelidir. Her varlığın sahibi ve business function bağlantısı belirlenmelidir.
Değişikliklerde envanter güncellenmelidir. Yeni SaaS alınması, merger, cloud migration, API açılması veya tedarikçi değişikliği business-impact mapping’i etkileyebilir. Shadow IT ve iş birimlerinin merkezi güvenlik dışında aldığı servisler Article 8 görünürlüğünü zayıflatır.
Article 9 protection and prevention kontrolleri neleri kapsar?
Article 9, ICT systems’in resilience, continuity ve availability’sini korumak ve veri availability, authenticity, integrity ve confidentiality’sini güvence altına almak için uygun ICT security policies, procedures, protocols ve tools ister. Risk temelli savunma katmanları kurulmalıdır.
Erişim kontrolü, strong authentication, network segmentation, encryption, secure configuration, change management, patching, endpoint security, logging, vulnerability management ve physical/environmental security uygulamada bu alanın parçalarıdır. Kontroller kritik fonksiyon ve veri sınıfına göre derinleştirilir.
Change management özel öneme sahiptir. Üretim değişikliği test edilmeli, onaylanmalı ve rollback planı bulunmalıdır. Acil güvenlik değişiklikleri hızlandırılmış süreçle yapılabilir; ancak kayıt ve bağımsız review ortadan kalkmamalıdır. Kontrolsüz değişiklik, saldırı kadar hizmet kesintisi yaratabilir.
Article 10 anomalileri ve ICT olaylarını nasıl tespit etmeyi ister?
Article 10, finansal kuruluşların network performance issues ve ICT-related incidents dahil anomalileri hızlı tespit edecek mekanizmalar kurmasını ister. Detection yalnız SIEM lisansı satın almak değildir; normal davranışın, kritik logların, alarm threshold’larının ve escalation kriterlerinin tanımlanması gerekir.
Monitoring coverage kritik fonksiyonlarla ilişkilendirilmelidir. Core banking, ödeme, trading, CASP custody veya müşteri kimlik sistemini destekleyen logların toplanmadığı bir yapıda major incident erken sınıflandırılamaz. Log kaynağı, retention, zaman senkronizasyonu ve bütünlük korunmalıdır.
Anomali tespitinde false positive oranı da yönetilmelidir. Binlerce alarm arasında kritik incident kayboluyorsa kontrol fiilen etkisizdir. Alert severity, owner ve maximum triage time belirlenmelidir.
Article 11 ICT response and recovery nasıl kurulmalı?
Article 11, finansal kuruluşun ICT-related incident sonrası müdahale ve kurtarma kapasitesini iş sürekliliğiyle birleştirir. Kuruluş ICT business continuity policy ile ICT response and recovery plans oluşturmalıdır. Amaç kritik veya önemli fonksiyonlarda kesinti ve zararı sınırlamak, hizmeti belirlenmiş hedeflerde geri getirmektir.
Planlar farklı kriz senaryolarını kapsamalıdır: ransomware, data corruption, cloud outage, telecom failure, insider misuse, identity provider outage veya third-party insolvency. Her senaryoda command structure, technical recovery sequence, internal/external communication ve decision authority belirlenmelidir.
RTO ve RPO kritik fonksiyonun iş etkisine göre tanımlanır. Teknik ekip “backup var” demek yerine, verinin kabul edilebilir kayıp noktası ve hizmetin kabul edilebilir geri dönüş süresini iş birimiyle birlikte belirlemelidir. Test sonucu hedefi karşılamıyorsa risk kaydına ve düzeltici plana aktarılır.
Article 12 backup, restoration ve recovery hangi standardı getirir?
Article 12, minimum downtime, sınırlı disruption ve loss ile ICT systems ve data restoration sağlamak için backup policies/procedures ile restoration/recovery methods’ı zorunlu tutar. Yedekleme sıklığı, kapsamı, izolasyonu ve restore kabiliyeti kritik fonksiyonlara göre belirlenmelidir.
Ransomware senaryosunda üretim sistemiyle aynı kimlik alanında veya aynı erişim hesabıyla yönetilen online backup saldırgan tarafından şifrelenebilir. Immutable veya offline copy, ayrılmış admin hesapları, MFA ve ayrı network segmenti gibi kontroller risk temelli uygulanabilir.
Restore testi yalnız tek dosya geri getirmek değildir. Kritik uygulama, veri tabanı, sertifika, konfigürasyon ve bağımlılıkların birlikte geri dönüşü end-to-end test edilmelidir. Test zamanı, veri kaybı ve hatalar kaydedilip RTO/RPO ile karşılaştırılmalıdır.
Article 13 learning and evolving neden ayrı bir DORA alanıdır?
Article 13, finansal kuruluşların incidents, testing, audit ve dış tehdit gelişmelerinden sürekli öğrenmesini ister. Post-incident review mekanizması major ICT-related incident’ın kök nedenlerini, müdahale etkinliğini ve kontrol boşluklarını değerlendirmelidir.
Lessons learned yalnız rapor olarak kalmamalı; risk assessment, policies, procedures, training ve technology roadmap’e aktarılmalıdır. Aynı phishing incident veya failover hatası tekrarlanıyorsa öğrenme döngüsü çalışmıyor demektir.
Article 13 ayrıca ICT security awareness programmes ve digital operational resilience training’in personel eğitim şemalarının zorunlu modülü olmasını öngörür. Eğitim görev bazlı olmalıdır: developer secure coding, SOC incident classification, legal/regulatory reporting, management Article 5 governance gibi farklı içerikler gerekir.
Article 14 kriz iletişimini nasıl düzenler?
Article 14, ICT risk management framework’ün parçası olarak major ICT-related incidents veya vulnerabilities hakkında clients, counterparts ve gerektiğinde kamuya sorumlu açıklama yapabilecek crisis communication plans bulunmasını ister.
İletişim planında kim onay verir, kim sözcüdür, regulator notification ile public communication nasıl koordine edilir, müşteri hangi kanaldan bilgilendirilir ve teknik detaylar hangi seviyede paylaşılır soruları önceden cevaplanmalıdır.
Normal kurumsal e-posta incident nedeniyle çalışmıyorsa alternatif iletişim kanalı bulunmalıdır. Kriz anında rastgele kişisel hesaplarla haberleşme; gizlilik, kayıt, kişisel veri ve delil bütünlüğü sorunları yaratabilir.
Article 6 yıllık review ve iç denetimi nasıl zorunlu tutar?
Article 6(5), microenterprise dışındaki finansal kuruluşlarda ICT risk management framework’ün en az yılda bir kez ve ayrıca major ICT-related incident, supervisory instruction veya relevant testing/audit sonucu sonrasında gözden geçirilmesini ister. Framework implementation ve monitoring’den öğrenilen derslerle sürekli iyileştirilmelidir.
Article 6(6) framework’ün düzenli iç denetime tabi olmasını; denetçilerin ICT risk konusunda yeterli knowledge, skills and expertise ve uygun independence’a sahip olmasını ister. Article 6(7), internal audit review sonuçları için kritik ICT audit findings’in zamanında doğrulanması ve giderilmesini içeren formal follow-up process zorunluluğu getirir.
Yönetim organı Article 5(2)(f) uyarınca audit planlarını onaylar. Audit issue kapanışlarının periyodik rapora girmesi Article 5 ve Article 6’yı birbirine bağlar.
DORA ICT risk framework için 2026 belge seti
- ICT risk management framework ve digital operational resilience strategy,
- ICT risk tolerance ve risk register,
- critical/important functions mapping,
- information/ICT asset inventory ve dependency map,
- security policies, access, change, patch ve vulnerability procedures,
- detection/monitoring coverage ve escalation matrix,
- ICT business continuity ve response/recovery plans,
- backup/restore test raporları ve RTO/RPO sonuçları,
- post-incident review ve lessons learned kayıtları,
- awareness/training kayıtları,
- crisis communication plan,
- annual framework review ve internal audit follow-up register.
Yönetim organının bu çerçevedeki sorumluluğu DORA Article 5 yönetim kurulu rehberinde, genel kapsam ise DORA 2026 ana rehberinde açıklanmıştır.
Sık sorulan sorular
DORA ICT risk framework hangi maddede?
Temel çerçeve Article 6’da; sistem, tanımlama, koruma, tespit, response/recovery, backup, learning ve communication Articles 7–14’te düzenlenir.
Framework yılda kaç kez gözden geçirilir?
Microenterprise dışındaki finansal kuruluşlarda Article 6(5) en az yılda bir review ister; major incident ve önemli supervisory/testing/audit sonuçları da ek review tetikleyebilir.
ICT iç denetimi zorunlu mu?
Evet. Article 6(6), microenterprise dışındaki kuruluşlarda framework’ün audit planıyla uyumlu düzenli iç denetimini öngörür.
Destek süresi bitmiş sistem DORA’ya aykırı mı?
Tek başına otomatik ihlal sonucuna varılmaz; ancak Article 7 kapsamında resilient ve uygun sistem/araç gereği nedeniyle EOL sistemi risk, telafi kontrolü ve migrasyon planıyla yönetilmelidir.
Yedek almak yeterli mi?
Hayır. Article 12 restoration ve recovery kabiliyetini de ister; restore testleri ve RTO/RPO doğrulaması gerekir.
Post-incident review zorunlu mu?
DORA Articles 13 ve ilgili incident framework, olaylardan öğrenme ve framework’ü iyileştirme beklentisini açıkça kurar.
Çalışan eğitimi DORA’da zorunlu mu?
Article 13, ICT security awareness ve digital operational resilience training’i personel eğitim şemalarının zorunlu modülleri arasına alır.
Kriz iletişim planı hangi maddede?
Article 14, major ICT incidents ve vulnerabilities için responsible disclosure yapabilecek crisis communication planlarını düzenler.
DORA yalnız siber saldırıları mı kapsar?
Hayır. ICT risk; arıza, kesinti, kapasite, insan hatası, tedarikçi sorunu, veri kaybı ve diğer dijital operasyonel riskleri de kapsar.
Bakırcı & Keskin Hukuk Bürosu
Bu yazı genel hukuki bilgilendirme amacı taşır; ICT risk framework finansal kuruluşun risk profili, ölçeği ve kritik fonksiyonlarına göre tasarlanmalı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.
