Kontrol Etkinliği Testi: Tasarım ve İşletim Etkinliği Farkı

Bir kontrolün var olması çalıştığını göstermez; çalışması da doğru riski ele aldığını göstermez. İç denetçiler, ITGC değerlendiricileri ve SOC 2 denetçileri bu yüzden iki soruyu ayrı ayrı test eder: kontrol doğru tasarlanmış mı, ve dönem boyunca tasarlandığı gibi işlemiş mi? Sahada ikisi sık karıştırılır; “prosedür yazılı, demek ki kontrol var” denir ve test orada biter. Aşağıda tasarım ve işletim etkinliği testlerini nasıl yürüttüğümüzü, dört temel test yönteminin ne zaman yettiğini ve bir erişim kontrolü için örnek test çalışma kağıdını gösteriyoruz.

Tasarım ve işletim etkinliği

Tasarım etkinliği, kontrol tanımlandığı şekliyle uygulandığında ilgili riski kabul edilebilir seviyeye indirip indiremeyeceğini sorgular. Bakılan unsurlar şunlar: kontrol doğru riske mi bağlı, sıklığı riskin hızına uygun mu, kontrolü yapan kişinin yetkisi ve bilgisi yeterli mi, kontrolün girdisi olan veri eksiksiz ve doğru mu, istisna bulunduğunda ne yapılacağı tanımlı mı?

İşletim etkinliği ise kontrolün denetim dönemi boyunca tasarlandığı gibi, tutarlı olarak ve yetkili kişilerce uygulandığını sorgular. Tek bir başarılı uygulama işletim etkinliğini kanıtlamaz. Dönemden seçilen örneklerin tamamında kontrolün çalıştığı gösterilmeli.

BT kontrol ve uyum denetimlerinde sıra değişmez: önce tasarım test edilir. Tasarım eksikse işletim testi boşa emektir, çünkü yanlış kurgulanmış bir kontrolün hatasız işlemesi riski azaltmaz. Örnek: ayrılan çalışanların hesaplarını üç ayda bir kapatan bir kontrol her çeyrekte eksiksiz uygulanabilir. Ama ayrılan birinin hesabı üç ay boyunca açık kalabiliyorsa, sorun işletimde değil tasarımdadır.

Test yöntemleri karşılaştırması

ISO 19011:2018 ve finansal denetim standartları kanıt toplamada benzer yöntemler tanımlar. Kontrol testinde kullanılan dört temel yöntem aşağıda karşılaştırılıyor.

Yöntem	Ne yapılır?	Güvence düzeyi	Tipik kullanım
Sorgulama	Kontrol sahibiyle görüşme	Düşük; tek başına yetersiz	Kontrolü anlamak, testi planlamak
Gözlem	Kontrolün uygulanmasını izlemek	Orta; yalnızca o anı kapsar	Fiziksel kontroller, anlık işlemler
İnceleme	Kayıt, onay ve raporları incelemek	Orta–yüksek	Onaylar, gözden geçirme kayıtları
Yeniden uygulama	Kontrolü denetçinin kendisi tekrar yürütür	Yüksek	Mutabakatlar, otomatik hesaplamalar

Yöntemler birleştirilir. Tipik kombinasyon şu: sorgulamayla kontrolün nasıl çalıştığı öğrenilir, incelemeyle seçilen örneklerde kanıt doğrulanır, kritik bir örnekte yeniden uygulama yapılır. Gözlem değerli ama dar bir yöntemdir. Kontrol sahibi izlendiğini bildiğinde kontrolü farklı uygulayabilir; ayrıca gözlem dönemin geri kalanı hakkında hiçbir şey söylemez.

İncelemede kanıtın kaynağı da güvence düzeyini belirler. Sistemden doğrudan alınan bir rapor, elle derlenmiş bir Excel tablosundan daha güvenilirdir; bu ayrım ekran görüntüsü ve sistem raporu karşılaştırmasında ayrıntılı anlatılıyor.

Walkthrough ile tasarım testi

Walkthrough, tek bir işlemin başından sonuna kadar izlenmesidir. Amaç, kontrolün dokümanda tarif edildiği gibi var olduğunu ve uygulandığını kendi gözünüzle görmektir. Adımlar:

1. Kontrol tanımını okuyun: Amaç, risk, sahip, sıklık, girdi, çıktı ve istisna yönetimi yazılı mı?
2. Kontrol sahibiyle sürece başlayın: Kontrolün tetiklendiği andan sonuçlandığı ana kadar her adımı anlatmasını isteyin.
3. Bir işlemi izleyin: Gerçek bir örnek seçin (örneğin geçen ay işe başlayan bir çalışanın erişim talebi) ve her adımın kanıtını sistemde görün.
4. Girdinin güvenilirliğini sorgulayın: Kontrolün kullandığı liste veya rapor nereden geliyor, eksiksiz mi?
5. Riski karşılayıp karşılamadığını değerlendirin: Bu kontrol tasarlandığı gibi çalışırsa ilgili riski önler veya zamanında tespit eder mi?

Dördüncü adım en sık atlanan adımdır. Gözden geçirilen kullanıcı listesi elle hazırlanmışsa, listede olmayan hesap hiç gözden geçirilmez. Girdi eksikse kontrol de eksiktir.

Dönem boyunca işletim testi

İşletim testi, tasarımı onaylanan kontrolün denetim dönemi boyunca çalıştığını örneklemle gösterir. Popülasyonun tanımlanması, eksiksizliğinin doğrulanması ve örnek büyüklüğünün kontrol sıklığına göre belirlenmesi iç denetimde örneklem seçimi rehberinde anlatılıyor. Örnekler seçildikten sonra her biri için önceden tanımlanmış test özellikleri (attributes) kontrol edilir. Test özellikleri kontrol tanımından türetilir ve her örnekte aynı şekilde uygulanır: “onay var mı”, “onay işlemden önce mi”, “onaylayan yetkili mi” gibi.

İşletim testinde sahada sık gördüğümüz hatalar:

• Örnekleri denetlenenin seçmesine izin vermek.
• Test özelliklerini örnekler incelendikten sonra belirlemek.
• Dönem içinde değişen bir kontrolü tek kontrol gibi test etmek. Kontrol dönem ortasında değiştiyse iki ayrı dönem olarak test edilmeli.
• Bir istisnayı “tek seferlik” diyerek geçiştirmek. İstisnanın nedeni araştırılmadan sonuç yazılmaz; bulgunun nasıl ifade edileceği denetim bulgusu yazımı rehberinde anlatılıyor.

Örnek test çalışma kağıdı

Aşağıdaki çalışma kağıdı üç aylık kullanıcı erişim gözden geçirmesi kontrolü için hazırlandı. Değerler ve kayıt numaraları örnektir.

KONTROL      : ERS-04 Üç aylık erişim gözden geçirmesi
RİSK         : R-12 Yetkisiz kişilerin kritik uygulamaya erişimi
TANIM        : ERP rol atamaları her çeyrek sonunu izleyen 15 iş günü
               içinde ilgili departman yöneticisi tarafından gözden
               geçirilir; kaldırılması istenen yetkiler 5 iş günü
               içinde BT tarafından kaldırılır.
TÜR / SIKLIK : Manuel, dedektif / Üç aylık
DÖNEM        : 01.01.2025 – 31.12.2025   POPÜLASYON: 4 gözden geçirme

TASARIM TESTİ (walkthrough, Q3 gözden geçirmesi)
  Girdi listesi ERP'den sistem raporu ile mi alındı?   Evet (rapor + parametre)
  Gözden geçiren, rolleri bilen yönetici mi?           Evet
  Kaldırma talebi ve uygulanması izlenebilir mi?       Evet (ticket)
  Sonuç: Tasarım etkin

İŞLETİM TESTİ (4 çeyreğin tamamı)
  Test özellikleri: A) zamanında tamamlandı  B) tüm kullanıcılar listede
                    C) yetkili onay            D) kaldırmalar 5 iş gününde
  Q1: A✓ B✓ C✓ D✓
  Q2: A✓ B✓ C✓ D✗  (2 kaldırma 9 iş gününde yapıldı)
  Q3: A✓ B✓ C✓ D✓
  Q4: A✓ B✓ C✓ D✓
  Yeniden uygulama: Q4 listesi ERP'den tekrar çekildi, kullanıcı sayısı eşleşti.

SONUÇ        : 1 istisna. Neden: BT ekibinde izin dönemi, kuyruk takibi yok.
               Bulgu DN-2025-07 olarak raporlandı.
HAZIRLAYAN   : [ad]  TARİH: [tarih]   GÖZDEN GEÇİREN: [ad]

