Annex A Organizasyonel Kontroller: 5. Tema Sahada Nasıl Yorumlanır?

SoA’da 5. temanın karşısına topluca “uygulanıyor” yazıp geçmek, Aşama 2’de en çok soru toplayan hatadır. ISO/IEC 27001:2022 Annex A’daki 93 kontrolün 37’si “organizasyonel kontroller” temasında, 5.1 ile 5.37 arasındadır. En kalabalık tema budur; politikadan bulut kullanımına, olay yönetiminden fikri mülkiyete kadar birbirine benzemeyen konuları toplar. Bu rehber, SoA’yı dolduran ve kontrolleri işleten BGYS sorumluları için bu kontrolleri işlevsel gruplara ayırır; her grup için denetçinin tipik olarak istediği kanıtı ve sahada sık gördüğümüz yorum hatalarını verir.

Organizasyonel kontroller temasının yapısı

2022 revizyonu Annex A’yı dört temaya ayırdı: organizasyonel (5), insan (6), fiziksel (7) ve teknolojik (8). Organizasyonel tema, belirli bir kişiye, fiziksel alana veya teknolojiye bağlanamayan, yönetim kararı ve süreç tasarımı gerektiren kontrolleri toplar. Annex A yalnızca kontrol ifadesini verir; her kontrolün amacı ve uygulama rehberi ISO/IEC 27002:2022’dedir. Yorum yaparken iki dokümanı yan yana açın. Tek başına Annex A yetmez.

37 kontrolü uygulamada altı gruba ayırmak SoA hazırlığını ve sorumlu atamasını kolaylaştırır. Bu gruplama standardın resmi sınıflandırması değildir; kontrol sahiplerini belirlemek için kullanılan pratik bir görünümdür.

Grup	Kontroller	Tipik sahibi
Yönetişim ve roller	5.1–5.8, 5.35–5.37	BGYS yöneticisi, üst yönetim
Varlık, bilgi ve erişim	5.9–5.18	IT, varlık sahipleri
Tedarikçi ve bulut	5.19–5.23	Satın alma, IT
Olay yönetimi	5.24–5.28	IT güvenlik, BGYS yöneticisi
Süreklilik	5.29–5.30	IT, iş sürekliliği sorumlusu
Yasal uyum ve gizlilik	5.31–5.34	Hukuk, KVKK sorumlusu

Yönetişim ve roller

Bu grupta bilgi güvenliği politikaları (5.1), roller ve sorumluluklar (5.2), görevler ayrılığı (5.3), yönetim sorumlulukları (5.4), otoritelerle ve özel ilgi gruplarıyla iletişim (5.5, 5.6), tehdit istihbaratı (5.7) ve proje yönetiminde bilgi güvenliği (5.8) vardır. Bağımsız gözden geçirme (5.35), politika ve standartlara uyum (5.36) ve dokümante edilmiş işletim prosedürleri (5.37) de doğası gereği buraya aittir.

• 5.1 Politikalar: Üst düzey bilgi güvenliği politikasına ek olarak konuya özgü politikalar (erişim kontrolü, kriptografi, yedekleme vb.) beklenir. Kanıt: onay ve gözden geçirme tarihleri, ilgili personele duyuru kaydı.
• 5.3 Görevler ayrılığı: Çatışan görevlerin listesi (ör. değişikliği talep eden, onaylayan ve canlıya alan). Küçük ekiplerde tam ayrım mümkün değilse telafi edici kontrol olarak izleme ve sonradan gözden geçirme kaydı tutulur. Üç kişilik IT ekibinde domain admin hesabını herkesin kullanması, bu kontrolün sahadaki klasik açığıdır.
• 5.7 Tehdit istihbaratı: 2022 ile gelen yeni kontrollerden biridir. İstihbarat aboneliği şart değildir; ama kaynakların (ulusal CERT duyuruları, üretici güvenlik bültenleri gibi) belirlenmesi, bilginin değerlendirilip aksiyona dönüştürülmesi ve bunun kaydı beklenir. Bülteni okumak yetmez; “firewall’umuzu etkiliyor mu, ne yaptık?” sorusunun cevabı kayıtta olmalı.
• 5.8 Proje yönetimi: Proje başlatma şablonunda bilgi güvenliği gereklilikleri ve risk değerlendirmesi yer alır. Kanıt: tamamlanmış bir projenin dosyasındaki güvenlik değerlendirmesi.

Politikaların nasıl yazılacağını bilgi güvenliği politikası rehberinde ayrıntılı anlattık.

Varlık ve bilgi yönetimi kontrolleri

5.9 ile 5.18 arası, bilginin ve ilişkili varlıkların envanterinden (5.9) başlayıp kabul edilebilir kullanım (5.10), varlıkların iadesi (5.11), sınıflandırma ve etiketleme (5.12, 5.13), bilgi transferi (5.14) ve erişim kontrolü ailesine (5.15 erişim kontrolü, 5.16 kimlik yönetimi, 5.17 kimlik doğrulama bilgisi, 5.18 erişim hakları) uzanır.

