SOX ITGC'de Denetçi Neden Önce Değişiklik Popülasyonunu İster?

SOX kapsamındaki bir şirkette bilgi sistemleri genel kontrollerinin (ITGC) denetimi, veritabanı ekibine genellikle tek bir istekle ulaşır: "Dönem içindeki bütün üretim değişikliklerinin listesini gönderin." Ekip bilet sisteminden bir dışa aktarım alır ve gönderir. Denetçinin ikinci sorusu ise çoğu zaman beklenmez: "Bu listenin eksiksiz olduğunu nereden biliyorsunuz?" Bu yazı denetçinin neden önce popülasyonu istediğini, popülasyonun tamlığının nasıl gösterildiğini ve örneklenen her değişiklik için hangi kanıtın beklendiğini anlatır.

Değişiklik Kontrolü Nasıl Test Edilir

SOX 404 finansal raporlamaya ilişkin iç kontrolün etkinliğini ister. Finansal veriyi işleyen sistemlerde "program değişikliği" kontrolü, üretime giden her değişikliğin yetkili, test edilmiş ve onaylanmış olduğunu ve onaylanan değişikliğin uygulandığını güvence altına alır. Veritabanı şema değişiklikleri, saklı yordamlar ve doğrudan veri düzeltmeleri bu kapsamdadır. Test üç adımda yürür: denetçi dönemin bütün değişikliklerinin listesini (popülasyonu) ister, bu listeden örnek seçer ve her örnek için kanıtı inceler.

Neden Önce Popülasyon

Eksik bir listeden seçilen örnek hiçbir şey kanıtlamaz: kayda girmemiş bir değişiklik örneğe de giremez. Bu yüzden denetim standartları, şirketin ürettiği bir bilgi kanıt olarak kullanılacaksa onun doğruluğunun ve tamlığının da test edilmesini ister; ABD'de halka açık şirket denetimlerinde bu, PCAOB'nin AS 1105 standardındaki kuraldır. Denetim dilinde bu tür listelere "şirketin ürettiği bilgi" (IPE) denir. Değişiklik listesi tipik bir IPE'dir ve denetçinin ilk sorusu onun nasıl üretildiğidir: hangi sistemden, hangi sorguyla, hangi filtreyle?

Popülasyon Nereden Çekilir

Tek bir kaynak yetmez. Bilet sistemi niyeti, veritabanı gerçeği tutar; tamlık ikisinin karşılaştırılmasıyla gösterilir. SQL Server Audit'te SCHEMA_OBJECT_CHANGE_GROUP açıksa dönemin fiili şema değişiklikleri şöyle çekilir (CR oluşturma, AL değiştirme, DR silme):

SELECT CAST(event_time AS date) AS ChangeDate, database_name, schema_name, object_name,
       action_id, server_principal_name, statement
FROM sys.fn_get_audit_file(N'D:\Audit\*.sqlaudit', DEFAULT, DEFAULT)
WHERE action_id IN ('CR', 'AL', 'DR')
  AND event_time >= '2026-01-01' AND event_time < '2026-04-01'
ORDER BY event_time;

İki Yönlü Mutabakat

Mutabakat iki yönde yapılır ve iki yön farklı riski yakalar:

• Gerçekten bilete: veritabanında yapılmış her değişikliğin bir bileti var mı? Eşleşmeyen satır, süreç dışından giden bir değişikliktir ve denetimin en ciddi bulgusu olur.
• Biletten gerçeğe: "uygulandı" olarak kapatılmış her biletin veritabanında bir karşılığı var mı? Eşleşmeyen bilet ya uygulanmamış ya da başka bir zamanda, başka bir içerikle uygulanmış demektir.

Eşleştirme anahtarı genellikle nesne adı, veritabanı ve tarihtir; bilet numarası betiğin açıklamasında ya da talep kaydında yazılıysa eşleşme kesinleşir. Eşleşmeyen her satırın yazılı bir açıklaması olmalıdır. Açıklaması olmayan bir fark, denetçinin gözünde kontrolün dönem boyunca çalışmadığının işaretidir.