İyi bir çalışma kağıdı, başka bir denetçinin aynı örneklerle aynı sonuca ulaşabileceği kadar ayrıntılıdır. Kanıtların dosya adları veya depo bağlantıları çalışma kağıdına eklenir. “İncelendi, uygun” yazıp geçmek test değildir. Erişim gözden geçirme kontrolünde hangi kanıtların beklendiği erişim gözden geçirme kanıtı rehberinde ayrıca anlatılıyor.

Otomatik ve manuel kontrollerde test farkı

Boyut	Manuel kontrol	Otomatik kontrol
Hata kaynağı	İnsan; unutma, dikkatsizlik	Yapılandırma; yanlış veya değiştirilmiş ayar
Örneklem	Sıklığa göre birden çok örnek	Genellikle yapılandırmanın bir kez doğrulanması
Ana test yöntemi	İnceleme, yeniden uygulama	Yapılandırma incelemesi, test işlemi
Dayandığı ek kontroller	Kontrol sahibinin yetkinliği	Değişiklik yönetimi ve yetkili erişim

Otomatik bir kontrolün tek seferlik testle kabul edilmesi, yapılandırmanın dönem boyunca değişmediğinin gösterilmesine bağlıdır. Active Directory parola politikası test ediliyorsa ayar bir kez incelenir (Get-ADDefaultDomainPasswordPolicy çıktısı ve ince ayarlı parola politikaları için Get-ADFineGrainedPasswordPolicy -Filter *). Ardından dönem içinde bu ayarı değiştirebilecek yetkili hesaplar ve değişiklik kayıtları kontrol edilir. Sahada en sık atlanan kısım ince ayarlı politikalardır: varsayılan politika sağlam görünür, ayrıcalıklı bir gruba bağlı daha gevşek bir PSO ise kimsenin aklına gelmez. Değişiklik yönetimi kontrolü etkin değilse otomatik kontrol için daha geniş bir test gerekir; dönemin birden fazla noktasında yapılandırma yeniden doğrulanır.

Yarı otomatik kontroller, yani sistemin ürettiği bir raporu insanın gözden geçirdiği kontroller, iki parçalı test edilir: raporun eksiksiz ve doğru olduğu (otomatik kısım) ve gözden geçirmenin dönem boyunca yapıldığı (manuel kısım). Bu karma kontroller pratikte sık istisna kaynağıdır. Raporun doğruluğu varsayılır, test edilmez.

Kontrol setinin tasarım ve işletim etkinliğini bağımsız olarak değerlendirmek için BT güvenlik denetimi ve kontrol etkinliği, erişim, değişiklik ve operasyon kontrollerinin kendisini kurmak için IT genel kontroller (ITGC) çalışması kullanılabilir.

Sık sorulan sorular

Tasarım testi başarısızsa işletim testi yapılır mı?

Genellikle hayır. Kontrol riski ele alacak şekilde tasarlanmamışsa, dönem boyunca hatasız çalışması da riski azaltmaz. Bulgu tasarım eksikliği olarak raporlanır; kontrol yeniden tasarlandıktan sonra işletim testi bir sonraki dönemde yapılır.

Sadece sorgulama ile bir kontrol test edilebilir mi?

Hayır. Sorgulama kontrolün nasıl çalıştığını anlamak için gereklidir ama tek başına güvence vermez; kişinin anlattığı ile fiilen yapılan farklı olabilir. Sorgulamayı her zaman gözlem, inceleme veya yeniden uygulama ile destekleyin.

Otomatik kontrollerde neden tek örnek yeterli kabul edilir?

Otomatik kontrol aynı yapılandırmayla her seferinde aynı şekilde çalışır. Yapılandırma bir kez doğrulandığında ve dönem boyunca değişmediği gösterilebildiğinde, kontrolün tutarlı çalıştığı sonucuna varılabilir. Bu yüzden otomatik kontrol testi, değişiklik yönetimi ve yetkili erişim kontrollerinin etkinliğine dayanır.

Walkthrough ile tasarım testi aynı şey mi?

Walkthrough tasarım testinin en yaygın yöntemidir ama tek başına tasarım testi değildir. Walkthrough bir işlemi baştan sona izleyerek kontrolün var olduğunu ve anlatıldığı gibi uygulandığını gösterir; tasarım testi buna ek olarak kontrolün ilgili riski gerçekten azaltıp azaltmadığını değerlendirir.