Bu grubun omurgası envanterdir. Sahibi belli olmayan bir varlık için sınıflandırma, erişim hakkı onayı veya iade kontrolü kanıtlanamaz. 2022 sürümü “bilgi ve diğer ilişkili varlıklar” ifadesini kullanır; yani envanter yalnız donanım listesi olamaz. Müşteri verisi, çizimler, kaynak kod gibi bilgi varlıkları ve bunları işleyen sistemler birlikte görünmelidir. Sahada en sık gördüğümüz durum: muhasebe yazılımının satın alma faturasından çekilmiş bir sunucu listesi var, ama hangi veritabanında hangi bilginin durduğu yok. Envanter alanlarını bilgi varlığı envanteri hazırlama yazısında ele aldık.

Erişim kontrol ailesinde ayrım şöyledir: 5.15 kuralları (politika), 5.16 kimliklerin yaşam döngüsünü, 5.17 parola ve benzeri kimlik doğrulama bilgisinin yönetimini, 5.18 ise hakların verilmesi, gözden geçirilmesi ve kaldırılmasını kapsar. Teknik uygulama (ör. çok faktörlü kimlik doğrulama yapılandırması) 8. temadaki 8.5 güvenli kimlik doğrulama kontrolüne düşer. Organizasyonel kontrolde denetçi kuralın tanımlandığını ve süreçle işletildiğini görmek ister. Pratik test basittir: son ayrılan çalışanın Active Directory hesabı, VPN profili ve SaaS lisansı hangi tarihte kapatıldı? Üç tarih de kayıtta yoksa 5.18 zayıftır.

Tedarikçi ve bulut kontrolleri

5.19 tedarikçi ilişkilerinde bilgi güvenliği, 5.20 tedarikçi sözleşmelerinde güvenlik, 5.21 BİT tedarik zincirinde güvenlik, 5.22 tedarikçi hizmetlerinin izlenmesi ve değişiklik yönetimi, 5.23 ise bulut hizmetlerinin kullanımında bilgi güvenliği kontrolleridir. 5.23 yeni bir kontroldür; bulut hizmetinin edinilmesinden kullanımına, yönetiminden çıkışına kadar süreç tanımlanmasını ister.

Uygulamada beklenen yapı:

1. Tedarikçileri eriştikleri bilgiye ve hizmet kritikliğine göre katmanlara ayırın. Firewall’unuza uzaktan bağlanan bakım firması ile kırtasiye tedarikçisi aynı katmanda olamaz.
2. Her katman için asgari sözleşme maddelerini (gizlilik, olay bildirimi süresi, alt yüklenici kullanımı, denetim hakkı, sözleşme sonunda verinin iadesi/imhası) tanımlayın.
3. Kritik tedarikçiler için periyodik değerlendirme yapın: bağımsız güvence raporları (ISO 27001 belgesi ve kapsamı, SOC 2 raporu gibi), anket veya yerinde ziyaret.
4. Bulut hizmetleri için paylaşılan sorumluluk modelini yazılı hale getirin: sağlayıcının neyi, sizin neyi yönettiğiniz ve çıkış (exit) planı.

Tedarikçi değerlendirme yöntemini tedarikçi bilgi güvenliği risk değerlendirmesi yazısında; bu alandaki hizmet kapsamımızı tedarikçi ve üçüncü taraf risk yönetimi sayfasında bulabilirsiniz.

Olay ve süreklilik kontrolleri

Olay yönetimi beş kontrolle bir yaşam döngüsü olarak tanımlanır: planlama ve hazırlık (5.24), olayların değerlendirilmesi ve karar (5.25), müdahale (5.26), olaylardan öğrenme (5.27) ve delil toplama (5.28). Çalışanların olay bildirmesi ise insan temasındaki 6.8 kontrolüdür; ikisini birlikte tasarlayın.

Denetçi bu grupta tipik olarak olay kaydını açar ve birkaç olayı baştan sona izler: nasıl bildirildi, hangi kritere göre “olay” veya “olay değil” kararı verildi, kim müdahale etti, kök neden ve alınan ders kayda geçti mi. Boş olay kaydı iyi haber değildir. Genellikle “olay yok” değil, “olaylar tanınmıyor veya kaydedilmiyor” diye okunur. Antivirüs konsolundaki karantina kayıtları, kilitlenen hesaplar, kaybolan bir dizüstü bilgisayar; bunların hiçbiri olay sürecine girmemişse süreç kâğıt üzerindedir. Prosedür yapısı için olay yönetimi prosedürü yazımı yazısına bakabilirsiniz.

Süreklilik tarafında 5.29 kesinti sırasında bilgi güvenliğinin korunmasını, yeni kontrol 5.30 ise iş sürekliliği için BİT hazırlığını ister. 5.30’un ayırt edici noktası, BİT hizmetlerinin kurtarma hedeflerinin iş etki analizinden türetilmesi ve bu hedeflerin test edilmesidir. Kanıt: BİT hizmetleri için belirlenmiş kurtarma süresi ve veri kaybı hedefleri, felaket kurtarma planı, son testin raporu ve testte çıkan eksiklerin takibi. Teknik yedekleme kontrolü (8.13) ayrıdır. Yedek almak 5.30’u karşılamaz.

