Kanıt Matrisi Nasıl Hazırlanır? Kontrol–Kanıt Eşleme Yöntemi

Denetim haftasında e-posta kutularını ve paylaşım klasörlerini tarayan ekiplerin derdi çoğu zaman kanıtın yokluğu değildir. Asıl sorun, hangi kontrolün hangi kayıtla karşılandığının hiçbir yerde yazılı olmamasıdır. Kanıt matrisi bu boşluğu kapatır: her kontrol için kanıtın ne olduğunu, kimin ürettiğini, hangi sıklıkla yenilendiğini ve nerede durduğunu tek tabloda tutar. Aşağıdaki model BGYS sorumluları ve TISAX hazırlığı yürüten ekipler için araçtan bağımsız kurulur, sütun sütun.

Kanıt matrisi neyi çözer?

Uygulanabilirlik Bildirgesi (SoA) hangi kontrollerin uygulandığını ve gerekçesini söyler; risk işleme planı neden uygulandığını açıklar. İkisi de “bu kontrolün çalıştığını hangi kayıtla gösteriyoruz?” sorusuna cevap vermez. Matris bu üçüncü katmandır ve sahada en sık gördüğümüz üç sorunu çözer:

• Kanıtın kişiye bağlı kalması: Yedekleme kanıtını yalnız sistem yöneticisi biliyorsa, o kişi izindeyken denetim oturumu tıkanır. Matris kanıtı role bağlar.
• Aynı işin iki kez yapılması: ISO 27001 ve TISAX’i birlikte yürüten kuruluşta aynı erişim gözden geçirme raporu iki klasörde, iki farklı sürümle durur. Matris tek kaynağı ve çoklu eşlemeyi görünür kılar.
• Periyodik kanıtın kaçması: Çeyreklik yapılması gereken gözden geçirme ancak denetim öncesinde fark edilirse geriye dönük üretilmeye çalışılır. Denetçinin ilk yakaladığı şey de budur. Sıklık ve son üretim tarihi sütunları bu riski aylar önce gösterir.

Matris SoA’nın kopyası değildir. SoA’da tek satır olan kontrol matriste birden çok kanıt satırına ayrılabilir; tek bir kanıt satırı da birden çok kontrole bağlanabilir. Bu yüzden matrisin birincil anahtarı kontrol değil, kanıt kalemidir. Bu karar her şeyi belirler.

Zorunlu sütunlar ve tanımları

Aşağıdaki sütunlar bir elektronik tabloda da, SharePoint listesi, GRC aracı veya bilet sisteminde de aynı şekilde kurulur. Sütun adlarını kuruluş içinde sabitleyin. Her denetim döneminde yeniden adlandırılan sütunlar, geçmiş dönemlerle karşılaştırmayı fiilen imkânsız hale getirir.

Sütun	İçerik	Örnek değer
Kanıt kimliği	Değişmeyen tekil kod	KNT-047
Kanıt adı	Neyin gösterildiği	Çeyreklik AD yetki gözden geçirmesi
Eşlenen kontroller	Standart ve kontrol numaraları	ISO 5.18, 8.2; VDA ISA 4.2.1
Kanıt türü	Kayıt, rapor, yapılandırma, ekran görüntüsü, gözlem	Sistem raporu + onay kaydı
Kanıt sahibi	Üretmekten sorumlu rol	Sistem yönetimi ekip lideri
Sıklık	Olay bazlı, aylık, çeyreklik, yıllık	Çeyreklik
Son üretim tarihi	En son kanıtın tarihi	Bir önceki çeyreğin son iş günü
Saklama yeri	Kalıcı konum, sürümlü	Kanıt kütüphanesi / 05-Erişim
Saklama süresi	Kayıt listesiyle uyumlu süre	Belge döngüsü + 1 yıl
Durum	Güncel, gecikmiş, eksik	Güncel

İki sütun daha sahada çok işe yarar: kaynak sistem (raporun hangi sistemden, hangi sorgu veya menüyle alındığı) ve doğrulayan (kanıtın yeterliliğini kontrol eden ikinci kişi). Kaynak sistem sütunu, bir sonraki dönemde aynı kanıtın aynı yöntemle yeniden üretilmesini sağlar. Denetçi “bu raporu şimdi tekrar alabilir misiniz?” diye sorduğunda cevap hazırdır. Konsolu açarsınız, sorguyu çalıştırırsınız.

Bir kontrol için kanıt nasıl seçilir?

Kontrol metnini okuyup “bunu gösteren bir doküman var mı?” diye sormak, matrisi politika dosyalarıyla doldurur. Politika yalnız kontrolün tasarımını gösterir; denetçi kontrolün işletildiğini görmek ister. Her kontrol için şu üç soruyu sırayla sorun:

1. Tasarım kanıtı: Kontrolün nasıl çalışması gerektiğini tanımlayan onaylı doküman hangisi? (Politika, prosedür, standart yapılandırma.)
2. İşletim kanıtı: Kontrolün dönem boyunca fiilen çalıştığını gösteren kayıt hangisi? (Gözden geçirme raporu, bilet kaydı, log, test sonucu.)
3. Sonuç kanıtı: Kontrolün bulduğu sapmalara ne yapıldığını gösteren kayıt hangisi? (Kaldırılan yetki, kapatılan zafiyet, düzeltici faaliyet kaydı.)

Üçüncü soru en sık atlanandır. Zafiyet taraması raporu kontrolün işletildiğini gösterir; ama kritik bulguların hangi sürede kapatıldığını gösteren kayıt yoksa denetçi kontrolün etkinliğini sorgular. Tarama yapmak yetmez. Kapanış izi gerekir. Kanıt türünün güvenilirliği de seçimi belirler: sistemden doğrudan alınmış, tarihli ve kaynağı belli bir rapor, aynı bilgiyi gösteren ekran görüntüsünden daha güçlüdür. Bu farkın ayrıntısı ekran görüntüsü ve sistem raporunun güvenilirlik farkını anlatan rehberde var.

Tek kanıtla birden çok kontrol: çoklu standart eşlemesi

ISO/IEC 27001:2022 Annex A ile VDA ISA büyük ölçüde örtüşür; KVKK kapsamındaki teknik ve idari tedbirler ile müşteri sözleşmelerindeki güvenlik maddeleri de çoğu zaman aynı kayıtlara dayanır. Çoklu eşlemenin mantığı basit: kanıt bir kez üretilir, matriste tek satır olarak tutulur, “eşlenen kontroller” sütununda tüm ilgili gereklilikler listelenir.

Bunu sağlıklı yürütmek için üç kural:

• En katı gereklilik belirler. ISO 27001 gözden geçirme sıklığını kuruluşa bırakırken müşteri sözleşmesi veya TISAX hedef olgunluk seviyesi daha sık ya da daha belgeli bir uygulama isteyebilir. Sıklık sütununa en sık olanı yazın.
• Kapsam farkını not edin. TISAX değerlendirmesinin kapsamı ISO 27001 belgesinin kapsamından farklı lokasyonları içerebilir. Tek kanıt iki kapsamı da kapsamıyorsa satırı ikiye bölün.
• Numaralandırma sürümünü sabitleyin. VDA ISA kontrol numaraları katalog sürümleri arasında değişebilir. Kullandığınız katalog sürümünü matris başlığına yazın; geçiş dönemlerinde eşlemeyi yeniden kontrol edin. Sürüm geçişinde nelere bakılacağı TISAX ve ISO 27001 ortak kontrollerini karşılaştıran yazıda ele alınıyor.

Çoklu eşlemenin bir kazancı da etki analizidir. Bir kanıtın üretimi aksadığında hangi standartların etkilendiğini matristen filtreleyerek saniyeler içinde görürsünüz.

Örnek matris satırları: organizasyonel, insan ve teknolojik kontroller

Aşağıdaki satırlar ISO/IEC 27001:2022 Annex A temalarından örneklerdir. VDA ISA numaraları ISA 6 kataloğuna göredir; kendi kullandığınız katalog sürümünde doğrulayın.

Kanıt	ISO 27001 Annex A	VDA ISA	Sahip / sıklık
Onaylı varlık envanteri dışa aktarımı ve sahiplik listesi	5.9	1.3.1	BT varlık yöneticisi / çeyreklik
Tedarikçi güvenlik değerlendirme kayıtları	5.19, 5.21	6.1.1	Satın alma / sözleşme başında ve yıllık
Farkındalık eğitimi tamamlama raporu ve ölçme sonuçları	6.3	2.1.3	İK / yıllık ve işe girişte
Yetki gözden geçirme raporu, kararlar ve kaldırma biletleri	5.18, 8.2	4.2.1	Sistem yönetimi / çeyreklik
Yedekleme iş raporları ve geri yükleme testi kaydı	8.13	5.2.9	Altyapı ekibi / aylık test
Değişiklik kayıtları listesi ve örnek onaylar	8.32	5.2.1	Değişiklik yöneticisi / sürekli

Yedekleme satırında aylık iş raporu tek başına yetmez. Yeşil “Success” satırları yedeğin alındığını gösterir, geri döndüğünü göstermez. Geri yükleme testinin hedefi, sonucu ve süresi de kanıt tanımına girmelidir; bu setin içeriği yedekleme ve geri yükleme denetim kanıtları rehberinde ayrıntılı anlatılıyor.

İnsan kontrollerinde kanıt kişisel veri içerir. Eğitim raporu veya işe alım öncesi tarama kaydı matrise bağlanırken, saklama yerinin erişim yetkileri kanıt kütüphanesinin geri kalanından daha dar tutulmalıdır.

Matrisin güncel tutulması ve sahiplik

Matris kurulduğu gün en doğru halindedir. Bakım yapılmazsa birkaç ayda çürür. Sürdürülebilir bir düzen şöyle kurulur:

