gait metodolojisi - global.theiia.org · amaçlarıyla yapılan kontrollerin tanımlanmasına da...

GAIT Metodolojisi

Genel IT kontrollerinin kapsamını değerlendirmek için risk-temelli bir yaklaşım

İç Denetim Enstitüsü

Tablo ve Grafikler

Tablo 1: GAIT Metodolojisindeki Bölümler …………………………………………………………………….....2

Tablo 2: GAIT’i anlamak …………………………………………………………………………………………………….3

Tablo 3: Dört ana GAIT prensipi…………………………………………………………………………………………5

Tablo 4: GAIT matrisi………………………………………………………………………………………………………….8

Tablo 5: GAIT’in uygulanması…………………………………………………………………………………………..11

Tablo 6: Boş GAIT matrisi…………………………………………………………………………………………………12

Tablo 7: Aplikasyon altyapısı ve riskler hakkında ilave bilgiler………………………………………….18

Tablo 8: Aplikasyon katmanı IT genel kontrol prosesleri (ITGC) ve tipik riskler…………………21

Tablo 9: Veritabanı katmanı IT genel kontrol prosesleri (ITGC) ve tipik riskler………………….22

Tablo 10: İşletim sistemi katmanı IT genel kontrol prosesleri (ITGC) ve tipik riskler………….24

Tablo 11: GAIT matrisindeki her hücre için sorulacak sorular……………………………………………25

Tablo 12: Yaygınlık değerlendirmesi…………………………………………………………………………………28

Tablo 13: Kilit IT genel kontrollerinin (ITGC) tanımlanması……………………………………………….29

Tablo 14: Kısmen tamamlanmış GAIT matrisi……………………………………………………………………31

Tablo 15: GAIT şablonu…………………………………………………………………………………………………….33

Tablo 16: Terimce…………………………………………………………………………………………………………….38

Prosedürler GAIT metodolojisini uygulama………………………………………………………………………………….13

Kilit manuel ve otomatik kontrolleri ve kilit işlevleri gözden geçirme....................... .14

ITGC’nin test edilmesini gerektiren aplikasyonları tanımlama....................................16

Kapsam-içi aplikasyonları ve bunların altyapısını daha kapsamlı kavrama.................18

IT genel kontrol proses (ITGC) hatası riskini değerlendirme.......................................23

IT genel kontrol proses (IYGC) yaygınlığını değerlendirme.........................................28

Test için kilit kontrolleri seçme...................................................................................29

Risk değerlendirme.....................................................................................................30

Aşağıdan-yukarıya risk değerlendirmesinin kullanılması……………………………………….....37

Bölüm 1. GAIT’i Anlamak

Bu bölüm, GAIT metodolojisini daha iyi anlamanıza yardımcı olmak amacıyla, aşağıda Tablo

2’de tarif edilen bölümler altında incelenmektedir.

Tablo 2. GAIT’i Anlamak

Bölüm Tanım Bakınız

“Yönetici özeti” GAIT’e yönetici düzeyinde giriş Sayfa 4

“GAIT’in dört ana

prensibini anlamak”

GAIT ana prensiplerinin detaylı tartışması Sayfa 6

“Kurum düzeyinde

kontroller hakkında

bir çift söz”

GAIT ile ilgili kurum düzeyinde kontroller Sayfa 10

Yönetici Özeti

Gerek şirket yönetim kademesinin, gerekse bağımsız denetçilerin karşı karşıya kaldığı önemli

zorluklardan biri, 2002 tarihli Sarbanes-Oxley Kanunu Madde 404 (“§404”) hükümlerinde

öngörülen şirket-içi finansal raporlama denetimlerinin (ICFR) yıllık değerlendirmesi için

etkin ve verimli bir kapsam tanımlama sorunudur.

ABD Menkul Kıymetler ve Borsa Komisyonu (SEC)1 ve Kamu Gözetimi Muhasebe ve

Denetim Standartları Kurumu (PCAOB)2, “§404” kapsamını ve bağlantılı kilit kontrolleri

tanımlamak için yukarıdan-aşağı ve risk-temelli bir yaklaşım önermiştir3. Bu yaklaşım,

finansal raporlama bağlamında karşılaşılması daha muhtemel ve önemli risklere odaklanan

etkin bir değerlendirmeye olanak verdiğinden dolayı tavsiye edilmektedir ve genel kabul

görmüştür.

1. 16 Mayıs 2005 tarihli “İç Denetim Raporlama Şartlarının Uygulanması Hakkında Komisyon

Bildirisi”nde ve Haziran 2007’de yayınlanan açıklayıcı kılavuzda.

2. 5 numaralı denetim standardında.

3. SEC ve PCAOB kılavuzlarında “kilit kontroller” kavramı tartışılmamaktadır. Ancak bu terim

hem şirket yönetimleri hem de dış denetçiler tarafından kabul gören ve kullanılan bir terim

haline gelmiştir. Sayfa 37’de “Kilit kontroller” bölümüne bakınız.

İç Denetim Enstitüsü (IIA) ve PCAOB gibi kurumlar, şirket düzeyinde kilit kontrollerin

tanımlanmasıyla ilgili kılavuzlar hazırlanmışlardır. Bunlara ilaveten, Bilişim Sistemleri

Denetim ve Kontrol Enstitüsü (ISACA) gibi kurumlar da IT şirketleri bünyesindeki kontrol

faaliyetlerinin değerlendirilmesine yönelik kılavuzlar hazırlamış ve yayınlamışlardır. Bununla

birlikte, IT şirketleri bünyesindeki kontroller (IT genel kontrolleri veya ITGC4,5) çerçevesinde

yapılan işlerin kapsamının tavsiye edilen yukarıdan-aşağı ve risk-temelli yaklaşımla nasıl

belirlenebileceği noktasında hâlâ tam netlik sağlanabilmiş değildir.

ITGC kilit kontrolleri (ITCG prosesleri bünyesinde var olan kontroller), mali tablolar ve kritik

muhasebe prosesleri düzeyinden başlayıp ITCG düzeyine kadar inen yukarıdan-aşağıya ve

risk-temelli bir yaklaşımın parçası olarak tanımlanmazlarsa,

kritik önem taşımayan kontrollerin değerlendirmeye alınması ve gözden geçirilmesi ve

böylece gereksiz emek ve kaynak sarfiyatı yapılması;

kilit önemde kontrollerin denetlenmemesi ve proses içinde geç bir aşamada denetlenmesi

ve neticede mali değerlendirme ve denetim etkinliğinin risk altına girmesi6

tehlikesi mevcuttur.

Mevcut IT Genel Kontrolleri Kapsamını Risk Temelli Değerlendirme Kılavuzu (GAIT), ICRF

için kilit kontrollerin kapsamını yukarıdan-aşağı ve risk-temelli olarak saptama çabalarının bir

parçası ve devamı olarak ITCG bünyesindeki kilit kontrol süreçlerini tanımlama yolunda hem

şirket yönetici kademesinin hem de dış denetçilerin7 istifade edebileceği bir metodolojiyi

kullanıma sunar. Bu kılavuz, PCAOB’nin 5 numaralı Denetim Standardına (AS/5),8 SEC’in

önerdiği açıklayıcı kılavuza (Haziran 2007’de yayınlanmıştır) ve IIA’nın “Sarbanes-Oxley

Kanunu Madde 404: İç Denetim Çalışanları için Yönetim Kılavuzu” (§ 404 Kılavuzu)

hükümlerine uygundur.

GAIT, herhangi bir kurumsal yapının ihtiyaçlarına göre şekillendirilebilen yapısal bir düşünce

prosesidir. Bu prosesin başlangıç noktası, yukarıdan-aşağıya ve risk-temelli bir yaklaşımla

tanımlanan işletme proses riskleri ve bununla bağlantılı kilit kontrollerdir. Mali tablolarla

ilgili riskler, GAIT yaklaşımıyla bir üst seviyeye taşınır. Bu seviye, bir kontrol ve güvenlik

zaafının iş prosesi içinde önemli bir kontrol hatasına yol açabileceği ve bağlantılı olarak mali

tabloların önemli oranda hatalı sunulmasıyla sonuçlanabileceği ITCG prosesi risklerinin

tanımlanmasıdır.

4. ITCG, genellikle bir IT kurumunun iş prosesleri çerçevesinde uygulanan kontrollerdir (alternatif

olarak ITCG prosesleri olarak tanımlanırlar). Bunların şu şekilde tanımlanması mümkündür:

“Genel manada ifade etmek gerekirse, ITCG, muhasebe hareketlerinin işlenmesi için gereken

işlevselliği sağlayan ve otomatik kontrol araçları temin eden aplikasyonların geliştirilmesine ve

akabinde bunların işlerliğinin idamesine olanak verir. Bu kontroller, ayrıca, aplikasyonların muntazam

işlerliğini ve gerek verilerin, gerekse programların yetkisiz değişikliklere karşı korunmasını sağlar.”

(§404 Kılavuzu)

5. Sayfa 36’da “ITCG” bölümüne bakınız.

6. Kilit kontrollerin işletme operasyonu açısından da kritik önem arz ettiği belirtilmelidir. Kilit

kontrollerin saptanmaması ve bunların test edilmemesi önemli işletme riskleri üzerindeki kontrolün

potansiyel olarak kaybedilmesi anlamına gelebilir – bu durum sadece mali raporlama konularını değil,

aynı zamanda işletme risk yönetimiyle ilgili hedefleri de etkiler.

7. Bu Kılavuz, “kullanıcılar” tanımı altında §404 Kılavuzundan sorumlu yöneticilere, bağımsız

denetçilere ve iç denetçilere vs. yönelik hazırlanmıştır.

8. Prensip olarak, PCAOB’nın, bu doküman gibi bir kılavuzu onaylama veya başka şekillerde resmen

tasdik etme veyahut da AS/5 prensiplerine uygunluğunu teyit etme gibi bir görevi yoktur.

GAIT, spesifik kilit kontrolleri tanımlamayıp, daha ziyade, kendileriyle ilgili kilit kontrollerin

tanımlanmasını gerektiren ITCG proseslerini ve bağlantılı IT kontrol hedeflerini tanımlar.

GAIT kullanıcıları, spesifik ITCG kilit kontrollerini tanımlamak ve sonrasında

değerlendirmek için, COBIT gibi başka araçlardan yararlanacaklardır.

ITCG prosesleri bünyesindeki risklerin tanımlanması, önemli hesaplardan ve bağlantılı iş

proseslerinden başlayan yukarıdan-aşağı yaklaşımın bir devamı olduğundan dolayı, işletme ve

IT uzmanlarından oluşan bütünleşik bir ekip tarafından yapılmalıdır. Tek başına işletme

uzmanları olayın teknik IT boyutunu gözden kaçırabilir; öte yandan, tek başına IT uzmanları

ise IT işlevlerine ne ölçüde bel bağlanabileceği konusunda yeterli ferasete sahip olmayabilir.

Bu noktada GAIT, her ne kadar ITCG risk değerlendirmesine ve §404 değerlendirmesi

kapsamının belirlenmesine odaklansa da, GAIT prensiplerinin başka değerlendirme

amaçlarıyla yapılan kontrollerin tanımlanmasına da tatbik edilmesi mümkündür.

GAIT’in dört ana prensibini anlamak

Bu bölümde, GAIT Prensipleri başlığı altında bulunan ve aşağıda Tablo 3’te özetlenen dört

ana GAIT prensibi açıklanmıştır. Bu prensiplerin tatbik edilmesi hakkında bilgi için Sayfa

11’de “GAIT Metodolojisi Uygulaması” bölümüne bakınız.

Tablo 3: Dört ana GAIT Prensibi

Prensip Ayrıntılar için, bakınız…

1 Genel IT kontrol prosesleri (örneğin değişim yönetimi,

yaygınlık, erişim güvenliği, operasyonlar) bünyesindeki

risklerin ve bunlarla bağlantılı kontrollerin tanımlanması

süreci iş prosesleri kapsamındaki önemli hesapların, bu

hesaplarla ilgili risklerin ve kilit kontrollerin tanımlanmasına

yönelik yukarıdan-aşağı, risk-temelli yaklaşımın bir devamı

niteliği taşımalıdır.

Sayfa 7

2 Tanımlanması gereken genel IT kontrol prosesi riskleri, mali

önem taşıyan uygulamalarla ilgili kritik IT işlevlerini ve

bağlantılı verileri etkileyen risklerden oluşur.

Sayfa 8

3 Tanımlanması gereken genel IT kontrol prosesi riskleri, Sayfa 9

aplikasyon program kodu, veritabanları, işletim sistemleri ve

ağlar olmak üzere bizzat IT proseslerinin içinde ve çeşitli IT

katmanlarında bulunur.

4 Genel IT kontrol proseslerinin içerdiği riskler, münferit

kontroller yoluyla değil, IT kontrol hedeflerinin

gerçekleştirilmesi yoluyla azaltılabilir.

Sayfa 9

Prensip 1

Genel IT kontrol prosesleri (örneğin değişim yönetimi, yaygınlık, erişim güvenliği,

operasyonlar) bünyesindeki risklerin ve bunlarla bağlantılı kontrollerin tanımlanması süreci,

iş prosesleri kapsamındaki önemli hesapların, bu hesaplarla ilgili risklerin ve kilit

kontrollerin tanımlanmasına yönelik yukarıdan-aşağı, risk-temelli yaklaşımın bir devamı

niteliği taşımalıdır.

GAIT, iş prosesiyle ilgili adımların (özellikle IT işlevselliğine dayanan kilit kontrolleri

tanımlama adımı) sonuçlarını kullanarak, AS/5’te belirtilen yukarıdan-aşağı yaklaşımı