Yasal uyum ve gizlilik kontrolleri

5.31 yasal, düzenleyici ve sözleşmesel gerekliliklerin belirlenmesini; 5.32 fikri mülkiyet haklarını; 5.33 kayıtların korunmasını; 5.34 ise kişisel verilerin gizliliğini ve korunmasını kapsar. Türkiye’de çalışan kuruluşlar için 5.34’ün ana girdisi 6698 sayılı KVKK ve ikincil düzenlemeleridir.

• 5.31: Gereklilik kayıt listesi (mevzuat, sözleşme maddeleri, müşteri şartnameleri), her birinin BGYS’de hangi kontrolle karşılandığı ve gözden geçirme tarihi.
• 5.32: Yazılım lisans envanteri ve lisans uyum kontrolü; kaynak kod ve tasarım belgelerinde kullanım hakları.
• 5.33: Kayıt türleri, saklama süreleri ve saklama ortamı; yasal saklama süresi dolan kayıtların imha kaydı.
• 5.34: Kişisel veri envanteri, aydınlatma metinleri, veri işleyen sözleşmeleri ve ihlal bildirim süreci.

5.35 bağımsız gözden geçirme ve 5.36 uyum kontrolleri BGYS’nin kendi kendini denetleme mekanizmasıdır; iç denetim, dış denetim raporları ve yönetici gözden geçirmeleriyle kanıtlanır.

Sık yapılan yorum hataları

Kontrol	Yaygın hatalı yorum	Doğru yaklaşım
5.1	Tek sayfalık genel politika yeterli	Konuya özgü politikalar da tanımlanır ve gözden geçirilir
5.3	Küçük şirkette uygulanamaz, hariç tutulur	Telafi edici izleme ve gözden geçirme ile uygulanır
5.7	Ücretli istihbarat servisi zorunlu	Kaynak, değerlendirme ve aksiyon süreci yeterli
5.9	Donanım envanteri yeterli	Bilgi varlıkları ve sahipleri de gösterilir
5.23	Bulut sağlayıcının belgesi her şeyi kapsar	Müşteri tarafı sorumluluklar ayrıca yönetilir
5.24–5.27	Olay yoksa kanıt gerekmez	Olay kriteri, tatbikat ve değerlendirme kaydı tutulur
5.30	Yedekleme yapıyoruz, karşılandı	İş etki analizine dayalı hedef ve test kanıtı

Bir diğer yaygın hata, Annex A’yı kontrol listesi gibi doldurup risk değerlendirmesiyle bağ kurmamaktır. ISO 27001 madde 6.1.3, kontrollerin risk işleme seçeneklerinden belirlenmesini ve ardından Annex A ile karşılaştırılarak hiçbir gerekli kontrolün atlanmadığının doğrulanmasını ister. Sıra önemlidir. Önce risk, sonra kontrol. Seçim kaydını ISO 27001 SoA yazısında anlattık; organizasyonel kontrollerin risklerle eşlenmesinde destek için risk analizi ve SoA hizmetimize bakabilirsiniz. İnsan ve fiziksel temalar için devam yazısı: Annex A insan ve fiziksel kontroller. Kontrol metinlerinin resmi kaynağı ISO/IEC 27002:2022 standardıdır.

Sık sorulan sorular

Organizasyonel kontrollerin hepsini uygulamak zorunlu mu?

Hayır. Annex A kontrolleri risk değerlendirmesine göre seçilir; uygulanmayanlar SoA’da gerekçesiyle yazılır. Ama politikalar, roller, erişim kontrolü ve olay yönetimi gibi kontrollerin hariç tutulmasını denetçiye savunmak pratikte çok zordur.

5.23 bulut kontrolü SaaS uygulamalarını da kapsar mı?

Evet. 5.23, IaaS ve PaaS ile birlikte SaaS hizmetlerini de kapsar. E-posta, dosya paylaşımı veya muhasebe gibi SaaS hizmetleri için de edinme, yapılandırma, izleme ve çıkış kuralları tanımlanmalıdır.

Tehdit istihbaratı kontrolü küçük bir şirkette nasıl karşılanır?

Güvenilir ve ücretsiz kaynakları belirlemek, bunları düzenli takip etmek, ilgili bilgiyi değerlendirip aksiyona çevirmek ve bu değerlendirmeyi kayda almak çoğu küçük kuruluş için yeterlidir. Belirleyici olan, bilginin bir karara ve aksiyona bağlanmasıdır.

Organizasyonel kontrol ile teknolojik kontrol arasındaki sınır nasıl çizilir?

Organizasyonel kontrol kuralı ve süreci tanımlar; teknolojik kontrol bu kuralın sistemlerde nasıl uygulandığını kapsar. Örneğin erişim hakları süreci 5.18’de, güvenli kimlik doğrulama yapılandırması 8.5’te değerlendirilir.