BGYS’de RACI Matrisi: Rol ve Sorumluluklar Nasıl Tanımlanır?

Denetimde “Bu kontrolden kim sorumlu?” diye soruluyor ve üç kişiden üç farklı cevap geliyor. Bu tablo, BGYS’de rol tanımlarının kâğıtta kaldığını gösterir. RACI matrisi, her BGYS faaliyetinde işi kimin yaptığını, kimin hesap verdiğini, kime danışıldığını ve kimin bilgilendirildiğini tek tabloda gösterir. Aşağıda ISO/IEC 27001:2022’nin rol gerekliliklerini RACI ile karşılamayı, örnek bir matrisi, küçük ekiplerde görevler ayrılığı sorununu ve dış kaynak rollerinin gösterimini sahadaki haliyle ele alıyoruz.

Rol, sorumluluk ve yetki gereklilikleri

ISO/IEC 27001:2022 madde 5.3, üst yönetimin bilgi güvenliğiyle ilgili rollerin sorumluluk ve yetkilerini atamasını ve kuruluş içinde iletmesini ister. Madde iki atamayı özellikle sayar: BGYS’nin standarda uygunluğunun sağlanması ve BGYS performansının üst yönetime raporlanması. Annex A 5.2 rol ve sorumlulukların kuruluşun ihtiyacına göre tanımlanıp tahsis edilmesini, 5.3 çatışan görevlerin ve sorumluluk alanlarının ayrılmasını, 5.4 de yönetimin personelden politikalara uymasını istemesini düzenler.

Denetçi bu gereklilikleri genellikle üç soruyla sınar: Roller yazılı mı? Atanan kişiler rollerini biliyor mu? Rolün gerektirdiği yetki sistemde gerçekten verilmiş mi? RACI matrisi yalnız ilk soruyu cevaplar. İkinci ve üçüncü soru için matrisin görev tanımlarına, atama yazılarına ve sistem yetkilerine yansıması gerekir. Tablo tek başına kanıt değildir.

RACI modelinin kuralları

RACI dört harften oluşur. Harfler herkes tarafından aynı okunmadığında matris karışıklığı azaltmaz, artırır. Matrisin başına kısa bir açıklama koyun:

Harf	Anlam	Kural
R – Responsible	İşi yapan	Her satırda en az bir R
A – Accountable	Sonuçtan hesap veren, onaylayan	Her satırda tam olarak bir A
C – Consulted	Görüşü alınan (iki yönlü)	Sayısı sınırlı tutulmalı
I – Informed	Sonuçtan haberdar edilen (tek yönlü)	Bildirim kanalı tanımlı olmalı

Sahada işe yarayan ek kurallar:

• Tek A kuralı: İki A’lı satır, karar anında kimsenin hesap vermemesi demektir. Ortak karar gerekiyorsa A bir komitedir ve komitenin karar kaydı tanımlanır.
• A ve R aynı kişi olabilir; ancak onay ve gözden geçirme gibi kontrol niteliğindeki faaliyetlerde bu durum görevler ayrılığı açısından ayrıca değerlendirilir.
• Satırlar faaliyet olmalı: “Erişim kontrolü” değil, “Ayrıcalıklı hesap talebini onaylamak” gibi fiil içeren, ölçülebilir ifadeler yazın.
• Sütunlar rol olmalı: Kişi adı değil unvan veya rol adı kullanın; isimler ayrı bir atama listesinde tutulur.
• Çok fazla C, yavaş karar demektir: Her faaliyette herkesin görüşünü almayın; gerçekten bilgisi gereken rolleri C yapın.

Örnek BGYS RACI matrisi

Aşağıdaki matris orta ölçekli bir kuruluş için başlangıç taslağıdır. Satırlar standardın madde yapısını ve sık denetlenen Annex A kontrollerini kapsar; kendi süreçlerinize göre satır ekleyip çıkarın. Sütun kısaltmaları: ÜY (üst yönetim), BGY (BGYS yöneticisi), BT (BT müdürü), İK, SS (süreç/varlık sahibi).