geliştirir ve böylece:

ITCG proseslerinde, hatalara veya usulsüzlüğe mahal verebilecek ve mali tabloların

önemli oranda tahrif edilmesine yol açabilecek potansiyel hata noktalarını tanımlama

noktasında kullanıcılara yardımcı olur ve

Bu risklerle ilgili kilit ITCG’leri tanımlama olanağı verir.

Aşağıda Şekil 1’de, GAIT faaliyetlerini içeren yukarıdan-aşağı prosesin özet sunumu (ayrıca

sayfa 38’e bakınız) verilmiştir. Bu sunum şunları içerir:

1. AS/2 aşaması: Önemli hesapların ve lokasyonların, ardından bu hesaplarla bağlantılı iş

proseslerinin, söz konusu iş proseslerinde önemli yanlış beyanlara yol açabilecek

potansiyel hata noktalarının ve önemli yanlış beyanları önleme ve teşhis etmeye yönelik

kilit kontrollerin tanımlanmasıyla başlar. ITCG, AS/2’de tartışma konusu yapılmış, fakat

detaylarına girilmemiştir.

2. GAIT, önemli yanlış beyanları önleme ve teşhis etmede kullanılan kritik IT işlevlerini

(örneğin kilit otomatik kontroller ve kilit raporlar), sonrasında önemli aplikasyonları9

(kritik IT işlevlerini ve/veya verilerini içeren aplikasyonlar), sonra önemli aplikasyonlarla

bağlantılı ITCG proseslerini ve sonra önemli aplikasyonlarda kritik IT işlevlerinin sürekli

işlerliğini güvenceye almak için gereken IT kontrol hedeflerini tanımlayarak yukarıdaki

prosesin devamını getirir.

3. ITGC’de kilit kontrolleri tanımlamak için kullanılan, COBIT gibi herhangi bir

metodoloji.

9. Bu bağlamda, “aplikasyon” terimi bilgisayar sistemine atıf yapmaktadır. Bazıları bu terimi iş

prosesinin bütünü için kullanır, fakat burada terimin kullanım amacı, IT Genel Kontrolleriyle

bağlantıları açısından değerlendirilmesi gereken bilgisayar sistemlerini tanımlamaktır. Benzer olarak,

“finansal açıdan önemli aplikasyonlar” terimi de, iş proseslerinin bütününden ziyade, bilgisayar

sistemlerine atıf yapmaktadır.

Şekil 1: GAIT dahil yukarıdan-aşağıya proses

Prensip 2

Tanımlanması gereken genel IT kontrol prosesi riskleri, mali açıdan önem taşıyan

uygulamalarla ilgili kritik IT işlevlerini ve bağlantılı verileri etkileyen risklerden oluşur.

§404 çerçevesinde yapılacak işlerin kapsamında, sadece mali tablolarda makul derecede

yüksek bir önemli hata riski teşkil eden ITCG prosesi risklerinin (kritik IT işlevleri üzerindeki

dolaylı etkilerinden kaynaklı) üzerinde düşünülmesi gerekir. AS/5’deki yukarıdan-aşağı

yaklaşım, iş proseslerindeki potansiyel hata ve arıza noktalarını ve bağlantılı kilit kontrolleri

tanımlamayı içerir. IT işlevlerine bağımlı (yani otomatik kilit kontrollere veya kilit raporlara

dayanan veya mali açıdan önemli verileri içeren) aplikasyonlar söz konusu olduğunda, bunlar

mali açıdan önemli aplikasyon olarak kabul edilir (Sayfa 36’da “Mali açıdan önemli” kısmına

bakınız) ve ITCG proseslerindeki zaaflardan dolayı bunların işlerliğinin maruz kaldığı

risklerin değerlendirilmesi gerekir.

Prensip 3

Tanımlanması gereken genel IT kontrol prosesi riskleri; aplikasyon program kodu,

veritabanları, işletim sistemleri ve ağlar olmak üzere bizzat IT proseslerinin içinde ve çeşitli

IT katmanlarında bulunur.

IT kapsamındaki örneğin ağ taramaları yapma, ağ yönelticilerin bakımını yapma ve

aplikasyonlardaki değişiklikleri test etme gibi etkinlikler ITCG proseslerini oluşturur. GAIT

metodolojisi, ITCG ile ilgili etkinliklerin değişim yönetimi, operasyonlar ve iş güvenlik

prosesleri kapsamına girdiğini varsayar. ITCG prosesleri için birebir bu tanımın (Sayfa 36’da

“Tanımlar” bölümünde bulunmaktadır) kullanılması GAIT’in kullanımı açısından kritik önem

taşımaz. Her GAIT kullanıcısı GAIT metodolojisinin özünü değiştirmeden kendince bir tanım

yapabilir.

Her ITCG prosesi ilgili aplikasyonunun altyapısındaki dört katmanda yürür; bunlar

aplikasyon, veritabanı (veritabanı şeması gibi bağlantılı yapıları da içerir), işletim sistemi ve

ağ altyapısıdır. Bu katmanlar aynı zamanda “yığıt” olarak da bilinir. Mali açıdan önem taşıyan

aplikasyonların ve verilerin güvenliğini tehdit eden riskler her ITCG prosesinin her IT altyapı

katmanında değerlendirilebilir (örneğin aplikasyon kodu katmanında değişim yönetimi

prosesinde veya veritabanı katmanında güvenlik yönetimi prosesinde söz konusu olan riskleri

değerlendirmek suretiyle).

Aşağıda Tablo 4’te, yığıt yapısının ITCG prosesleriyle ilişkisini gösteren boş bir GAIT

matrisi örneği verilmiştir. GAIT matrisinin doldurulması hakkında bilgi için, Sayfa 22’deki

“ITCG proses hataları riskinin değerlendirilmesi” başlıklı bölüme bakınız. Kısmen

doldurulmuş bir GAIT matrisi için Sayfa 29’daki “Örnek GAIT matrisi” bölümüne bakınız.

Tablo 4: GAIT matrisi

Katman Değişim Yönetimi Operasyonlar Güvenlik

Aplikasyon

Veritabanı

İşletim sistemi

Ağ altyapısı

Prensip 4

Genel IT kontrol proseslerinin içerdiği riskler, münferit kontroller yoluyla değil, IT kontrol

hedeflerinin gerçekleştirilmesi yoluyla azaltılabilir.

Her ITCG prosesi, aşağıda sayılan IT kontrol hedeflerine ulaşmaya yardımcı kontroller içerir:

Tüm sistemler üretime alınmadan önce uygun bir şekilde test edilir ve valide edilir.

Veriler yetkisiz değişikliklere karşı koruma altına alınır.

Operasyon esnasında karşılaşılan problemler veya olaylar münasip bir şekilde

cevaplanır, kaydedilir, araştırılır ve çözülür.

Bu hedeflere ulaşmada yaşanacak bir başarısızlık, kritik IT işlevlerinin muntazam ve istikrarlı

bir şekilde yürümemesi anlamına gelebilir. GAIT, mali açıdan önemli aplikasyonlar için

gereken IT kontrol hedeflerini tanımlamaya yardımcı olur.

ITCG prosesleri kapsamındaki kontroller doğrudan mali tablolarla ilgili önemli hata riskiyle

ilgili değildir. ITGC’lerin kapsamındaki her kontrol, önemli ve ilgili IT kontrol hedeflerine

ulaşılmasını güvenceye alır. Bu kontrol hedefleri, önemli IT işlevlerinin tutarlı bir şekilde

çalışmasını temin eder. Söz konusu kritik IT işlevleri, iş proseslerindeki kilit kontrollerin

istikrarlı işlev görmesi için mutlak gerekli olan işlevlerdir. İş prosesleri kapsamındaki kritik

kontroller ise mali tablolardaki esaslı ve önemli hataları önlemeye ve tespit etmeye yararlar.

Sonuç olarak, ilk etapta önemli IT kontrol hedeflerinin tanımlanması önemlidir; ancak bunlar

tanımlandıktan sonra ITGC kapsamındaki kilit kontrolleri tanımlama aşamasına geçilir.

Kapsam içine alınması gereken kilit ITGC kontrolleri, IT kontrol hedeflerine ulaşmak için

mutlaka gereken kontrollerdir. Bazı ITGC kontrolleri ne kadar önemli görünürse görünsünler,

belirli bir IT kontrol hedefine ulaşmaya yardımcı olmadıkları müddetçe bunların §404’de

öngörülen değerlendirme ve test kapmasına alınmaları şart değildir.

Kurum seviyesinde kontroller hakkında bir çift söz10

SEC ve PCAOB, kurumsal kontrollerin (Sayfa 35’te “Kurum düzeyinde kontrol” bölümüne

bakınız) §404 prosesinin erken bir safhasında yapılmasını tavsiye etmektedir. Kurum

düzeyinde yapılan risk değerlendirmesinden ve kontrollerden elde edilen bilgiler (özellikle

COSO Kontrol Çevresi katmanıyla ilgili olanlar), örneğin ITGC prosesleri gibi daha alt

düzeylerde yapılan risk değerlendirmesinde ve bağlantılı kontrollerde dikkate alınabilir.

Bundan dolayı, GAIT, IT kurumsal kontrollerin değerlendirilmesi hakkında detaylı bir

tartışma içermez. Bu kontrollerin, kurum düzeyinde yapılan kontroller kapsamında gözden

geçirilmiş oldukları varsayılır.

GAIT metodolojisini kullanırken, kurum-düzeyinde kontrol faaliyetlerinden elde edilen

bilgilerin muhakkak dikkate alınması gerekir, çünkü bu bilgiler belirli ITGC proses

hatalarının meydana gelme ihtimalini değerlendirme noktasında etkili ve yararlı olabilir.

Örneğin, COSO Kontrolleri Çevresi, işletmede uygun kalifikasyonlu ve eğitimli personelin

istihdam edilmesiyle ilgili soruları içerir. IT branşında bu alanla ilgili sorunlar varsa - örneğin

aplikasyonları deneyimsiz kişiler test ediyorsa – bu durum, testlerin yeterli düzeyin altında

kalma riskinin daha yüksek olduğu anlamına gelebilir.

10. Sayfa 38’deki Terimce’ye bakınız. “Kurum-düzeyinde” teriminin, bazı yayınlarda tercih edilen

“şirket-düzeyinde” terimiyle eşanlamlı olduğunu not ediniz.

Bölüm 2. GAIT Metodolojisi Uygulaması

GAIT metodolojini uygulamaya başlamanıza yardımcı olmak amacıyla, bu bölüm, aşağıda

Tablo 5’te açıklanan iki kısma ayrılmıştır.

Tablo 5: GAIT’in Uygulanması

Bölüm Tanım Bakınız

“GAIT: Kısa Tanım” GAIT metodolojisinin özü Aşağı

“GAIT sonuçlarının dokümantasyonu” GAIT sonuçlarının nasıl dokümante edileceği

hakkında açıklama

Sayfa 12

“GAIT’in uyarlanması” GAIT’in kurumunuza uyarlanması hakkında

açıklama

Sayfa 13

“GAIT değerlendirme ekibinin

toplanması”

GAIT uygulaması için gereken ekip elemanlarının

tanımı

Sayfa 13

“GAIT metodoloji safhaları” Adım adım GAIT uygulama prosesi safhaları Sayfa 13

GAIT: Kısa Tanım

GAIT metodolojisi finansal önem taşıyan her uygulamayı irdeler ve ITCG proseslerinde yığıt

yapısının farklı katmanlarında meydana gelen hataların, ilgili uygulamanın kritik işlevlerinin

istikrarlı operasyonuna muhtemel bir tehdit oluşturup oluşturmayacağını tayin eder. Hata

meydana gelmesi muhtemelse, GAIT, ITGC proses risklerini ve bağlantılı kontrol hedeflerini

detaylı olarak tanımlar; bu kontrol hedeflerine ulaşıldığında bahsedilen riskler de azalır. ITGC

kontrol hedeflerine ulaşmaya yardımcı kilit kontrolleri tanımlamak için COBIT ve bir dizi

başka metodolojiden yararlanılabilir.

Kısaca, GAIT metodolojisi sırayla şu üç soruyu yönelterek size kılavuzluk eder:

1. Finansal açıdan önemli aplikasyonlardaki hangi IT işlevi, önemli raporlama hatalarını

önlemeye/tespit etmeye yönelik iş prosesi kilit kontrollerinin uygun işlerliği bakımından

kritik önem arz etmektedir (başka bir deyişle hangi IT işlevi kritiktir)?

2. Yığıt yapısının farklı katmanlarındaki her IT prosesi için, meydana gelen bir proses

hatasının kritik işlev hatasına yol açma ihtimali – ve dolaylı olarak önemli raporlama

hatası riski doğurma ihtimali – makul derecede yüksek midir (başka bir deyişle, ilgili

katmandaki proses aksadığında, kritik işlevler bundan nasıl etkilenecektir? Bu aksama,

ilgili işlevi önemli raporlama hatası riskine yol açacak ölçüde etkiler mi)?

3. Bu gibi ITGC proses riskleri mevcutsa, bununla ilgili IT kontrol hedefleri nelerdir (başka

bir deyişle, kritik işlevlerin işlerliğini güvenceye almak için ne gibi IT kontrol hedeflerine

ulaşmak gerekir)?

Örneğin:

Risk (yığıt yapısının aplikasyon katmanındaki değişim yönetimi prosesi

kapsamında): Test edilmeyen uygulama değişiklikleri kritik işlevlerin aksamasına