Örneklenen Her Değişiklik İçin Kanıt

Popülasyon kabul edildikten sonra denetçi örnek seçer ve her biri için beş şeyi görmek ister:

1. Talep: değişikliği kim, hangi gerekçeyle istedi?
2. Onay, uygulamadan önce: onay zamanı çalıştırma zamanından önce mi?
3. Test: değişiklik üretimden önce denendi mi, sonucu nerede?
4. Görevler ayrılığı: isteyen, onaylayan ve uygulayan farklı kişiler mi?
5. Uygulanan = onaylanan: üretimde çalışan metin onaylanan metin mi?

Beşinci madde en sık eksik kalanıdır: bilet onayı genellikle bir açıklamaya verilir, betiğin son haline değil.

Ürünün Katkısı ve Sınırı

SQL Change Guard'daki "Period Population" raporu dönemin bütün taleplerini iki ayrı kaynaktan toplar, talep tablosundan ve denetim kaydından, ve satır satır karşılaştırır. Her satırda bir PopulationCheck değeri bulunur: Match, NotInAuditTrail, NotInTable, StatusMismatch ya da InProgress; eşleşmeyen satırlar en üstte listelenir. Dönem paketi aynı popülasyonu imzalı bir dosya olarak verir; paket en fazla 92 günü kapsar ve olay sayısı sınırı aşılırsa kırpılmaz, reddedilir. Örneklenen her talebin denetim dosyasında yukarıdaki beş maddenin karşılığı bulunur: talep sahibi ve gerekçe, onayların zamanı, izole deneme sonucu (yapıldıysa), görevler ayrılığı istisnaları ve onaylanan içeriğin çalıştırılan içerikle aynı parmak izini taşıdığı.

Sınırı açık: ürünün popülasyonu ürün üzerinden giden taleplerdir. Ürün dışından yapılan bir değişiklik bu listede yoktur; mutabakatın "gerçekten bilete" yönü için yukarıdaki veritabanı denetim kaydı yine gerekir. "Expected Access Principals" raporu ürünün her sunucuda kullandığı SQL hesabını listeler; bu hesap dışındaki bir hesapla yapılan şema değişikliği, ürün dışından gelmiştir.

Sık Sorulan Sorular

SOX Türkiye'de kimi ilgilendirir?

ABD borsalarında menkul kıymeti işlem gören şirketleri ve bunların konsolidasyona giren bağlı ortaklıklarını. Türkiye'deki bir bağlı ortaklığın sistemleri grup finansal raporlamasını besliyorsa aynı ITGC testleri orada da yapılır. Ayrıca bağımsız denetimde bilgi sistemleri kontrolleri benzer yöntemle test edilir; popülasyon ve örneklem mantığı aynıdır.

Acil değişiklikler popülasyona girer mi?

Evet, ve çoğu zaman ayrıca test edilir. Acil değişiklikte onay uygulamadan sonra gelebilir; denetçi bu durumda olay sonrası gözden geçirmenin yapıldığını ve belirlenen süre içinde yapıldığını görmek ister.

Örneklem büyüklüğünü kim belirler?

Denetçi, kontrolün sıklığına ve riskine göre belirler. Sizin etkileyebileceğiniz şey her örneğin kanıtını toplamanın maliyetidir; bu maliyet düştükçe daha geniş test ve daha az bulgu mümkün olur. Ayrıntı için ilgili yazıya bakın.

Veri düzeltmeleri de program değişikliği mi?

Finansal veriyi doğrudan değiştiren bir UPDATE ya da DELETE, kod değişikliği olmasa da denetim kapsamındadır; birçok denetimde "doğrudan veri değişikliği" ayrı bir kontrol olarak test edilir. Popülasyonda şema değişikliklerinin yanında bunlar da bulunmalıdır.