• Matris sahibi tek kişidir: Genellikle BGYS yöneticisi. Kanıtları üretmez; satırların eksiksizliğini ve durum sütununu yönetir.
• Kanıt sahipleri role bağlıdır: Kişi adı yerine rol yazılır, rol–kişi eşlemesi ayrı bir RACI tablosunda tutulur. Görev değişikliğinde matris değil, RACI güncellenir.
• Aylık durum taraması: “Son üretim tarihi + sıklık” bugünden eskiyse satır otomatik olarak “gecikmiş” işaretlenir. Elektronik tabloda bu basit bir koşullu biçimlendirme, liste tabanlı araçlarda hesaplanmış bir sütundur.
• Tetikleyici olaylar: Yeni sistem devreye alındığında, SoA revize edildiğinde, kapsam değiştiğinde veya standart sürümü güncellendiğinde matris gözden geçirilir.
• Yönetimin gözden geçirmesi (YGG) girdisi: Gecikmiş ve eksik kanıt sayısı, YGG’de bilgi güvenliği performans göstergesi olarak raporlanabilir.

Kanıtların durduğu platform matristen bağımsızdır. Yine de saklama yeri sütununun kalıcı bağlantılarla çalışması için doküman kütüphanesinin klasör yapısını matrisin tema sınıflandırmasıyla aynı kurmak işi çok kolaylaştırır. SharePoint kullananlar için kütüphane yapısı, sürümleme ve yetki modeli SharePoint ile kanıt yönetimi yazısında anlatılıyor. Kanıt kütüphanesini ve matrisi birlikte kurmak isteyen ekipler denetim kanıt toplama ve SharePoint hizmetimizi inceleyebilir.

Sahada en sık görülen hatalar

• Matrisi SoA ile birebir kurmak: Kontrol başına bir satır, “kanıt” sütununda politika adı. Bu yapı işletim kanıtını hiç göstermez.
• Kanıt tanımını belirsiz bırakmak: “Loglar” yazmak yerine “SIEM’de alarm kuralı listesi dışa aktarımı ve aylık alarm inceleme kaydı” gibi tekrar üretilebilir bir tanım yazın.
• Dosya adını kanıt kimliği yerine kullanmak: Dosya yeniden adlandırıldığında bağ kopar. Kanıt kimliği değişmez; dosya adları kimliği önek olarak taşır.
• Tarihsiz kanıt: Üretim tarihi olmayan rapor, denetim dönemine ait olduğunu kanıtlayamaz. Tarih raporun içinde veya dosya meta verisinde bulunmalıdır.
• Denetim öncesi toplu üretim: Bir yılın dört çeyreklik gözden geçirmesinin aynı hafta tarihli olması, örneklem incelemesinde ilk bakışta görülür. Kontrolün işletilmediğinin işaretidir.
• TISAX ve ISO kanıtlarını ayrı klasörlerde çoğaltmak: İki kopya zamanla ayrışır; denetçi iki farklı sürümle karşılaşır. Tek kaynak, çoklu eşleme kuralı korunmalı. TISAX değerlendirmesine özgü kanıt dosyası hazırlığında TISAX denetim öncesi hazırlık çalışması bu ayrımı baştan kurar.

Başlarken tüm Annex A’yı tek seferde matrise dökmeyin. En çok bulgu çıkan beş alanla başlayın: erişim yönetimi, değişiklik yönetimi, yedekleme, tedarikçi ve eğitim. Bu satırlar oturduğunda geri kalan kontroller aynı şablonla hızla eklenir. ISO/IEC 27001:2022’nin resmi metni için ISO’nun standart sayfası başvuru noktasıdır.

Sık sorulan sorular

Kanıt matrisi ile SoA aynı doküman olabilir mi?

Olabilir ama önermeyiz. SoA kontrolün uygulanıp uygulanmadığını ve gerekçesini gösterir; kanıt matrisi kanıt kalemlerini, sahiplerini, sıklıklarını ve saklama yerlerini izler. Birleştirirseniz SoA her kanıt güncellemesinde revize edilmek zorunda kalır ve doküman kontrolü zorlaşır.

Bir kontrol için kaç kanıt yeterlidir?

Sayı değil kapsam belirler. Her kontrol için en az bir tasarım kanıtı (onaylı doküman) ve dönem boyunca işletildiğini gösteren bir işletim kanıtı olmalı. Sapma bulan kontrollerde, sapmaların nasıl kapatıldığını gösteren sonuç kanıtı da eklenmeli.

Kanıt matrisi için özel bir GRC yazılımı gerekli mi?

Hayır. Buradaki sütunlar bir elektronik tabloda veya SharePoint listesinde kurulur. Asıl gereken sabit kanıt kimlikleri, sürümlü saklama yeri, rol bazlı sahiplik ve gecikmeyi gösteren bir durum takibidir.

VDA ISA katalog sürümü değiştiğinde matris ne olur?

Kanıt satırları genellikle aynı kalır; değişen, eşlenen kontrol numaraları ve bazı gerekliliklerin kapsamıdır. Geçiş döneminde eşleme sütunu yeni kataloğa göre yeniden kontrol edilmeli ve matris başlığındaki katalog sürümü güncellenmelidir.