yol açabilir.

Kontrol hedefi: Tüm program değişiklikleri uygun bir şekilde test edilir ve

uygulamaya geçilmeden evvel sonuçlar gözden geçirilir ve onaylanır.

Kilit kontroller:

Program değişiklikleri ayrı bir test ortamında test edilir.

Tüm test sonuçları bir yönetici tarafından gözden geçirilir ve onaylanır.

Önemli değişikliklerin tümü kullanıcı tarafından test edilir ve bir yetkili

yönetici tarafından onaylanır.

Acil değişiklikler üst IT yönetim kademesi tarafından gözden geçirilir ve

onaylanır.

GAIT sonuçlarının dokümantasyonu

Bu doküman, GAIT sonuçlarının dokümante edilmesiyle ilgili iki farklı yaklaşım sunar.

Bunlar, aşağıda açıklanan GAIT matrisi ve GAIT şablonudur (“GAIT şablonu” Sayfa 33’da

açıklanmıştır. Öte yandan, benimsediğiniz yaklaşım ne olursa olsun, sonuçları ayrıntılı bir

şekilde dokümante etmeli ve böylelikle sonuçları gözden geçiren mantıklı bir kişinin

sonuçların arkasındaki mantığı kavramasına olanak vermelisiniz.

GAIT matrisi (aşağıda Tablo 6’ya bakınız) metodolojiyi açıklar ve mali açıdan önemli her

uygulamaya ilişkin sonuçları dokümante etmenize imkân verir. Matrisin her hücresine, ilgili

yığıt yapısının o katmanındaki iş prosesi için kritik işlevlerin risk altında olup olmadığı

değerlendirmesini girebilir ve ilgili IT kontrol hedeflerini tanımlayabilirsiniz.

Tablo 6: Boş GAIT Matrisi


Aplikasyon

Veritabanı

İşletim sistemi

Ağ altyapısı

GAIT’in uyarlanması

GAIT esnek bir metodolojidir. Kullanıcılar GAIT adımlarını kendi terminolojilerine ve IT

kontrol çerçevelerine göre uyarlayabilirler. Özellikle, kullanıcılar kendi ITGC proseslerini ve

seviyelerini GAIT matrisi yığıtında kendilerine uygun şekilde tanımlayabilirler ve örneğin

önceden var olan değişiklik yönetimi, operasyonlar, güvenlik kademelerine kullanıcı erişimi

ve öncelikli erişim seçenekleri ekleyebilirler. Yığıt yapısı hakkında daha fazla bilgi için Sayfa

9’da “Prensip 3” başlığı altına bakınız.

GAIT değerlendirme ekibinin toplanması

Tecrübeler göstermektedir ki, işletme kullanıcıları kullandıkları ekranlarda ve raporlardaki IT

işlevlerini her zaman tam manasıyla anlamamakta, öte yandan IT uzmanları ise işletme

proseslerini ve bunların nelerden beslendiklerini her zaman tam olarak kavrayamamaktadırlar.

Dolayısıyla, GAIT değerlendirmesi hem işletme/ekonomi bilgisi hem de IT bilgisi olan karma

bir iç denetim uzmanları ekibi tarafından yapılmalıdır.

GAIT; başlangıç aşamalarında işletme ekonomisi uzmanı personel tarafından icra edilen

yukarıdan-aşağı ve risk-temelli yaklaşımın bir devamı niteliğine sahiptir. GAIT, iş prosesleri

içindeki potansiyel hata ve aksama noktalarının değerlendirilmesi aşamasında tanımlanmış

olan ve iş prosesi kilit kontrollerinin (mali tablolardaki esaslı ve önemli hataları önlemeye ve

tespit etmeye yönelik kontroller) uygun ve etkin bir şekilde yapılabilmesi için gerek duyulan

kritik IT işlevlerinin kavranmasına dayanır.

GAIT değerlendirmesi IT altyapısının ve IT proseslerinin daha teknik yönlerine doğru

derinleştikçe, IT uzmanlığı daha da kritik hale gelir. Bu uzmanlık kritik IT işlevlerini (kilit

otomatik kontroller, kilit raporlar ve diğer işlevler), ilgili ITGC proseslerindeki potansiyel

aksama noktalarını ve uygun ITGC kontrol hedeflerini ve kilit kontrolleri anlamak ve

tanımlamak için yeterli düzeyde olmalıdır.

GAIT değerlendirmesinin sonuçları karma bir ekip tarafından gözden geçirilmeli ve bu

sonuçların uygunluğu ve akla yatkınlığı doğrulanmalıdır.

GAIT metodolojisi safhaları

GAIT metodolojisini uygulamak için, aşağıdaki prosedürde sıralanan safhaları izleyiniz.

GAIT metodolojisini uygulamak için

Safha 1: Kritik IT işlevlerini tanımlayınız (ve gerekirse valide ediniz). Bakınız sayfa 14.

Safha 2: ITGC’nin test edilmesini gerektiren [önemli] aplikasyonları tanımlayınız. Bakınız

sayfa 16.

Safha 3: ITGC proses risklerini ve bağlantılı kontrol hedeflerini tanımlayınız. Bakınız Sayfa

17. GAIT metodolojisinin can alıcı safhası budur.

Safha 4: Kontrol hedeflerinin karşılanması için test edilecek ITGC’yi tanımlayınız. Bakınız

Sayfa 25.

Safha 5: Sonuçlar, makul ve mantıklı bir kişi tarafından gözden geçirilir. Bakınız Sayfa 28.

GAIT metodolojisinin kullanımı ve uygulama senaryoları hakkında daha fazla bilgi için,

IIA’ın www.theiia.org adresli internet sitesini tıklayabilirsiniz.

Safha 1 Kritik IT işlevini tanımlayınız (ve gerekirse valide ediniz)

GAIT metodolojisi, kilit manuel ve otomatik kontrollerin, bunların yanında kritik sistem

işlevlerinin tanımlanmasıyla başlar. (Bu ve müteakip safhanın GAIT çerçevesine nasıl

yerleştirildiği aşağıda Şekil 2’de gösterilmiştir). İş proseslerinin yukarıdan-aşağı

değerlendirilmesi suretiyle bu kilit manuel ve otomatik kontroller tanımlanmış olacaktır.

GAIT değerlendirmesine temel oluşturan listenin doğrulanması ve tüm kritik IT işlevlerinin

tanımlanmasıyla yukarıdan-aşağı prosese devam edilir. Bu liste, Safha 2’de finansal açıdan

önemli olan aplikasyonları tanımlamak için, yani hangi aplikasyonların §404 değerlendirmesi

ve testleri “kapsamı içinde” değerlendirileceğini belirlemek için kullanılır.

Şekil 2: Safha 1 ve 2

Kilit manuel ve otomatik kontrolleri ve kilit işlevleri gözden geçirmek için

1. Şirketin mali proseslerindeki kilit kontrolleri, kilit raporları ve diğer işlevleri tanımlayınız

ve hangilerinin manuel, hangilerinin otomatik olacağını tayin ediniz.

2. Dayanılan kritik IT işlevlerinin listesini oluşturunuz. Bu liste otomatik kontrolleri

(aşağıda Basamak 3’e bakınız) ve diğer kritik IT işlevlerini (aşağıda Basamak 4’e

bakınız) içerecektir. Otomatik kontroller şunları içerir:

http://www.theiia.org/

Tam otomatik kontroller (örneğin defter-i kebirdeki hesapların denkleştirilmesi

veya güncellenmesi.)

Manuel kontroller için ihtiyaç duyulan11 ve meydana gelen bir işlev hatasının

gözden kaçabileceği aplikasyon işlevleri (Ayrıca Sayfa 37’de “Kilit rapor”

bölümüne de bakınız). Bunlar bazen “hibrit kontroller” şeklinde de adlandırılır.

Örneğin, çift makbuzları tespit etme amaçlı bir kilit kontrol, bir sistem raporunun

gözden geçirilmesini içerebilir. Normalde kontrolün manuel icra edilen bölümünün

rapordaki yanlışlıkları tespit etmesi beklenirken, raporun tamlığını ve bütünlüğünü

temin etmesi mümkün olmayabilir. Dolayısıyla, bu rapor kapsam itibariyle bir kilit

rapor hüviyeti kazanır. Buna mukabil, bir banka mutabakatı söz konusu olduğunda

kurumun defter-i kebir tutma sisteminde cari işlemler dengesini, gelirleri ve

harcamaları gösteren bir rapor kullanılabilir. Ancak banka mutabakat işlemi

kontrolünün normal işleyişi içinde rapordaki bir hata derhal tespit edilecektir.

Bundan dolayı, kontrolün otomatik kısmı kilit nitelik taşımayacak, sadece manuel

kısmı kilit önemde olacaktır.

3. Kilit otomatik kontrolleri teyit ediniz:

Kilit niteliklerini doğrulamak için otomatik kontrolleri gözden geçiriniz12. Manuel

ve otomatik proseslerin içerdiği riskleri ve bunlarla bağlantılı kontrolleri, özellikle

bir kontrol listesi yardımıyla veya diğer yukarıdan-aşağı yaklaşımlarla belirleyen

farklı ekiplere sahip organizasyonlarda, normalde kilit nitelik taşımayan otomatik

kontrollerin, kilitmiş gibi sınıflandırılmış olması mümkündür.

Otomatik kontrollerin aksaması halinde bir önemli hatanın gözden kaçma

olasılığının en azından makul ölçüde mevcut olup olmadığını değerlendiriniz.

Bazen bir otomatik kilit kontrolde meydana gelen bir aksaklığı önemli bir hataya

yol açmadan önce tespit eden veya verilerde potansiyel olarak önemli bir hata

doğurabilecek bir yetkisiz değişikliği tespit eden manuel kilit kontroller kullanılır.

Bu gibi manuel kontrollerin kilit kontrol olarak tanımlandığından emin olabilmeli

ve otomatik kontrolleri kilit kontroller listesinden çıkarabilmelisiniz.

4. Kilit kontrol olarak tanımlanmayan aplikasyonlardaki bir hatanın gözden kaçabileceği ve

mali tablolarda makul ölçüde bir önemli hata riski doğurabileceği başka kritik IT

işlevlerinin olup olmadığını belirleyiniz. Çoğu aplikasyon, mali hareketlerin işlenmesi ve

ilgili muhasebe kayıtlarının tutulması için ihtiyaç duyulan hesaplamaları veya başka

işlemleri13 yaparlar. Bu işlemler tam anlamıyla kontrol niteliği taşımazlar (Sayfa 35’teki

kontrol tanımına bakınız). Ancak bu aplikasyonların işlevinde bir aksama meydana

gelmişse, söz konusu işlemlerde, kilit manuel veya otomatik kontrollerde tespit

edilemeyen önemli hataların ortaya çıkması mümkündür. Bundan dolayı, bu gibi

işlemleri de ilaveten kritik işlev olarak listeye almalı ve bunların tabi olduğu riskleri de

hesaba katmalısınız.

Bu noktada, finansal önem arz eden her aplikasyonda tüm kritik IT işlevlerinin tanımlanmış

olması gerekir.

12.Manuel kontrollerle veya otomatik kontrollerle güvenliği sağlama ve test etme seçenekleri arasında

seçim yaparken, bunlarla bağlantılı maliyetleri de hesaba katmanız gerekir. Bazıları otomatik

kontrollerin, manuel kontrollerden daha etkili ve daha düşük maliyetli olduğu kanaatindedir. Böyle

düşünenlerin öne sürdüğü gerekçe, (nispeten) çok sayıda işlem ve hareket içinden örneklem

oluşturarak test edilmeleri gerektiğinden dolayı manuel kontrolleri test etmenin pahalı olması, buna

karşılık otomatik kontrolleri sadece bir defa test etmenin yeterli olmasıdır. Ancak otomatik

kontrollerde tek bir testle yetinebilmek için, etkin ve verimli bir ITGC uygulamasının mevcut olması

şarttır, zira ITGC, otomatik kontrollerin istikrarlı bir şekilde işlevini sürdürmesini güvenceye alır ve

bağlantılı olarak tek ögeli bir örneklemle yetinilmesini mümkün kılar. Otomatik kontrollere bel

bağlamanın maliyeti, ilgili ITGC genel kontrolleri proses kilit kontrollerinin değerlendirilmesini ve

test edilmesini de içerir. Birçok şirketin manuel kontrollerden ziyade otomatik kontrolleri tercih ederek

kârlı çıkma ihtimali yüksek olmakla birlikte, bu şirketlerin hangi kontrolleri seçecekleri konusunda,

bağlantılı tüm maliyetleri ve riskleri hesaba katarak dikkatli karar vermeleri gerekir. Otomatik

kontroller kilit kontrol hüviyetini devam ettirmekle birlikte, otomatik kontrollerle bağlantılı IT genel

kontrol proseslerindeki riskler değerlendirildiğinde, manuel kilit kontroller değerli bir tercih haline

gelebilir.

13. Bazı IT denetçileri, defter-i kebir hesaplarının güncellenmesi vs. gibi bu hesaplamalar için

“programlı prosedürler” veya “programlı muhasebe prosedürleri” terimini kullanırlar.

Safha 2 ITGC’nin test edilmesini gerektiren [önemli] aplikasyonları tanımlama

Kritik IT işlevleri doğrulandıktan sonra, mali açıdan önem taşıyan aplikasyonların

tanımlanması aşamasına geçilebilir. Finansal açıdan önemli aplikasyonlar, potansiyel ITGC

riski içeren aplikasyonlardır, zira bunlar kritik IT işlevlerini ve verilerini içerirler (Sayfa 38’te

terimce bölümüne bakınız). Finansal hareketlerin işlenmesinde rol oynayan, fakat ne bir kritik

IT işlevi, ne de yetkisiz değişiklik (önemli ve fahiş hataya yol açabilecek) riski içeren

aplikasyonlar §404 kapsamına girmez; bunlarla ilgili ITGC’lerin test edilmesine gerek yoktur.

ITGC’nin test edilmesini gerektiren aplikasyonları tanımlamak için

1. Kritik IT işlevlerini aplikasyona göre sınıflandırınız. Sonuçta oluşan kritik işlevli

aplikasyonlar listesi, ITGC proseslerinin içerdiği risklerin değerlendirilmesini gerektiren

(sadece bir sonraki basamağa tabi olan), finansal açıdan önemli aplikasyonların listesini

oluşturur. Finansal açıdan önem taşıyan aplikasyon tanımı için Sayfa 36’ya bakınız.

2. Kritik IT işlevinden dolayı finansal açıdan önemli görülmeyen uygulamalar için bir ilave

basamak daha vardır. Bu basamak, doğrudan aplikasyon verilerinde yapılan yetkisiz bir

değişikliğin gözden kaçan bir önemli hataya yol açıp açmayacağının değerlendirilmesidir

(Ayrıca Sayfa 7’de “Prensip 1” başlığına bakınız”). Bu basamakta, normal prosesi ve

kontrolleri atlatarak (bazen “arka kapıdan erişim” diye adlandırılır) verilerde yapılan

değişikliklerin, finansal tablolarda, normal kontrol prosedürleri içinde gözden kaçan

önemli bir hataya yol açıp açamayacağı tayin edilir. Eğer bu mümkünse, aplikasyonun,

finansal açıdan önemli bir aplikasyon hüviyetiyle GAIT yoluyla değerlendirilmesi

gerekir. Değilse, aplikasyon kapsam dışında görülebilir.

Zaman zaman hesaplamalarda ve diğer işlevlerde, bir önceki aplikasyonda üretilen

verilerin kullanılabileceği akılda tutulmalıdır. Söz konusu verilerde meydana gelen bir

değişikliğin gözden kaçan önemli hatalara yol açabileceği durumlarda, sadece verilerin

kullanıldığı aplikasyon değil, aynı zamanda başka aplikasyonlar (örneğin, verilerin

üretildiği aplikasyonun yanında, verilerin saklandığı, dolayısıyla riske maruz kalan başka

herhangi bir aplikasyon) da risk altına girebilir. Tüm bu önceki aplikasyonlarda üretilen

verilerde meydana gelen değişiklikler, orada veya başka bir yerde fark edilmediği

taktirde, bu aplikasyonların finansal açıdan önemli ve vahim sonuçlar doğurması

mümkündür.

3. Sadece finansal önem taşıyan aplikasyonlarla devam edin.

Safha 3 IT Genel Kotrol Proses (ITGC) risklerini ve bağlantılı kontrol hedeflerini

tanımlama

Bu safha başlıca iki aktivite içerir:

Her önemli aplikasyon için ilave bilgiler temin etme.

Her önemli aplikasyon için ITGC proses risklerini değerlendirme: Bu değerlendirme

yığıt yapısının her kademesinde her ITGC prosesi için yapılır.

Aşağıdaki şekilde bu safhanın GAIT kapsamında nerede konumladığı gösterilmiştir:

Kilit Nokta: Bir aplikasyonda aşağıdakilerden hiçbiri mevcut değilse, bu

aplikasyon finansal açıdan önemli değildir ve ITGC’ye bağımlılığı

yoktur:

a. Kilit otomatik (aplikasyon kontrolleri).

b. Kilit raporlar veya diğer karma raporlar (IT işlevlerine,

taramalarına, raporlarına vs. bağımlı manuel kontroller).

c. Diğer kritik IT işlevleri.

d. Verilerin, kilit kontrollerin zaafa uğramasına (aşağı akış

yönünde olabilir) veya başka hallerde önemli hatalara yol

açabilecek şekilde değiştirilebilmesi (pass-through olsa bile)

imkânı. Bu veriler işlem verileri veya referans veriler (örneğin

fiyatlar, kredi limitleri vs.) olabilir.

Şekil 3: Safha 3

Yukarıdan aşağıya proseslerin iş prosesleriyle ilgili kısmında, finansal bilgilerin işlenmesinde

rol oynayan her bir aplikasyonu kapsamlı bir şekilde kavradınız. Bu kapsamda, iş

proseslerinde test edilmesi gereken uygun kontrollerin tanımlanması gerekiyordu. Finansal

önem taşıyan her bir aplikasyonun risk değerlendirmesini tamamlamak için genellikle

birtakım ilave bilgilere ihtiyaç duyulur.

Kapsam-içi aplikasyonları ve bunların altyapısını daha kapsamlı kavramak için

GAIT değerlendirmesini tamamlamak için ihtiyaç duyulan bilgiler üç geniş kategori altında

toplanır: Aplikasyon altyapısı, ilgili ITGC prosesleri ve risk göstergeleri.

Tablo 7: Aplikasyon altyapısı ve riskler hakkında ilave bilgiler

Kategori Tanım

Aplikasyon altyapısı Aplikasyon yığıt yapısının her seviyesindeki riskleri anlamak ve

değerlendirmek için yararlanılan tipik elemanlar aşağıda verilmiştir.

Aplikasyonları destekleyen altyapı elemanları (örneğin veri

tabanları, işletim sistemleri, ağlar ve veri merkezleri).

Otomatik kontrollerin aplikasyon koduna kıyasla, ne ölçüde

konfigürasyon ayarlarının sonucu olduğuna dair bilgi.

Kullanılan veritabanı teknolojisi. Bu teknolojinin doğasının

kavranması ve şemalar gibi veritabanı elemanlarında kilit

otomatik kontroller için önem arz eden değişikliklerin hangi

sıklıkta meydana geldiğinin anlaşılması.

İşletim sistemi (örneğin hangi aplikasyon için ne kullanılıyor

ve bunlar ne sıklıkta değiştiriliyor).

Önemli arayüzler ve bunlar üzerindeki manuel kontroller. Kilit

kontroller arasına dahil edilmemişlerse, tanımlanan kilit

kontrollerin normal operasyonunda bu manuel kontrollerin

verdiği hatalar fark edilemeyecekse ve önemli hatalara yol

açmaları muhtemelse, bu kontrolleri de kilit otomatik

kontroller listesine eklemeniz gerekebilir.

Ağ altyapısı ve onun potansiyel hata noktaları (örneğin

aplikasyon ve onun kilit otomatik kontrolleri, ağ içinde görev

geçişlerini gerektirebilir ve bu geçiş noktalarında meydana

gelebilecek bir ağ hatası veya ağ güvenlik ihlâli makul bir

olasılıkla mali tablolarda gözden kaçabilecek önemli bir hataya

yol açabilir).

Aplikasyon şirket-içinde mi geliştirilmiştir veya dışarıdan mı

satın alınmıştır?

Aplikasyonun bakımı şirket-içinde mi yapılmaktadır veya dış

kaynaklardan bakım hizmeti mi alınmaktadır?

Aplikasyonlar ve altyapı nasıl desteklenmektedir: Paylaşılmış

hizmetler yoluyla merkezi olarak mı, yoksa coğrafi olarak mı,

yoksa ayrı iş birimleri bazında münferiden mi?

Veri merkezi operasyonları şirket-içinde mi

gerçekleştirilmekte, yoksa bunun için dış kaynaklardan hizmet

mi satın alınmaktadır?

Hangi ağ ve teknik altyapı operasyonları şirket-içinde

yürütülmekte, hangileri dış kaynaklardan temin edilmektedir?

IT nasıl organize edilmiştir? Kritik işlevler birbirinden ayrılmış

mıdır?

Risk göstergeleri Belirli bazı göstergeler IT proseslerinde daha yüksek seviyede bir

riske işaret edebilir. Risk değerlendirmesinde bunlar dikkate

alınmalıdır:

Önceki periyotta § 404 uyarınca yapılan testlerde veya iç

denetimlerde hangi kilit kontroller hata verdi ve bunların sayısı

kaçtı?

Aplikasyon kaç yaşındadır ve hangi sıklıkla modifiye

edilmektedir?

Verilerde veya bilgi işlem süreçlerinde bilinen problemler var

mıdır?

Herhangi bir önemli aplikasyon işlevinde bilinen problemler

var mıdır?

Satın alınan bir aplikasyon ne kapsamda modifiye edilmiş,

uyarlanmış ve konfigüre edilmiştir?

Yüksek-öncelikli değişim taleplerinin birikimi (backlog) nasıl

yönetilmektedir?

Bilgi işlem problemleri ne sıklıkta meydana gelmektedir?

Acil değişiklikler ne sıklıkla yapılmaktadır?

Kilit pozisyonlardaki personel sirkülasyonu ne düzeydedir?

Personel ne kadar tecrübelidir ve yeterli eğitimden geçirilmiş

midir?

GAIT değerlendirmesinin esas nüvesi şimdi tamamlanmış durumdadır. GAIT metodolojisi,

finansal önem taşıyan her aplikasyon için, yığıt yapısının her katmandaki IT prosesini alır ve

IT proses risklerini ve bağlantılı kontrol hedeflerini tanımlar.

İş proseslerine kıyasla, bu düzeyde risk değerlendirmesinin güçlüğü, ITGC proseslerinin mali

tablolarla sadece dolaylı yoldan bağlantılı olmasından ileri gelir. GAIT’de, IT proses riski,

kritik IT işlevlerinin düzenli icrası konusunda yarattığı risk esas alınarak değerlendirilir.

Risk değerlendirmesini etkileyen bir diğer etmen, ITGC proseslerindeki birçok hatanın, genel

iş prosesleri kapsamındaki hatalardan ziyade, normal operasyonların bir parçası olarak tespit

edilme olasılığının daha yüksek olmasıdır. Örneğin, bir güvenlik zafiyeti varsa ve ağ

solucanların ve virüslerin saldırısına uğrarsa, bunun derhal görülmesi ve verdiği zararın

asgariye indirilmesi muhtemeldir. Dolayısıyla bir olay meydana gelme olasılığı mevcuttur.

Ancak olayın karakteri olayın derhal ve anında tespit edilmesine olanak veriyorsa, kritik

işlevselliklerin bu tip olayları derhal tespit edememesi riski çok azdır ve bundan dolayı, bu tür

olayların mali tablolarda esaslı ve önemli bir hataya neden olma riski de azdır.

Risk değerlendirilirken şu noktalar dikkate alınmalıdır:

Bir IT proses hatasının meydana gelme olasılığı ve bunun potansiyel etkileri. Bu

değerlendirme birkaç basamaktan oluşur:

IT prosesinin, kritik IT işlevselliğini sekteye uğratacak şekilde hata verme olasılığı

nedir?

Kritik işlevlerin anında tespit edilmeyen bir hata vermesi ve mali raporlarda önemli bir

hataya rol açması en azından makul düzeyde olası mıdır?

§ 404 hedefleri çerçevesinde temel odak noktasını, herhangi bir boyuttaki hatalara değil

de, aslen önemli hatalara neden olabilecek (IT işlevselliği üzerindeki etkilerinden ötürü)

olan IT proses hataları oluşturur. Meydana gelmesi sadece teorik olarak mümkün olan,

ancak pek muhtemel görünmeyen IT proses risklerini değerlendirme kapsamına almak §

404 kapsamını yersiz bir şekilde genişletmek ve verimsizleştirmek anlamına gelir.

Hatanın kasıtlı mı (usulsüzlük amacıyla veya başka bir hasardan dolayı) veya dikkatsizlik

sonucu mu (kazara) olduğu. Kasti hatalar için (örneğin kasten yetkisiz bir kod ekleme

veya verileri yetkisiz olarak değiştirme), gerçekleşmesi sadece en azından makul düzeyde

muhtemel olan risklerin § 404 kapsamında değerlendirileceğini aklınızdan çıkarmayın.

Bu doküman usulsüzlük riskinin değerlendirilmesi noktasında kılavuz olma iddiası

taşımaz, fakat usulsüzlüğü aynen iş prosesinde olduğu gibi değerlendirmenizi önerir.

Başka bir deyişle, sadece kasti bir hatanın mümkün olup olmadığını değil, fakat aynı

zamanda böyle bir hatanın gerçekleşmesini en azından makul düzeyde olası hale getiren

faktörlerin olup olmadığını da (örneğin likit kaynaklara erişim, yöneticileri fiktif işlemler

yapmaya teşvik eden unsurlar ve denetim çevresinin değerlendirilmesi sırasında

tanımlanan diğer riskler) değerlendirmelisiniz.

Bu aşamada GAIT matrisini tamamlamaya başlarsınız14. Ancak GAIT matrisini doldurma

adımlarına geçmeden önce (bakınız “Sayfa 23’te ITGC proses hataları riskinin

değerlendirilmesi), ITGC proseslerinin her yığıt katmanında nasıl değiştiğini anlamak önemli

bir noktadır:

“Aplikasyon katmanı IT genel kontrol prosesleri”. Sayfa 20’ye bakınız.

“Veritabanı katmanı IT genel kontrol prosesleri”. Sayfa 21’e bakınız.

“İşletim sistemi katmanı IT genel kontrol prosesleri”. Sayfa 21’e bakınız.

“Ağ altyapısı katmanı IT genel kontrol prosesleri”. Sayfa 22’ye bakınız.

Aplikasyon katmanı IT genel kontrol prosesleri

Aşağıda Tablo 8’de aplikasyon katmanı ITGC prosesleri ve dikkate alınabilecek riskler

açıklanmıştır.

Tablo 8: Aplikasyon katmanı IT genel kontrol prosesleri ve tipik riskler

IT genel kontrol prosesleri

Değişim

Yönetimi

Değişim yönetimi aşağıdaki hususların yerine getirilip

getirilmediğini dikkate alan bir dizi potansiyel risk alanını kapsar:

Yenilenen ve değiştirilen işlevin uygun bir şekilde tasarlanıp

onaylanması.

Değişikliğin yeterli düzeyde test edilerek, uygun işlerliğinin

güvenceye alınması.

Kullanıcının değişikliği kabul etmesi ve gerektiği gibi işlev

gördüğünü teyit etmesi.

Yetkisiz değişikliklerin önlenmesi.

Operasyonlar Operasyonlar aşağıdaki içeren potansiyel risk alanları kapsar:

Aplikasyonların hedeflenen şekilde çalışmalarını güvenceye

almaya yönelik kontroller (örneğin gereken sıklıkta

çalışmaları, güncel referans dosyalarını kullanmaları ve tüm

girdi dosyalarını işleme almaları).

Proses hatalarının zamanında çözümlenmesi ve istisnalar.

Kritik aplikasyon ve veri dosyalarının yedeklenmesi.

Bilgi işlem operasyonlarının fiziki güvenliği. (Not: Geçmişte

bilgisayar odasındaki operasyonlar konsoluna erişim büyük

risk olarak görülüyordu. Günümüzde kişilerin verileri

manipüle etme amacıyla güvenlik duvarını aşma niyetli

girişimleri daha ziyade ağ üzerinden gerçekleştiğinden dolayı,

bu artık önemli bir risk olarak görülmemektedir).

Güvenlik Güvenlik konusu, verilerin ve aplikasyon kodunun maruz kaldığı

riski kapsar. Bu IT genel kontrol prosesine, genellikle aplikasyon

güvenliği, erişim haklarının tanınması ve geri alınması ve

aplikasyon koduna erişim hakları dahil edilir.

Not: § 404 değerlendirmesinin ilk yıllarında sık karşılaşılan bir

eksiklik, programcıların kodun üretim versiyonuna erişim

imkânlarıydı (özellikle Web uygulamaları için). Teorik olarak,

programcılar yetkisiz değişiklikler yapabiliyorlardı. Ancak

sonradan yapılan analizlerde ve değerlendirmelerde bunun

meydana gelme ve (örneğin otomatik kontroller üzerindeki

etkiler değerlendirildikten sonra vs.) önemli bir hataya yol açma

riskinin düşük olduğu belirlendi. Programcıları yetkisiz değişiklik

yapmaya teşvik eden unsurlar pek yoktu (örneğin likit varlıklara

erişim gibi) ve önemli bir hatanın tespit edilmeme ihtimali

düşüktü.

GAIT metodu, potansiyel bir riskin kontrol işlevi test edilmeden

önce dikkate alınmasına imkân verir ve bu daha etkili bir

yaklaşımdır: Test et ve sonra riskin muhtemel olup olmadığını

belirle yaklaşımı yerine riski değerlendir ve sadece muhtemel ise

test et yaklaşımı.

Veritabanı katmanı IT genel kontrol prosesleri

Genel olarak, aplikasyon ve veritabanında ne kadar az risk tanımlanırsa, yığıt yapısının alt

basamaklarında riskle karşılaşma ihtimali o denli azalacaktır. Örneğin, işletim sistemi veya ağ

altyapısı katmanındaki değişim yönetimi kusurlarının bir otomatik kontrolün işlevselliğini

sekteye uğratması teorik olarak mümkün olmakla birlikte, bunun otomatik kontrol işlevini

çökertecek ve önemli bir hataya yol açacak raddede gerçekleşmesi ihtimali genellikle pek

yoktur.

Aşağıda Tablo 9’da veritabanı katmanı ITGC prosesleri açıklanmıştır.

Tablo 9: Veritabanı katmanı IT genel kontrol prosesleri ve tipik riskler

IT genel kontrol

prosesleri

Tanım

Değişim

Yönetimi

Bu katmandaki değişim yönetimi, şemalar gibi veri-dışı

elemanların değişmesi riskini hesaba katar. Veritabanı

yazılımının verileri aplikasyona sunuş şeklinde yapılan ve göz

ardı edilen hatalı değişiklikler, eksik veya hatalı hesaplamalara ve

raporlara yol açabilir.

Operasyonlar Bu katmandaki operasyon riskleri genellikle aplikasyon

katmanındaki operasyonlar için tanımlanan kontrollerin

aynılarıyla ele alınır.

Güvenlik Verilere yetkisiz erişim sorununun doğrudan üzerine gidildiği

nokta burasıdır. Geleneksel olarak verilerin güvenliği ITGC

kapsamında ele alınması gereken en kritik alanlardan biri olup,

bu noktada, güvenlik risklerini tanımlamak ve en azından makul

bir ölçüde meydana gelme olasılığı bulunan ve (kritik IT işlevleri

üzerindeki etkilerinden dolayı doğrudan veya dolaylı olarak)

gözden kaçan önemli bir hataya yol açma olasılığı taşıyan

risklere odaklanmak için kendi yargı gücünüzü ve kilit manuel

kontroller de dahil işletme prosesinin bütünü hakkındaki

bilgilerinizi kullanmaya teşvik edilirsiniz.

İşletim sistemi katmanı IT genel kontrol prosesleri

İşletim sistemi katmanındaki kusur ve hataların önemli hatalara (verilerde yapılan yetkisiz

değişiklikler yoluyla doğrudan veya kritik IT işlevlerinin uygun operasyonu üzerindeki

etkileri yoluyla dolaylı olarak) yol açmaları pek muhtemel değildir, zira bunların etkileri

gerek üretim fireleri, gerekse prosesleme hataları formunda olmak üzere genelde derhal fark

edilir. Ancak birçok organizasyon ve onların denetçileri, işletim sistemi üzerindeki

kontrolleri, sanki bunlarda meydana gelen zaaflar otomatik kontrolleri olumsuz

etkileyecekmişçesine gerçek bir risk olarak dokümante etme ve test etme yoluna gitmişlerdir.

§ 404 kapsamında uygun alanlara odaklanmayı sağlamak için bu düzeydeki riskleri kendi

yargı gücünüzü ve teknoloji ve kilit kontroller (sadece ITGC proseslerindekiler değil, fakat

aynı zamanda, yüksek seviyede denetleyici (monitör) kontrolleri içeren iş prosesi kontrolleri)

hakkındaki engin kavrayışınızı ve bilgilerinizi kullanarak değerlendirmelisiniz.

Aşağıda Tablo 10’da işletim sistemi katmanı IT genel kontrol prosesleri açıklanmıştır.

Tablo 10: İşletim sistemi katmanı IT genel kontrol prosesleri ve tipik riskler

IT genel kontrol

prosesleri

Tanım

Değişim

Yönetimi

Bu katmadaki değişim yönetimi, işletim sistemi ortamında

yapılan yamalama gibi değişikliklerin taşıdığı riskleri dikkate

alır.

Operasyonlar Bu katmandaki operasyon risklerinin üzerine genellikle

aplikasyon katmanında operasyonlar için tanımlanan kontrollerin

aynılarıyla gidilir.

Güvenlik İşletim sistemine yetkisiz erişim sorununun ele alındığı bölüm

burasıdır. Bu noktada, güvenlik risklerini tanımlamak ve en

azından makul ölçüde meydana gelme olasılığı bulunan ve (kritik

IT işlevleri üzerindeki etkileriyle dolaylı olarak veya doğrudan

verilerde yapılan yetkisiz değişikliklerin sonucu olarak) gözden

kaçan bir önemli hataya yol açma olasılığı taşıyan risklere

odaklanmak için kendi muhakemenizi ve kilit manuel kontroller

de dahil işletme prosesinin bütünü hakkındaki bilgilerinizi

kullanmaya teşvik edilirsiniz. Genellikle işletme sistemi

katmanındaki riskler çok nadiren “kök” seviyesine ve diğer

imtiyazlı erişim yollarına kadar uzanır.

Ağ altyapısı katmanı IT genel kontrol prosesleri

Genellikle, işletmeler bu katmanda daha az riskle karşı karşıyadırlar. Bu katmanda

karşılaşılan meseleler daha az doğrudan sonuç doğurur ve dolayısıyla kilit kontrollerin

işlevselliğini kaybetmesine veya mali raporlarda önemli bir hataya neden olabilecek veri

değişikliklerine yol açma ihtimali daha düşüktür. Diğer katmanlarda yapılan risk

değerlendirmesinde kazanılan bilgiler bu katmandaki risk değerlendirmesine yardımcı olur.

Bu katmanda uygun bir kapsam çıkarmak için aplikasyonun teknik altyapısının iyi

kavranması (Safha 2’de bu kavrayışa ulaşılır), iş prosesinde ve yüksek seviye izleme

proseslerinde başvurulan kontrollerin güçlü yanlarının değerlendirilebilmesi gerekir. ITGC

proseslerinde kilit kontrollere odaklanabilmek için GAIT’de risklerin mümkün mertebe

spesifik bir şekilde tanımlanması önerilir. Örneğin, üst düzey karmaşık bir aplikasyonda ağ

üzerinden kredi kartı ödemelerinin alındığını ve onaylandığını varsayalım. Bu durumda

yapılması gereken testleri sınırlandırmak için ağdaki potansiyel hata noktalarını tanımlamanız

gerekir.

ITGC proses hatası riskini değerlendirmek için

1. Finansal önem taşıyan her aplikasyon için, IT altyapısının her katmanındaki spesifik

ITGC proses risklerini ve ilgili kontrol hedeflerini tanımlayınız. Kısacası, GAIT

matrisindeki her hücrenin üzerinden geçiniz ve aşağıda Tablo 11’de listelenen uygun

soruları yanıtlayınız. Buradaki her soru önemli hata riskine odaklanır. Yukarıda

tartışıldığı gibi, ITGC proses riskleri mali raporlarda doğrudan önemli bir hataya yol

açmaz. Bunlar, kilit otomatik kontrollerin ve diğer kritik IT işlevlerinin (örneğin kilit

raporlar) gerektiği gibi istikrarlı çalışmayacak şekilde hata vermesine yol açabilir ve bu

da mali raporlardaki önemli bir hatayı önleme veya tespit etme noktasında zafiyete neden

olabilir.

2. Sonuçları GAIT matrisine (Sayfa 29’daki örnek GAIT matrisine bakınız) veya GAIT

şablonuna (Sayfa 33’deki GAIT şablonuna bakınız) kaydediniz. Tam bir değerlendirme

için gerekirse COBIT gibi destekleyici ve tamamlayıcı araçlar kullanınız.

Tablo 11: GAIT matrisindeki her hücre için sorulacak sorular


Aplikasyon Değişim yönetimindeki bir hatanın kritik

işlevlerin birini veya

birden fazlasını etkisiz

kılması ve tespit

edilemeyen önemli bir

hataya yol açması en

azından makul düzeyde

olası mıdır?

Olası ise, riskleri ve

bağlantılı kontrol

hedeflerini

tanımlayınız.

Olası değilse, değişim

yönetiminde bu

aplikasyonun koduna ilişkin kontroller

kapsam dışında

bırakılır. Kanaatimizce

bu pek olası değildir.

Operasyonlardaki bir

hatanın kritik işlevlerin

birini veya birden

fazlasını etkisiz kılması

ve tespit edilemeyen

önemli bir hataya yol

açması en azından makul

düzeyde olası mıdır?



hedeflerini

tanımlayınız.

Olası değilse,

operasyonlarda bu

aplikasyona ilişkin

kontroller kapsam

dışındadır.

Güvenlikteki bir


birini veya birden




açması en azından

makul düzeyde olası

mıdır?

Başka bir ifadeyle, bir

güvenlik hatasının

herhangi bir

aplikasyondaki

(örneğin taramalı

tablolar) verilerin

yetkisiz bir şekilde

değiştirilmesine yol

açması ve neticede mali

tablolarda tespit


hataya neden olması en

azından makul ölçüde

olası mıdır?



hedeflerini

tanımlayınız.

Olası değilse,

güvenlik alanında bu

aplikasyona ilişkin

kontroller kapsam

dışındadır.

Veritabanı Değişim yönetimindeki bir hatanın kritik



kılması ve tespit




olası mıdır?





birini veya birden








Güvenlikteki bir


birini veya birden






mıdır?

Başka bir ifadeyle, bir

güvenlik hatasının

hedeflerini

tanımlayınız.


yönetiminde bu

aplikasyonun

veritabanına ilişkin

kontroller kapsam

dışındadır.

hedeflerini

tanımlayınız.

Olası değilse,

operasyonlarda bu

aplikasyonun


kontroller kapsam

dışındadır.

verilerin veya diğer

unsurların (örneğin

şemalar) yetkisiz bir

şekilde değiştirilmesine

yol açması ve neticede

mali tablolarda tespit


hataya neden olması en

azından makul ölçüde

olası mıdır?



hedeflerini

tanımlayınız.

Olası değilse,


aplikasyonun


kontroller kapsam

dışındadır.

İşletim

sistemi Değişim yönetimindeki bir hatanın kritik



kılması ve tespit




olası mıdır?



hedeflerini

tanımlayınız.


yönetiminde bu

aplikasyonun işletim

sistemine ilişkin

kontroller kapsam

dışındadır.



birini veya birden








hedeflerini

tanımlayınız.

Olası değilse,

operasyonlarda bu


sistemine ilişkin

kontroller kapsam

dışındadır.

Güvenlikteki bir


birini veya birden






mıdır?



hedeflerini

tanımlayınız.

Olası değilse,



sistemine ilişkin

kontroller kapsam

dışındadır.

Ağ altyapısı Değişim yönetimindeki bir hatanın kritik



kılması ve tespit





birini veya birden





Güvenlikteki bir


birini veya birden






olası mıdır?



hedeflerini

tanımlayınız.


yönetiminde bu

aplikasyonun ağ

altyapısına ilişkin

kontroller kapsam

dışındadır.




hedeflerini

tanımlayınız.

Olası değilse,

operasyonlarda bu

aplikasyonun ağ


kontroller kapsam

dışındadır.


mıdır?



hedeflerini

tanımlayınız.

Olası değilse,


aplikasyonun ağ


kontroller kapsam

dışındadır.

Safha 4 Kontrol hedeflerinin karşılanması için test edilecek kilit ITGC’leri

tanımlayınız

Tüm riskler ve bağlantılı IT kontrol hedefleri tanımlandıktan sonra, bu hedefleri karşılamak

için ITGC kapsamında başvurulacak spesifik kilit kontroller belirlenebilir. Bu noktada COBIT

gibi çerçeveler önemli ölçüde yardımcı olabilir. GAIT metodolojisi §404 prosesinde hemen

sonra gelen bu adımı kapsamaz. Bu konuda tek tavsiyemiz, her ITGC kilit kontrolünün GAIT

yoluyla tanımlanan IT kontrol hedefleriyle ve dolayısıyla risk altındaki kritik IT işlevinin

nizami operasyonuyla spesifik olarak ilişkilendirilmesidir.

Bu bölümde aşağıdaki konular hakkında bilgi verilmiştir:

“ITGC’nin yaygınlığını değerlendirme”. Aşağıya bakınız.

“Test için kilit kontrollerin seçilmesi”. Sayfa 26’ya bakınız.

ITGC’nin yaygınlığının değerlendirilmesi

ITGC’nin genel olarak geniş bir alanı etkilediği düşünülür, çünkü ITGC proseslerindeki

kontroller birden çok otomatik kontrolü etkilemeye meyillidir ve birçoğu birden çok

aplikasyonu etkiler. Bu aşamaya kadar metodoloji,

çoğu organizasyon için, risk değerlendirmesinin birden çok aplikasyon için yapıldığı

durumda eşdeğer riskleri tanımlar.

Finansal önem arz eden birden çok aplikasyonda kritik IT işlevlerinin maruz kaldığı

risklerin tek bir ITGC prosesindeki hatadan etkilenebileceği durumlarda toplam riski

tanımlamaz. Başka bir deyişle, kritik işlevlerdeki potansiyel hatalar bir araya geldiğinde,

gerçekleşmesi makul ölçüde muhtemel olan önemli bir hata riskine yol açmaları

mümkündür. Tek bir ITGC proses kontrolündeki küçük bir hata kritik IT işlevlerini veya

finansal önem taşıyan başka uygulamalardaki birden çok veritabanını etkileyebilir. Tek

başına bunların hiçbiri yüksek bir risk altında olmasa da, ITGC proses hatasının

kümülatif etkisi toplamda yüksek bir riske mal olabilir.

GAIT, önceki safhaların sonuçlarını kullanarak ayrı bir değerlendirme sürecini yürütmenizde

size kılavuzluk yapar. Bu ayrı değerlendirmede, tek bir ITGC prosesinin veya riskin birden

çok aplikasyonu etkileyip etkilemediği ve hepsi bir araya geldiğinde önemli bir hataya yol

açabilme ihtimali en azından makul ölçüde mevcut olan birden çok kilit kontrol hatasına

neden olmasının en azından makul ölçüde mümkün olup olmadığı test edilir. Bu gibi

durumlarda, ITGC proseslerindeki kilit kontrollerin tanımlanmasını gerektiren aplikasyonların

tabi oldukları riskler toplanır.

ITGC’nin yaygınlığını değerlendirmek için

Aşağıda Tablo 12’de listelenen soruların üzerinde düşününüz.

Tablo 12: Yaygınlık değerlendirmesi

Her soru için…. Şunları değerlendirin…

Aplikasyonlarla ilgili olarak; değişim

yönetimi, operasyonlar veya güvenlik

alanında birden çok aplikasyonu ve

onların kritik IT işlevlerini en azından

makul ölçüde etkileme ihtimali olan

riskler var mı?

Veritabanlarıyla ilgili olarak; değişim





riskler var mı?

İşletim sistemleriyle ilgili olarak; değişim





riskler var mı?

Ağ altyapısıyla ilgili olarak; değişim





riskler var mı?

IT ortamının bütünüyle ilgili olarak;

yığıt yapısının farklı katmanlarında birden

çok aplikasyonu etkileme potansiyeli

taşıyan riskler mevcut mu? Örneğin, aynı

güvenlik açığının söz konusu olduğu bir

durumda, bunun, hem aplikasyon kodunda

hem de verilerde gözden kaçan önemli bir

hatanın meydana gelmesini uzak bir

ihtimal olmaktan çıkaracak şekilde bir

yetkisiz veriye yol açması en azından

makul ölçüde mümkün müdür?

Cevap “hayır” ise, söz konusu IT prosesi,

aplikasyona ilişkin yığıt yapısının bu

katmanı için kapsam dahilinde değildir.

Cevap “evet” ise, riskleri tanımlayınız. Bu

riskleri ortadan kaldırmaya yönelik IT

kontrol hedeflerinin tanımlanması genel

kabul görmüş bir IT denetim

uygulamasıdır (Sayfa 9’da “Prensip 4”e

bakınız). Yapılan değerlendirmenin ve

ilgili IT kontrol hedeflerinin gerekçelerini

dokümante ediniz.

Test için kilit kontrollerin seçilmesi

GAIT, ITGC proseslerindeki kilit kontrollerin §404 kapsamına dahil edilmesini gerektiren

risklerin ve bağlantılı ITGC kontrol hedeflerinin tanımlanmasına yönelik bir metodoloji

sağlar. Ancak aşağıdaki hususlar ele alınmadan kilit ITGC’lerin tam olarak değerlendirildiği

söylenemez:

Test için kilit kontrolleri seçmek için

Aşağıda Tablo 13’te listelenen sorunları ele alınız:

Tablo 13: Kilit ITGC’lerin tanımlanması

Konu Açıklama

Manuel kontrollere

başvurma

Başvurulacak koruyucu ve teşhis edici kontrollerin uygun bileşimini

belirlemek için var olan tüm kontrolleri kapsamlı bir şekilde gözden

geçirin.

Birçok organizasyon, önemli bir hatayı sunulan mali raporlara

girmeden önce büyük olasılıkla teşhis eden kuvvetli izleme

prosedürlerine ve başka kontrol prosedürlerine sahiptir. Hangi

kontrollerin kilit olarak nitelendirileceğine ve hangilerine

başvurulacağına karar verirken, kilit kontroller kapsamına tedbir olarak

daha fazla sayıda ayrıntılı kontrolün eklenip eklenmeyeceğini ya da

daha yüksek seviyeli kontrollere mi başvurulacağını belirleyin.

Önemli bir hataya yol açabilecek bir otomatik kontrol prosedürü

kusurunu tespit etmek için periyodik validasyon kontrolleri (örneğin

stokların veya diğer varlıkların fiziksel envanterleri) yeterli olabilir.

Karşılaştırma

(Benchmarking)

Kıyaslama kilit otomatik kontrollerin ve diğer kritik IT işlevlerinin

(örneğin kilit raporlar) testlerini sınırlandırır ve şu noktalara uygulanır:

Genellikle aplikasyon katmanında yapılan değişim yönetimi

kontrollerinin güçlü olduğu durumlarda. Kıyaslama, her bir kilit

otomatik kontrolün her sene test edilmesi yerine, bu kontroller ile

otomatik kontrollerde önceki dönemlerde yapılan testlerin bir

kombinasyonuna dayanarak çalışma imkânı verir.

Tüm otomatik kontrollerin başarıyla test edilmesi durumunda,

aplikasyonun önceki yıla göre değişiklik göstermediği hallerde.

Örneğin SAP programındaki denetim geçmişi gözden geçirilir ve

herhangi bir değişikliğin yapılmadığı doğrulanırsa, otomatik

kontrolü test etmeye gerek yoktur ve aplikasyon katmanında ITGC

değişim yönetimi için herhangi bir risk söz konusu değildir.

Otomatik

kontrollerde

kapsamlı testler

Yıl boyunca etkili olan ITGC’ler otomatik kontrollerde yapılacak olan

testleri tek bir örnekle sınırlandırabilmekle birlikte, bir aplikasyonda

sadece birkaç tane otomatik kontrol varsa, ITGC’ye bel bağlamamak

daha verimli bir yol olabilir.

Az sayıda otomatik kontrolün var olduğu durumda, bunların etkin bir

şekilde işlediklerinden emin olmak için ITGC kontrollerine bel

bağlamak yerine, bunların örneğin her yıl çeyreğinin sonunda olmak

üzere daha sık kontrol edilmeleri mümkündür. Bu yaklaşımı seçtiğiniz

takdirde, kontrol operasyonu frekansını temel alan örneklem

metodolojilerini kullanarak kilit otomatik kontrolleri test ediniz.

Örneğin bir kilit rapor aylık olarak kullanılıyorsa, raporun tamlığını ve

doğruluğunu test etmek için kullanılacak örneklem büyüklüğü bu

frekans bilgisini temel almalıdır.

Bu yaklaşımda karar kılmadan önce, aplikasyonun maruz kaldığı tüm

riskleri anlamak için GAIT’i kullanmak suretiyle mutlaka tam bir

değerlendirme yapın. Örneğin kapsamlı testler, veritabanında, işletim

sisteminde veya ağ altyapısında varolan riskleri kapsamıyor olabilir.

Safha 5 Makul ve mantıklı kişi değerlendirmesi yapın

Sıkı bir ITGC proses riski değerlendirmesi, önceki değerlendirmelere nazaran, daha az sayıda

ITGC’yi gerektiren daha az sayıda riskin tanımlanmasıyla sonuçlanabilir. Bunun muhtemel

nedeni, kapsama dahil edilmeyen diğer risklerin, kritik işlevlerde muhtemelen önemli bir

hatayla sonuçlanabilecek bir tespit edilmemiş hataya yol açmalarının makul ölçüde mümkün

olmadığının değerlendirilmesidir. Bu durum IT’nin hiçbir kontrole tabi olmadığı anlamına

gelmeyip, sadece bu kontrollerin § 404 testleri için risk-bazlı bir perspektiften bakıldığında

kapsam dahiline alınmayabileceklerini gösterir.

Riskleri değerlendirmek için:

1. Risklerin ve kilit kontrollerin, mali tabloların tabi olduğu riskin bağımsız ve basiretli bir

görevlinin gözüyle makul bir şekilde idrak edilmesine imkân verdiğini doğrulayın.

2. § 404 kapsamında organizasyonun risk toleransı göz önünde bulundurulduğunda, risk

seçiminin makul ve mantıklı yapıldığından emin olun. Başka bir deyişle, benimsenen

yaklaşım, muhafazakâr bir yaklaşım mıdır, yoksa agresif bir yaklaşım mıdır?

Ekler

Bu bölümde aşağıdakileri kapsayan destekleyici bilgiler verilmektedir:

“Örnek GAIT matrisi”. Aşağıya bakınız.

“GAIT şablonu”. Sayfa 33’e bakınız.

“Aşağıdan-yukarıya risk değerlendirmelerinin kullanılması”. Sayfa 36’e bakınız.

“Terimce”. Sayfa 38’e bakınız.

Örnek GAIT matrisi

Aşağıda Tablo 14’te kısmen tamamlanmış bir GAIT matrisi açıklayıcı notlarla birlikte

verilmiştir.

Tablo 14: Kısmen tamamlanmış GAIT matrisi


Aplikasyon Evet

Aplikasyon, aplikasyon

kodu seviyesinde değişim

yönetimi hatalarının

meydana gelmesi halinde

istikrarlı bir

işlevselliğinin olumsuz

etkilenmesi en azından

makul bir ölçüde

muhtemel olan birçok

kilit otomatik kontrol ve

diğer kritik işlevler (kilit

raporlar, hesaplamalar ve

defter-i kebirin

güncellenmesi gibi)

içermektedir. Ele

alınması kontrol hedefleri

şunları içerir:

Tüm program

değişiklikleri

uygulamaya

alınmadan önce hem

UT hem de kullanıcı

yönetimi bölümlerince

onaylanır.

Program değişiklikleri

uygun bir şekilde test

edilir ve uygulamaya

alınmadan önce test

sonuçları onaylanır.

Evet

Aplikasyon bu prosesteki

kontrollere bağımlı olan

bir dizi toplu arayüz işi

içerir. Kontrol hedefleri

şunları içerir:

Toplu işler izlenerek,

normal olarak

tamamlanmaları temin

edilir; proseste

karşılaşılan tüm

olaylar rapor edilir ve

uygun düzeltici

adımlar atılır.

Toplu işler bir

otomatize programa

dahil edilerek,

gerektiği şekilde

yerine getirilmeleri

güvenceye alınır.

Evet

Aplikasyon işlemlerin

belirli kişilerle ve

işlevlerle

sınırlandırılmasıyla

ilgili otomatik

kontroller içerdiğinden

dolayı, kullanıcı erişim

kontrolleri uygulanır.

İlgili kontrol hedefleri

şunları içerir:

Erişim, her

kullanıcının

sorumluluklarına

paralel belirli iş

rolleri temelinde

kısıtlanır.

Erişim yetkisi

verilen çalışanlar ve

üstleniciler, iş

akitleri biter bitmez

derhal yetkilendirme

listesinden

çıkarılırlar.

Sadece yetkili

kişilerin imtiyazlı

erişim hakkına sahip

olduklarından emin

olmak için periyodik

değerlendirmeler

yapılır.

Veritabanı Değerlendirme

tamamlanmadı

İşletim

sistemi

Hayır

İşletim sistemine yapılan

acil yamalar gibi

değişikliklerin, kritik IT

işlevlerini çökmelerine

neden olacak raddede

etkilemesi pek olası

görülmez. Özellikle,

yerinde olmayan

değişiklikler veya

yeterince test edilmeden

yapılan değişiklikler

aplikasyonun bütününü

çökerteceğinden dolayı

hemen fark edilirler.

Ağ altyapısı Değerlendirme

tamamlanmadı.

GAIT şablonu

GAIT şablonu, GAIT değerlendirmesinin sonuçlarını dokümante etmek için GAIT matrisine

(Sayfa 29’a bakınız) alternatif olarak kullanılabilecek bir araçtır.

Tablo 15: GAIT şablonu

Aplikasyon:

(Aplikasyonun adı)

İşletme prosesleri:

Değerlendirmeyi yapan kişi ve değerlendirme tarihi:

Kontrol eden ve onaylayan:

Aplikasyon değerlendirmesi:

(Genel olarak, aplikasyonun kısa bir tanımını yapın ve bu kapsamda aplikasyonun dışarıdan

satın alınan bir ürün mü yoksa şirket-içinde geliştirilen bir ürün mü olduğunu, yaşını,

modifikasyon sıklığını, kritik arayüzlerini, işletim sistemini ve veritabanı teknolojisini,

nerede barındırıldığını ve değerlendirme için önem taşıyan diğer bilgileri belirtin.)

Kritik IT işlevleri:

(Her kritik IT işlevine ilişkin tam metni ekleyin.)

Kilit otomatik kontroller:

Aplikasyonun işlevselliğine bağımlı kilit manüel kontroller:

(Bunlar aplikasyonun işlevselliğine bağımlı olan manüel kontroller olup, aplikasyonun

işlevinde meydana gelen bir arıza manüel kontrolün normal işleyişi içinde tespit edilemez ve

önemli bir hataya yol açabilir (örneğin kilit raporlarda). Risk altındaki işlevi açık bir şekilde

vurgulayınız.)

Diğer kritik IT işlevleri:

(Otomatik kontrol olarak değerlendirilmeye alınmayan, fakat olası bir hatanın tespit

edilmeden gözden kaçabileceği ve önemli bir hataya yol açabileceği IT işlevlerini

açıklayınız.)

Önemli manüel kilit kontroller:

(Seçime bağlı bu bölümde, değerlendirme açısından önem arz eden manüel kilit kontrollerin

tümünü listeleyiniz. Otomatik kontrollerin ITGC’deki kusur ve arızalardan kaynaklı maruz

kaldığı riskin değerlendirilmesi için bu kontrollerin dikkate alınması yararlı olacaktır. Örneğin

bu kontroller, güvenlik kusurlarından kaynaklanan riskin değerlendirilmesine yardımcı olabilir.)

Önemli manüel kilit kontroller:

Değişim yönetimindeki bir hatanın kritik IT işlevlerinin muntazam işleyişini, bunlardan birini

veya birden çoğunu etkisiz kılacak ölçüde ve (dolaylı olarak) tespit edilemeyen önemli bir

hataya yol açacak şekilde etkilemesi en azından makul ölçüde olası mıdır?

Olası ise, aplikasyon kodu için değişim yönetimi risklerini ve ilgili kontrol hedeflerini

tanımlayın.

Olası değilse, değişim yönetiminde bu aplikasyonun koduyla ilgili kontroller kapsam

dahilinde değildir.

Operasyonlardaki bir hatanın kritik IT işlevlerinin muntazam işleyişini, bunlardan birini veya

birden çoğunu etkisiz kılacak ölçüde ve (dolaylı olarak) tespit edilemeyen önemli bir hataya yol

açacak şekilde etkilemesi en azından makul ölçüde olası mıdır?

Olası ise, aplikasyon kodu için operasyon risklerini ve ilgili kontrol hedeflerini tanımlayın.

Olası değilse, operasyonlarda bu aplikasyonun koduyla ilgili kontroller kapsam dahilinde

değildir.

Bir güvenlik hatasının kritik IT işlevlerinin muntazam işleyişini, bunlardan birini veya birden

çoğunu etkisiz kılacak ölçüde ve (dolaylı olarak) tespit edilemeyen önemli bir hataya yol açacak

şekilde etkilemesi en azından makul ölçüde olası mıdır? Başka bir deyişle, güvenlik

prosesindeki bir hatanın herhangi bir aplikasyondaki (örneğin taramalı tablolar) verilerin

yetkisiz bir şekilde değiştirilmesine yol açması ve neticede mali tablolarda tespit edilemeyen

önemli bir hataya neden olması en azından makul ölçüde olası mıdır?

Olası ise, aplikasyon kodu için var olan güvenlik risklerini ve kontrol hedeflerini

tanımlayın.

Olası değilse, bu aplikasyonun koduyla ilgili güvenlik kontrolleri kapsam dahilinde

değildir.

Yığıt yapısının veritabanı katmanında değerlendirme:




Olası ise, veritabanı elemanları için değişim yönetimi risklerini ve ilgili kontrol hedeflerini

tanımlayın.

Olası değilse, değişim yönetiminde bu aplikasyonun veritabanıyla ilgili kontroller kapsam


Operasyonlardaki hatanın kritik IT işlevlerinin muntazam işleyişini, bunlardan birini veya



Olası ise, veritabanı elemanları için operasyon risklerini ve ilgili kontrol hedeflerini

tanımlayın.

Olası değilse, operasyonlarda bu aplikasyonun veritabanıyla ilgili kontroller kapsam




şekilde etkilemesi en azından makul ölçüde olası mıdır? Başka bir deyişle, güvenlik

prosesindeki bir hatanın verilerde veya diğer elemanlarda (şemalar gibi) yetkisiz değişikliklere

yol açması ve neticede mali tablolarda tespit edilemeyen önemli bir hataya neden olması en

azından makul ölçüde olası mıdır?

Olası ise, veritabanı elemanları için önemli bir hataya yol açabilecek güvenlik risklerini ve

kontrol hedeflerini tanımlayın.

Olası değilse, bu aplikasyonun veritabanıyla ilgili güvenlik kontrolleri kapsam dahilinde

değildir.

Yığıt yapısının işletim sistemi katmanında değerlendirme:




Olası ise, işletim sistemi için değişim yönetimi risklerini ve ilgili kontrol hedeflerini

tanımlayın.

Olası değilse, değişim yönetiminde bu aplikasyonun işletim sistemiyle ilgili kontroller

kapsam dahilinde değildir.




Olası ise, işletim sistemi için operasyon risklerini ve ilgili kontrol hedeflerini tanımlayın.

Olası değilse, operasyonlarda bu aplikasyonun işletim sistemiyle ilgili kontroller kapsam




şekilde etkilemesi en azından makul ölçüde olası mıdır?

Olası ise, işletim sistemi için güvenlik risklerini ve kontrol hedeflerini tanımlayın.

Olası değilse, bu aplikasyonun işletim sistemiyle ilgili güvenlik kontrolleri kapsam


Yığıt yapısının ağ altyapısı katmanında değerlendirme:




Olası ise, ağ altyapısı için değişim yönetimi risklerini ve ilgili kontrol hedeflerini

tanımlayın.

Olası değilse, değişim yönetiminde bu aplikasyonun ağ altyapısıyla ilgili kontroller kapsam





Olası ise, ağ altyapısı için operasyon risklerini ve ilgili kontrol hedeflerini tanımlayın.

Olası değilse, operasyonlarda bu aplikasyonun ağ altyapısıyla ilgili kontroller kapsam




şekilde etkilemesi en azından makul ölçüde olası mıdır?

Olası ise, ağ altyapısı için güvenlik risklerini ve kontrol hedeflerini tanımlayın.

Olası değilse, bu aplikasyonun ağ altyapısıyla ilgili güvenlik kontrolleri kapsam dahilinde

değildir.

Diğer yaygın ITGC risklerinin hesaba katılması

ITGC’de kilit kontrollerin tanımlanması

(Tanımlanan ITGC proses risklerini ve bağlantılı kontrol hedeflerini özetleyiniz ve her biri için

ITGC’deki hangi kilit kontrolün §404 kapsamına dahil edilmesi gerektiğini belirleyiniz.

Aşağıdan-yukarıya risk değerlendirmelerinin kullanılması

GAIT, yukarıdan-aşağı ve risk-bazlı bir yaklaşım kullanır. Ancak aşağıdan-yukarıya bir

yaklaşım kullanıldığında ITGC proses riski ortaya çıkabilir. Örneğin bir mali denetçi, müşavir

ve IT müdürü, belirli bir riskin önemli olduğunu gösteren bir makaleye veya kontrol listesine

referans yapabilir ve bunun neden ITGC listesine dahil edilmediğini sorgulayabilir. Bu

şekilde gündeme getirilen (yukarıdan-aşağı yerine aşağıdan-yukarıya) bir sorun GAIT

yöntemine başvurularak değerlendirildiğinde, muhtemel bir önemli hata riski içermesi

mümkün değildir.

Aşağıdan-yukarıya risk değerlendirmesinin kullanılması

1. Sorunun potansiyel olarak etkilediği aplikasyonları belirleyiniz. Örneğin sorun yönelticinin

(router) tasarımıysa, bu durumda potansiyel olarak etkilenen aplikasyonları tanımlayın.

Sorun veritabanı yöneticisinin verilere erişimi ise, bu veritabanını kullanan aplikasyonları

tespit edin.

2. Bu şekilde belirlenen her aplikasyon için, hakkındaki risk değerlendirmesini gözden

geçirin:

Bu aplikasyonda kritik IT işlevi var mıdır?

Sorun, verilerin yetkisiz bir şekilde değiştirilmesine yol açan ve neticede (dolaylı

olarak) tespit edilemeyen önemli bir hatayla sonuçlanma riski taşıyan bir sorun mudur?

Veyahut manüel ve otomatik kontroller kombinasyonu, sorundan kaynaklanan riski,

önemli bir hatanın en azından makul ölçüde muhtemel olduğu bir seviyenin altına

düşürmekte midir?

Risk değerlendirmesi yığıt yapısında potansiyel olarak etkilenen katmanı ve bununla

ilgili ITGC prosesini uygun bir şekilde değerlendirmekte midir? Bu söz konusu değilse,

değerlendirmeyi gereken şekilde güncelleyiniz.

3. İlave riskler:

tanımlanmamışsa, sorunun kümülatif bazlı bir risk olarak dikkate alınıp

alınamayabileceğini düşünün. Gözden geçirmede, tek başlarına potansiyel risk

taşımayan, fakat üst üste geldiklerinde en azından makul ölçüde muhtemel bir önemli

hatayla sonuçlanabilecek olan potansiyel riskler tanımlanmış mıdır?

tanımlanmışsa, §404 kapsamına ilave ITGC kilit kontrollerinin ilave edilip edilmemesi

gerektiğini belirleyin.

Tanımlar

Aşağıda Tablo 16’da bu dokümanda kullanılan terimlerin tanımları verilmiştir.

Tablo 16: Terimce

Terim Tanım

Aplikasyon

kontrolü

“Aplikasyon seviyesindeki riskleri ele almaya yönelik aplikasyon

kontrolleri sisteme bütünleşik bilgisayarlı kontroller, manuel icra edilen

kontroller veya bunların bir kombinasyonu formunda olabilir. Örnek

olarak dokümanların bilgisayarlı eşleştirilmesi (satınalma emri, fatura

ve mal alındı raporu), bilgisayarda hazırlanan bir çekin kontrolü ve

imzalanması ve üst kademe yöneticilerin istisnai raporları kontrol

etmeleri.” ISACA, Aplikasyon Sistemi İncelemesi, doküman G14.

Değişim yönetimi

ve ilk geliştirme

Aplikasyonları, işletim sistemlerini ve veritabanı elemanlarını

geliştirme, uygulama ve sürdürme prosesi.

COBIT Bilişim ve bağlantılı teknolojiler için kontrol hedefleri (COBIT), IT

yönetiminde kullanılan bir çerçeve olup, Bilişim Sistemleri Denetim ve

Kontrol Topluluğu (ISACA) ve IT Yönetişim Enstitüsü (ITGI)

tarafından 1992 yılında oluşturulmuş ve 2006’da güncellenmiştir.

Kontrol İşletme hedeflerine ulaşılacağına ve istenmeyen hadiselerin

önleneceğine veya tespit edilip düzeltileceğine dair makul bir güvence

vermek üzere tasarlanmış politikalar, prosedürler, uygulamalar ve

organizasyonel yapılar. (COBIT)

COSO Treadway Komisyonunu Destekleyen Kuruluşlar Komitesi (COSO),

1985’de kurulan bir ABD özel-sektör inisiyatifidir. Temel amacı,

finansal raporlama uygulamalarında usulsüzlüğe yol açan etmenleri

belirlemek ve bunların meydana gelme sıklığını azaltmak için

tavsiyelerde bulunmaktır. COSO; iç denetimler, standartlar ve

şirketlerin ve organizasyonların kontrol sistemlerini değerlendirmede

baz alacağı kriterler için müşterek bir tanım geliştirmiştir.

Kritik IT işlevleri Safha 2, Sayfa 16’da açıklandığı üzere, kritik IT işlevleri şunları içerir:

Kilit otomatik kontroller

Kilit manüel kontrollerin muntazam işleyişi için başvurulan IT

işlevleri

Kilit raporlar

Hesaplamalar veya defter-i kebire kaydetme gibi, olası bir hatanın

tespit edilemeyebileceği ve mali raporlarda önemli bir hataya yol

açabileceği diğer kritik işlevler. Bunun için kimileri “programlı

muhasebe prosedürleri” terimini kullanır.

Kurumsal düzeyde

kontrol

COSO’nun kontrol tanımı hem kurumsal düzeyde hem de ayrıntılı

proses düzeyinde var olan kontrolleri kapsar. Kurumsal düzeydeki

riskler, organizasyonun bütününü ve ayrıntılı proses seviyesinde birden

çok kontrolün etkinliğini etkileyebileceğinden dolayı daha yaygın

karaktere sahip olabilirler.

“Kurumsal seviyede” terimi, önerilen AS/2 revizyonunda kullanılan ve

daha doğru bir karşılık olan “şirket seviyesinde” terimiyle eşanlamlıdır.

ERP İşletme kaynak planlama (ERP) sistemleri, şirketin operasyonları veya

üretim konularıyla ilgili birçok işletme uygulamasını birbirine entegre

eden ve otomatikleştiren yönetim bilişim sistemleridir.

Finansal açıdan

önemli

Finansal açıdan önemli:

Aplikasyonlar, kilit otomatik aplikasyon kontrolleri, kilit

raporlar ve diğer kilit otomatik prosesleri içeren finansal

raporlama sürecinin bütünlüğünü güvenceye almak için

kullanılan işlevleri içerir. Bu işlevler istikrarlı ve doğru bir

şekilde çalışmazlarsa, en azından, önlenemeyen ya da gözden

kaçırılan önemli bir yanlış beyanın yapılması ihtimali ortaya

çıkacaktır. Bir işlevin bu tanım kapsamına alınabilmesi için,

önemli yanlış beyanların tespit edilmesi veya önlenmesi için

mutlak gerekli bir işlev olması şarttır (örneğin bir kilit

kontrolün parçası).

Veriler; normal aplikasyon kontrollerinde gözden kaçan

(örneğin bir ITGC hatası neticesinde) yetkisiz bir değişikliğe

maruz kaldıkları takdirde, önlenemeyen veya tespit edilemeyen

bir önemli yanlış beyanda bulunulmasını en azından makul

ölçüde olanaklı hale getiren verilerdir. Böyle bir durum, söz

konusu verilerin finansal veriler olması halinde veya bir

otomatik prosedürün istikrarlı operasyonu için gerek duyulan

veriler olması halinde söz konusu olabilir.

ICFR Finansal raporlama üzerinde iç denetim

IIA İç Denetim Enstitüsü, küresel merkezi Altamonte Springs, Florida,

ABD adresinde olan, 130.000’in üzerinde üyeye sahip bir uluslararası

meslek örgütüdür. IIA örgütü, iç denetim mesleğiyle ilgili

sertifikasyon, eğitim, araştırma ve teknolojik rehberlik alanlarında

dünya çapında öncü kuruluş olarak kabul edilmektedir.

IT genel kontrol

prosesleri

IT kapsamında yürütülen ağ taramaları yapma, yönelticilerin (router)

bakımı ve aplikasyon değişikliklerinin test edilmesi gibi faaliyetler, IT

genel kontrol proseslerine dahildir. ITGC kontrol prosesleri için mutlak

olarak bu tanımların kullanılması GAIT metodolojisinin kullanımı

açısından gerek şart değildir. Her GAIT kullanıcısı, GAIT

metodolojisinin özünü bozmamak kaydıyla bunların yerine kendi

tanımlarını kullanabilir (Prensip 3’e de bakınız).

ITGC ITGC genel kontrolleri, genellikle IT organizasyonunda bulunan genel

IT kontrol prosesleri üzerindeki kontrol prosedürleridir.

“Genel manada ifade etmek gerekirse, ITCG, muhasebe hareketlerinin

işlenmesi için gereken işlevselliği sağlayan ve otomatik kontrol araçları

temin eden aplikasyonların geliştirilmesine ve akabinde bunların

işlerliğinin sürdürülmesine olanak verir. Bu kontroller, ayrıca,

aplikasyonların muntazam işlerliğini ve gerek verilerin, gerekse

programların yetkisiz değişikliklere karşı korunmasını sağlar.” (§404

Kılavuzu)

Dokuz bağımsız denetim firmasının temsilcileri, Aralık 2004 tarih ve

“Kontrol Beklentileri ve Zafiyetleri için Değerlendirilme Çerçevesi”

başlıklı çalışmalarında, ITGC ile ilgili bazı bölümleri içeren bir

doküman hazırlamışlardır. Bu dokümanda ITGC ile aplikasyon

kontrolleri (veya otomatik kilit kontroller) arasındaki ilişki şu şekilde

tarif edilmiştir: “ITGC’ler aplikasyon kontrollerinin süreğen etkin

işleyişini etkileyebilir. Örneğin, etkili bir güvenlik yönetimi işlevi,

erişimi kısıtlayan aplikasyon kontrollerinin sürekli etkin işlerliğini

destekler. Başka bir örnek vermek gerekirse; etkin program değişikliği

kontrolleri, üç-yollu eşleme gibi programlı aplikasyon kontrollerinin

sürekli etkin işlerliğini destekler. ITGC’ler ayrıca aplikasyon

düzeyinde kontrol işlevi de görebilir. Örneğin, ITGC’ler erişimi

kısıtlamaya yönelik kontrol amacını doğrudan yerine getirebilir ve

böylelikle yetkisiz işlem ve hareketlerin başlatılmasını en baştan

önleyebilir.”

Kilit Kontrol Hata vermesi halinde, mali tablolardaki önemli bir hatanın

önlenememesi veya zamanında tespit edilememesi en azından makul

ölçüde muhtemel olan bir kontrol, kilit kontrol olarak tanımlanır. Başka

bir deyişle, önemli hataların önlenmesini veya zamanında tespit

edilmesini makul ölçüde güvenceye alan her kontrol kilit kontrol

sınıfına girer.

Kontrol tek başına hata verebileceği gibi, aynı anda hata vermesi

muhtemel diğer kontrollerle eşzamanlı olarak da hata verebilir.

Literatürde buna “kümelenme” denir. Bir kontrolün hata vermesi

önemli bir bildirim hatasına yol açmasa bile, bunların birkaçının aynı

anda sekteye uğraması riski uzak bir ihtimal olmaktan çıkaracak

derecede artırır. Kümelenme durumunda, kontrollerin, örneğin aynı

anda, aynı kişi tarafından veya aynı bilgisayar sistemiyle

çalıştırılmalarından dolayı muhtemelen aynı anda sekteye uğramaları

gerekir.

Bir hatanın zamanında tespit edilmesi kritik önem taşır. Aksi halde,

hataların mali tablolar SEC’e sunulduktan sonra tespit edilmesi söz

konusu olabilir ve bu da potansiyel olarak tabloların yeniden

hazırlanmasını ve sunulmasını gerektirir.

PCAOB’nin AS5 dokümanında ifade ettiği gibi, kilit kontroller esas

itibariyle şöyle tanımlanabilir:

“İç denetçi, mali raporlardaki her beyanın tabi olduğu yanlış bilgi

riskini yeterli düzeyde değerlendiren şirket kontrollerini seçerek

bunların test edilmesine karar verir.”

Kilit Rapor Kilit kontrolde kullanılan raporlardır ve genellikle sistem tarafından

hazırlanır. Bir raporun kilit rapor olarak nitelendirilebilmesi için

aşağıdaki şartların karşılanması gerekir:

Rapordaki tespit edilmeyen bir hata, örneğin rapordaki bilginin bir

hareket (yevmiye kaydı gibi) meydana getirmek için

kullanılmasından veya bir kontrole (günü geçmiş alacakların gözden

geçirilmesi gibi) temel oluşturmasından dolayı önemli bir hatayla

sonuçlanabilir

Kontrolün manüel bölümünün raporda mutlaka hata tespit etmesi

gerekmez.

Önemli hata SEC’e sunulan mali raporlarda bulunan bir önemli yanlış bilgi beyanı.

Operasyon

yönetimi

Aplikasyonları ve sistemleri işletme ve çalıştırma prosesi. Bu proses

tipik olarak fiziki güvenlik yedeklemesini ve veri kurtarmayı ve veri

merkezi operasyonlarının diğer alanlarını içerir.

PCAOB Halka Açık Şirketler Muhasebe Gözetim Kurulu (PCAOB), kamu

şirketlerinin denetçilerini izlemek ve denetlemek amacıyla Sarbanes-

Oxley kanunuyla oluşturulan, kâr amacı gütmeyen bir özel sektör

kuruluşudur. Tüzükte belirtilen amacı, “Açıklayıcı, tarafsız ve bağımsız

denetim raporlarının hazırlanmasında yatırımcıların çıkarlarını

korumak ve kamu çıkarını geliştirmek” olarak ifade edilmiştir”.

PCAOB özel bir kuruluş olmasına rağmen, hükümetin sahip

olduklarına benzer birçok düzenleyici işleve de sahiptir ve bu yönüyle,

Birleşik Devletler’de borsaları ve finansal piyasaların diğer alanlarını

düzenleyen özel Özdüzenleyici Kuruluşlar’a (SRO’lar) çok yakın bir

işlev üstlenmiştir.

SEC Birleşik Devletler Tahvil ve Borsa Komisyonu (SEC), temel

sorumluluğu federal tahvil kanunlarını uygulamak ve tahvil piyasalarını

düzenlemek olan bir Birleşik Devletler hükümet dairesidir. SEC, 1934

tarihli Tahvil Borsaları Kanunu’nun 4. Maddesi (günümüzde 15 U.S.C.

§78d olarak kodlanmıştır) hükümleri uyarınca oluşturulmuştur. SEC,

1934 kanununa ek olarak, 1933 tarihli Tahvil Kanunu, 1939 tarihli

Yatırım Fonu Senetleri Kanunu, 1940 tarihli Yatırım Şirketleri

Kanunu, 1940 tarihli Yatırım Danışmanlığı Kanunu, 2002 tarihli

Sarbanes-Oxley Kanunu hükümlerini de uygular.

Güvenlik Yönetimi Sistemlere ve verilere erişimi kısıtlamak suretiyle aplikasyonların,

verilerin, işletim sistemlerinin ve ağ altyapısının sağlamlığını

güvenceye alma prosesidir.

Yığıt Her IT genel kontrolleri prosesi her aplikasyonun IT altyapısındaki dört

katmanda - aplikasyon, veritabanı (şema gibi bağlantılı yapılar da

dahil), işletim sistemi ve ağ altyapısı - işlerlik gösterir. Bu katmanlar

aynı zamanda “yığıt” olarak da bilinirler. GAIT kullanıcıları yığıt

tanımını kendi organizasyonlarına uyacak şekilde değiştirebilirler.

Yukarıdan-aşağı PCAOB, yukarıdan-aşağı yaklaşımı AS5’te şöyle açıklamıştır:

yaklaşım Denetçi, kontrol edilecek olan testleri seçmek için, mali raporlama

üzerinde iç kontrol denetimine yukarıdan-aşağı bir yaklaşım

benimsemelidir. Yukarıdan-aşağı yaklaşım mali tablolar düzeyinde ve

denetçinin mali raporlama üzerindeki iç kontrol mekanizmalarının tabi

olduğu genel riskleri anlamasıyla başlar. Denetçi daha sonra kurumsal

düzeydeki kontrollere odaklanır ve önemli hesaplara, beyanlara ve

bunlarla ilgili açıklamaların derinine iner. Bu yaklaşım denetçinin

dikkatini, mali tablolarda ve ilgili beyanlarda bir önemli bilgi yanlışı

yapılmasını makul düzeyde olanaklı kılan hesaplara, beyanlara ve

açıklamalara yöneltir. Daha sonra, denetçi, şirket proseslerinde mevcut

riskleri tam anlayıp anlamadığını test eder ve önemli hususların her biri

için değerlendirilen yanlış beyan riskini yeterince kapsayan kontrolleri

test etmek üzere seçer.

Copyright 2009-2012 by The Institute of Internal Auditors ‘ dan , 247 Maitland Avenue, Altamonte

Springs, Florida 32701-4201, USA. All Rights reserved.

Telif hakkı sahibi olan The Institute of Internal Auditors ‘ dan , 247 Maitland Avenue, Altamonte Springs,

Florida 32701-4201, USA, bütün önemli açılardan orjinali ile aynı olan çevirinin – değiştirilmesi

onaylanmış durumlar hariç - yayınlanması konusunda izin alınmıştır. Bu dokümanın hiçbir parçası, IIA

Inc. ‘ dan yazılı izin alınmadan, tekrar çoğaltılamaz, herhangi bir sistemde saklanamaz veya herhangi bir

formatta paylaşılamaz, herhangi bir elektronik, mekanik, fotokopi, kayıt veya farklı bir yöntemle

çoğaltılamaz.

gait metodolojisi - global.theiia.org · amaçlarıyla yapılan kontrollerin tanımlanmasına da...

Documents