Faaliyet	ÜY	BGY	BT	İK / SS
Bilgi güvenliği politikasını onaylamak	A	R	C	İK: I, SS: I
Risk değerlendirmesini yürütmek	I	A	R	SS: R
Risk işleme planını ve kalan riski kabul etmek	A	R	C	SS: C
Erişim talebini iş açısından onaylamak	–	I	R	SS: A
Periyodik erişim gözden geçirmesi	I	A	R	SS: R
İşe giriş ve ayrılışta hesap işlemleri	–	I	R	İK: A
Farkındalık eğitim programı	I	A	C	İK: R
Bilgi güvenliği olayına müdahale	I	A	R	SS: C
İç denetim programı	A	C	I	İç denetçi: R
Yönetimin gözden geçirmesi	A	R	C	SS: C

Bazı tercihlerin gerekçesini matrisin altına yazın; denetçi soracaktır. Erişim onayında A’nın süreç sahibinde olması, yetkinin iş ihtiyacına göre verildiğini gösterir. BT yalnızca uygular. İşe giriş ve ayrılışta A’nın İK’da olması, tetikleyici olayın İK kaydı olduğunu ve BT’nin bildirim almadan hareket edemeyeceğini yansıtır. Sahada en sık gördüğümüz açık tam burada: İK ayrılışı bildirmez, hesap aylarca aktif kalır, VPN bağlantısı açık durur. İç denetimde BGYS yöneticisinin R değil C olması ise madde 9.2’nin istediği tarafsızlık için bilinçli bir seçimdir. Kişi kendi kurduğu süreci denetlemez.

Küçük organizasyonlarda görevler ayrılığı

Annex A 5.3 çatışan görevlerin ayrılmasını ister. Tek kişilik BT ekibi olan bir kuruluşta ise yetkiyi talep eden, veren ve gözden geçiren çoğu zaman aynı kişidir. Standart burada imkânsızı beklemez; çatışmanın tanımlanmasını ve riskin telafi edici kontrollerle azaltılmasını bekler. Bu değerlendirme risk kaydında, gerekirse uygulanabilirlik bildirgesinde açıklanır.

Sık görülen çatışmalar ve telafi yolları:

Çatışma	Telafi edici kontrol
BT yöneticisi hem yetki veriyor hem gözden geçiriyor	Gözden geçirmeyi süreç sahipleri imzalar; liste sistemden doğrudan alınır
Yönetici hesapları aynı kişide, logları da o inceliyor	Loglar kişinin silemeyeceği merkezi ortama gönderilir; özet raporu üst yönetim veya dış taraf inceler
Değişikliği yapan ve onaylayan aynı kişi	Önceden onaylı standart değişiklik listesi; diğerleri için yönetici onayı ve sonradan kontrol
BGYS yöneticisi aynı zamanda BT müdürü	İç denetimin dış kaynaktan veya başka birimden yapılması

Telafi edici kontrolün de sahibi ve kanıtı olmalı. “Üst yönetim logları inceler” cümlesi tek başına kontrol sayılmaz. İncelemenin hangi sıklıkta, hangi rapor üzerinden yapıldığı ve imzalı kaydın nerede durduğu yazılmalıdır. Pratikte işleyen yöntem şudur: Domain Admins grubu üyeliği ve olay günlüğü temizleme kayıtları gibi birkaç kritik olay merkezi log ortamından aylık rapor olarak çıkar, rapor yönetici tarafından imzalanır ve arşivlenir. Bu tür ayrımın kurumsal ölçekte nasıl kurgulandığına üç savunma hattı modeli rehberinde de değiniliyor.

Dış kaynak ve tedarikçi rollerinin gösterilmesi

Yönetilen hizmet sağlayıcı, dış kaynak bilgi güvenliği yöneticisi veya bulut hizmeti varsa ve matris yalnız iç rollerden oluşuyorsa, tablo gerçeği yansıtmaz. Dış tarafları ayrı sütun olarak ekleyin ve şu ilkeye uyun: R dış tarafta olabilir, A kuruluş içinde kalır. Yedekleme işletimini hizmet sağlayıcı yürütür (R); geri yükleme testinin sonucunu kabul eden ise BT müdürüdür (A). Yedek test edilmeden yedek değildir.

Dış kaynak sütunlarının matrise doğru yansıması için:

• Her dış rol için ilgili sözleşme veya hizmet seviyesi anlaşmasına atıf verin; RACI’deki R ile sözleşme kapsamı çelişmemelidir.
• Dış tarafın kuruluş adına karar veremeyeceği faaliyetleri (risk kabulü, politika onayı) açıkça iç rollere atayın.
• Bulut hizmetlerinde paylaşılan sorumluluk modelini satır düzeyinde yansıtın: altyapı yamalarını sağlayıcı yapar, kullanıcı ve erişim yönetimi kuruluşta kalır.

Sahada sık rastlanan durum, sözleşmede “yedekleme” yazması ama geri yükleme testinin hiçbir tarafa atanmamasıdır. Sözleşmeyi ve matrisi yan yana okuyun. Dış kaynak bir BGYS yöneticisiyle çalışırken hangi çıktıların teslim alınması gerektiği dış kaynak BGYS danışmanlığı teslimatları yazısında anlatılıyor. Rolün nasıl kurgulanabileceği için dış kaynak bilgi güvenliği yöneticisi (vCISO) sayfasına bakabilirsiniz.

Matrisin görev tanımlarına ve kayıtlara yansıtılması

RACI tek başına bir taslaktır. Atamanın gerçekleştiğini gösteren kayıtlar olmadan denetimde kanıt değeri sınırlı kalır. Matrisi işler hale getirmek için:

1. Atama listesi: Her rolün güncel sahibini ve vekilini isim, unvan ve başlangıç tarihiyle gösteren ayrı bir liste tutun.
2. Görev tanımları: İK’daki görev tanımlarına ilgili R ve A satırlarını ekleyin; çalışan imzası veya elektronik onay ile iletimi kanıtlayın.
3. Üst yönetim onayı: Matrisin kendisini üst yönetim onaylasın; madde 5.3’teki atamanın kanıtı budur.
4. Sistem yetkileriyle karşılaştırma: Matriste A olan kişinin onay iş akışında gerçekten onaylayıcı olarak tanımlı olduğunu kontrol edin. Hizmet masası aracındaki onay grubuna bakmak yeterlidir.
5. Doküman kontrolü: Matrisi sürüm numarası ve gözden geçirme tarihiyle yönetin; organizasyon değişikliği güncellemeyi tetiklesin. Sürüm ve onay akışı için doküman kontrolü rehberine bakılabilir.

Matrisin doğruluğunu ölçmenin basit bir yolu var. Rastgele üç satır seçin ve A sütunundaki kişiye o faaliyetin son kaydını sorun. Kayıt birkaç dakikada bulunuyorsa matris çalışıyordur. Kişi rolünden habersizse sorun tabloda değil, iletimdedir. Rol dağılımını politika ve prosedür setiyle birlikte kurmak için bilgi güvenliği politika ve prosedür paketi bir başlangıç çerçevesi sunar.

Sık sorulan sorular

RACI matrisi ISO 27001’de zorunlu mudur?

Hayır. Standart rollerin, sorumlulukların ve yetkilerin atanmasını ve iletilmesini ister; formatı belirlemez. RACI, bu gerekliliği tek tabloda ve denetlenebilir biçimde göstermenin pratik yollarından biridir.

Bir faaliyette birden fazla A olabilir mi?

Olmamalı. İki hesap veren, karar anında sorumluluğu belirsizleştirir. Ortak karar gerekiyorsa A olarak bir komite veya kurul yazılır ve karar kaydının nasıl tutulacağı tanımlanır.

Küçük şirketlerde görevler ayrılığı nasıl sağlanır?

Tam ayrım mümkün değilse çatışma risk kaydına yazılır ve telafi edici kontroller tanımlanır: bağımsız log saklama, iş birimi yöneticilerinin erişim gözden geçirmesi, üst yönetimin periyodik incelemesi veya iç denetimin dış kaynaktan yapılması gibi.

Dış kaynak hizmet sağlayıcı RACI’de A olabilir mi?

Operasyonel işleri yürüten R olabilir. Risk kabulü, politika onayı ve sonuçların kabulü gibi hesap verebilirlik gerektiren faaliyetlerde A kuruluş içindeki bir rolde kalmalıdır.