BAB 19 : Praktik Terbaik ITIL®, Infrastruktur IT, dan Pengendalian

Umum
AUDITOR INTERNAL INI HARUS MEMILIKI pemahaman yang kuat tentang
Teknik kontrol internal TI yang mendukung proses dan sistem TI perusahaan, mulai
dari aplikasi keuangan hingga kontrol buku besar akuntansi umum proses media sosial
dan Internet yang menyeluruh. Meskipun garis-garis pemisahan kadang-kadang sulit,
kita umumnya dapat memikirkan kontrol TI pada dua tingkat luas: aplikasi kontrol yang
mencakup proses spesifik, seperti aplikasi yang dapat dibayarkan ke akun untuk
membayar faktur dari pembelian, dan apa yang disebut kontrol TI umum. Yang terakhir
ini Kategori mencakup kontrol internal yang tidak hanya terkait dengan aplikasi TI
tertentu tetapi penting untuk semua aspek infrastruktur operasi TI perusahaan.
Konsep kontrol umum TI kembali ke hari-hari awal mainframe terpusat
komputer ketika auditor internal mencari hal-hal seperti kunci pada computer pintu
tengah sebagai kontrol umum yang mencegah akses tidak sah ke perangkat keras dan
file-file pendukung kaset dan kartu punch. Hari ini, kita sering memikirkan banyak dan
beragam proses yang mencakup semua operasi TI untuk suatu perusahaan sebagai
infrastruktur TI. Karena banyaknya kemungkinan variasi dalam teknik yang digunakan,
sebenarnya tidak ada seorang pun set atau hak dan kesalahan di sini, dan perusahaan
harus membuat dan mengimplementasikan suatu set praktik terbaik yang akan
berfungsi sebagai panduan untuk membangun kontrol umum TI.
Bab ini akan melihat kontrol TI umum atau infrastruktur dari internal perspektif
audit dengan penekanan pada serangkaian praktik terbaik yang diakui di seluruh dunia
disebut Perpustakaan Infrastruktur Teknologi Informasi (ITIL®). Ini menguraikan jenis
kerangka kerja audit internal harus dipertimbangkan ketika meninjau risiko
pengendalian internal TI dan merekomendasikan peningkatan kontrol umum TI yang
efektif.
Pengetahuan tentang IT umum atau kontrol infrastruktur merupakan
persyaratan CBOK yang penting untuk semua auditor internal. Beberapa tahun yang
lalu, beberapa auditor internal berpendapat, "Saya seorang auditor internal keuangan
atau operasional dan jangan tinjau hal-hal TI — teknologi audit TI harus meninjau
masalah kontrol umum tersebut. " Dengan penggunaan IT dan Internet untuk kami
semua aspek operasi perusahaan, semua auditor internal harus memiliki tingkat CBOK
pemahaman tentang IT umum atau kontrol infrastruktur serta masalah IT lainnya
dibahas dalam Bagian Lima bab berikut.
19.1 PENTINGNYA KONTROL UMUM
Auditor internal menjadi terlibat dengan prosedur TI awal — kemudian disebut
pemrosesan data kontrol — ketika aplikasi akuntansi pertama kali diinstal pada
komputer punch-card awal sistem. Sistem-sistem awal sering dipasang di kamar
berdinding kaca di dalamnya lobi perusahaan untuk mengesankan pengunjung dengan
kecanggihan perusahaan. Namun demikian sistem awal tidak terlalu canggih menurut
standar saat ini, dan internal auditor, yang sering tidak terbiasa dengan teknologi
pemrosesan data, akan “mengaudit di sekitar komputer. " Artinya, auditor internal
mungkin melihat prosedur kontrol input dan output aplikasi untuk memeriksa apakah
input seimbang dengan output laporan. Di era ini ada sedikit pertanyaan tentang
akurasi dan kontrol laporan diproduksi oleh sistem IT. Auditor internal hanya akan
berkeliling komputer yang sebenarnya prosedur pemrosesan program.
Seperti yang kita diskusikan di Bab 11, banyak hal berubah pada awal 1970-an
dengan Ekuitas Penipuan dana. Auditor eksternal menjalankan program perangkat
lunak audit mereka sendiri terhadap Equity File pendanaan untuk menemukan
penipuan besar-besaran dengan data yang tidak valid dicatat pada file sistem. Di
setelah urusan Pendanaan Ekuitas, organisasi seperti American Institute Akuntan
Publik (AICPA) Bersertifikat dan Institut Auditor Internal (IIA) mulai menekankan
pentingnya meninjau apa yang kemudian disebut pemrosesan data operasi dan kontrol
aplikasi. Spesialisasi profesional baru, yang disebut audit komputer, diluncurkan.
Pada masa-masa awal pemrosesan data bisnis, sebagian besar sistem
komputer dipertimbangkan menjadi "besar," dan set standar tujuan dan prosedur
kontrol auditor dikembangkan untuk meninjau kontrol. Sementara banyak yang masih
berlaku hari ini, auditor internal harus melihat tujuan pengendalian TI ini dari perspektif
yang agak berbeda ketika meninjau kontrol dalam lingkungan TI modern. Profesi mulai
memikirkan IT kontrol dalam hal kontrol dalam aplikasi spesifik dan apa yang disebut
umum atau kontrol infrastruktur, kontrol yang menyebar di sekitar semua sistem
informasi operasi. Kontrol umum atau infrastruktur TI mencakup semua operasi TI dan
mencakup:
 Keandalan pemrosesan sistem informasi. Kontrol yang baik harus ada
tempatkan semua operasi sistem TI. Dibahas sepanjang bab ini, ini kontrol
sering tergantung pada sifat dan manajemen ukuran dan jenis yang
ditentukan sistem yang digunakan.
  Integritas data. Proses harus ada untuk memastikan tingkat integritas
berakhir semua data digunakan dalam berbagai program aplikasi. Ini adalah
kombinasi dari sang jenderal kontrol operasi dalam bab ini serta kontrol
aplikasi spesifik yang dibahas dalam Bab 22.
 Integritas program. Program baru atau yang direvisi harus dikembangkan
dan dikelola dengan cara yang terkontrol dengan baik untuk memberikan
hasil pemrosesan yang akurat. Ini masalah kontrol meliputi keseluruhan
proses pengembangan program aplikasi dan adalah bagian dari diskusi kami
tentang praktik terbaik ITIL®.
 Kontrol pengembangan dan implementasi sistem yang tepat.Kontrol
harus ada untuk memastikan pengembangan tertib yang baru dan direvisi
sistem Informasi. Masalah kontrol ini juga dibahas dalam Bab 22.
 Kelanjutan pemrosesan. Kontrol harus ada di tempat untuk mendukung
sistem kunci dan untuk memulihkan operasi jika terjadi pemadaman yang tak
terduga — apa yang disebut perencanaan pemulihan bencana dan sering
dikenal hari ini sebagai kelangsungan bisnis perencanaan. Masalah kontrol
ini dibahas dalam Bab 24.
Bab ini membahas kontrol umum atas operasi sistem informasi in-house mulai
dari sistem client-server hingga operasi desktop dan juga yang lebih tua, operasi
sistem komputer mainframe yang lebih besar yang masih ada di beberapa lingkungan.
Meskipun ada perbedaan antara ukuran dan manajemen yang berbeda ini sistem,
semua harus tunduk pada kebutuhan kontrol umum yang sama. Sebagai tambahannya
membahas prosedur kontrol umum, bab ini juga membahas beberapa komputer terkait
jenis dan karakteristik perangkat keras. Semoga diskusi ini mendorong auditor internal
untuk meminta atau mencari informasi yang benar dalam suatu informasi lingkungan
sistem.
19.2 SERVER KLIEN DAN SISTEM KECIL UMUM KONTROL IT
Auditor internal secara tradisional memiliki masalah dalam mengevaluasi kontrol umum
dalam skala kecil Pengoperasian TI, mulai dari sistem client-server hingga sistem
desktop perusahaan dan smartphone - aplikasi nirkabel berbasis. Kontrol umum ini
timbul masalah kesadaran karena sistem kecil sering dipasang dengan staf terbatas
secara lebih ramah pengguna jenis lingkungan. Namun, auditor internal terkadang
masih mencari TI umum kontrol dalam hal lingkungan TI mainframe yang lebih
tradisional dan besar yang dibahas di bagian berikut. Artinya, auditor internal mencari
fisik yang kuat keamanan, revisi yang baik, dan kontrol pemisahan tugas yang tepat
 yang seringkali tidak ada atau hanya sebagian diimplementasikan dalam lingkungan
sistem kecil yang khas. Ini kurang pendekatan formal mungkin memadai ketika sistem
bisnis atau desktop kecil ini digunakan terutama untuk akuntansi kantor tunggal atau
aplikasi risiko rendah serupa. Kapasitas besar dan kemampuan sistem kecil saat ini,
pertumbuhan Internet, dan transisi ke komputasi client-server telah membuat sistem
kecil ini penting bagian dari kerangka kendali TI. Ketika dihadapkan dengan evaluasi
kontrol di kecil ini pengaturan sistem komputer, auditor internal kadang-kadang kembali
ke tradisional, hampir semua jenis rekomendasi kontrol buku masak. Artinya, mereka
merekomendasikan bahwa sistem desktop ditempatkan di ruang terkunci atau yang
kecil, pengembangan TI dua orang staf diperluas menjadi empat untuk memastikan
pemisahan tugas yang tepat. Sementara di sana mungkin situasi di mana kontrol
seperti itu sesuai, seringkali mereka tidak berlaku di pengaturan bisnis kecil. Audit
internal dapat dengan mudah kehilangan kredibilitas jika rekomendasi kontrol mereka
tidak sesuai dengan risiko yang ditemukan dalam pengaturan sistem komputer kecil.
Kontrol internal atas yang terkecil dari sistem TI ini, seperti berbasis smartphone dan
tablet aplikasi, dibahas pada Bab 20 tentang kontrol internal komputasi nirkabel.
Bab ini dimulai dengan diskusi tentang perbedaan antara umum, saling
tergantung kontrol dan kontrol aplikasi dalam sistem besar. Perbedaan-perbedaan ini
sama berlaku untuk kecil, sistem berbasis Internet dan konfigurasi server-klien. Intern
auditor harus memahami kontrol umum yang mengelilingi sistem komputer kecil.
Kontrol umum yang memadai diperlukan untuk menempatkan ketergantungan pada
aplikasi tertentu kontrol. Perusahaan menerapkan peningkatan jumlah, jaringan, dan
sistem untuk mendukung unit bisnis kecil, komputasi departemen spesifik, atau
menyediakan TI untuk seluruh perusahaan. Meskipun ukurannya kecil, sistem ini
sering kali mewakili signifikan masalah kontrol umum.

Kontrol Umum untuk Sistem Bisnis Kecil

Meskipun beberapa auditor internal pernah memikirkan komputer bisnis kecil
dan sistem client-server sebagai satu kelas sistem TI generik (berbeda dengan
mainframe yang lebih besar komputer), perubahan teknologi telah memperkenalkan
perbedaan kontrol yang signifikan prosedur dan masalah audit internal terkait. Sistem
kecil dapat diimplementasikan di berbagai cara, tergantung pada konfigurasi sistem
dan ukuran perusahaan.
Auditor internal harus dapat mengenali perbedaan-perbedaan ini dan
mengembangkan yang sesuai prosedur kontrol internal umum untuk meninjau kontrol
umum mereka. Bab ini akan membahas kontrol umum ini dalam hal sistem TI bisnis
kecil, Internet dan sistem jaringan, dan sistem client-server, serta sistem besar klasik.
Auditor internal dapat menghadapi berbagai macam IT skala kecil maupun besar
sistem dalam perusahaan modern yang khas. Sistem komputer bisnis kecil
menyediakan total Dukungan TI untuk fungsi atau unit bisnis kecil; sistem ini juga
dapat mendukung unit atau fungsi komputasi departemen dalam perusahaan yang
lebih besar dalam mendukung komputer pusat sumber daya sistem.
Sistem client-server, yang didefinisikan secara lebih rinci di bagian selanjutnya,
seringkali merupakan kombinasi berbagai jenis dan ukuran sistem TI yang saling
berhubungan dan dapat ditemukan di semua jenis dan ukuran perusahaan. Proses
atau sistem non-bisnis mencakup banyak jenis komputer kecil semakin banyak
digunakan untuk pembuatan, distribusi, dan lainnya berbagai aplikasi kontrol
operasional. Audit internal akan sering menemukan ini mesin kontrol khusus di banyak
bidang operasi perusahaan.
Jika sistem TI terletak di fasilitas yang aman, memiliki sistem operasi multitask,
atau memiliki staf pendukung aplikasi yang relatif besar, audit internal mungkin harus
mempertimbangkannya menjadi sistem komputer "besar" untuk keperluan
perencanaan audit dan harus ditinjau prosedur kontrol umum sistem besar yang sesuai
sebagaimana dibahas pada Bab 21. Sementara tidak terlalu tepat, definisi ini
mencakup sistem TI utama yang khas. Ini sama tipe deskripsi berbasis atribut bisa
lebih sulit di lingkungan sistem kecil. Definisi arsitektur perangkat keras komputer yang
ketat seringkali tidak membantu internal mengaudit untuk memutuskan kapan harus
menerapkan prosedur peninjauan kontrol internal sistem yang lebih kecil. Untuk
Misalnya, komputer desktop kecil dapat digabungkan dengan periferal yang terpasang
perangkat untuk memberikan daya komputer lebih dari banyak mesin mainframe
tradisional. Ketika meninjau kontrol dalam lingkungan seperti itu, audit internal harus
mempertimbangkan ini komputer yang terhubung harus sama dengan sistem
mainframe lama yang akan dibahas nanti dalam bab ini. Masalah lain dalam
mengidentifikasi komputer kecil adalah bahwa mereka sering terlihat seperti prosesor
besar. Sebagai contoh, jajaran komputer Sistem Daya IBM pertama kali
diimplementasikan pada tahun 1988 sebagai komputer bisnis kecil yang disebut AS /
400 dan kemudian diganti namanya menjadi System i. Lini produk ini dan kapasitas
masing-masing mesin telah diperluas berkali-kali untuk membuat banyak dari sistem ini
beroperasi secara efektif sebagai sistem mainframe klasik.
 Sistem kecil, yang dulu dikenal sebagai minicomputer, telah digunakan untuk
aplikasi bisnis sejak sekitar akhir 1960-an. Mereka adalah produk dari miniaturisasi
komponen elektronik yang meningkat serta berbagai pendekatan yang digunakan oleh
para insinyur komputer. Karena mereka relatif murah, mudah digunakan, dan tidak
memerlukan daya rumit atau dukungan pendingin udara, minicomputer pernah
digunakan oleh banyak perusahaan bisnis kecil serta untuk aplikasi IT khusus. Jauh
sebelum diperkenalkannya sistem desktop hari ini, mereka membawa kemampuan TI
ke perusahaan yang tidak mampu melakukan investasi besar yang diperlukan oleh
sistem mainframe klasik.
Sistem desktop, laptop, atau tablet saat ini memiliki kurva pertumbuhan yang
cepat. Dimulai dengan penggemar membuat mikrokomputer mereka sendiri
menggunakan chip sirkuit terintegrasi yang baru tersedia pada pertengahan 1970-an,
semuanya benar-benar dimulai pada akhir 1970-an ketika Apple Computer Corporation
dibentuk dan memproduksi mikrokomputer Apple II. Meskipun mesin itu awalnya
dipandang sebagai mainan yang aneh, paket perangkat lunak spreadsheet, VISICALC,
diperkenalkan sekitar setahun kemudian, menjadikan Apple II alat yang serius untuk
pengambilan keputusan bisnis. Beberapa tahun kemudian, pada awal 1980-an, IBM
memperkenalkan komputer pribadinya dan melegitimasi komputer mikro sebagai alat
pemrosesan bisnis yang serius. Saat ini, banyak mesin yang masih dikatakan
"kompatibel dengan IBM" meskipun IBM tidak memiliki namanya pada produk ini atau
bahkan memproduksinya.
Saat ini, komputer pribadi, sering terhubung ke jaringan nirkabel, digunakan
untuk banyak aplikasi TI bisnis. Mereka sering merupakan satu-satunya sumber daya
sistem komputer untuk perusahaan kecil, dan telah menggantikan sistem "mainframe"
kecil. Mereka juga dapat digunakan untuk komputasi departemen khusus meskipun
mungkin juga ada kemampuan komputer mainframe yang lebih besar. Secara khusus,
komputer khusus ini digunakan untuk aplikasi seperti laboratorium penelitian atau
kontrol proses manufaktur daripada untuk TI bisnis murni. Mesin yang sama ini juga
dapat digunakan untuk beberapa aplikasi pemrosesan bisnis di samping tujuan khusus
yang dimaksudkan.
Kecepatan dan kapasitas yang terus meningkat telah melakukan banyak hal
untuk mempromosikan penggunaan sistem server ini. Ketika Apple II pertama dirilis, itu
memiliki memori internal 48 KB (kilobyte) dari memori akses acak (RAM). Pada
pertengahan 1990-an, sebaliknya, mesin off-shelf biasanya datang dengan kapasitas
RAM 32 juta megabyte atau 32 MB. Saat ini, ukuran dan kemampuan memori jauh
lebih besar dari hampir semua ukuran, apakah itu kecepatan pemrosesan,
kemampuan menjalankan banyak tugas, atau kapasitas memori.
Sistem unit bisnis kecil ini dapat menyebabkan kesulitan bagi beberapa auditor
internal yang telah menyatakan dalam rencana mereka kepada komite audit bahwa
mereka berencana untuk meninjau kontrol umum seputar "semua" sistem TI di
perusahaan. Jelas, jenis tujuan ini pernah dianggap hanya mencakup komputer
mainframe dan sistem komputer mini divisi terpisah. Arahan juga dapat mencakup
komputer desktop departemen perusahaan, terkadang berdiri sendiri tetapi lebih sering
terhubung ke computer Internet. Namun, audit internal mungkin bertanya-tanya apakah
tujuan seperti itu benar-benar mencakup stasiun kerja IT khusus di laboratorium teknik
yang digunakan untuk merekam hasil pengujian atau sistem di ujung jalur distribusi
yang menimbang paket dan mengarahkannya ke dermaga pengiriman yang benar.
Masalah definisi ini hanya menjadi lebih buruk karena sistem embedded saat ini
mengambil peran yang lebih besar dalam mengendalikan proses bisnis. Sistem
tertanam adalah komputer yang berada di belakang hal-hal seperti dasbor mobil atau
pada panel kontrol perekam video atau bahkan di microwave dapur. Sebagai
konsumen, kami menekan layar panel datar ini dan umumnya tidak berpikir kami
mengirimkan perintah sistem komputer. Namun, sistem embedded akan mengambil
peran yang lebih besar dalam proses bisnis karena kapasitas dan aplikasinya
meningkat.
Sementara semua sistem TI di atas harus menjadi bagian dari audit internal
umum, tujuan TI untuk meninjau kontrol internal di semua sistem TI, tinjauan audit
internal harus menekankan sistem yang digunakan untuk keperluan TI bisnis. Untuk
mengikuti contoh yang baru saja disebutkan, prosesor di akhir jalur distribusi mungkin
menggunakan seperangkat standar perangkat lunak tertanam yang tidak dapat
dimodifikasi oleh staf lokal. Itu sangat mungkin dibeli dari vendor sistem luar, dan
setelah instalasi dan pengujian awal, itu hanya bekerja, tanpa interaksi programmer.
Mesin seperti itu umumnya memiliki bisnis yang terbatas atau mengendalikan implikasi
risiko.
Audit internal akan sering bekerja di lingkungan di mana hanya sistem bisnis
kecil digunakan, terutama ketika perusahaan relatif kecil. Contohnya adalah
perusahaan nirlaba yang hanya membutuhkan sistem server dan sistem desktop untuk
mendukung pengiriman surat langsung dan aplikasi terkait akuntansi terbatas.Audit
internal harus meninjau kontrol umum atas konfigurasi server seperti seolah-olah itu
adalah sistem perusahaan klasik yang besar. Artinya, masih ada kebutuhan untuk
keamanan sistem, integritas, dan prosedur cadangan. Jenis sistem bisnis kecil ini
umumnya akan memiliki karakteristik umum berikut:
 Staf TI terbatas. Sistem komputer bisnis kecil, apakah sistem desktop tunggal
atau serangkaian unit nirkabel yang terhubung ke server lokal atau berbasis
cloud, akan memiliki staf IT khusus yang sangat terbatas, jika ada. Sistem
desktop untuk memberikan laporan akuntansi untuk perusahaan kecil dapat
dikelola oleh satu orang. Bisnis kecil atau sistem server dapat memiliki
manajer / administrator dan mungkin satu atau dua administrator sistem
sebagai departemen TI totalnya. Operasi IT sekecil itu menciptakan risiko
pengendalian karena bergantung pada beberapa perusahaan konsultan kecil
yang terpisah untuk banyak dukungan TInya, dan persyaratan seperti membuat
cadangan file penting mungkin diabaikan. Namun, ukuran staf yang kecil tidak
dengan sendirinya menciptakan masalah pengendalian internal. Audit internal
harus dapat mencari kontrol kompensasi seperti halnya ketika meninjau
departemen akuntansi kecil di mana pemisahan tugas yang klasik kurang.
 Kemampuan pemrograman terbatas. Sistem komputer bisnis kecil yang khas
membuat penggunaan ekstensif paket perangkat lunak yang dibeli. Satu-
satunya "pemrograman" tanggung jawab perusahaan mungkin untuk memuat
program pembaruan untuk paket perangkat lunak yang dibeli, memelihara tabel
parameter sistem, dan menulis program pencarian sederhana. Jika audit
internal menemukan staf pemrograman besar atau aktivitas pengembangan in-
house yang ekstensif, beberapa prosedur kontrol yang dibahas dalam bagian
selanjutnya untuk fungsi pengembangan sistem besar harus dipertimbangkan.
 Kontrol lingkungan yang terbatas. Sistem bisnis kecil umumnya dapat
dicolokkan ke sistem daya normal dan beroperasi dalam kisaran suhu yang
cukup luas. Karena persyaratan yang terbatas ini, kadang-kadang dipasang
tanpa kontrol lingkungan yang penting dan mudah diinstal seperti drive
cadangan, sistem catu daya berbasis baterai yang tidak terputus, atau
pelindung lonjakan daya listrik. Sementara beberapa instalasi komputer bisnis
kecil atau server file mungkin ditempatkan di ruang komputer formal yang
dikontrol lingkungan, ini bukan atribut yang diperlukan dari sistem ini.
 Kontrol keamanan fisik yang terbatas. Karena kurangnya kebutuhan untuk
pengendalian lingkungan, sistem ini sering dipasang langsung di daerah kantor.
Tingkat kekhawatiran auditor mengenai kontrol keamanan fisik tergantung pada
jenis peralatan dan aplikasi yang diproses. Audit internal kadang-kadang dapat
 merekomendasikan agar keamanan fisik ditingkatkan, khususnya ketika
aplikasi penting sedang diproses. Namun, dalam banyak kasus lain, kurangnya
kontrol keamanan fisik ini seharusnya tidak menghadirkan masalah kontrol
internal yang signifikan.
 Jaringan telekomunikasi yang luas. Hampir semua sistem desktop saat ini
memiliki koneksi nirkabel ke Internet. Data dan aplikasi dapat dengan mudah
diunggah atau diunduh. Selain itu, materi dapat diunduh dengan mudah melalui
perangkat USB yang umum digunakan dan mudah digunakan. Kombinasi
kontrol dan kebijakan harus ditetapkan untuk melindungi perusahaan.
Karakteristik ini tentu saja tidak mendefinisikan sistem komputer bisnis kecil,
tetapi hanya menjelaskan beberapa atribut umum. Namun, mereka harus membantu
audit internal untuk lebih baik memutuskan prosedur pengendalian yang akan
digunakan. Sebagaimana dicatat, ketika ragu, audit internal harus mempertimbangkan
sistem itu besar, lebih kompleks.

19.3 SISTEM KOMPUTER KLIEN-SERVER

Istilah client-server pertama kali muncul dalam literatur IT pada akhir 1980-an.
Untuk spesialis non-IT, termasuk banyak auditor internal, ini adalah salah satu istilah IT
khusus yang sering sulit dipahami, apalagi dijelaskan. Namun, arsitektur client-server
telah menjadi konfigurasi TI yang sangat populer di semua ukuran perusahaan dan
sistem. Dalam lingkungan jaringan lokal, misalnya, setiap workstation adalah klien, dan
prosesor terpusat, yang berisi file bersama bersama dan sumber daya lainnya, disebut
server. Mungkin juga ada server khusus untuk tugas-tugas seperti manajemen
penyimpanan atau pencetakan. Pengguna workstation mengirimkan permintaan dari
mesin klien ke server, yang kemudian melayani klien itu dengan melakukan
pemrosesan yang diperlukan.
Arsitektur client-server ini, bagaimanapun, melampaui hanya workstation dan
server. Aplikasi yang menanyakan database terpusat dapat dianggap sebagai klien,
sedangkan database yang mengembangkan tampilan database adalah server untuk
semua workstation yang meminta layanan database. Demikian pula, program aplikasi
dapat meminta layanan dari server komunikasi sistem operasi. Tampilan 19.1
menunjukkan konfigurasi sampel sistem server-klien di mana satu server menangani
permintaan dari banyak klien di seluruh jaringan. Konfigurasi klien-server ini, meskipun
sangat umum, mewakili sistem TI yang khas saat ini.
 Prosesor Klien

Interne
t

Server Server server

Penyimpanan Administratif pencetakan

PEMPERLIHATKAN 19.1 Konfigurasi Sistem Client-Server

Di banyak perusahaan saat ini, sistem lain yang sering dikonfigurasikan dengan
klien-server dapat ditemukan di area di luar operasi TI dan mungkin berlokasi di
laboratorium teknik, operasi kontrol manufaktur, departemen pemasaran, dan di tempat
lain. Sistem ini dapat digunakan untuk kontrol proses, pekerjaan desain otomatis,
pemrosesan analisis statistik, atau banyak aplikasi lainnya. Beberapa sepenuhnya
didedikasikan untuk aplikasi spesifik, sementara yang lain dapat digunakan untuk
berbagai tugas dalam fungsi yang ditugaskan. Banyaknya mesin-mesin TI telah
muncul di banyak perusahaan karena biaya yang relatif rendah dari mesin-mesin
tersebut, keakraban banyak profesional dengan teknik-teknik TI saat ini, dan
 ketidakmampuan departemen-departemen TI tradisional untuk mendukung kebutuhan-
kebutuhan khusus TI.
Meskipun sistem ini tidak digunakan untuk kebutuhan informasi bisnis
tradisional, seperti memelihara catatan piutang usaha, mereka sering mendukung
aplikasi penting untuk perusahaan. Sistem ini sering ditemukan di lingkungan jaminan
kualitas yang dibahas dalam Bab 31. Misalnya, komputer teknik dapat mendukung
pekerjaan desain berbantuan komputer. Cadangan sistem dan masalah integritas di
lingkungan ini mungkin sama besarnya dengan di pusat bisnis TI yang khas. Peran
audit internal sehubungan dengan operasi TI khusus akan bervariasi sesuai dengan
arahan manajemen dan tujuan tinjauan audit internal. Sementara beberapa
perusahaan audit akan memiliki sedikit keterlibatan dengan mengulas sistem komputer
khusus, kendali TI yang ditinjau di sini sering kali dapat memainkan peran penting
dalam mendukung pemahaman audit internal tentang prosedur pengendalian dan
dalam kegiatan audit operasional lainnya.
Sebelum mencoba meninjau sistem komputer yang khusus seperti itu, audit
internal harus memahami secara mendalam fungsi-fungsi operasi itu. Sebagai contoh,
auditor internal yang berencana untuk meninjau desain dan operasi komputer yang
dibantu komputer khusus memerlukan pemahaman umum tentang terminologi, cara
kerja umum, dan tujuan sistem ini. Ulasan sistem TI khusus tidak direkomendasikan
untuk auditor internal yang kurang berpengalaman. Untuk menemukan analogi kontrol
dari situasi TI bisnis normal dan menerjemahkannya ke lingkungan kontrol khusus,
auditor harus cukup berpengalaman dalam meninjau pusat-pusat komputer IT bisnis,
apakah itu operasi besar atau kecil. Seiring waktu, audit internal akan menghadapi
lebih banyak operasi komputer khusus ini. Auditor internal yang kreatif dapat
memberikan kontribusi yang meningkat kepada manajemen dengan melakukan
tinjauan operasional atas pusat-pusat komputer ini secara berkala.

19.4 PENGENDALIAN INTERNAL SISTEM KECIL

Seperti dibahas, auditor internal secara tradisional mencari pemisahan tugas
yang tepat sebagai prosedur pertama untuk mengevaluasi kontrol internal dan kontrol
umum TI. Kontrol ini, bagaimanapun, juga sering kurang dalam fungsi TI bisnis kecil.
Sementara tujuan kontrol TI yang baik membutuhkan pemisahan tanggung jawab yang
tepat antara pengguna dan operator, kontrol ini seringkali sulit dilakukan di departemen
kecil. Ketika auditor internal pertama kali mulai meninjau kontrol umum di departemen
TI kecil dan mencoba menerapkan solusi kontrol sistem besar tradisional, rekomendasi
sebelumnya sulit dijual ke manajemen yang sadar biaya dan akan diperlakukan
dengan cemoohan hari ini.
Manajer yang bertanggung jawab untuk sistem server-klien kecil hari ini juga
dapat menjadi spesialis teknis utama dan mengoperasikan peralatan untuk tugas-tugas
seperti pemrosesan cadangan. Kontrol pemisahan tugas yang ditemukan di sebuah
toko besar tidak ada di lingkungan kecil ini, tetapi harus ada kontrol kompensasi,
termasuk:
 Perangkat lunak yang dibeli. Hampir semua sistem komputer kecil saat ini
beroperasi dengan paket perangkat lunak yang dibeli di mana "programmer"
tidak memiliki akses atau memiliki akses yang sangat terbatas ke kode sumber.
Tugas utama mungkin hanya menginstal pembaruan perangkat lunak vendor
pada sistem lokal.
 Meningkatkan perhatian manajemen terhadap laporan sistem dan
kegiatan konsultan. Meskipun manajemen usaha kecil mungkin memiliki
sedikit pengetahuan tentang teknik-teknik TI, mereka seringkali harus
memberikan perhatian yang besar pada laporan-laporan kunci yang dihasilkan
komputer. Dalam sebuah perusahaan kecil, bukan hal yang aneh bagi
manajemen puncak untuk meninjau, misalnya, piutang yang berusia lanjut
dengan rincian saldo percobaan dan secara teratur. Dalam lingkungan ini,
banyak usaha kecil sangat tergantung pada bantuan manajemen konsultasi dari
perusahaan konsultan yang juga sangat kecil. Perhatian harus diberikan pada
pemantauan kegiatan konsultasi semacam itu dalam hal waktu yang
dihabiskan, akses ke catatan perusahaan lain, dan hal-hal lain.
 Pemisahan tugas input dan pemrosesan. Di hampir semua sistem TI bisnis
kecil modern, pengguna mengirimkan input data melalui workstation masing-
masing dan menerima output pada terminal atau printer jarak jauh. Auditor
internal harus mencari beberapa level kontrol kompensasi jika memungkinkan,
termasuk firewall nirkabel untuk mencegah akses ke sistem tidak resmi terdekat
lainnya.

Bahkan dengan kontrol kompensasi ini dalam sistem TI bisnis kecil modern,
audit internal juga harus menyadari potensi risiko dan kelemahan kontrol. Masih ada
departemen TI di mana manajer yang bertanggung jawab mengimplementasikan
banyak aplikasi, memiliki tanggung jawab untuk manajemen jaringan, mengendalikan
semua kata sandi, dan tampaknya menjadi satu-satunya orang di perusahaan yang
memahami aplikasi TI. Sementara staf terbatas mungkin dapat diterima dalam
beberapa keadaan, perusahaan menghadapi risiko kontrol jika semua pengetahuan IT
diberikan hanya dalam satu orang. Gejala kelemahan kontrol lainnya di perusahaan IT
kecil yang biasanya tidak ada di departemen besar meliputi:

 Karyawan "Setia" yang tidak mengambil cuti pribadi mereka

 Penggunaan program khusus dan tidak berdokumen yang hanya diketahui oleh
manajer TI
 Partisipasi departemen TI langsung dalam transaksi input sistem, seperti
penyesuaian sistem persediaan

Risiko pengendalian dapat menjadi pertimbangan utama ketika prosedur audit

telah mengidentifikasi kelemahan kontrol yang signifikan dalam sistem bisnis kecil. Di
perusahaan besar, auditor internal sering mencari deskripsi posisi yang
terdokumentasi dalam tinjauan kontrol internal mereka sebagai bukti kontrol
manajemen yang baik atas fungsi TI. Banyak perusahaan kecil sering tidak memiliki
deskripsi seperti itu untuk karyawan mana pun. Auditor internal tidak akan efektif dalam
menyarankan bahwa uraian posisi tersebut disusun hanya untuk fungsi TI sementara
mengabaikan seluruh perusahaan ketika risiko kontrol keseluruhan minimal karena
ukuran kecil perusahaan.
Sebagaimana dibahas, organisasi terencana dan praktik manajemen terkait
sering kali berada di antara prosedur kontrol terkuat di perusahaan IT besar. Dalam
usaha kecil, ukuran dan informalitas yang biasanya terkait dengan kelompok seperti itu
akan cenderung melemahkan kontrol. Manajemen senior harus memiliki pemahaman
yang baik tentang fungsi TI, rencananya, dan tujuannya. Kontrol umum yang sangat
penting bagi perusahaan IT kecil adalah dokumentasi yang memadai atas sistem dan
prosedurnya. Ada contoh di mana kedua anggota organisasi TI dua orang tiba-tiba
mengundurkan diri karena ketidaksepakatan atau tawaran pekerjaan yang lebih baik.
Tanpa dokumentasi yang memadai, sangat sulit bagi orang lain untuk mengambil alih.
Ini benar bahkan jika perusahaan terutama menjalankan perangkat lunak paket,
karena mungkin ada banyak prosedur khusus yang terkait dengan paket-paket itu.
Risiko sama tingginya jika perusahaan menggunakan sistem desktop atau tablet di
mana pengguna melakukan banyak pekerjaan mereka sendiri. Administrator jaringan
 yang mengonfigurasi sistem dan mencadangkan file memiliki tanggung jawab kontrol
utama.
Kadang-kadang operasi sistem TI kecil adalah unit operasi perusahaan besar
dengan fasilitas TI terpusat. Meskipun perusahaan IT kecil mungkin sepenuhnya
berdiri bebas, itu mungkin menerima arahan pusat untuk standar dan prosedur yang
sesuai. Untuk memastikan kepatuhan dengan standar-standar ini, internal audit harus
memiliki pemahaman umum tentang mereka dan tingkat di mana mereka diharapkan
untuk diikuti. Kadang-kadang perusahaan besar akan mengeluarkan standar wajib
yang berlaku untuk semua unit operasinya, tidak peduli ukurannya, meskipun standar
tersebut mungkin tidak praktis untuk unit kecil. Sementara manajemen pusat mungkin
melihat ke arah lain mengenai kepatuhan lokal terhadap standar-standar ini, audit
internal seringkali merasa terdorong untuk memunculkan pelanggaran yang ditemukan
di unit yang lebih kecil. Jika ada masalah seperti itu, audit internal harus membahas
masalah ini dengan kelompok manajemen TI pusat yang bertanggung jawab atas
standar. Sangat sedikit yang dicapai jika auditor internal mengemukakan pelanggaran
terhadap standar perusahaan yang ditemukan di unit jauh ketika manajemen pusat
tidak mengharapkan kepatuhan penuh. Ini mungkin lebih dari topik untuk tinjauan
terpusat standar.

19.5 AUDIT IT KONTROL UMUM UNTUK SISTEM IT KECIL

Beberapa sistem TI kecil mungkin merupakan unit operasi yang terpisah dari
perusahaan besar dan memberikan dukungan untuk total perusahaan. Sistem seperti
itu mungkin memiliki banyak atribut dari sistem komputer mainframe yang lebih besar,
termasuk perusahaan IT yang terbatas tetapi formal, jadwal produksi, dan tanggung
jawab untuk mengimplementasikan aplikasi baru. Namun, perusahaan sistem IT kecil
seringkali tidak memiliki fungsi khusus lainnya. Audit internal akan menemukan
berbagai merek perangkat keras komputer atau nama produk dalam lingkungan sistem
kecil, tetapi sebagian besar akan berupa sistem terbuka dengan sistem operasi umum
yang dapat beroperasi tidak peduli apa pun merek perangkat keras yang digunakan. Ini
berbeda dari komputer mainframe klasik, di mana produsen umumnya membangun
perangkat keras komputer serta sistem operasi. Sejumlah vendor memasok sistem
komputer sekecil itu dengan fungsionalitas dan kinerja harga yang lebih baik, dan
auditor internal akan lebih efektif dalam meninjau kontrol sistem komputer bisnis kecil
jika mereka memiliki pengetahuan keseluruhan tentang beberapa kemampuan mereka.
 Terlepas dari sifat kecil dan informal dari sistem komputer bisnis kecil, audit
internal tetap harus mengharapkan untuk memiliki tujuan pengendalian umum dengan
masalah pengendalian internal berikut:
Kontrol sistem yang lemah atas akses ke data dan program. Ketika orang yang
tidak berwenang diizinkan untuk mengakses dan memodifikasi file komputer,
kontrol umum sangat lemah, dan audit internal harus mempertimbangkan akses
ke data dan program sebagai tujuan kontrol umum utama ketika meninjau
perusahaan IT kecil. Ini benar apakah departemen TI menggunakan produk
perangkat lunak paket atau spreadsheet atau basis data yang dikembangkan di
perusahaan.
Kontrol atas akses ke data dapat dipertimbangkan dalam hal aplikasi
spesifik dan kontrol umum. Namun, dalam sistem TI kecil, kontrol umum sering
kali lebih penting daripada kontrol akses data aplikasi spesifik karena aplikasi
yang beroperasi pada sistem komputer bisnis kecil tunggal biasanya akan
semua beroperasi di bawah set kontrol akses data yang sama. Dalam sistem
kecil, data dapat diakses dengan tidak semestinya dan dimodifikasi melalui
yang tidak tepat upaya akses data melalui terminal pengguna, penggunaan
program utilitas khusus yang tidak sah, atau permintaan TI yang tidak valid.
Akses data yang tidak benar melalui workstation pengguna. Sistem kecil,
apakah serangkaian laptop yang terhubung melalui sistem nirkabel atau sistem
server yang kuat, sering tidak memiliki kontrol keamanan canggih yang
ditemukan pada sistem tipe mainframe besar. Sebaliknya, sistem kecil memiliki
identifikasi log-on / kata sandi pengguna digabungkan dengan keamanan
informasi berbasis menu. Pengguna sistem biasanya memasukkan log-on atau
kode identifikasi ID pengguna yang ditetapkan ke terminal dan menerima layar
menu dengan aplikasi yang tersedia untuk kode itu. Pengguna hanya dapat
mengakses aplikasi yang ditugaskan ke menu itu.
Sistem keamanan berbasis menu ini, secara historis ditemukan dalam
sistem seperti versi atau model IBM AS / 400 yang lebih lama, dapat
memberikan kontrol yang cukup efektif terhadap upaya akses yang tidak tepat.
Namun, mereka dapat rusak karena informalitas dan kurangnya aturan dan
prosedur formal di banyak perusahaan kecil. Kode-kode log-on sering tidak
diubah secara teratur, satu menu umum diberikan kepada hampir semua
karyawan, atau terminal dengan ID yang lebih istimewa ditinggalkan untuk
digunakan semua orang. Karena pengguna sering tidak menyadari potensi
 kerentanan data, manajemen mungkin hanya memberikan perhatian minimal
terhadap masalah keamanan tersebut. Untuk meninjau kontrol di bidang ini,
audit internal harus terlebih dahulu mendapatkan pemahaman umum tentang
sistem keamanan data yang dipasang, yang dapat berkisar dari sistem berbasis
kata sandi yang baik hingga serangkaian prosedur yang terstruktur. Langkah
selanjutnya adalah memahami bagaimana sistem keamanan itu telah
diterapkan dan digunakan. Langkah terakhir menyiratkan bahwa auditor internal
harus meluangkan waktu untuk meninjau penggunaan kontrol aplikasi di area
pengguna.
Sistem komputer bisnis kecil mungkin tidak memiliki mekanisme
pencatatan untuk memantau upaya akses yang tidak valid. Sebagai gantinya,
audit internal harus meninjau keseluruhan prosedur administrasi yang
mencakup sistem keamanan. Ini dapat mencakup peninjauan seberapa sering
log-ons diubah, siapa yang memiliki akses ke menu administrator sistem, dan
apresiasi umum manajemen lokal terhadap kontrol akses TI.
Penggunaan program utilitas secara tidak sah. Sistem kecil modern sering
dilengkapi dengan program utilitas yang kuat yang dapat dengan mudah
mengubah file data aplikasi apa pun. Program-program ini dirancang untuk
digunakan untuk situasi pemecahan masalah khusus, dan seringkali hanya
menghasilkan laporan jejak audit yang terbatas. Terlalu sering, utilitas ini
berfungsi sebagai pengganti program pembaruan produksi normal atau
digunakan oleh manajer TI untuk pembaruan khusus ini, dan kadang-kadang
bahkan diberikan kepada pengguna. Misalnya, perusahaan mungkin telah
menginstal sistem status inventaris. Walaupun sistem biasanya menyediakan
catatan penyimpanan stok yang tepat, status persediaan mungkin salah saji
dari waktu ke waktu karena berbagai alasan. Untuk membantu pengguna
memperbaiki masalah pencatatan status persediaan ini, administrator TI
mungkin telah mengembangkan praktik mengoreksi saldo inventaris melalui
penggunaan program utilitas. Sementara manajer TI mungkin mengikuti arahan
manajemen yang tepat dalam penggunaan normal program semacam itu,
mungkin tidak ada jejak audit atas penggunaannya.
Program-program utilitas ini memiliki berbagai nama tergantung pada
jenis sistem operasi komputer. Misalnya, dalam sistem operasi Unix
lingkungan, perintah su (pengguna super) memiliki beberapa atribut kuat yang
harus dilindungi. Audit internal harus memahami jenis program utilitas standar
 yang tersedia untuk sistem yang sedang ditinjau. Penggunaan program tertentu
dapat ditentukan melalui penyelidikan dan observasi.
Data IT yang tidak benar dan permintaan akses program. Informalitas
perusahaan kecil seringkali memungkinkan data diakses secara tidak benar
melalui prosedur operasi TI normal. Misalnya, seseorang yang dikenal dengan
fungsi IT dapat memulai menjalankan komputer khusus, yang menghasilkan
akses yang tidak tepat ke data rahasia. Di perusahaan yang lebih besar dan
lebih formal, permintaan semacam itu sering kali memerlukan semacam izin
manajemen khusus, tetapi perusahaan kecil dan informal sering kali
mengabaikan persyaratan tersebut. Jenis akses ini mungkin merupakan risiko
kontrol yang lebih besar daripada akses melalui penggunaan program yang
tidak patut.
Audit internal harus mencari kontrol untuk mencegah permintaan TI biasa
seperti itu. Kontrol terbaik bisa berupa jenis formal "permintaan layanan data", disetujui
oleh manajemen. Selain itu, log harus dipelihara yang mencantumkan semua kegiatan
TI produksi serta nama pemohon dan penerima laporan. Banyak dari kekhawatiran
kontrol atas akses yang tidak tepat ke data juga berlaku untuk perpustakaan program
sistem kecil. Sistem bisnis kecil biasanya tidak memiliki alat kontrol perangkat lunak
yang canggih atas perpustakaan program yang ditemukan dalam sistem besar, tetapi
mereka umumnya memiliki sistem berbasis menu yang menawarkan beberapa jenis
kontrol keamanan. Tanpa jenis menu yang tepat dari sistem keamanan untuk
membatasi akses yang tidak patut, seringkali dapat relatif mudah bagi seseorang
dengan sedikit pengetahuan untuk menemukan dan berpotensi memodifikasi file
pustaka program.
Audit internal juga dapat menemukan kontrol yang lemah atas pembaruan
perpustakaan program. Satu atau dua personel di departemen TI kecil yang bertindak
sebagai administrator jaringan biasanya dapat memperbarui perpustakaan program
dengan sedikit perhatian untuk mendokumentasikan perubahan tersebut atau
mendapatkan segala jenis otorisasi manajemen tingkat atas. Sementara beberapa
perubahan ini dapat dibenarkan untuk menanggapi permintaan darurat pengguna,
yang lain mungkin tidak diotorisasi dengan baik. Sulit, jika bukan tidak mungkin, untuk
menginstal kontrol pemisahan tugas perusahaan atas perpustakaan program sistem
bisnis kecil. Selain itu, audit internal mungkin tidak akan berfungsi untuk menyarankan
agar manajemen meninjau dan menyetujui semua pembaruan perpustakaan program
secara formal — mereka tidak akan tertarik atau tidak memiliki keterampilan teknis
untuk melakukan tinjauan tersebut. Metode kontrol terbaik di sini mungkin untuk
menginstal prosedur yang memerlukan pencatatan semua perubahan atau pembaruan
paket perangkat lunak ke pustaka program produksi, dengan catatan seperti itu akan
ditinjau secara berkala oleh auditor internal.
Jenis kontrol ini mengambil keuntungan dari kenyataan bahwa banyak sistem
TI bisnis kecil mempertahankan jumlah total hash1 dari ukuran program dalam byte
dan juga memiliki kemampuan untuk mempertahankan beberapa bentuk tanggal atau
nomor versi dalam nama program. Audit internal kemudian menyarankan kontrol
perpustakaan program sistem komputer bisnis kecil sebagai berikut:
 Tetapkan konvensi penamaan program yang mencakup tanggal atau nomor
versi yang disertakan dengan nama program. Ketika tidak tersedia dalam
perangkat lunak yang dibeli secara komersial, file kontrol terpisah dengan data
ini dapat dibuat. Fitur ini menjadi semakin umum; misalnya, dapat diterapkan
dalam sistem operasi Windows.
 Mintalah orang yang berwenang untuk membuat tabel program atau perubahan
parameter mencatat nomor versi, tanggal, ukuran program, dan alasan
perubahan dalam daftar manual yang tunduk pada manajemen berkala. Jika
aplikasi dikembangkan sendiri, kode sumber harus berisi komentar yang
menjelaskan perubahan tersebut.
 Pertahankan setidaknya satu salinan cadangan dari program perpustakaan dan
putar salinan file program perpustakaan untuk mengamankan drive disk
portabel di lokasi di luar situs setidaknya sekali seminggu.
 Perkuat kontrol akses sehingga personel yang tidak berwenang tidak dapat
dengan mudah mengakses program perpustakaan perpustakaan.
 Tinjauan kinerja audit internal log perubahan perpustakaan secara berkala.
Tinjauan itu harus cocok dengan versi, tanggal, dan ukuran program yang
dicatat dengan data yang dilaporkan pada file pustaka program.
Langkah-langkah ini tidak akan memberikan jaminan lengkap bahwa semua
perubahan program telah disahkan; namun, jika audit internal secara berkala meninjau
perubahan yang dicatat dan mempertanyakan setiap perbedaan, personel sistem
perusahaan mungkin akan berhati-hati untuk mendokumentasikan dan mencatat
perubahan program produksi secara lebih baik dan konsisten.
Pesan kami di seluruh bagian ini adalah bahwa ada atau harus ada beberapa
masalah pengendalian internal TI umum untuk semua sistem TI kecil, apakah jaringan
laptop digabungkan ke server melalui tautan nirkabel atau bahkan lepas dari sistem
 desktop. Ada banyak variasi dalam jenis konfigurasi TI sistem kecil, tetapi auditor
internal harus menggunakan beberapa tujuan pengendalian internal umum untuk
meninjau kontrol umum di lingkungan TI ini. Tampilan 19.2 berisi tujuan kontrol umum
untuk tinjauan sistem TI bisnis kecil.

19.6 KOMPONEN DAN KONTROL SISTEM LEGACY MAINFRAME

Sebagaimana dibahas dalam pengantar bab ini, UNIVAC II, salah satu komputer IT
bisnis pertama yang berhasil, diperkenalkan pada tahun 1951 dan membantu
memprediksi hasil pemilihan presiden 1952 A.S. Dibutuhkan sejumlah besar ruang
fisik, beratnya 15 ton, dan biaya $ 1,3 juta (dalam dolar 1950). Unit pemrosesan
pusatnya ditempatkan di sebuah kabinet dengan pintu di kedua ujungnya sehingga
seorang teknisi dapat melewatinya untuk melakukan perbaikan yang diperlukan tetapi
memiliki kemampuan memori yang lebih sedikit daripada smartphone saat ini. Apakah
UNIVAC II sistem komputer "besar"? Dalam istilah hari ini, meskipun secara fisik
besar, berdasarkan biaya dan ruang yang ditempati, sehubungan dengan memori,
kecepatan, dan kemampuan fungsionalnya, jawabannya adalah tidak. Istilah besar
seperti yang berlaku untuk sistem komputer menjadi lebih sulit saat ini. Setelah
dideskripsikan oleh pabrikan mereka sebagai "minicomputer," sistem kecil mungkin
tampak sebagai "komputer besar" bagi auditor karena mereka beroperasi sebagai
server untuk mendukung berbagai macam peralatan TI seperti beberapa workstation,
perangkat disk dan penyimpanan, dan banyak lainnya. perangkat yang terpasang pada
sistem. Perangkat keras komputer sistem besar juga dapat didukung oleh staf operasi
besar dan akan menangani banyak tugas pemrosesan yang beragam. Profesional
yang berbeda masing-masing memiliki definisi sendiri tentang apa sistem komputer
yang besar itu. Programmer teknis
MEMPERLIHATKAN 19.2 Tujuan Pengendalian Umum untuk Sistem TI Bisnis Kecil
1. Menentukan apakah ada inventaris lengkap dan terkini dari perangkat keras sistem,
termasuk server, printer, dan pengontrol jaringan serta inventaris lengkap aplikasi dan
perangkat lunak sistem.
2. Jika karyawan dan pemangku kepentingan lainnya telah diberi wewenang untuk
menggunakan smartphone dan tablet pribadi untuk proses sistem, tinjau kontrol atas siapa
yang telah mengeluarkan peralatan ini dan nilai kecukupan manajemen dan penggunaan
fasilitas ini.
3. Laporan inventaris perangkat keras jaringan harus berisi nomor model dan identifikasi.
7. Amati proses penyimpanan untuk membuat cadangan file-file utama untuk menentukan
bahwa media secara teratur dicadangkan untuk mengamankan lokasi di luar lokasi.
8. Menilai kecukupan prosedur keamanan kontrol akses untuk menentukan bahwa sistem dan
file utama dilindungi secara memadai oleh kata sandi yang secara teratur diubah dan sulit
dideteksi dengan mudah.
9. Tinjau prosedur yang berlaku untuk membatasi, mengidentifikasi, dan melaporkan
pengguna yang tidak sah dari lingkungan jaringan dan menilai kecukupan proses untuk
menyelidiki dan memperbaiki pelanggaran keamanan.
10. Menilai kecukupan proses pemantauan keamanan sistem serta praktik pelatihan karyawan
baru untuk menekankan keamanan aplikasi.
11. Periksa kecukupan prosedur untuk menginstal perangkat lunak baru di lingkungan sistem
dan menilai bahwa ada kontrol untuk mencegah pengenalan produk perangkat lunak yang
tidak sah.
12. Tinjau sampel aplikasi utama dan verifikasi apakah didukung oleh rencana kesinambungan
yang memadai untuk keperluan pemulihan bencana. Juga, tentukan bahwa rencana
kesinambungan diuji secara berkala.
13. Saya melihat orang-orang yang bertanggung jawab atas administrasi keamanan jaringan
untuk menentukan bahwa alat firewall yang memadai telah diinstal.
14. Tinjau catatan downtime sistem selama periode terakhir dan tentukan bahwa langkah-
langkah jangka pendek dan panjang yang memadai tersedia untuk perbaikan berkelanjutan.
15. Jika tersedia, dapatkan jadwal operasi aplikasi yang mencakup aplikasi keuangan dan
operasional utama dan tentukan bahwa perhatian yang memadai diberikan pada kontrol
internal aplikasi.
16. Saya melihat sistem palungan / administrator untuk menilai apakah orang ini
berpengetahuan luas dan terlatih dengan baik. Juga, jika sistem dikelola oleh konsultan
luar, tinjau kecukupan upaya dukungan sistem.
17. Saya meninjau sampel pengguna sistem dan menentukan apakah mereka puas dengan
kinerja sistem, termasuk waktu respons dan ketersediaan.
 dapat mendefinisikan sistem komputer besar dalam hal desain atau arsitektur internal
prosesor sentral. Manajemen dapat menentukan ukuran sistem komputer yang sama
dalam hal konfigurasi peralatan dan ukuran staf TI yang diperlukan untuk
mendukungnya. Beberapa auditor yang tidak terbiasa dengan sistem TI dapat
mengamati sistem yang lebih tua, atau yang sekarang disebut warisan, yang terletak di
dalam fasilitas yang aman dengan lantai yang dinaikkan, dan atas dasar itu akan
menyimpulkan bahwa itu harus besar. Ini khususnya benar jika pengalaman auditor
terbatas pada laptop kecil, perangkat desktop dan server, atau koneksi komputasi
awan.
Auditor internal sekali lagi tertarik pada ukuran sistem komputer untuk ditinjau
daripada yang sekarang karena dampaknya pada pendekatan audit internal dan
prosedur kontrol audit. Ini telah berubah dengan serbuan maju perkembangan
teknologi, dan tidak ada lagi hubungan langsung antara ukuran alat berat dan
kompleksitas audit. Namun demikian, beberapa kontrol yang diharapkan ditemukan
oleh audit internal dalam operasi pusat komputer yang sangat besar tidak perlu
diterapkan pada sistem komputer bisnis kecil yang dibahas pada bagian sebelumnya.
Misalnya, staf pemrograman teknis atau sistem, yang bertanggung jawab untuk
memantau kinerja dan memelihara sistem operasi komputer besar, sering kali tidak
diperlukan untuk sistem komputer kecil dan modern.

Karakteristik Sistem IT Besar

Sistem besar biasanya memiliki beberapa karakteristik umum, apakah mainframe IBM
klasik yang membutuhkan pendinginan air dingin atau beberapa prosesor server file
Unix yang saling berhubungan. Meskipun tidak semua karakteristik kontrol internal TI
dapat berlaku untuk setiap sistem komputer besar, berikut ini akan membantu auditor
internal memahami karakteristik sistem TI bisnis besar:
 Kontrol keamanan fisik. Pusat komputer besar dengan banyak server dan file
data yang signifikan biasanya terletak di ruangan dengan kontrol akses yang
dikunci dan tidak ada jendela di luar. Keamanan ini membantu melindungi
peralatan serta program dan data. Pintu yang terkunci ke ruang komputer
 mencegah orang yang tidak berwenang, baik karyawan maupun orang luar,
memasuki area tersebut untuk mengajukan pertanyaan yang mengganggu
operator atau menyebabkan kerusakan berbahaya.
Di masa lalu, sistem komputer skala besar pertama-tama membutuhkan
susunan pita penggerak magnetik yang luas, kemudian kartrid penyimpan yang
bersifat magnetis, dan sejumlah besar unit penyimpanan penggerak cakram
kepala-berputar. Saat ini, dengan kemampuan masif perangkat penyimpanan
yang murah dan miniatur, biasanya ada kebutuhan minimal bagi personel
operasi untuk memasang, memuat, atau melepas ke perpustakaan media
penyimpanan perangkat yang lebih tua ini.
Sementara semua operasi bisnis tunduk pada terorisme, kebakaran,
atau banjir, pusat komputer sistem besar memiliki kerentanan tertentu karena
peralatan tidak dapat dengan mudah menangani tekanan ini. Karena jenis dan
luasnya data yang diproses dalam sistem komputer skala besar modern,
operasi sistem harus ditempatkan di lokasi yang tidak mencolok dan dibangun
untuk meminimalkan paparan terhadap kebakaran, banjir, atau tindakan Tuhan
lainnya.
 Persyaratan pengendalian lingkungan. Sistem tenaga listrik khusus serta
sistem pendingin udara atau sistem pendingin air sering diperlukan karena
komponen listrik mini yang beroperasi dengan daya penuh menghasilkan panas
yang cukup besar. Karena kebutuhan khusus ini dan karena sistem TI terdiri
dari beberapa bagian peralatan yang dihubungkan oleh kabel komunikasi,
perangkat keras sistem sering terletak di ruangan khusus dengan kontrol
pemantauan lingkungan khusus dan lantai palsu yang menyediakan ruang
untuk kabel daya dan ventilasi. Sistem besar, rentan terhadap pemadaman
listrik atau fluktuasi, hampir selalu dilengkapi dengan catu daya darurat yang
dapat memperlancar fluktuasi daya atau menyediakan sumber daya darurat
untuk memungkinkan sistem komputer dimatikan dengan tertib.
Beberapa sistem mungkin didukung oleh generator independen untuk
memberikan daya selama periode yang diperpanjang jika terjadi pemadaman.
Kelemahan dalam pengendalian lingkungan berpotensi menyebabkan
kegagalan dalam pengoperasian aplikasi TI utama. Audit internal harus selalu
mengetahui prosedur pengendalian di bidang ini dan membuat rekomendasi
yang sesuai.
 Sistem operasi multitask. Hampir semua komputer menggunakan beberapa
jenis sistem operasi utama untuk mengontrol berbagai program yang dijalankan
oleh komputer dan tugas-tugas lain seperti membaca berbagai file dan folder
lain atau memasok data laporan atau fasilitas server cetak. Biasanya sistem
operasi ini dapat menjalankan banyak program secara paralel serta tugas-tugas
lain seperti mencetak. Sistem operasi multitask pada komputer besar harus
dikelola dan biasanya memerlukan personel khusus, yang disebut pemrogram
sistem.
 Kemampuan pemrograman in-house. Sementara perusahaan staf kecil
membeli sebagian besar aplikasi mereka dari vendor perangkat lunak atau
memiliki sistem mereka dipasok oleh staf kantor pusat perusahaan, perusahaan
dengan sistem komputer besar sering didukung oleh sistem in-house dan
departemen pemrograman mulai dari berbagai kelompok mungkin beberapa
ratusan karyawan atau lebih kepada orang lain dengan kemampuan
pemrograman in-house terbatas. Programmer juga berbeda. Sampai awal
1990-an, banyak yang menggunakan bahasa COBOL, tetapi programmer saat
ini hanya dapat mengembangkan parameter untuk paket perangkat lunak yang
dibeli khusus atau dapat melakukan beberapa pekerjaan kustom dalam bahasa
seperti C ++ atau Visual BASIC. Pemrogram internal hampir tidak pernah
menulis kontrol inventaris khusus atau aplikasi penggajian. Perusahaan besar
dengan pemrogramannya sendiri dan staf analisis sistem harus memiliki
metodologi pengembangan sistem yang cukup formal atau prosedur siklus
pengembangan sistem (SDLC) untuk mengembangkan dan
mengimplementasikan aplikasi baru. SDLC dibahas dalam Bab 22. Harus ada
file perpustakaan khusus untuk mengontrol program komputer serta
dokumentasi teknis yang mencakup pekerjaan programmer.
 Jaringan telekomunikasi yang luas. Hampir semua sistem modern memiliki
jaringan telekomunikasi yang luas, baik nirkabel maupun yang terhubung
dengan kabel, untuk mendukung beberapa terminal online yang berlokasi di
seluruh perusahaan dan terhubung baik secara langsung ke sistem komputer
pusat atau ke Internet. Jaringan mungkin juga memerlukan tenaga teknis
khusus dalam perusahaan IT untuk mengelola telekomunikasi.
 File yang sangat besar atau kritis. Meskipun suatu sistem TI mungkin agak
kecil dalam banyak hal, ia mungkin memiliki satu atau lebih aplikasi yang
memelihara data penting pada database yang sangat besar. Sementara file-file
 penting ini dulu terdiri dari banyak gulungan pita magnetik, sistem manajemen
basis data yang berorientasi pada disk atau hard drive digunakan sekarang.
Karena kekritisan basis data yang sedemikian besar, sistem TI — apa pun
konfigurasi perangkat kerasnya yang sebenarnya — mengambil karakteristik
sistem besar. Kebutuhan akan salinan cadangan dan integritas file penting
sangat penting untuk fungsi TI. Perusahaan harus memerlukan prosedur
pencadangan file yang kuat dan administrator database untuk membantu
memastikan keakuratan, integritas, dan kelengkapan database.
 Bagian kontrol input-output. Meskipun sama sekali tidak umum hari ini,
beberapa sistem pernah memiliki fungsi kontrol input-output untuk menerima
data input batch (seperti kaset yang dikirim dari sumber jarak jauh), untuk
mendistribusikan input apa pun, dan untuk menjadwalkan dan mengatur
pekerjaan produksi. Pada hari-hari awal IT, ketika sebagian besar pekerjaan
produksi dijalankan dalam mode batch, fungsi kontrol seperti itu sering
menyeimbangkan batch input ke output sistem dan menyelesaikan banyak
masalah. Saat ini, pengguna umumnya bertanggung jawab atas data mereka
sendiri, dikirimkan melalui terminal di area pengguna dengan output yang
dikirimkan kembali kepada mereka, dan kontrol harus dibangun ke dalam
sistem yang menerima atau mengirimkan data ini.

Karakteristik ini, meskipun tidak spesifik hanya untuk sistem warisan besar,
memberikan beberapa panduan untuk membantu menentukan apakah auditor
internal bekerja dengan lingkungan sistem TI yang besar. Ada banyak variasi
dalam apa yang dapat didefinisikan sebagai sistem komputer besar atau kecil.
Sementara tujuan kontrol audit internal pada dasarnya akan tetap sama untuk
keduanya, prosedur kontrol akan berbeda. Teknik untuk mengaudit sistem kecil
telah dibahas sebelumnya di bagian 19.2. Jika auditor internal memiliki keraguan
tentang apakah tinjauan TI harus disesuaikan dengan sistem besar atau kecil,
pendekatan teraman adalah mempertimbangkan sistem untuk ditinjau sebagai
besar, kompleks.

19.7 TINJAUAN PENGENDALIAN INTERNAL DARI MAINFRAME CLASSIC ATAU

SISTEM IT LEGACY
Sistem IT besar biasanya memiliki karakteristik kontrol unik mereka sendiri.
Meskipun banyak yang telah dipublikasikan tentang sistem klien-server dan desktop
 hari ini, perubahan signifikan juga telah terjadi selama bertahun-tahun untuk operasi
komputer mainframe yang besar. Untuk auditor internal, masalah pengendalian internal
yang dulunya sering menjadi masalah audit sekarang hampir menjadi bagian yang
diterima dari prosedur operasi sistem besar saat ini. Lain, masalah kontrol yang lebih
baru sekarang telah menjadi bagian dari proses peninjauan audit internal. Pada hari-
hari awal sistem mainframe klasik yang lebih tua, masalah audit internal yang umum
adalah bahwa operator komputer tidak boleh memiliki akses ke program operasi
komputer atau pengetahuan untuk mengubahnya. Alasannya adalah bahwa jika
programmer dapat mengoperasikan peralatan, mereka dapat memodifikasi atau
menjalankan program yang tidak sah. Daftar periksa dan program audit diterbitkan —
termasuk dalam edisi awal buku ini — yang mengarahkan auditor internal untuk
membuktikan bahwa, di antara hal-hal lain, operator komputer tidak menjalankan
program dan pemrogram tidak mengoperasikan peralatan. Meskipun konfigurasi
sistem dan prosedur organisasi mungkin sangat beragam saat ini karena perbedaan
jenis dan usia perangkat keras dan perangkat lunak dalam area operasi sistem besar
modern, Gambar 19.3 membahas beberapa area yang harus dipertimbangkan oleh
auditor internal untuk mengumpulkan beberapa basis informasi mengenai operasi dan
prosedur kontrol dalam operasi pusat data yang besar.
Tidak ada konfigurasi perangkat keras yang khas untuk perusahaan IT besar
dan modern. Seringkali auditor internal yang tidak berpengalaman akan diberikan tur
melalui ruangan yang penuh dengan prosesor pusat, server, perangkat penyimpanan,
dan peralatan lainnya dan dapat menyelesaikan tur dengan sedikit pemahaman
tentang apa yang dilihat. Karena miniaturisasi

MEMPERLIHATKAN 19.3 Sistem Informasi Survei Besar Pengendalian Umum IT Kontrol Besar
1. Dapatkan informasi dasar tentang lingkungan melalui diskusi eksplorasi awal dengan
manajemen sistem informasi (SI).
2. Tinjau bagan organisasi yang diterbitkan untuk menentukan bahwa ada pemisahan fungsi
yang tepat antara operasi, sistem, dan manajemen basis data. Diskusikan potensi konflik
dengan manajemen IS.
3. Dapatkan uraian tugas personel IS utama dan tinjau dokumentasi personel ini untuk kualifikasi,
definisi tugas, dan tanggung jawab yang memadai dan sesuai. Pastikan bahwa keamanan dan
kontrol akuntabilitas ditugaskan secara tepat kepada personil kunci.
4. Berdasarkan diskusi dalam manajemen baik di dalam maupun di luar organisasi SI, nilai
apakah struktur organisasi selaras dengan strategi bisnis untuk memastikan pemberian
layanan SI yang diharapkan.
5. Tinjau kebijakan IS dan prosedur yang dipilih untuk kelengkapan dan relevansi dengan
penekanan khusus pada keamanan, perencanaan kontinuitas bisnis, operasi, dan
pengembangan sistem baru.
6. Tanyakan apakah tanggung jawab telah diberikan untuk menjaga kebijakan dan prosedur
tetap terkini, untuk mendidik / mengomunikasikannya kepada anggota staf, dan untuk
memantau kepatuhan terhadapnya.
10. Menentukan bahwa ada proses untuk membuat perubahan pada program aplikasi dalam
produksi, termasuk pengujian dan penandatanganan dokumentasi, dan persetujuan formal untuk
mengimplementasikan perubahan menjadi produksi.
11. Memastikan bahwa tanggung jawab untuk keamanan fisik dan logis telah dibagikan secara tepat
dan bahwa ada prosedur terdokumentasi yang sesuai.
12. Tinjau prosedur yang berlaku untuk mengoperasikan dan memelihara jaringan bersama dengan
router yang terpasang, dalam hal konfigurasi perangkat dan perubahan parameter perangkat
lunak, dan memastikan bahwa prosedur untuk mengalokasikan dan memelihara konfigurasi
jaringan dilakukan secara terjadwal dan sesuai manajemen perubahan.
13. Tinjau rencana pemulihan bencana / kesinambungan untuk memastikan bahwa rencana rinci
untuk pemulihan operasi telah disiapkan, bahwa rencana tersebut didokumentasikan,
dikomunikasikan kepada personel yang tepat, dan diuji dengan benar secara berkala.
14. Tinjau anggaran IS dan biaya aktual serta kinerja terhadap yang diukur untuk menilai kinerja
keuangan. Diskusikan alasan perbedaan apa pun.

komponen elektronik, pusat komputer modern membutuhkan ruang jauh lebih sedikit
daripada yang dibutuhkan sebelumnya. Sebagai contoh, sistem mainframe legacy IBM
yang besar hingga pertengahan 1990-an sering membutuhkan sistem pendingin air
yang membutuhkan pipa ledeng yang luas. Kemajuan teknologi telah menghilangkan
kebutuhan akan banyak dari sistem yang rumit, besar, dan mahal ini.
Selain itu, ada perubahan signifikan dalam desain banyak komponen perangkat
TI. Drive tape magnetik yang dulu umum, misalnya, kini sudah tidak ada lagi, dan
bahkan kartrid yang kemudian menjadi lebih umum sekarang sering dikonfigurasi
sebagai drive solid-state kecil. Disk drive masih digunakan tetapi sering dikonfigurasi
 sebagai array disk kecil dengan data yang jauh lebih besar kapasitas penyimpanan.
Pencetakan hasil masih dilakukan pada printer laser berkecepatan tinggi jarak jauh,
tetapi perusahaan semakin berusaha untuk pergi tanpa kertas dan
mengkomunikasikan laporan sebagai file digital. Auditor internal harus memahami jenis
peralatan TI yang digunakan dengan meminta bagan konfigurasi perangkat keras dari
manajemen operasi. Walaupun audit internal biasanya tidak dalam posisi untuk
menentukan, misalnya, model disk drive yang benar, bagan tersebut akan
menunjukkan bahwa manajemen telah melakukan perencanaan dalam konfigurasi
perangkat keras komputer mereka. Grafik ini sering diisi dengan nomor model dan
bukan penjelasan dari peralatan. Auditor internal harus selalu bertanya tentang sifat
peralatan ini.
Sementara jumlah dan jenis perangkat penyimpanan dan peralatan lainnya
akan bervariasi, auditor internal dapat berharap untuk menemukan karakteristik yang
sama di semua fasilitas operasi. Mereka harus membantu audit internal untuk
mengembangkan prosedur untuk menguji kontrol yang sesuai. Ketika auditor pertama
kali mulai meninjau kontrol umum TI, mereka sering mencari hal-hal seperti pintu ruang
komputer yang terkunci, alat pemadam kebakaran, dan kontrol batch yang tepat.
Kontrol seperti itu sekarang ada sebagai hal yang biasa di pusat-pusat komputer
besar. Sementara audit internal harus selalu mengingat pengendalian ini, tujuan dan
prosedur pengendalian umum lainnya juga harus dipertimbangkan.

Perangkat Lunak Sistem Operasi

Sistem komputer bisnis awal hanya memiliki sedikit lebih dari satu program master
dasar — yang kemudian disebut sistem operasi — untuk memuat dan menjadwalkan
program aplikasi, dengan program aplikasi yang menangani fungsi utilitas mereka
sendiri, seperti memeriksa atau menyortir label file rekaman. data. Komputer IBM 1401
pada pertengahan 1960-an hanya memiliki 8 KB (8.000 byte) memori untuk memuat
sistem operasinya. Sistem operasi dasar 1401 tidak lebih dari memuat program dan
berkomunikasi dengan perangkat input dan output. Perangkat lunak sistem operasi
modern jauh lebih kompleks daripada sistem lama dan mampu menangani banyak
fungsi pengguna dan sistem. Pengguna biasa dengan sistem laptop saat ini dapat
kewalahan dengan kompleksitas sistem operasi komputer itu, apakah itu Microsoft
Windows atau Apple OS Mac.
Sistem operasi TI adalah alat perangkat lunak dasar yang menyediakan
antarmuka antara pengguna sistem, program aplikasi, dan perangkat keras TI lainnya.
Selain sistem operasi dasar, auditor internal akan menemukan berbagai monitor dan
pengontrol, termasuk perangkat lunak khusus untuk menjadwalkan pekerjaan atau
menangani keamanan logis. Perangkat lunak sistem operasi mencakup sistem operasi
pusat, program kontrol, berbagai alat bantu pemrograman, dan perangkat lunak
pendukung terkait aplikasi. Auditor internal harus mengembangkan pemahaman umum
tentang berbagai jenis perangkat lunak sistem operasi yang diinstal yang mungkin ada
pada sistem tertentu serta risiko pengendalian tingkat tinggi, termasuk:
 Sistem operasi pusat. Sistem operasi mengawasi pemrosesan semua sumber
daya dan program sistem. Contohnya sistem operasi MVS besar IBM. Karena
sistem operasi ini sering sangat erat kaitannya dengan perangkat keras mereka
mengontrol, sistem operasi secara tradisional telah unik untuk peralatan vendor
komputer. Hari ini kecenderungannya adalah menuju sistem operasi yang
umum atau terbuka. Sistem operasi Unix, misalnya, telah diimplementasikan
pada hampir semua ukuran dan model sistem komputer. Meskipun kurang
umum pada mainframe besar, Unix ditemukan pada banyak komputer kecil
hingga menengah dan merupakan pengontrol utama untuk sistem Internet.
Unix menyediakan fungsi antarmuka pengguna yang umum dengan perangkat
keras tempat ia diinstal. Ada versi lain dari Unix yang sedikit berbeda. Selain
itu, sistem operasi open source Linux menjadi semakin umum saat ini.
 Monitor sistem. Berbagai produk perangkat lunak pendukung sistem operasi
dasar membantu menjadwalkan pekerjaan, memantau aktivitas sistem, dan
membantu menyelesaikan masalah operator atau kesalahan sistem. Produk-
produk ini sangat terkait erat dengan sistem operasi dasar tetapi biasanya dijual
dan diinstal secara terpisah. Monitor menyediakan sinyal internal untuk fungsi
sistem operasi lain — yaitu, sinyal tersebut mirip dengan sinyal semafor yang
pernah ditemukan di jalur kereta api. Setelah kereta memasuki bentangan trek,
monitor kontrol mendeteksi kereta dan menaikkan berbagai semafor untuk
memberi sinyal pada kereta lain yang sudah ada di trek. Beberapa monitor
hanya mencatat aktivitas sistem operasi untuk tujuan historis. Contohnya
adalah utilitas fasilitas manajemen sistem (SMF) IBM tentang apa yang
sekarang dikenal sebagai Sistem z IBM. Fasilitas perangkat lunak SMF
memonitor hampir semua kegiatan sistem, termasuk program mana yang
diproses dan berbagai file disk yang digunakan. Memori sistem operasi adalah
contoh lain dari monitor. Di sini, isi dari memori sistem yang terpengaruh
dilaporkan ketika suatu program masuk ke status kesalahan.
  Pengontrol jaringan dan monitor teleproses. Ini adalah program sistem
operasi khusus yang mengawasi dan mengontrol transmisi antara sistem
komputer host dan perangkat periferal. Perangkat ini memungkinkan aplikasi
memproses pada sistem komputer host untuk berkomunikasi dengan beberapa
koneksi jaringan. Program perangkat lunak yang mendukung interaksi antara
terminal online dan komputer host juga termasuk dalam kelas perangkat lunak
operasi ini. Monitor online IBM, CICS (Sistem Kontrol Informasi Pelanggan) —
sering disebut “tendangan” - memungkinkan terminal pengguna untuk
mengakses dan memproses program online. Auditor internal mungkin
menemukan nama CICS agak penasaran, karena umumnya digunakan untuk
lebih dari aplikasi informasi pelanggan. CICS pada awalnya dikembangkan oleh
IBM pada masa-masa awal komputer seri 360 lama untuk pelanggan tertentu
yang membutuhkan metode untuk mengakses program secara online. IBM
tidak memiliki produk perangkat lunak online seperti itu pada saat itu, walaupun
persaingan sistem komputer mainframe-nya terjadi. Jadi ia menciptakan CICS
sebagai produk khusus yang telah menjadi produk kontrol pemrosesan dasar
online; banyak yang telah lupa apa arti sebenarnya dari singkatan CICS.

Semua nama atau akronim khusus ini dapat menyebabkan auditor mengalami
beberapa masalah komunikasi. Pengguna sistem komputer mungkin tahu apa yang
dilakukan produk tetapi mungkin lupa apa singkatan sebenarnya. Selama spesialis
sistem dan auditor memahami fungsi-fungsi produk perangkat lunak, ada sedikit
kebutuhan untuk khawatir tentang arti spesifik akronim. Auditor internal tidak boleh
berkecil hati oleh bahasa asing ini istilah dan nama perangkat lunak komputer khusus.
Ketika personel teknis TI berbicara dalam techno-jargon mereka sendiri, seorang
auditor internal harus selalu meminta klarifikasi ketika tidak pasti.

19.8 LEGASI SISTEM BESAR TINJAUAN KONTROL UMUM

Dalam lingkungan TI tradisional yang lebih tua, area pengoperasian komputer sering
kali merupakan area utama audit internal yang menjadi perhatian pengendalian
internal. Pada masa itu, operator komputer memiliki kekuatan yang cukup besar untuk
membuat perubahan atau mem-bypass kontrol sistem seperti mengesampingkan
kontrol label file data, membuat perubahan pada urutan pemrosesan program, atau
memasukkan instruksi program tanpa izin ke dalam aplikasi produksi. Sementara ini
masih mungkin hari ini, kompleksitas sistem operasi komputer yang besar dan volume
pekerjaan yang melewati pusat operasi TI modern membuat tindakan yang tidak sah
tersebut menjadi sulit. Audit internal memiliki risiko lebih besar untuk dipertimbangkan.
Banyak rekomendasi audit internal yang biasa dilakukan operasi TI untuk
perbaikan kontrol tidak lagi layak hari ini. Misalnya, komputer lawas pusat data bisnis
yang lebih lama memiliki printer konsol yang terpasang untuk merekam perintah
operator, dan auditor internal secara tradisional merekomendasikan agar log konsol ini
ditinjau secara berkala. Log sering diabaikan tetapi berguna untuk melacak aktivitas
operator yang tidak pantas. Saat ini aktivitas konsol ini direkam ke file log, tetapi
volume semata-mata dari data tersebut membuat tinjauan manusia secara berkala
atas laporan log konsol semuanya sama sekali tidak realistis; alat dan kontrol lain
tersedia untuk membantu auditor internal memahami kontrol operasi. Audit internal
pada awalnya harus mendapatkan pemahaman tentang perusahaan sistem informasi,
prosedur kontrol yang ditetapkan, dan tugas dan tanggung jawab khusus.
Langkah pertama yang penting dalam tinjauan audit internal operasi TI kontrol
umum sistem besar adalah dengan jelas mendefinisikan tujuan ulasan itu. Terlalu
sering, anggota komite audit atau manajemen senior dapat meminta audit internal
untuk "meninjau kontrol sistem komputer" di beberapa pusat data perusahaan.
Permintaan itu mungkin didasarkan pada kontrol TI seperti yang pernah ada di sistem
yang lebih lama. Auditor internal harus mempertimbangkan pertanyaan-pertanyaan
berikut ketika merencanakan tinjauan pusat data seperti itu:

 Apa tujuan dari tinjauan operasi sistem informasi?

 Kontrol dan prosedur spesifik apa yang diharapkan ada?
 Bagaimana bukti dikumpulkan untuk menentukan apakah kontrol berfungsi?

Berdasarkan hasil dari latihan ini, audit internal harus mengembangkan

serangkaian tujuan kontrol yang secara spesifik dirancang untuk tinjauan yang
direncanakan daripada hanya menggunakan serangkaian standar pertanyaan kontrol
internal. Apakah IT atau ulasan lain, tujuan audit internal yang diidentifikasi tergantung
pada tujuan tinjauan.
Jika manajemen telah meminta peninjauan atas biaya dan efisiensi operasi
pusat data, misalnya, prosedur audit internal mungkin mencakup bidang-bidang seperti
tolak bayar dan sistem penjadwalan pekerjaan. Meskipun ulasan besar kontrol sistem
TI dapat memiliki berbagai tujuan, itu sering akan menjadi salah satu dari empat jenis
ulasan berikut.
 1. Tinjauan awal dari kontrol umum TI. Ini adalah jenis tinjauan yang kadang-
kadang disebut auditor luar sebagai survei pendahuluan atau penilaian risiko
pengendalian. Tujuannya adalah untuk mendapatkan pemahaman umum atau
gambaran umum dari lingkungan kontrol TI. Audit internal mengajukan pertanyaan,
mengamati operasi, dan meninjau dokumentasi, tetapi biasanya hanya ada pengujian
yang sangat terbatas, jika ada. Sebagai contoh, audit internal mungkin menanyakan
tentang prosedur untuk memperbarui perpustakaan program produksi dan mungkin
meninjau formulir yang digunakan untuk proses persetujuan. Namun, auditor mungkin
tidak akan memilih sampel program di perpustakaan produksi untuk menentukan
apakah mereka telah mengikuti prosedur pembaruan perpustakaan yang tepat.
Tinjauan pendahuluan dapat membantu menentukan kebutuhan untuk tinjauan
kontrol umum yang lebih rinci atau penilaian risiko kontrol yang diperluas di kemudian
hari, atau dapat mengumpulkan informasi kontrol awal untuk tinjauan aplikasi tertentu.
Jenis tinjauan terbatas dalam ruang lingkup dan mungkin tidak mencakup semua
aspek dari perusahaan IT. Beberapa area di mana tinjauan pendahuluan akan sesuai
mungkin termasuk tinjauan kontrol pendahuluan operasi TI pada akuisisi baru atau
tinjauan tindak lanjut setelah tinjauan kontrol umum yang sangat rinci dari periode
sebelumnya; review di sini akan menekankan perubahan dalam prosedur kontrol serta
tindakan yang diambil atas rekomendasi audit sebelumnya.
Meskipun mungkin ada banyak perubahan berdasarkan tujuan spesifik review,
Pameran 19.4 menguraikan langkah-langkah untuk survei pendahuluan kontrol umum
TI. Langkah-langkah ini harus memandu auditor internal untuk mendapatkan informasi
tentang struktur umum operasi TI, bagaimana merencanakan dan mengatur sumber
daya, alat pelaporan manajemennya, dan prosedur untuk keamanan dan perencanaan
kontinjensi. Langkah-langkah audit ini tidak akan membantu dalam memahami jenis
aplikasi yang ada, tetapi akan menilai bagaimana fungsi TI diatur dan dikelola.
2. Tinjauan kontrol umum terperinci dari operasi TI. Tinjauan komprehensif
dan terperinci tentang sistem besar TI kontrol umum harus mencakup semua aspek
operasi TI, termasuk pemrograman sistem, router dan kontrol telekomunikasi,
perangkat firewall, dan administrasi penyimpanan. Tinjauan kontrol umum yang
terperinci, termasuk pengujian kontrol, seringkali memerlukan audit internal untuk
menghabiskan waktu kerja lapangan yang cukup baik dalam operasi TI dan fungsi
pengembangan sistem. Sementara tinjauan pendahuluan kadang-kadang dapat
dilakukan oleh auditor yang kurang berpengalaman yang mengembangkan
keterampilan audit TI, tinjauan kontrol umum yang rinci paling baik dilakukan oleh
anggota staf audit yang lebih senior dengan pemahaman yang baik tentang kontrol dan
prosedur TI. Berdasarkan tinjauan awal operasi TI awal, audit internal harus
mengembangkan pemahaman umum tentang prosedur pengendalian TI yang ada.
Pertanyaan yang mungkin diajukan oleh audit internal meliputi:
 Bagaimana jadwal kerja? Beberapa operator komputer sistem besar
melakukan lebih dari memulai pekerjaan dari file antrian pekerjaan
produksi, sementara yang lain memiliki otoritas yang cukup besar dalam
memutuskan pekerjaan yang akan dijalankan. Dalam situasi terakhir, audit
internal mungkin ingin menghabiskan waktu meninjau laporan log kontrol
dan instruksi operator. Jika prosedur ini telah diotomatisasi, audit internal
mungkin ingin mempertimbangkan tinjauan khusus bidang perangkat lunak
kontrol produksi.
 Bagaimana cara mengelola media penyimpanan? Alat otomatis sering
digunakan di sini. Selain itu, beberapa operasi memiliki fasilitas
perpustakaan terpisah di mana kartrid media produksi dipasang. Bahkan
ketika perangkat lunak telah diinstal, operator komputer sering dapat
melewati kontrol label dan memasukkan file yang salah ke lingkungan
produksi.
 Apa jenis prosedur atau instruksi operator yang digunakan?
Dokumentasi operasi sistem besar dapat mengambil berbagai format; audit
internal harus memiliki pemahaman umum tentang format dan konten
dokumentasi ini untuk membantu dalam merancang tes audit spesifik.
 Bagaimana pekerjaan dimulai dan bagaimana ia mengalir melalui
operasi? Dalam banyak operasi sistem TI besar, produksi dimulai melalui
terminal pengguna entri pekerjaan jarak jauh. Di sisi lain, fungsi kontrol
produksi menyalurkan semua data input yang diperlukan untuk operasi alat
berat. Beberapa fungsi bergantung pada pengguna untuk menginisiasi
sebagian besar input melalui terminal online mereka. Jenis dan sifat
pengujian audit internal akan tergantung pada prosedur adat.

Ide dasarnya adalah untuk audit internal untuk memahami bagaimana fungsi
operasi TI di pusat data ditinjau. Auditor internal yang efektif harus melalui serangkaian
jenis pertanyaan ini sebelum setiap tinjauan. Fungsi operasi sistem besar dapat
memasang prosedur baru dari waktu ke waktu, mengubah atau menambah
kompleksitas pada struktur kontrol. Prosedur audit yang akan dilakukan dalam tinjauan
terperinci dari kontrol umum untuk sistem komputer lama dapat luas, tergantung pada
ukuran dan ruang lingkup audit. Tampilan 19.4 berisi serangkaian tujuan kontrol
terbatas untuk jenis tinjauan sistem besar ini.

MEMPERLIHATKAN 19.4 Tujuan Tinjauan Kontrol Sistem Besar TI

1. Menentukan bahwa peralatan TI terletak di fasilitas yang aman dan terkendali lingkungan.
2. Diskusikan prosedur pengendalian fisik dan lingkungan dengan manajemen sistem
informasi untuk menentukan kebijakan saat ini, perubahan besar, dan rencana masa depan
lainnya.
3. Jelajahi fasilitas server ruang komputer dan amati kekuatan dan kelemahan keamanan
fisik, termasuk:
a. . Adanya mekanisme penguncian untuk membatasi akses ruang komputer hanya
untuk individu yang berwenang
b. Penempatan dinding perimeter ruang komputer dan jendela untuk membatasi
akses
c. Lokasi transformator daya, unit pendingin air jika sesuai, dan unit pendingin udara
untuk memberikan perlindungan yang tepat

d. Lokasi umum fasilitas ruang komputer di dalam keseluruhan bangunan untuk

meminimalkan lalu lintas
e. Keberadaan alat pendeteksi kebakaran, termasuk detektor panas dan asap yang
dikendalikan oleh zona dan alat pemadam lokal
4. Tinjau suhu ruang komputer, kelembaban, dan kontrol lingkungan lainnya dan nilai
kecukupannya.
5. Tinjau catatan pemeliharaan secara singkat untuk memastikan bahwa kontrol fisik dan
lingkungan secara teratur diperiksa dan dipelihara.
6. Pemrosesan produksi harus dijadwalkan untuk mempromosikan penggunaan peralatan
komputer secara efisien sesuai dengan persyaratan pengguna sistem. Melalui wawancara
dengan manajemen operasi, kembangkan pemahaman keseluruhan tentang tuntutan
pemrosesan komputer, termasuk pekerjaan produksi online dan lainnya serta komputasi
sosial pengguna akhir.
7. Juga melalui wawancara, deskripsikan jaringan telekomunikasi di sekitar sistem komputer,
termasuk router, koneksi ke workstation, pusat komputer, dan luar.
8. Tinjau prosedur untuk menjadwalkan pekerjaan produksi reguler termasuk penggunaan alat
penjadwalan pekerjaan otomatis.
9. Sesuaikan sejumlah pekerjaan produksi terjadwal dengan waktu penyelesaian aktual untuk
menentukan apakah jadwal aktual diikuti.
10. Menentukan bahwa kelas pekerjaan sistem operasi atau kode prioritas digunakan untuk
memberikan prioritas yang tepat untuk pekerjaan produksi kritis, dan mengevaluasi
prosedur untuk pekerjaan terburu-buru atau menjalankan kembali.
11. Tinjau standar dokumentasi untuk aplikasi produksi untuk menentukan bahwa mereka
memberikan informasi kepada operator mengenai:
a. Operasi normal, termasuk instruksi untuk formulir khusus, file pita, dan laporan
disposisi
b. Aplikasi restart dan prosedur pemulihan
18. Pilih beberapa file program darurat yang terdokumentasi dan tentukan bahwa perubahan
yang diperlukan ditambahkan ke perpustakaan pemrosesan produksi dan
didokumentasikan.
19. Menentukan bahwa sistem otomatis tersedia untuk mencatat semua aktivitas sistem
komputer, termasuk semua pekerjaan dan program yang dijalankan, setiap tayangan ulang,
pemutusan yang tidak normal, atau perintah dan data operator yang dimasukkan melalui
konsol sistem.
20. Menentukan bahwa log aktivitas komputer setidaknya ditinjau tingkat tinggi secara berkala,
bahwa situasi pengecualian diselidiki, dan bahwa hasil investigasi didokumentasikan.
21. Menentukan bahwa file yang dihasilkan dari monitor log sistem operasi komputer
dipertahankan cukup lama untuk memungkinkan penyelidikan aktivitas yang tidak biasa.
22. Tinjau prosedur untuk mencatat masalah untuk menentukan bahwa semua kondisi operasi
perangkat lunak dan perangkat keras yang abnormal didokumentasikan.
23. Menentukan bahwa ada jadwal untuk pengajuan file kumpulan input kritis dan prosedur
yang ada untuk menindaklanjuti data yang hilang.
24. Tinjau prosedur untuk melarang input atau akses tidak sah ke file dan program produksi.
25. Tinjau sampel terbatas aplikasi batch produksi untuk menentukan bahwa teknik kontrol
sistem yang tepat digunakan.
26. Tentukan apakah pengguna atau personel sistem informasi bertanggung jawab untuk
meninjau kontrol output dan menilai apakah review kontrol tersebut dilakukan.
27. Menilai prosedur untuk meninjau laporan hasil yang didistribusikan untuk menentukan
apakah laporan tersebut lengkap.
 3. Ulasan khusus atau berorientasi pada lingkup terbatas. Karena
permintaan manajemen dan risiko yang dirasakan, auditor sering melakukan tinjauan
terbatas atas area khusus dalam fungsi TI secara keseluruhan. Tinjauan khusus ini
dapat dibatasi pada satu fungsi, seperti administrasi basis data, atau bidang khusus,
seperti distribusi laporan keluaran. Seringkali, manajemen akan meminta audit internal
melakukan jenis tinjauan ini karena beberapa masalah yang teridentifikasi, seperti
pelanggaran keamanan yang dipublikasikan dengan baik.
Audit atas area operasi IT yang sangat terspesialisasi atau teknis sering
membutuhkan kreativitas auditor yang cukup besar dalam merencanakan pekerjaan.
Manajemen mungkin khawatir tentang ekuitas sistem pengembalian komputer dan
dapat meminta audit internal untuk melihatnya. Akan ada kebutuhan untuk
mendapatkan pemahaman umum tentang sistem yang digunakan, menghabiskan
waktu merencanakan prosedur tambahan dan pengujian yang akan dilakukan, dan
kemudian kembali ke pengujian yang sebenarnya.
Karena TI semakin kompleks dan penting bagi perusahaan, auditor internal
dapat berharap untuk melakukan lebih banyak ulasan khusus dan terbatas ini. Dengan
fungsi TI sebagai sumber daya utama di banyak perusahaan, mungkin tidak pantas
untuk mencoba meninjau semua kontrol umum TI di semua bidang operasional
sebagai satu ulasan terperinci tunggal. Ini akan sama seperti jika audit internal
berusaha untuk melakukan tinjauan "manufaktur" di lingkungan pabrik utama. Daripada
mencakup semua fungsi manufaktur, audit internal mungkin meninjau kontrol produksi
satu tahun dan menerima dan inspeksi berikutnya, dan akhirnya mencakup sebagian
besar fungsi yang signifikan. Untuk tinjauan khusus pada area kontrol TI tertentu,
seperti manajemen perpustakaan media memori, audit internal harus memperluas
prosedur yang dikembangkan untuk tinjauan kontrol umum di area itu dan
menambahkan tes audit tambahan yang diperlukan.
4. Tinjauan untuk menilai kepatuhan terhadap hukum atau peraturan.
Salah satu tujuan utama pengendalian internal, sebagaimana dibahas dalam Bab 3
tentang dasar-dasar pengendalian internal COSO, adalah kepatuhan terhadap hukum
dan peraturan. Auditor internal harus selalu mengetahui tujuan di bidang ini dan
memasukkan tes yang sesuai dalam ulasan mereka. Auditor yang bekerja dengan
lembaga pemerintah atau di perusahaan yang melakukan kontrak pemerintah yang
luas sering kali diminta untuk melakukan audit kepatuhan terkait TI untuk menentukan
 apakah undang-undang dan peraturan yang tepat diikuti. Ini akan sangat berbeda dari
agen ke agen dan dari satu divisi politik ke yang lain.
Tinjauan TI terkait kepatuhan seringkali dapat digabungkan dengan tinjauan
kontrol umum awal atau terperinci, tetapi auditor internal harus mengetahui prosedur
dan peraturan yang relevan, seperti yang diterbitkan oleh lembaga pemerintah yang
membutuhkan audit. Sebagian besar lembaga pemeriksaan bank, misalnya, telah
menerbitkan pedoman kendali TI. Ketika beroperasi dalam lingkungan seperti ini,
auditor internal harus mengetahui lingkungan peraturan serta prosedur apa pun yang
dipublikasikan.

19.9 DUKUNGAN LAYANAN DAN PENGIRIMAN INFRASTRUKTUR PRAKTEK

TERBAIK
Seperti yang didefinisikan sebelumnya, ITIL® adalah singkatan dari
Perpustakaan Infrastruktur Teknologi Informasi, seperangkat praktik terbaik pertama
yang dikembangkan pada tahun 1980-an oleh Kantor Pemerintah Inggris untuk
Perdagangan Pemerintah (OGC) - yang sebelumnya disebut Central Computer and
Telecommunications Agency. Ini adalah kumpulan praktik-praktik terbaik vendor /
pemasok independen yang telah dikenal luas dalam operasi TI, pertama di Inggris,
diikuti oleh Uni Eropa, kemudian di Kanada dan Australia, dan sekarang semakin
meningkat di Amerika Serikat. ITIL® adalah kerangka kerja terperinci dari praktik
terbaik TI yang signifikan, dengan daftar periksa, tugas, prosedur, dan tanggung jawab
yang komprehensif yang dirancang untuk disesuaikan dengan organisasi TI mana pun.
Membagi proses utama antara yang mencakup pengiriman layanan TI dan yang untuk
dukungan layanan, ITIL® telah menjadi standar de facto untuk menggambarkan
banyak proses mendasar dalam manajemen layanan TI, seperti konfigurasi atau
manajemen perubahan.
ITIL® adalah "perpustakaan" formal publikasi teknis yang diterbitkan oleh OGC
Inggris.2 Publikasi dan isinya dikontrol ketat, mirip dengan publikasi standar
internasional Organisasi Internasional untuk Standardisasi (ISO) yang dibahas dalam
Bab 33. Auditor internal harus mengetahui tentang keberadaan ITIL® dan harus
menanyakan fungsi TI mereka berapa banyak mereka telah memeluk atau
mengadopsi praktik terbaik ITIL®. Maksud kami di sini bukan untuk memberikan
deskripsi terperinci tentang komponen-komponen ITIL® tetapi untuk memberikan
pemahaman tingkat tinggi kepada beberapa auditor tentang elemen-elemennya.
Pengetahuan umum tentang ITIL® akan memungkinkan auditor internal untuk lebih
memahami beberapa proses TI utama dan membuat rekomendasi yang lebih efektif
ketika mereka meninjau kontrol umum TI.
Proses ITIL® mencakup apa yang sering kita sebut infrastruktur TI — proses
pendukung yang memungkinkan aplikasi TI berfungsi dan memberikan hasilnya
kepada pengguna sistem. Terlalu sering, auditor internal memusatkan perhatian
mereka pada sisi pengembangan aplikasi TI dan mengabaikan pemberian layanan
pendukung yang penting dan mendukung proses TI. Suatu perusahaan dapat
melakukan upaya besar-besaran, misalnya, untuk membangun dan menerapkan
sistem perkiraan anggaran baru, tetapi aplikasi tersebut akan bernilai kecil kecuali jika
ada proses yang baik di tempat, seperti manajemen masalah dan kejadian, untuk
memungkinkan pengguna sistem melaporkan kesulitan sistem. Juga dibutuhkan
kapasitas dan ketersediaan proses yang baik untuk memungkinkan aplikasi baru
berjalan seperti yang diharapkan. Semua proses ITIL® ini adalah bagian dari apa yang
disebut infrastruktur TI, dan aplikasi yang dirancang dengan baik dan dikontrol dengan
baik memiliki nilai yang kecil bagi penggunanya tanpa dukungan layanan dan proses
pengiriman yang kuat. Auditor internal harus memiliki pemahaman yang baik tentang
proses perusahaan ini dan kemudian mengembangkan tes kontrol yang sesuai. Ini
mungkin telah tercakup dalam tinjauan kontrol umum TI, dan ITIL® menyediakan
model praktik terbaik umum yang baik untuk diikuti.
Walaupun mereka telah menjadi sangat umum di tempat lain di dunia, proses
ITIL® sekarang diakui secara luas di Amerika Serikat dan belum diakui secara
memadai oleh auditor internal. Bagian berikut akan memberikan tinjauan umum
tentang beberapa proses ITIL® yang penting bagi auditor internal, termasuk bidang-
bidang seperti manajemen kapasitas atau tingkat layanan. Ini harus memberi auditor
internal beberapa pedoman tentang bagaimana fungsi TI, seperti help desk, harus
menyediakan area untuk perbaikan kontrol internal di area proses TI yang sangat
penting ini.
Proses ITIL® secara tradisional terpecah antara yang mencakup apa yang
didefinisikan ITIL® sebagai dukungan layanan dan yang untuk pengiriman layanan.
Proses dukungan layanan membantu membuat aplikasi TI beroperasi secara efisien
dan memuaskan pelanggan, sementara proses pengiriman layanan meningkatkan
 efisiensi dan kinerja elemen infrastruktur TI. Ada lima proses praktik terbaik dukungan
layanan ITIL®, mulai dari manajemen rilis, untuk menempatkan proses dalam produksi,
hingga manajemen insiden, untuk pelaporan masalah atau peristiwa TI secara teratur.
Proses dukungan layanan ITIL mencakup praktik-praktik yang baik untuk setiap
perusahaan IT, baik itu operasi terpusat yang menggunakan sistem mainframe legacy
klasik terutama sebagai titik kontrol pusat TI-nya, hingga operasi server-klien yang
sangat terdistribusi. Karena banyak variasi yang dimungkinkan dalam fungsi operasi
TI, ITIL® tidak meresepkan rincian "bagaimana" untuk mengimplementasikan proses
dukungan layanan seperti konfigurasi atau manajemen perubahan. Sebaliknya, ini
menyarankan praktik dan cara yang baik untuk mengelola input dan hubungan antara
proses-proses ini. Tidak ada urutan atau prioritas di antara masing-masing. Mereka
dapat dipertimbangkan dan dikelola secara terpisah, tetapi semuanya agak terkait satu
sama lain. Tampilan 19.5 menunjukkan pandangan tingkat tinggi

Perencanaan untuk Menerapkan Manajemen Layanan

Infr
Bisnis

astr

Dukungan Layanan ukt

Manajemen ur
Tek
Perspektif Manajemen Infrastruktur
nol
Bisnis Pelayanan
ogi

Jasa Pengiriman Manajemen

keamanan

Manajemen Aplikasi

PEMPERLIHATKAN 19.5 Kerangka ITIL®

Sumber: Kontrol Internal Sarbanes-Oxley: Audit Efektif dengan AS5, COBIT, dan ITIL, Robert R. Moeller. Hak Cipta © 2008
John Wiley & Sons. Dicetak ulang dengan izin dari John Wiley & Sons, Inc.Bisnis

kerangka kerja ITIL®. Ini menunjukkan bahwa area manajemen layanan

pengiriman dan dukungan layanan, bersama dengan manajemen keamanan,
menyediakan hubungan antara operasi bisnis dan teknologi TI dan manajemen
infrastruktur.
 Meskipun ada banyak komponen dan elemen untuk ITIL®, bagian ini hanya
akan membahas proses dukungan layanan yang telah ditentukan, bidang-bidang yang
penting bagi auditor internal yang melakukan tinjauan kontrol umum TI. Mereka
menyarankan pendekatan yang lebih disukai untuk fungsi operasi TI untuk mengatur
dan mengoperasikan sistem produksinya dengan cara yang akan mempromosikan
operasi yang efisien dan akan memberikan layanan berkualitas kepada pengguna
akhir atau pelanggan layanan tersebut. Ini sangat berguna untuk auditor internal yang
melakukan peninjauan dan membuat rekomendasi di bidang operasi TI.
Ketika auditor internal mengamati dan meninjau kontrol internal operasi TI,
pendekatan yang bermanfaat adalah memikirkan hal-hal terkait dengan proses ITIL®
yang terpisah ini. Misalnya, proses ITIL® yang disebut manajemen insiden, atau apa
yang secara tradisional disebut help desk, adalah fasilitas di mana pengguna sistem
atau pelanggan dapat menelepon dengan pertanyaan atau masalah. Meskipun fungsi
help desk bisa sangat berguna, sering kali menjadi sumber keributan ketika, misalnya,
masalah serupa dipanggil berulang kali tanpa ada upaya nyata untuk menganalisis
sesuatu dan memulai solusi. Melampaui hanya meja bantuan biasa dan memikirkan ini
sebagai proses keseluruhan di mana hal-hal dilaporkan ke proses pendukung lainnya
akan meningkatkan kinerja dan kualitas keseluruhan operasi TI.

Layanan ITIL Mendukung Manajemen Insiden

Proses manajemen insiden mencakup aktivitas yang diperlukan untuk memulihkan
layanan TI setelah gangguan. ITIL® mendefinisikan gangguan sebagai segala jenis
masalah yang mencegah pengguna TI menerima layanan yang memadai, apakah itu
merupakan kegagalan sistem secara keseluruhan, ketidakmampuan pengguna untuk
mengakses aplikasi karena berbagai alasan, kegagalan kata sandi karena kesalahan
pengetikan “fat fi ngers”, atau masalah lainnya. Masalah yang dilaporkan disebut
insiden, semacam penyimpangan dari operasi standar. Kami akan menggunakan
terminologi ini dan merujuk pada insiden selama diskusi kami tentang ITIL®. Meskipun
banyak fungsi IT memiliki fungsi yang disebut help desk atau kelompok dukungan
pelanggan, kami menyebut fungsi umum ini di sini sebagai desk service. Meja layanan
biasanya adalah pemilik untuk proses manajemen insiden, meskipun semua kelompok
dukungan layanan di TI mungkin memiliki peran.
Tujuan dari proses manajemen insiden yang efektif adalah untuk memulihkan
operasi normal secepat mungkin dengan cara yang hemat biaya dengan dampak
minimal pada keseluruhan bisnis atau pengguna. Seberapa cepat “cepat” seharusnya
tidak tunduk pada interpretasi, dan ITIL® menyerukan standar kerangka waktu
pemulihan untuk didefinisikan dalam apa yang disebut perjanjian tingkat layanan (SLA)
antara TI dan pelanggan atau pengguna. SLA yang efektif adalah komponen penting
dari infrastruktur TI dan dibahas kemudian sebagai salah satu proses pemberian
layanan ITIL®; keberadaan mereka harus di layar radar auditor internal. Komponen
pertama dari proses manajemen insiden ITIL® adalah deteksi dan dokumentasi insiden
oleh meja layanan, sebagai satu titik kontak. Insiden ini dapat mencakup hal-hal seperti
pengguna yang menelepon dalam beberapa masalah aplikasi spesifik untuk operasi TI
yang memberi tahu meja layanan tentang masalah pemrosesan aplikasi.
Setelah meja layanan menerima insiden yang dilaporkan, ia harus
mengklasifikasikannya berdasarkan prioritas, dampak, dan urgensinya. Definisi
prioritas insiden yang dilaporkan adalah salah satu aspek terpenting dalam mengelola
insiden TI. Setiap orang yang menelepon dalam suatu insiden berpikir bahwa miliknya
adalah yang paling penting, dan fungsi manajemen insiden memiliki tugas yang sulit
untuk menentukan prioritas relatif dari insiden yang dilaporkan, pentingnya, dan
dampaknya terhadap bisnis. Tampilan 19.6 menunjukkan siklus hidup suatu insiden
dari panggilan awal melalui resolusi dan penutupan. Maksud kami di sini adalah untuk
membantu audit internal memahami bukan bagaimana mengelola proses desk service
tetapi lebih pada praktik terbaik yang direkomendasikan. Pemahaman tentang praktik
terbaik ITIL® memungkinkan auditor internal untuk mengajukan beberapa pertanyaan
yang menyelidik ketika meninjau kontrol umum TI. Sebagai contoh, auditor internal
harus mencari SLA formal, sebagai bagian dari proses manajemen tingkat layanan,
untuk menentukan prioritas dengan mana insiden perlu diselesaikan dan upaya
dimasukkan ke dalam resolusi dan pemulihan dari insiden. SLA ini harus bergantung
pada:
 Dampak atau kekritisan insiden pada entitas pelapor atau
perusahaan secara keseluruhan. Manajemen insiden harus menilai,
misalnya, berapa banyak pengguna akan menderita sebagai akibat dari
kegagalan teknis dari komponen perangkat keras. Demikian pula,
panggilan tentang masalah dengan proses penutupan akhir bulan harus
diberi tingkat kekritisan yang lebih tinggi daripada masalah dengan
sistem yang menghasilkan pesanan pembelian.
 Urgensi dari insiden yang dilaporkan. Urgensi mengacu pada
kecepatan yang diperlukan untuk menyelesaikan insiden dampak
tertentu. Insiden dampak tinggi tidak, secara default, selalu harus
 diselesaikan segera. Panggilan insiden yang melaporkan bahwa
beberapa kelompok pengguna tidak dapat bekerja sama sekali karena
pemadaman layanan seringkali lebih mendesak daripada manajer
senior yang menelepon untuk meminta perubahan fungsi.
 Ukuran, ruang lingkup, dan kompleksitas insiden. Tim manajemen
insiden harus menyelidiki insiden yang dilaporkan sesegera mungkin
untuk menentukan luasnya. Kegagalan komponen yang dilaporkan
dapat berarti bahwa perangkat tidak berfungsi atau server sedang
rusak. Jenis-jenis insiden itu seringkali tidak terlalu rumit dan dapat
diperbaiki dengan relatif mudah. Kegagalan telekomunikasi yang dapat
berdampak pada banyak unit internasional dan karenanya dapat
menunda penutupan keuangan bulanan dapat jauh lebih besar dalam
ukuran dan ruang lingkup.
Kepemilikan, Pemantauan, Pelacakan, dan Komunikasi

Deteksi dan Pencatatan

Resolusi dan PemulihanResolusi dan Pemulihan
Insiden

Klasifikasi dan Dukungan

Awal

Perminta
Prosedur Permintaan
an
Layanan
layanan

Investigasi dan
Diagnosis

Resolusi dan Pemulihan

Penutupan Insiden
PEMPERLIHATKAN 19.6 Siklus Hidup Manajemen Insiden ITIL®

Setelah insiden masuk, proses investigasi dan diagnosis harus dimulai. Jika
meja layanan tidak dapat menyelesaikan insiden, itu harus ditugaskan ke tingkat
dukungan TI lainnya untuk resolusi. Namun, semua pihak yang bekerja pada insiden
tersebut harus menyimpan catatan tindakan mereka dengan memperbarui file log
insiden umum.
Beberapa insiden dapat diselesaikan melalui "quick fi x" oleh meja layanan,
yang lain dengan solusi masalah yang lebih formal, atau dalam kasus masalah yang
lebih signifikan, dengan bekerja di sekitar untuk mendapatkan sesuatu kembali dalam
operasi parsial ditambah dengan permintaan resmi untuk perubahan (RFC) ke sistem,
ke vendor, atau pihak apa pun yang perlu untuk memperbaiki masalah yang signifikan.
Dalam hal apa pun, upaya harus dikerahkan untuk memperbaiki masalah dengan
fungsi manajemen insiden mempertahankan kepemilikan masalah sampai
penyelesaian. Dokumentasi yang solid harus dipertahankan untuk melacak insiden
tersebut hingga resolusi. Insiden dapat ditutup secara formal setelah masalah
diselesaikan, atau jika tidak mudah dipecahkan, insiden tersebut harus diteruskan ke
fungsi proses manajemen masalah seperti yang dibahas nanti.
Semua proses ITIL® agak terkait satu sama lain, dan kami telah memilih
manajemen insiden sebagai satu untuk didiskusikan. Dalam banyak kasus,
manajemen insiden mewakili garis pertama antara pengguna layanan TI dan TI itu
sendiri. Diorganisasikan dengan benar, manajemen insiden harus lebih dari sekadar
meja bantuan pada waktu sebelumnya ketika pengguna dipanggil dengan masalah
tetapi tidak mendapatkan banyak bantuan di luar mungkin mengatur ulang kata sandi.
Manajemen insiden adalah titik kontak pertama antara pelanggan — pengguna — dan
fungsi TI secara keseluruhan. Insiden, hasil dari kegagalan atau kesalahan dalam
infrastruktur TI, menghasilkan variasi aktual atau potensial dari rencana operasi
layanan. Kadang-kadang penyebab insiden ini dapat terlihat dan dapat diatasi atau
diperbaiki tanpa perlu penyelidikan lebih lanjut. Dalam situasi lain mungkin ada
 kebutuhan untuk perbaikan perangkat keras atau perangkat lunak, suatu masalah yang
sering membutuhkan waktu untuk diimplementasikan. Solusi jangka pendek bisa
berupa penyelesaian, perbaikan cepat untuk kembali beroperasi, atau RFC formal
untuk proses manajemen perubahan untuk menghilangkan kesalahan. Contoh
penyelesaian jangka pendek mungkin hanya menginstruksikan pelanggan untuk mem-
boot ulang komputer pribadi atau me-reset jalur komunikasi, tanpa secara langsung
menangani penyebab mendasar dari insiden tersebut.
Jika penyebab yang mendasari insiden tidak dapat diidentifikasi, seringkali
tepat untuk mengangkat catatan masalah untuk kesalahan yang tidak diketahui dalam
infrastruktur. Biasanya catatan masalah dimunculkan hanya jika penyelidikan
dibenarkan, dan dampak aktual dan potensial harus dinilai. Pemrosesan catatan
masalah yang berhasil akan menghasilkan identifikasi kesalahan yang mendasarinya,
dan catatan tersebut kemudian dapat dikonversi menjadi kesalahan yang diketahui
begitu suatu penyelesaian telah dikembangkan dan / atau RFC diajukan.

Dukungan Layanan Manajemen Masalah

Ketika proses manajemen insiden menemui penyimpangan dengan sebab atau alasan
yang tidak diketahui, insiden itu harus diteruskan ke proses manajemen masalah untuk
penyelesaian. Tujuannya di sini adalah untuk meminimalkan dampak total masalah
melalui proses deteksi dan perbaikan formal serta mengambil tindakan untuk
mencegah terulangnya kembali. Proses manajemen masalah adalah langkah
selanjutnya dalam kekritisan dari beberapa insiden yang dilaporkan dan harus
dipertimbangkan dalam tiga subproses: kontrol masalah, kontrol kesalahan, dan
manajemen masalah proaktif. ITIL® mendefinisikan "masalah" sebagai penyebab
mendasar yang tidak diketahui yang disebabkan oleh satu atau lebih insiden, dan
"kesalahan yang diketahui" adalah masalah yang telah berhasil didiagnosis dan untuk
mana suatu penyelesaian telah diidentifikasi. Idenya bukan untuk menciptakan fungsi
administratif kedua di perusahaan TI untuk mengambil insiden help desk yang
dilaporkan, tetapi untuk mengidentifikasi kapan dan bagaimana beberapa insiden help
desk yang dilaporkan harus diteruskan ke orang lain atau pihak berwenang untuk
mendiagnosis lebih baik masalah yang dilaporkan dan mengobatinya sebagai
masalah. Proses manajemen masalah yang efektif dapat melakukan banyak hal untuk
meningkatkan layanan pelanggan TI secara keseluruhan.
Selain menyelesaikan setiap insiden tunggal yang bertabrakan dengan proses
manajemen masalah, TI harus mencoba membuat proses untuk kontrol masalah dan
kesalahan yang lebih baik, termasuk memelihara data untuk membantu
mengidentifikasi tren dan menyarankan perbaikan prosedur untuk pencegahan proaktif
masalah. Data harus dipelihara pada solusi dan / atau solusi yang tersedia untuk
masalah yang diselesaikan dan catatan masalah yang ditutup. Dalam banyak kasus,
manajemen masalah mungkin menghadapi situasi di mana perlu untuk melangkah
lebih jauh dan mengajukan permintaan resmi untuk perubahan baik melalui fungsi
pengembangan TI atau melalui vendor perangkat keras atau perangkat lunak.
Proses manajemen masalah berfokus pada menemukan pola antara insiden,
masalah, dan kesalahan yang diketahui. Tinjauan terperinci dari pola-pola ini
memungkinkan seorang analis untuk memecahkan masalah dengan
mempertimbangkan banyak kemungkinan dan mempersempit hal-hal menjadi solusi,
apa yang disebut analisis akar penyebab. Ada banyak teknik yang baik untuk
menyelesaikan dan memperbaiki masalah, seringkali disebabkan oleh kombinasi faktor
teknis dan nonteknis. Auditor internal yang meninjau proses manajemen masalah
harus mencari prosedur formal yang terdokumentasi untuk mendukung analisis dan
penyelesaian masalah. Manajemen masalah adalah bidang yang baik untuk audit
internal untuk mendiagnosis proses penyampaian layanan TI agar dapat lebih
memahami kesehatan operasi TI secara keseluruhan. Area di mana audit internal
dapat mengajukan beberapa pertanyaan di sini termasuk:

1. Jumlah RFC meningkat dan dampak RFC tersebut pada ketersediaan dan
keandalan layanan TI secara keseluruhan tercakup.
2. Jumlah waktu yang digunakan untuk investigasi dan diagnosis untuk
berbagai jenis masalah oleh unit organisasi atau vendor.
3. Jumlah dan dampak dari insiden yang terjadi sebelum akar masalah
diselesaikan atau kesalahan yang diketahui dikonfirmasi.
4. Rencana untuk penyelesaian masalah terbuka terkait dengan orang dan
persyaratan sumber daya lainnya serta biaya terkait dan jumlah yang
dianggarkan.
 Proses manajemen masalah dukungan layanan ITIL® adalah area penting bagi
auditor internal untuk dipertimbangkan dan dipahami ketika menilai kesehatan
keseluruhan operasi infrastruktur TI. Proses manajemen insiden yang efisien
diperlukan untuk menerima panggilan pelanggan dan mengambil tindakan korektif
segera, tetapi proses manajemen masalah yang efektif akan melangkah lebih jauh
untuk menganalisis dan menyelesaikan masalah, memulai RFC di mana perlu dan
sebaliknya meningkatkan kepuasan pelanggan TI.

Manajemen Konfigurasi Dukungan Layanan

Apa pun ukuran relatifnya, fungsi operasi TI kompleks, dengan beberapa jenis dan
versi komponen sistem yang harus bekerja bersama secara tertib dan terkelola dengan
baik. Ini tentu benar untuk operasi sistem TI kecil dan untuk perusahaan besar dengan
sistem mainframe klasik, "ladang" server, dan banyak perangkat penyimpanan dan
peralatan komunikasi. Fungsi manajemen konfigurasi formal adalah proses pengiriman
layanan penting yang mendukung identifikasi, pencatatan, dan pelaporan komponen TI
dan versinya, komponen penyusunnya, dan hubungan. Item yang seharusnya berada
di bawah kendali manajemen konfigurasi termasuk perangkat keras, perangkat lunak,
dan dokumentasi terkait. Manajemen konfigurasi bukan konsep yang sama dengan
proses akuntansi penyusutan untuk manajemen aset, meskipun keduanya terkait.
Sistem manajemen aset mempertahankan perincian pada peralatan TI di atas nilai
tertentu, unit bisnis mereka, dan lokasi mereka. Manajemen konfigurasi juga
memelihara hubungan antar aset, yang biasanya tidak dimiliki oleh manajemen aset.
Beberapa perusahaan mulai dengan manajemen aset dan kemudian beralih ke
manajemen konfigurasi.
Aktivitas dasar dari proses manajemen konfigurasi adalah untuk
mengidentifikasi berbagai komponen individu dalam operasi TI, yang disebut item
konfigurasi (CI), dan kemudian untuk mengidentifikasi data pendukung utama untuk CI
ini, termasuk pemiliknya, mengidentifikasi data, dan nomor versi, serta keterkaitan
sistem. Data ini harus ditangkap, diorganisasi, dan direkam dalam apa yang sering
dikenal sebagai database manajemen konfigurasi (CMDB). Tim yang bertanggung
jawab untuk manajemen konfigurasi harus memilih dan mengidentifikasi struktur
konfigurasi ini untuk seluruh CI infrastruktur, termasuk membangun hubungan antara
setiap CI dan komponen yang terhubung dalam konfigurasi infrastruktur TI secara
keseluruhan. Melampaui sekadar entri dalam CMDB, proses tersebut harus
memastikan bahwa hanya CI resmi yang telah diterima dan tidak ada CI yang
ditambahkan, dimodifikasi, diganti, atau dihapus tanpa permintaan perubahan yang
sesuai dan spesifikasi yang diperbarui.
Auditor internal dapat memikirkan pentingnya proses manajemen konfigurasi
dalam hal aplikasi desktop di departemen audit. Setiap auditor internal saat ini mungkin
memiliki komputer laptop, tetapi kecuali masing-masing memiliki versi perangkat lunak
yang konsisten, mungkin ada kesulitan dalam sistem berkomunikasi satu sama lain. Di
sinilah manajemen konfigurasi penting. Itu bahkan lebih penting ketika mencoba untuk
memahami berbagai versi atau bahkan jenis perangkat lunak dan peralatan dalam
operasi TI yang besar.
Proses manajemen konfigurasi juga mencakup beberapa elemen kontrol.
Serangkaian tinjauan dan audit harus dilaksanakan untuk memverifikasi keberadaan
fisik CI dan memeriksa bahwa mereka dicatat dengan benar dalam sistem manajemen
konfigurasi. Meskipun kami telah menggunakan kata audit di sini, ini bukan proses
audit internal tetapi istilah ITIL® yang ditetapkan untuk tim TI yang bertanggung jawab
atas proses manajemen konfigurasi. Manajemen konfigurasi juga harus memelihara
catatan untuk akuntansi status CI untuk melacak status CI saat itu berubah dari satu
negara ke negara lain, misalnya dari yang sedang dikembangkan, untuk diuji, untuk
ditayangkan, dan kemudian ditarik.
CMDB tidak harus berupa aplikasi khusus yang rumit. Suatu perusahaan dapat
menetapkan tingkat CMDB yang sangat mendasar hanya dengan menggunakan
spreadsheet, basis data lokal, atau bahkan sistem berbasis kertas. Namun, dalam
infrastruktur TI yang besar dan kompleks, manajemen konfigurasi memerlukan
penggunaan perpustakaan fisik dan elektronik bersama dengan CMDB untuk memiliki
salinan perangkat lunak dan dokumentasi yang pasti. CMDB harus didasarkan pada
teknologi basis data yang menyediakan fasilitas interogasi yang fleksibel dan kuat. Ini
harus berisi rincian tentang hubungan antara semua komponen sistem, termasuk
insiden, masalah, kesalahan yang diketahui, perubahan, dan rilis.
Keberadaan dan kontrol yang mendukung CMDB dapat menjadi titik yang baik
untuk audit internal untuk memahami proses manajemen konfigurasi TI perusahaan
dan kontrol pendukungnya. Jika fungsi TI perusahaan tidak memiliki CMDB yang baik,
audit internal dapat mengantisipasi melihat masalah kontrol internal yang kuat di
seluruh infrastruktur TI. Tampilan 19.7 menguraikan prosedur audit untuk meninjau
proses manajemen konfigurasi perusahaan.
Proses manajemen konfigurasi berinteraksi langsung dengan pengembangan
sistem, pengujian, manajemen perubahan, dan manajemen rilis untuk memasukkan
 produk baru yang diperbarui. Kontrol harus diberikan dari proyek atau pemasok ke
penyedia layanan pada waktu yang dijadwalkan dengan catatan konfigurasi yang
akurat. Selain itu, CMDB dapat digunakan oleh proses manajemen tingkat layanan
untuk menyimpan rincian layanan dan menghubungkannya dengan komponen TI yang
mendasarinya. CMDB juga dapat digunakan untuk menyimpan detail inventaris CI,
seperti pemasok, biaya, tanggal pembelian, dan tanggal pembaruan untuk lisensi.
Bonus tambahan adalah penggunaan CMDB untuk mencakup aspek hukum yang
terkait dengan pemeliharaan lisensi dan kontrak.

MEMPERLIHATKAN 19.7 Langkah-langkah Audit Internal Manajemen Konfigurasi ITIL®

1. Tinjau dan pahami praktik manajemen konfigurasi perusahaan yang ada serta antarmuka
mereka terhadap proses manajemen layanan, pengadaan, dan pengembangan.
2. Menilai pengetahuan dan kemampuan fungsi TI yang ada dan stafnya dalam hal kontrol dan
proses untuk konfigurasi, perubahan, dan lepaskan proses manajemen.
3. Tinjau tingkat dan kompleksitas perangkat lunak konfigurasi dan data pendukung sistem yang
ada, apakah disimpan dalam bentuk hard-copy, dalam spreadsheet lokal, atau dalam
database manajemen konfigurasi (CMDB), dan kembangkan pemahaman tentang database
itu dan alat pengambilannya.
4. Pilih aplikasi produksi dan pahami definisinya pada CMDB secara terperinci, termasuk
antarmuka untuk mengubah manajemen, manajemen rilis, proses manajemen layanan
lainnya, pengadaan, dan pengembangan.
5.

5. Dengan menggunakan alat pelaporan CMDB yang terinstal, tentukan inventaris item
konfigurasi (CI) untuk satu sistem yang dipilih dan secara fisik lacak sampel CI yang
dilaporkan ke komponen konfigurasi aktual.
6. Menentukan proses untuk menghubungkan proses bisnis manajemen konfi gurasi dan
prosedur dengan alat CMDB.
7. Uji C MDB dan alat pendukung lainnya untuk menentukan komponen utama, perangkat
lunak, dan dokumentasi telah diimplementasikan dan dikendalikan pada CMDB.
8. Tinjau kecukupan fasilitas untuk menyediakan area penyimpanan yang aman untuk
mengelola C Is (mis., Kabinet, perpustakaan yang dikendalikan, dan direktori).
9. Menilai kecukupan proses untuk berkomunikasi dan melatih staf tentang pentingnya dan
penggunaan manajemen konfigurasi.
10.Tinjau proses manajemen masalah untuk menentukan tingkat dan kesesuaian penggunaan
CMDB mereka untuk menyelesaikan masalah.
11.Menentukan bahwa akses dan pembaruan kontrol yang sesuai tersedia untuk mencegah
penggunaan CMDB yang tidak sah atau tidak pantas.
12.Tetapkan bahwa CMDB menerima cadangan yang memadai dan bahwa itu adalah bagian
dari rencana kontinuitas prosedur pencadangan dan pemulihan sumber daya utama
Dukungan Layanan Manajemen Perubahan
Proses manajemen masalah, yang dibahas sebelumnya, seringkali menghasilkan
perlunya perubahan TI, mulai dari perubahan program hingga revisi proses yang
meningkatkan layanan atau mengurangi biaya. Tujuan dari manajemen perubahan
ITIL® adalah untuk menggunakan metode dan prosedur standar untuk penanganan
semua perubahan yang efisien dan cepat, untuk meminimalkan dampaknya terhadap
kualitas layanan dan operasi sehari-hari. Proses manajemen perubahan ITIL® meliputi:

 Perangkat keras dan perangkat lunak sistem TI

 Peralatan dan perangkat lunak komunikasi
 Semua perangkat lunak aplikasi
 Semua dokumentasi dan prosedur yang terkait dengan menjalankan,
mendukung, dan memelihara sistem hidup

Poin terakhir di sini adalah perhatian khusus untuk auditor internal. Terlalu
sering, perangkat keras dan lunak TI berubah dengan sedikit perhatian yang diberikan
untuk juga mengubah dokumentasi pendukung. Perubahan pada komponen TI apa
pun — misalnya, perangkat lunak aplikasi, dokumentasi, atau prosedur — harus
tunduk pada proses manajemen perubahan formal.
Auditor internal sering menemui fungsi-fungsi TI di mana proses manajemen
perubahan paling tidak serampangan. Contoh di sini adalah perubahan pada aplikasi
tanpa memikirkan implikasinya pada infrastruktur TI secara keseluruhan, perbaikan
manajemen insiden yang membuat perubahan lain, atau permintaan manajemen
senior untuk perubahan untuk menyelesaikan masalah jangka pendek atau langsung.
Proses manajemen perubahan formal yang meninjau dan menyetujui setiap perubahan
yang diajukan akan hampir selalu meningkatkan TI dan proses kontrol internal
perusahaan. Proses manajemen perubahan ITIL® harus dikaitkan dengan erat dengan
manajemen konfigurasi, dibahas sebelumnya, untuk memastikan bahwa informasi
mengenai implikasi yang mungkin dari perubahan yang diajukan tersedia, dan segala
kemungkinan dampak terdeteksi dan disajikan dengan tepat.
 Proses manajemen perubahan harus memiliki visibilitas tinggi dan saluran
komunikasi terbuka untuk mempromosikan transisi yang lancar ketika perubahan
terjadi. Untuk meningkatkan proses ini, banyak fungsi TI telah melembagakan dewan
penasehat perubahan formal (CAB), yang terdiri dari orang-orang dari TI dan fungsi
lain dalam perusahaan, untuk meninjau dan menyetujui perubahan. CAB juga
membantu dalam penilaian dan memprioritaskan perubahan. Ini harus diberikan
tanggung jawab untuk memastikan bahwa semua perubahan dinilai secara memadai
dari sudut pandang bisnis dan teknis. Untuk mencapai campuran ini, CAB harus terdiri
dari tim dengan pemahaman yang jelas tentang kebutuhan bisnis pelanggan serta
pengembangan teknis dan fungsi dukungan. Dipimpin oleh manajer perubahan yang
bertanggung jawab, CAB harus terdiri dari pelanggan TI, pengembang aplikasi,
berbagai pakar / konsultan teknis yang sesuai, dan perwakilan kontraktor atau pihak
ketiga mana pun jika dalam situasi outsourcing. Meskipun CAB harus bertemu secara
teratur untuk meninjau dan menjadwalkan perubahan yang diusulkan, itu tidak boleh
bertindak sebagai penghambat operasi TI. Seharusnya ada untuk menyediakan
penjadwalan tertib dan pengenalan semua jenis perubahan infrastruktur TI.
Proses manajemen layanan keseluruhan yang efisien membutuhkan
kemampuan untuk mengubah berbagai hal dengan tertib, tanpa membuat kesalahan
dan keputusan yang salah. Proses manajemen perubahan yang efektif sangat
diperlukan untuk infrastruktur TI yang efektif. Ketika meninjau kontrol internal TI,
auditor internal harus mencari proses manajemen perubahan yang efektif yang
menyediakan:
 Penyelarasan layanan TI yang lebih baik dengan persyaratan bisnis
 Peningkatan visibilitas dan komunikasi perubahan baik untuk staf pendukung
bisnis maupun layanan
 Peningkatan penilaian risiko
 Dampak negatif yang berkurang dari perubahan kualitas layanan
 Penilaian yang lebih baik dari biaya perubahan yang diusulkan sebelum
mereka terjadi
 Lebih sedikit perubahan yang harus didukung, bersama dengan peningkatan
kemampuan untuk melakukan ini lebih mudah bila perlu
 Peningkatan produktivitas pelanggan TI, melalui lebih sedikit gangguan dan
layanan berkualitas tinggi
 Kemampuan TI yang lebih besar untuk menyerap volume besar perubahan
 Proses manajemen perubahan yang efektif adalah komponen penting dari
kontrol infrastruktur TI. Proses harus menyelaraskan erat dengan proses utama lainnya
dalam infrastruktur TI: perubahan, konfigurasi, kapasitas, dan manajemen rilis.

Dukungan Layanan Manajemen Rilis

Fungsi TI membutuhkan proses yang efektif untuk memastikan bahwa perubahan
diperkenalkan kepada semua pihak yang terkena dampak secara tertib dan terkontrol
dengan baik. Manajemen rilis mencakup pengenalan perubahan resmi ke layanan TI.
Rilis biasanya akan terdiri dari sejumlah masalah dan penyempurnaan layanan,
termasuk perangkat lunak dan perangkat keras baru atau yang diubah untuk
mengimplementasikan perubahan yang disetujui yang disyaratkan.
Rilis biasanya akan diimplementasikan sebagai rilis penuh, di mana semua
komponen yang diubah dibangun, diuji, didistribusikan, dan diimplementasikan
bersama. Ini menghilangkan bahaya bahwa versi CI yang usang (dibahas dalam
manajemen konfigurasi sebelumnya dalam bab ini) akan secara keliru dianggap tidak
berubah dan digunakan dalam rilis. Dengan rilis penuh, semua komponen yang
mendukung beberapa area aplikasi atau sistem dirilis sebagai komponen tunggal.
Dengan semua komponen baru dan yang sudah ada digabungkan bersama, masalah
apa pun lebih mungkin untuk dideteksi dan diperbaiki sebelum masuk ke lingkungan
langsung. Kerugiannya adalah waktu, upaya, dan sumber daya komputasi yang
dibutuhkan untuk membangun, menguji, mendistribusikan, dan mengimplementasikan
rilis lengkap akan meningkat.
Pendekatan alternatif untuk manajemen rilis adalah rilis delta atau parsial, yang
hanya mencakup CI yang berubah sejak rilis penuh atau delta terakhir. Rilis delta
mungkin lebih tepat ketika rilis penuh tidak dapat dibenarkan karena faktor-faktor
seperti urgensi untuk fasilitas yang dibutuhkan atau ukuran dan persyaratan sumber
daya terkait rilis delta dibandingkan dengan rilis penuh. Tidak ada pilihan tunggal yang
benar, dan keputusan untuk melakukan rilis delta harus diambil berdasarkan kasus per
kasus, dengan CAB membuat rekomendasi. Auditor internal harus memahami
pentingnya proses rilis yang tertata dengan baik dan harus mencari proses yang tertata
dengan baik dan mapan saat mereka melakukan tinjauan kontrol umum TI.
Bagian-bagian dalam bab ini telah menguraikan proses dukungan layanan
ITIL® pada tingkat yang sangat tinggi. Ketika meninjau kontrol umum TI, auditor
internal harus memikirkan pentingnya proses seperti manajemen konfigurasi. Auditor
internal tidak perlu menjadi ahli dalam bidang-bidang dukungan layanan ITIL® ini,
 tetapi harus selalu mengingatnya saat meninjau kontrol umum TI. Auditor internal
harus cukup terbiasa dengan proses ini untuk lebih memahami kontrol dan prosedur
yang mendukung dukungan layanan TI.

19.10 PRAKTEK TERBAIK PENGIRIMAN LAYANAN

Paragraf sebelumnya telah menjabarkan lima proses dukungan layanan ITIL®. Selain
itu, ada beberapa proses pengiriman layanan ITIL®. Dukungan layanan mencakup
pemrosesan yang akurat dari aplikasi dan komponen TI mulai dari menerima insiden
yang dilaporkan hingga mendefinisikan masalah hingga memperkenalkan perubahan
dan kemudian melepaskannya ke dalam produksi. Proses penyampaian layanan ITIL®
yang sama pentingnya mencakup area yang lebih dekat dengan operasi infrastruktur
TI yang lancar dan efisien. Beberapa di antaranya, seperti proses manajemen
kontinuitas, secara tradisional sudah dekat dan disukai hati banyak auditor internal.
Lainnya, seperti perjanjian tingkat layanan yang mendefinisikan kinerja dan harapan
antara TI dan pelanggannya, harus akrab dengan auditor internal yang menemukan
pengaturan serupa di bidang lain.

Layanan Pengiriman Manajemen Tingkat Layanan

Manajemen tingkat layanan adalah nama yang diberikan kepada proses perencanaan,
koordinasi, penyusunan, persetujuan, pemantauan, dan pelaporan ITIL® pada
perjanjian formal antara TI dan penyedia dan penerima layanan TI. Seperti dijelaskan
sebelumnya, perjanjian ini disebut perjanjian tingkat layanan (SLA), dan mereka
mewakili perjanjian formal antara TI dan penyedia layanan untuk TI serta pelanggan
pengguna akhir TI. Ketika materi praktik terbaik tingkat layanan ITIL® pertama kali
diterbitkan pada tahun 1989, SLA adalah konsep yang menarik tetapi tidak terlalu
umum. Saat ini banyak perusahaan telah memperkenalkan mereka — walaupun
dengan berbagai tingkat keberhasilan — dan auditor internal harus memahami dan
memahami pentingnya SLA ketika meninjau kontrol infrastruktur TI internal.
Dalam contoh SLA, IT kontrak dengan penyedia luar, seperti untuk cadangan
pemulihan bencana. Pengaturan ini akan dicakup oleh kontrak formal di mana
penyedia pemulihan bencana setuju untuk menyediakan tingkat layanan tertentu,
mengikuti beberapa jadwal berdasarkan respons waktu. Kontrak yang mengatur di sini
adalah SLA antara IT dan penyedia layanan kontinuitas. SLA antara IT dan pelanggan
mereka bahkan lebih penting di sini, dari perspektif kontrol internal. Kami telah
menggunakan istilah pelanggan untuk mewakili pengguna TI yang historis dan masih
umum. Ada banyak grup di perusahaan yang menggunakan layanan IT, dan sebagai
pelanggan, mereka memiliki harapan pada tingkat layanan dan respons tertentu.
Pengaturan ini didefinisikan melalui SLA, perjanjian tertulis antara IT dan
pelanggannya yang menentukan target layanan utama dan tanggung jawab kedua
belah pihak. Penekanannya harus pada kesepakatan, dan SLA tidak boleh digunakan
sebagai cara untuk menahan satu pihak atau pihak lain untuk tebusan. Kemitraan
sejati harus dikembangkan antara penyedia TI dan pelanggan untuk perjanjian yang
saling menguntungkan; jika tidak, SLA dapat dengan cepat menjadi rusak dan budaya
menyalahkan dapat mencegah peningkatan kualitas layanan yang sebenarnya terjadi.
Dalam SLA, TI berjanji untuk memberikan layanan per set jadwal yang
disepakati dan memahami bahwa akan ada penalti jika standar layanan ini tidak
terpenuhi. Tujuannya adalah untuk mempertahankan dan meningkatkan kualitas
layanan melalui siklus konstan untuk menyetujui, memantau, melaporkan, dan
meningkatkan level layanan TI saat ini. SLA harus difokuskan secara strategis pada
bisnis dan menjaga keselarasan antara bisnis dan TI.
Meskipun tidak ada persyaratan format untuk SLA, Pameran 19.8 menguraikan
konten SLA biasa. Ini seharusnya bukan jenis dokumen lengkap yang auditor internal
mungkin temukan sebagai bagian dari penutupan hipotek pribadi. Sebaliknya,
pelanggan TI akan menegosiasikan persyaratan layanan TI yang mereka cari, seperti
"waktu respons rata-rata tidak lebih dari. . . " atau “sistem keuangan proses dekat
diselesaikan oleh. . . " atau faktor lainnya. Untuk mengatasi harapan dan menunjukkan
apa yang bisa tersedia, fungsi TI biasanya menyediakan katalog penawaran layanan.
Persyaratan layanan TI Pelanggan harus dinegosiasikan dan SLA formal ditetapkan.
Kinerja terhadap SLA ini harus dipantau secara berkelanjutan dengan kinerja
dilaporkan secara teratur. Kegagalan untuk memenuhi standar SLA ini dapat
menghasilkan negosiasi tambahan dan penyesuaian SLA. Proses SLA ini memberikan
manfaat bagi bisnis dan TI, termasuk:
 Karena TI harus bekerja untuk memenuhi standar yang dinegosiasikan,
layanan TI akan cenderung memiliki kualitas yang lebih tinggi,
menyebabkan lebih sedikit gangguan. Produktivitas pelanggan TI juga
harus meningkat.
 Sumber daya staf TI akan cenderung digunakan secara lebih efisien ketika
TI menyediakan layanan yang lebih baik dalam memenuhi harapan
pelanggannya.
  Dengan menggunakan SLA, TI dan pelanggannya dapat mengukur
layanan yang diberikan dan persepsi operasi TI pada umumnya akan
meningkat.
 Layanan yang disediakan oleh pihak ketiga lebih mudah dikelola dengan
kontrak pendukung dan kemungkinan pengaruh negatif pada layanan TI
yang diberikan berkurang.
 Memantau keseluruhan layanan TI di bawah SLA memungkinkan untuk
mengidentifikasi titik-titik lemah yang dapat ditingkatkan.

MEMPERLIHATKAN 19.8 Contoh Isi Perjanjian Tingkat Layanan TI

Meskipun tidak ada satu bentuk atau format yang diterima secara umum untuk dokumen
SLA, set konten berikut harus dianggap sebagai elemen kunci untuk sebagian besar SLA:
Halaman Pendahuluan Perjanjian
 Pihak-pihak dalam perjanjian ini
 Judul dan deskripsi singkat perjanjian
 Penanda tangan
 Tanggal: mulai, berakhir, ulasan
 Lingkup perjanjian: apa yang dicakup dan apa yang dikecualikan
 Tanggung jawab penyedia layanan dan pelanggan
 Deskripsi layanan yang tercakup.
Jam Layanan
 Jam-jam yang biasanya diperlukan oleh setiap layanan (mis. 24 × 7, Senin hingga
Jumat 08: 00-18: 00)
 Pengaturan untuk meminta perpanjangan layanan, termasuk periode pemberitahuan
yang diperlukan (mis., Permintaan harus diajukan ke meja layanan pada siang hari
 untuk malam
tunjangan jam hari)
khususekstensi, pada
(misalnya, siang
hari libur hari
umum)pada hari Kamis untuk perpanjangan
akhir pekan)
 Kalender layanan
Ketersediaan
 Target ketersediaan dalam jam yang disepakati, biasanya dinyatakan sebagai
persentase. Periode dan metode pengukuran harus ditetapkan dan dapat dinyatakan
untuk keseluruhan layanan, layanan dasar, dan komponen penting, atau ketiganya.
Karena sulit untuk berhubungan dengan persentase yang disederhanakan,
ketersediaan dapat diukur dalam hal ketidakmampuan pelanggan untuk melakukan
kegiatan bisnisnya.
Keandalan
 biasanya dinyatakan sebagai jumlah istirahat layanan, atau waktu rata-rata antara
kegagalan (MTBF) atau waktu rata-rata antara insiden sistem (MTBS).
Dukungan
 Jam dukungan (bila tidak sama dengan jam layanan), termasuk pengaturan untuk
meminta ekstensi dukungan
 Periode pemberitahuan yang diperlukan (mis., Permintaan harus diajukan ke meja
layanan pada siang hari untuk perpanjangan malam, pada siang hari Kamis untuk
Pengisian daya
 Detail rumus dan periode pengisian (jika dikenakan biaya). Jika S LA mencakup
hubungan outsourcing, biaya harus dirinci dalam lampiran yang mungkin tidak tersedia
untuk umum karena ketentuan kerahasiaan potensial.
Pelaporan dan Tinjauan Layanan
 Konten, frekuensi, dan distribusi laporan layanan, dan frekuensi pertemuan tinjauan
layanan.
Insentif / Denda Kinerja
 Rincian perjanjian apa pun terkait insentif keuangan atau hukuman berdasarkan kinerja
terhadap tingkat layanan. Ini lebih cenderung dimasukkan jika layanan disediakan oleh
organisasi pihak ketiga. Perlu dicatat bahwa klausa hukuman dapat membuat kesulitan
mereka sendiri.
 Proses SLA harus menjadi komponen penting dari operasi TI. Jika suatu
perusahaan tidak menggunakan SLA formal, auditor internal yang meninjau operasi TI
kontrol umum harus mempertimbangkan untuk merekomendasikan bahwa fungsi TI
perusahaan memulai proses SLA formal. SLA dapat menciptakan lingkungan yang
benar-benar baru dalam TI, di mana semua pihak akan lebih memahami tanggung
jawab dan kewajiban layanan mereka, dengan SLA sebagai dasar untuk
menyelesaikan banyak masalah. Audit internal dapat menggunakannya sebagai dasar
untuk menilai kontrol internal di berbagai bidang dan untuk membuat rekomendasi
perbaikan kontrol yang kuat

Pengiriman Layanan Manajemen Keuangan untuk Layanan TI

Pada hari-hari sebelumnya, fungsi TI di sebagian besar perusahaan dioperasikan
sebagai layanan dukungan "gratis". Pengeluarannya ditangani melalui manajemen
pusat dengan biaya yang dialokasikan untuk pengguna yang menguntungkan. Ada
sedikit perhatian yang diberikan pada biaya di masa-masa awal itu. Jika sebuah
departemen menginginkan beberapa aplikasi baru, itu akan menekan manajemen
untuk membeli paket dan menambahkan orang yang diperlukan tambahan untuk
mengelolanya. Seiring waktu, perusahaan IT mulai membuat proses tolak bayar, tetapi
ini terlalu sering dipandang sebagai serangkaian transaksi "uang lucu" di mana tidak
ada yang terlalu memperhatikan biaya aktual dan harga layanan TI.
Saat ini, biaya dan harga layanan TI adalah atau harus menjadi pertimbangan
yang jauh lebih penting. Fungsi TI yang dikelola dengan baik harus beroperasi sebagai
bisnis, dan manajemen keuangan adalah proses ITIL® utama untuk membantu
mengelola kontrol keuangan untuk bisnis itu. Tujuan dari proses manajemen keuangan
pengiriman layanan adalah untuk menyarankan pedoman untuk pengelolaan aset dan
sumber daya yang hemat biaya yang digunakan dalam menyediakan layanan TI. TI
harus dapat memperhitungkan sepenuhnya pengeluarannya untuk layanan TI dan
untuk mengaitkan biaya layanan yang dikirim ke pelanggan perusahaan. Ada tiga
subproses terpisah yang terkait dengan manajemen keuangan ITIL®:
1. Penganggaran TI adalah proses memprediksi dan mengendalikan
pengeluaran uang untuk sumber daya TI. Penganggaran terdiri dari siklus
negosiasi berkala, biasanya tahunan, untuk menetapkan anggaran
bersama dengan pemantauan anggaran harian saat ini. Penganggaran
 memastikan bahwa telah ada perencanaan dan pendanaan untuk layanan
TI yang sesuai dan bahwa TI beroperasi dalam anggaran ini selama
periode tersebut. Fungsi bisnis lainnya akan melakukan negosiasi berkala
dengan IT untuk menetapkan rencana pengeluaran dan program investasi
yang disepakati; ini pada akhirnya menetapkan anggaran untuk TI.
2. Akuntansi TI adalah serangkaian proses yang memungkinkan TI untuk
bertanggung jawab penuh atas cara uangnya dihabiskan oleh pelanggan,
layanan, dan kegiatan. Fungsi TI sering tidak selalu melakukan pekerjaan
dengan baik di bidang ini. Mereka memiliki berbagai macam biaya
eksternal, termasuk perangkat lunak, perjanjian sewa peralatan, biaya
telekomunikasi, dan lainnya, tetapi biaya-biaya ini seringkali tidak dikelola
atau dilaporkan dengan baik. Mereka memiliki cukup data untuk membayar
tagihan dan mengevaluasi beberapa biaya area tertentu, tetapi fungsi TI
sering kali tidak memiliki tingkat akuntansi terperinci yang dapat ditemukan
di perusahaan manufaktur besar, misalnya. Akuntansi biaya produksi atau
model akuntansi berbasis aktivitas memiliki penerapan di sana.
3. Pengisian adalah serangkaian proses penetapan harga dan penagihan
untuk menagih pelanggan atas layanan yang disediakan. Ini membutuhkan
akuntansi IT yang baik dan perlu dilakukan dengan cara yang sederhana,
adil, dan terkontrol dengan baik. Proses pengisian daya TI terkadang rusak
dalam fungsi TI karena laporan penagihan layanan TI terlalu rumit atau
teknis untuk dipahami oleh banyak pelanggan. TI perlu membuat laporan
layanan TI yang jelas dan dapat dimengerti yang digunakan sehingga
pelanggan dapat memverifikasi detail, cukup memahami untuk mengajukan
pertanyaan terkait layanan, dan menegosiasikan penyesuaian jika perlu.
Manajemen keuangan untuk layanan TI menyediakan informasi penting untuk
proses manajemen tingkat layanan, yang dibahas sebelumnya, tentang strategi
penetapan harga, penetapan harga, dan pengisian daya TI. Meskipun umumnya tidak
dioperasikan sebagai pusat laba, proses manajemen keuangan memungkinkan TI dan
pelanggannya untuk memikirkan operasi layanan TI dalam istilah bisnis. Proses
manajemen keuangan dapat memungkinkan TI dan manajemen secara keseluruhan
untuk membuat keputusan tentang apa, jika ada, fungsi harus disimpan di rumah atau
diserahkan kepada penyedia eksternal.

MEMPERLIHATKAN 19.9 Biaya dan Langkah-Langkah Tinjauan Audit Internal Harga

1. Mengembangkan dan mendokumentasikan pemahaman umum tentang struktur biaya
untuk operasi TI, termasuk biaya sewa peralatan, sewa vendor, suplai TI, dan biaya
personil.
2. Tinjau dan pahami filosofi penetapan biaya perusahaan untuk operasi TI – apakah ini
merupakan fungsi overhead, pengembalian biaya, atau menghasilkan pendapatan?
3. Tinjau proses penetapan biaya dan penetapan harga layanan TI:
 Proses manajemen keuangan ITIL® memungkinkan analisis manfaat-biaya
yang akurat dari layanan TI yang disediakan dan memungkinkan perusahaan IT untuk
menetapkan dan memenuhi target keuangan. Ini juga menyediakan pelaporan tepat
waktu ke proses manajemen tingkat layanan, sehingga pelanggan dapat memahami
metode pengisian dan penetapan harga yang digunakan. Dari semua dukungan
layanan ITIL® dan proses pengiriman, manajemen keuangan adalah manajemen yang
sering mendapat sedikit perhatian. Orang-orang TI memiliki orientasi teknis dan
cenderung menganggap manajemen keuangan sebagai masalah akuntansi, hampir di
bawah mereka. Di sisi lain dari koin, profesional keuangan dan akuntansi cenderung
melihat masalah ini sebagai terlalu teknis dan melampaui transaksi seperti akuntansi
sewa peralatan atau biaya ruang fasilitas. Auditor internal harus menggunakan
keterampilan keuangan mereka serta pengetahuan TI untuk meninjau dan menilai
proses manajemen keuangan pengendalian internal. Tampilan 19.9 memberikan
prosedur untuk tinjauan audit internal terhadap biaya dan harga proses TI. Ini bukan
area ulasan umum untuk audit internal, tetapi mengingat biaya besar yang
 didistribusikan kepada pelanggan serta pentingnya sumber daya TI perusahaan, ini
bisa menjadi area audit internal yang penting.

Manajemen Kapasitas Pengiriman Layanan

Manajemen kapasitas ITIL® memastikan bahwa kapasitas infrastruktur TI selaras
dengan kebutuhan bisnis untuk mempertahankan tingkat pemberian layanan yang
diperlukan dengan biaya yang dapat diterima melalui tingkat kapasitas yang sesuai.
Melalui pengumpulan data kapasitas bisnis dan teknis, proses ini harus menghasilkan
rencana kapasitas untuk memberikan persyaratan kapasitas yang dibenarkan biaya
bagi perusahaan. Selain menjadi tujuan utama untuk memahami persyaratan kapasitas
TI perusahaan dan memenuhi persyaratan tersebut, manajemen kapasitas
bertanggung jawab untuk menilai potensi keuntungan teknologi baru yang bisa dimiliki
perusahaan.
Proses manajemen kapasitas umumnya dipertimbangkan dalam tiga subproses
yang mencakup bisnis, layanan, dan manajemen kapasitas sumber daya. Manajemen
kapasitas bisnis adalah proses jangka panjang untuk memastikan bahwa kebutuhan
bisnis di masa depan dipertimbangkan dan kemudian direncanakan dan
diimplementasikan seperlunya. Manajemen kapasitas pengiriman layanan bertanggung
jawab untuk memastikan bahwa kinerja semua layanan TI saat ini berada dalam
parameter yang ditentukan dalam SLA yang ada. Akhirnya, manajemen kapasitas
sumber daya memiliki fokus yang lebih teknis dan bertanggung jawab atas
pengelolaan masing-masing komponen dalam infrastruktur TI. Beberapa input untuk
tiga subproses manajemen kapasitas ini meliputi:

 Pelanggaran SLA dan SLA

 Rencana dan strategi bisnis
 Jadwal operasional dan perubahan jadwal
 Masalah pengembangan aplikasi
 Kendala dan akuisisi teknologi
 Insiden dan masalah
 Anggaran dan rencana keuangan
Sebagai hasil dari beragam input ini, proses manajemen kapasitas — sering
kali di bawah satu manajer kapasitas yang ditunjuk — akan mengelola proses TI,
 mengembangkan dan memelihara rencana kapasitas formal, dan memastikan bahwa
catatan kapasitas sudah mutakhir. Selain itu, manajer kapasitas harus dilibatkan dalam
mengevaluasi semua perubahan untuk menetapkan efek pada kapasitas dan kinerja.
Evaluasi kapasitas ini harus terjadi baik ketika perubahan diajukan maupun setelah
diterapkan. Manajemen kapasitas harus memberi perhatian khusus pada efek
kumulatif dari perubahan selama periode waktu yang dapat menyebabkan waktu
respons yang menurun, masalah penyimpanan file, dan permintaan berlebih untuk
kapasitas pemrosesan. Tanggung jawab proses manajemen kapasitas lainnya
termasuk beberapa tugas dari jaringan, aplikasi, dan manajer sistem. Mereka
bertanggung jawab untuk menerjemahkan persyaratan bisnis ke dalam kapasitas yang
diperlukan untuk dapat memenuhi persyaratan ini dan mengoptimalkan kinerja TI.
Penerapan proses manajemen kapasitas yang efektif menawarkan manfaat
dari tinjauan umum aktual atas kapasitas yang ada saat ini dan kemampuan untuk
merencanakan kapasitas di muka. Manajemen kapasitas yang efektif harus dapat
memperkirakan dampak dari aplikasi atau modifikasi baru serta memberikan
penghematan biaya yang selaras dengan persyaratan bisnis. Perencanaan kapasitas
yang tepat dapat secara signifikan mengurangi keseluruhan biaya kepemilikan sistem
TI. Meskipun perencanaan kapasitas formal membutuhkan waktu, sumber daya staf
internal dan eksternal, dan perangkat lunak dan perangkat keras, potensi kerugian
yang terjadi tanpa perencanaan kapasitas dapat menjadi signifikan. Kehilangan
produktivitas pengguna akhir dalam fungsi-fungsi bisnis penting, membayar lebih untuk
peralatan atau layanan jaringan, dan biaya peningkatan sistem yang sudah dalam
produksi dapat lebih dari sekadar membenarkan biaya perencanaan kapasitas. Ini
adalah proses ITIL® yang penting, dan auditor internal harus mempertimbangkan
proses manajemen kapasitas saat meninjau kontrol dan proses infrastruktur TI.

Manajemen Ketersediaan Pengiriman Layanan

Perusahaan semakin tergantung pada layanan TI pada ketersediaan 24/7. Ketika
layanan TI tidak tersedia, dalam banyak kasus bisnis berhenti juga. Oleh karena itu
penting bahwa fungsi TI mengelola dan mengendalikan ketersediaan layanannya. Ini
dapat dicapai dengan mendefinisikan persyaratan dari bisnis mengenai ketersediaan
layanan TI dan kemudian mencocokkannya dengan kemungkinan perusahaan IT.
Manajemen ketersediaan tergantung pada beberapa input: persyaratan terkait
ketersediaan bisnis; informasi tentang keandalan, pemeliharaan, pemulihan, dan
kemudahan servis CI; dan informasi dari proses lain, insiden, masalah, dan tingkat
layanan yang dicapai. Output dari proses manajemen ketersediaan adalah:

 Rekomendasi mengenai infrastruktur TI untuk memastikan ketahanannya

 Laporan tentang ketersediaan layanan TI
 Prosedur untuk memastikan bahwa ketersediaan dan pemulihan ditangani
untuk setiap layanan TI baru atau yang ditingkatkan
 Rencana untuk meningkatkan ketersediaan layanan TI

Kegiatan manajemen ketersediaan dapat digambarkan sebagai perencanaan,

peningkatan, dan pengukuran tindakan. Perencanaan melibatkan menentukan
persyaratan ketersediaan untuk mengetahui apakah dan bagaimana TI dapat
memenuhinya. Proses manajemen tingkat layanan, yang dibahas sebelumnya,
memelihara kontak dengan bisnis dan akan dapat memberikan harapan ketersediaan
kepada manajemen ketersediaan. Bisnis mungkin memiliki harapan yang tidak realistis
sehubungan dengan ketersediaan tanpa memahami apa artinya ini secara riil.
Misalnya, mereka mungkin menginginkan ketersediaan 99,9% namun tidak menyadari
bahwa ini akan menelan biaya lima kali lebih banyak daripada menyediakan
ketersediaan 98%. Merupakan tanggung jawab manajemen tingkat layanan dan proses
manajemen ketersediaan untuk mengelola harapan tersebut.
Fungsi TI dapat mendesain untuk ketersediaan atau pemulihan. Ketika bisnis
tidak mampu membayar downtime layanan tertentu untuk jangka waktu berapa lama,
TI perlu membangun ketahanan dalam infrastruktur dan memastikan bahwa
pemeliharaan preventif dapat dilakukan untuk menjaga layanan tetap beroperasi.
Dalam banyak kasus membangun ketersediaan tambahan ke dalam infrastruktur
adalah tugas yang mahal yang dapat dibenarkan oleh kebutuhan bisnis. Merancang
untuk ketersediaan adalah pendekatan proaktif untuk menghindari downtime dalam
layanan TI.
Ketika bisnis dapat mentolerir beberapa downtime layanan atau justifikasi biaya
tidak dapat dilakukan untuk membangun ketahanan tambahan ke dalam infrastruktur,
merancang untuk pemulihan adalah pendekatan yang tepat. Di sini, infrastruktur akan
dirancang sedemikian rupa sehingga jika terjadi kegagalan layanan, pemulihan akan
"secepat mungkin." Merancang untuk pemulihan adalah pendekatan manajemen
reaktif untuk ketersediaan. Dalam kejadian apa pun, proses seperti manajemen insiden
harus ada untuk pulih sesegera mungkin jika terjadi gangguan layanan.
 Manfaat utama manajemen ketersediaan adalah proses terstruktur untuk
memberikan layanan TI sesuai dengan persyaratan yang disepakati pelanggan. Ini
harus menghasilkan ketersediaan layanan TI yang lebih tinggi dan meningkatkan
kepuasan pelanggan. Ini mencakup area di mana auditor internal sering dapat
mengajukan beberapa pertanyaan sulit sebagai bagian dari ulasan kontrol TI umum
mereka.

Manajemen Kontinuitas Pengiriman Layanan

Ketika bisnis menjadi semakin tergantung pada TI, dampak dari tidak tersedianya
layanan TI telah meningkat secara drastis. Setiap kali ketersediaan atau kinerja suatu
layanan berkurang, pelanggan TI tidak dapat melanjutkan pekerjaan normal mereka.
Tren menuju ketergantungan yang tinggi pada dukungan dan layanan TI akan terus
berlanjut dan akan mempengaruhi pelanggan, manajer, dan pembuat keputusan
langsung. Manajemen kontinuitas ITIL® menekankan bahwa dampak dari kerugian
total atau bahkan sebagian dari layanan TI harus diperkirakan dan rencana
kesinambungan ditetapkan untuk memastikan bahwa bisnis, dan infrastruktur TI
pendukungnya, akan selalu dapat berlanjut.
ITIL® menyerukan strategi yang tepat untuk dikembangkan yang berisi
keseimbangan optimal dari pengurangan risiko dan opsi pemulihan. Ini memerlukan
beberapa strategi kesinambungan bisnis dan pemulihan bencana yang sama seperti
yang dibahas dalam Bab 24 buku ini. Dengan menggunakan pendekatan yang
diuraikan di sana, sebuah perusahaan IT dapat mengimplementasikan serangkaian
proses kontinuitas layanan yang efektif, dan auditor internal harus merujuk pada bab
tersebut untuk lebih memahami dan mengevaluasi proses perencanaan kontinuitas
dan pemulihan bencana.

19.11 AUDIT IT MANAJEMEN INFRASTRUKTUR

Dukungan layanan ITIL® dan proses pemberian layanan memperkenalkan pendekatan
yang diperluas dan ditingkatkan untuk melihat semua aspek infrastruktur TI. Proses-
proses ini tidak independen dan berdiri sendiri. Sementara setiap proses agak dapat
beroperasi dengan sendirinya, mereka semua bergantung pada input dan dukungan
dari proses terkait lainnya. Kami telah mencoba untuk menunjukkan saling
ketergantungan ini dalam beberapa deskripsi proses, dan auditor internal yang
meninjau kontrol atas setiap proses ITIL® harus memikirkan kontrol ini terkait dengan
proses lain yang terhubung.
Penyampaian layanan ITIL® dan dukungan layanan adalah dua elemen yang
saling terkait dan berdampingan. Mereka mendukung manajemen infrastruktur TI dan
manajemen perusahaan. Aplikasi TI berada di pusat teka-teki ini dan bidang utama
yang menjadi perhatian pengendalian internal.
Diskusi kami sebelumnya tentang manajemen masalah, manajemen insiden,
dan manajemen perubahan proses ITIL®, antara lain, cenderung membutuhkan fungsi
TI yang sangat besar dengan berbagai tingkat staf dan sumber daya manajemen.
Auditor internal mungkin bertanya bagaimana standar ITIL® ini berlaku untuk
perusahaan yang jauh lebih kecil. Jawaban kami di sini sangat banyak bahwa ya,
ITIL® berlaku untuk semua ukuran fungsi TI. Untuk menjadi ITIL®-compliant, sebuah
perusahaan tidak memerlukan banyak staf pendukung. Sebaliknya, perlu dipikirkan
berbagai dukungan layanan dan proses pengiriman layanan dari perspektif praktik
terbaik ITIL®. Fungsi TI kecil mungkin tidak perlu menetapkan manajemen insiden dan
fungsi manajemen masalah yang terpisah, tetapi harus menganggap masing-masing
sebagai proses terpisah dengan prosedur kontrol yang unik. Bahkan dalam fungsi IT
yang sangat kecil, setiap area proses ITIL® harus diperlakukan sebagai area terpisah
untuk peningkatan proses.
Auditor internal harus memberikan perhatian khusus pada bidang ini ketika
membuat rekomendasi. Ukuran dan ruang lingkup area yang diaudit dan ruang lingkup
operasi harus selalu dipertimbangkan. Penulis ini memikirkan hari-hari awal kontrol TI,
ketika banyak aplikasi dikembangkan in-house untuk aplikasi produksi. Untuk
mempromosikan pemisahan tugas yang memadai, banyak bahan pedoman audit
merekomendasikan bahwa ada pemisahan tugas antara orang-orang yang
mengoperasikan komputer dan mereka yang memprogramnya. Kalau tidak, pada hari-
hari sistem yang jauh lebih sederhana, ada risiko bahwa seseorang yang memiliki niat
curang dapat mengubah program aplikasi — misalnya, menulis cek yang tidak sah
untuk dirinya sendiri — misalnya, dan kemudian menghasilkan cek pribadi ini ketika
mengoperasikan sistem. Ini adalah kontrol yang baik di awal-awal TI, tetapi tidak
relevan saat ini. Saat ini, auditor internal harus memikirkan kecukupan dan kesesuaian
kontrol TI dalam hal kontrol yang dibangun ke dalam aplikasi individual serta kontrol
proses infrastruktur yang dibahas dalam bab ini.
Area infrastruktur TI merupakan area penting untuk tinjauan audit internal.
Terlalu sering auditor internal memusatkan perhatian mereka pada kontrol aplikasi dan
 kontrol umum TI di masa lalu. Dalam dunia saat ini dari proses kompleks yang
mendukung infrastruktur TI, proses ITIL® yang diuraikan dalam bab ini menawarkan
beberapa area yang sangat baik untuk perhatian audit internal. Ketika meninjau kontrol
internal untuk perusahaan IT apa pun, apakah operasi TI tingkat perusahaan besar
atau fungsi yang lebih kecil ditemukan di banyak perusahaan saat ini, auditor internal
yang efektif harus berkonsentrasi pada peninjauan kontrol atas proses infrastruktur
utama.

19.12 AUDITOR INTERNAL CBOK MEMBUTUHKAN PENGENDALIAN UMUMNYA

Kebutuhan akan badan pengetahuan umum auditor internal (CBOK) adalah tema yang
sedang berlangsung di seluruh bab ini. Dalam beberapa kasus, seperti memahami
Standar Internasional untuk Praktik Profesional Audit Internal, sebagaimana dibahas
dalam Bab 9, pengetahuan ini harus menjadi persyaratan CBOK auditor internal yang
penting. Area topik lainnya, seperti pembahasan Bab 33 tentang ISO 9000 dan standar
sistem kualitas lainnya, auditor internal harus memiliki pemahaman dasar CBOK
tentang area tersebut tetapi tidak perlu tingkat pengetahuan yang terperinci. Bab ini
telah membahas tinjauan audit internal kontrol umum TI dan infrastruktur TI. Area-area
ini mewakili persyaratan CBOK yang kuat untuk semua auditor internal.
Seperti yang telah kita bahas, dunia kendali umum TI tampaknya terus berubah
dan berevolusi ketika kita telah beralih dari komputer mainframe klasik dari era
sebelumnya ke beberapa perangkat server saat ini yang terhubung melalui jaringan
nirkabel dan Internet. Mungkin ada banyak masalah teknis di sini yang mungkin terbaik
diperuntukkan bagi spesialis audit TI, tetapi semua auditor internal saat ini harus
memiliki tingkat pengetahuan CBOK yang kuat tentang kontrol umum TI dan
infrastruktur pendukung yang memungkinkan kontrol umum tersebut untuk beroperasi
dan berfungsi.
Bab-bab berikutnya akan membahas masalah terkait TI lainnya yang juga
penting bagi auditor internal, seperti cybersecurity dan perencanaan kontinuitas, tetapi
pemahaman audit internal tentang kontrol umum TI sangat penting. Tidak peduli
ukuran atau ruang lingkup operasi TI, prosedur kontrol tertentu — seperti kontrol revisi
program — bersifat umum dan berlaku untuk semua operasi. Selain itu, pemahaman
keseluruhan praktik terbaik ITIL® harus memungkinkan auditor internal memahami dan
mengevaluasi kontrol umum TI di banyak lingkungan.

CATATAN
1. Total hash adalah penjumlahan dari nilai numerik dan alfabet untuk beberapa nilai
komputer. Ini digunakan sebagai total kontrol.
2. Publikasi ITIL® tersedia dari agen Inggris yang disebut Kantor Alat Tulis dan dapat
ditemukan melalui www.tsoshop.co.uk.

BAB 34 : CBOK untuk Auditor Internal Modern

BAB SEBELUMNYA BUKU INI telah menggambarkan proses audit internal yang ada
untuk auditor internal modern saat ini. Kami telah menjelaskan area di mana
keterampilan dan pemahaman audit internal sangat penting, dan area lain di mana
auditor internal harus memiliki pemahaman umum yang kuat. Semua ini menjadi badan
audit pengetahuan umum internal (CBOK).
Pendekatan CBOK auditor internal kami didasarkan pada tata kelola, risiko, dan
bidang kepatuhan saat ini dan yang berkembang yang penting bagi auditor internal,
pengalaman masa lalu penulis ini dalam melakukan dan memimpin audit internal, dan
penelitiannya tentang tren penting dan berkembang. Dengan demikian kami telah
menyoroti bidang pengetahuan audit internal yang harus menjadi penting, jika tidak
penting, untuk auditor internal. Contoh di sini adalah diskusi Bab 6 tentang COBIT,
kerangka kerja alternatif penting untuk mendokumentasikan dan memahami kontrol
internal. Sementara ekstrak dari situs web IIA cenderung memandang COBIT hanya
sebagai alat audit TI khusus dan tidak banyak yang lain, kami membahas pentingnya
COBIT sebagai alat audit internal alternatif dan penting untuk mengevaluasi dan
memahami kontrol internal. Kami menyarankan bahwa semua auditor internal harus
memiliki pemahaman CBOK tingkat tinggi dan keakraban dengan kerangka kerja
COBIT.
Komentar tentang COBIT ini merujuk pada pendekatan kami untuk
mendefinisikan audit internal CBOK. Daripada menerbitkan hasil dari survei yang
cukup terbuka tetapi tidak selalu terkontrol, berdasarkan anggota IIA yang menanggapi
permintaan Web "Beritahu kami apa yang menurut Anda penting", kami telah mencoba
untuk menguraikan bidang-bidang pengetahuan yang harus penting bagi semua
auditor internal.
Publikasi IIARF CBOK dikembangkan dengan mempekerjakan tim konsultan
untuk mengirim survei ke anggota IIA terpilih di seluruh dunia dan kemudian
menerbitkan hasil survei CBOK 1 khusus anggota IIA mereka pada waktu yang sama
ketika edisi ketujuh buku ini dirilis. IIARF CBOK 2006 itu tampaknya mengumpulkan
data respons survei tentang apa auditor internal mengatakan bahwa mereka
melakukannya, tetapi dengan beberapa hasil yang dilaporkan terkadang mengganggu.
Sebagai contoh, walaupun selalu ada cara untuk memanipulasi statistik dan walaupun
kami tidak memiliki akses lengkap ke semua data, survei IIARF CBOK 2006 yang
sekarang dihapus dan usang menemukan bahwa beberapa auditor internal bahkan
tidak mengikuti standar profesional mereka sendiri. Sebagai contoh, penelitian CBOK
IIARF 2006 melaporkan bahwa hanya sekitar 90% dari eksekutif audit kepala yang
disurvei merasa bahwa fungsi audit internal mereka “menambah nilai” dan “secara
proaktif memeriksa masalah keuangan, risiko, dan kontrol internal yang penting” di
perusahaan CAE. . Ini adalah area-area di mana kami berharap bahwa hampir 100%
 CAE harus disetujui. Statistik yang dilaporkan dan masalah serupa lainnya mengarah
pada tujuan kami untuk lebih mendefinisikan audit internal CBOK seperti yang
dilaporkan dalam edisi ini. Ketika buku ini mulai dicetak, IIARF sekali lagi mengedarkan
beberapa formulir survei CBOK kepada para anggotanya untuk menerbitkan IIARF
CBOK yang diperbarui. Studi CBOK 2006 asli mereka telah dihapus dari catatan IIARF
dan kritik kami terhadap struktur yang buruk ini hanya tersedia di file penulis ini dalam
format hard-copy.
Auditor internal CBOK kami, sebagaimana dibahas di seluruh buku ini, tidak
didasarkan pada tanggapan dari beberapa kuesioner survei yang cukup dan tidak
terkendali, melainkan pada standar dan informasi yang dipublikasikan yang merupakan
bidang pengetahuan audit internal yang diperlukan. Selain itu, rekomendasi CBOK
kami didasarkan pada pengalaman penulis selama lebih dari 40 tahun dalam banyak
aspek audit internal. Kami telah mencoba untuk mendefinisikan CBOK auditor internal
kami dalam hal beberapa bidang utama di mana semua auditor internal harus memiliki
tingkat pengetahuan dan pemahaman yang kuat - seperti kepatuhan terhadap standar
audit internal - serta bidang lain di mana kami merekomendasikan auditor internal
tersebut harus memiliki setidaknya pengetahuan umum yang bagus.
Deskripsi kami tentang auditor internal CBOK jauh lebih besar dari sekadar
serangkaian poin-poin yang akan dirangkum dalam satu tabel atau grafik. Kerangka
kerja untuk auditor internal ini CBOK telah dibahas dalam bab-bab sebelumnya, dan di
sini kami akan merangkum CBOK dengan meninjau kembali masing-masing dari
delapan bagian buku ini dengan ringkasan kebutuhan CBOK yang dijelaskan dalam
bab-bab pendukung tersebut.
Beberapa auditor internal yang berpengalaman mungkin tidak setuju dengan
pilihan kami atas beberapa persyaratan CBOK kami, dengan mengatakan kami telah
memberikan terlalu banyak area tertentu atau bahwa kami melewatkan yang lain.
Namun, kami merasa bab-bab ini memberikan ikhtisar yang baik tentang CBOK untuk
semua auditor internal.

34.1 BAGIAN SATU: PENDIRIAN PERSYARATAN CBOK AUDIT INTERNAL

Bab 1 dan 2 di Bagian Satu membahas latar belakang dan asal-usul profesi audit
internal, serta memberikan pengantar dan diskusi tentang perlunya audit internal
 CBOK. Kami memberikan beberapa definisi profesi audit internal yang diakui dengan
baik. Profesional di semua tingkatan karir mereka sering menerima pertanyaan di
sepanjang baris "Apa yang auditor internal lakukan?" Sementara pertanyaan ini
dijawab secara lebih rinci dalam bab-bab lain, bab-bab dasar ini memberikan beberapa
definisi auditor internal dasar — persyaratan CBOK yang esensial.
Bab 2 memberikan latar belakang tentang asal-usul dan kebutuhan untuk audit
internal CBOK. Karena berbagai macam industri dan wilayah geografis di mana auditor
internal beroperasi dalam mengevaluasi kontrol internal dan membantu manajemen,
mungkin ada banyak variasi dalam mode dan gaya operasi mereka. Namun, semua
auditor internal harus memiliki beberapa keterampilan dan kompetensi dasar —
kebutuhan akan CBOK. Selain itu, auditor internal harus memahami mengapa CBOK
penting bagi profesi mereka dan mengapa mereka harus selalu berusaha mengikuti
praktik terbaik CBOK dalam setiap aspek pekerjaan audit internal mereka.

34.2 BAGIAN DUA: PENTINGNYA KONTROL INTERNAL PERSYARATAN CBOK

Lima bab di sini memperkenalkan beberapa praktik umum yang merupakan
persyaratan pengetahuan esensial untuk setiap auditor internal. Bab 3 membahas
berapa banyak perusahaan dan auditor internal mereka yang berjalan selama
bertahun-tahun tanpa pemahaman yang jelas dan konsisten tentang makna dan
konsep pengendalian internal. Namun, definisi-definisi tersebut diselesaikan dan
diklarifikasi melalui kerangka kendali internal Komite Sponsoring Organisations
(COSO), sebuah model tiga dimensi tentang bagaimana suatu perusahaan harus
mengatur dan memikirkan kontrol internalnya.
Awalnya diluncurkan sebagai semacam gambaran praktik terbaik dari kontrol
internal yang baik, kerangka kerja kontrol internal COSO menjadi yang pertama di A.S.
dan sekarang menjadi standar dunia untuk mendefinisikan dan menetapkan kontrol
internal yang baik. Kerangka kerja COSO direvisi pada tahun 2014 untuk lebih
mencerminkan perubahan dalam operasi bisnis, pertumbuhan sistem TI yang meluas,
dan perubahan struktural organisasi umum saat ini. Bab 3 menggambarkan kerangka
kerja COSO yang direvisi, persyaratan utama CBOK auditor internal.
Baik beroperasi di lingkungan industri, sebagai auditor internal spesialis IT, atau
di sektor nirlaba atau pemerintah, setiap auditor internal harus memiliki pemahaman
CBOK tentang kerangka kerja pengendalian internal COSO yang baru direvisi.
Sebagai bagian dari kerangka kerja pengendalian internal tersebut, COSO telah
memperkenalkan 17 prinsip kontrol internal, langkah-langkah utama untuk memahami
dan mengevaluasi kontrol internal. Prinsip-prinsip COSO ini dibahas pada Bab 4.
Memahami mereka adalah persyaratan CBOK auditor internal karena mereka akan
membantu untuk merencanakan dan membangun audit internal di banyak bidang
operasi.
Pada bagian awal abad ini, serangkaian penipuan akuntansi besar dan
kegagalan bisnis di Amerika Serikat dan di tempat lain menjadi seruan untuk audit
eksternal dan reformasi tata kelola perusahaan. Hasilnya adalah Sarbanes ‐ Oxley Act
(SOx) di Amerika Serikat, sebagaimana dibahas dalam Bab 5. Sementara fokus awal
SOx pada awalnya adalah pada perusahaan-perusahaan besar AS, ia telah
menetapkan aturan dan standar pelaporan yang merupakan persyaratan bagi banyak
perusahaan, besar dan kecil, di Amerika Serikat dan di seluruh dunia. Meskipun
undang-undang SOx secara keseluruhan sangat luas dan memiliki peraturan dan
aturan di beberapa bidang yang mungkin kurang menarik bagi sebagian besar auditor
internal, pengetahuan dan pemahaman yang kuat tentang prosedur peninjauan kontrol
internal SOx harus menjadi persyaratan CBOK untuk semua auditor internal yang
bekerja dengan perusahaan publik. Selain itu, semua auditor internal harus memiliki
pemahaman CBOK umum tentang persyaratan pengendalian internal SOx dan aturan
tata kelola perusahaannya, sebagaimana dijelaskan dalam Bab 5.
Bab 6 memperkenalkan kerangka kerja kontrol internal lain yang sangat
penting, mengontrol tujuan TI (COBIT). Pemahaman tentang COBIT, kerangka kerja
pengendalian internal dengan asal terkait dengan spesialis audit TI, adalah penting
untuk semua auditor internal karena sistem dan proses TI sangat meresap dalam
semua aspek hampir setiap perusahaan saat ini. Apakah spesialis operasional,
keuangan, atau TI, semua auditor internal harus memiliki setidaknya pemahaman
CBOK tingkat tinggi tentang kerangka kerja COBIT dan bagaimana hal itu mungkin
berlaku untuk kegiatan audit internal mereka.
Bagian Dua berakhir dengan Bab 7, pada kerangka kerja manajemen risiko
perusahaan COSO (COSO ERM), sebuah model untuk membantu memahami risiko
bukan hanya dalam audit internal tunggal, tetapi keseluruhan perusahaan.
Pemahaman dasar tentang konsep-konsep dan prinsip-prinsip manajemen risiko ini
penting untuk semua auditor internal saat ini, sebagai dukungan untuk menilai
berbagai bidang untuk ditinjau dan dalam membuat keputusan audit internal lainnya.
Setiap auditor internal juga harus memiliki pemahaman CBOK tingkat tinggi tentang
COSO ERM.
34.3 BAGIAN TIGA: PERENCANAAN DAN KINERJA AUDIT INTERNAL
PERSYARATAN CBOK
Memiliki pengetahuan dan pemahaman yang baik tentang kerangka kerja
pengendalian internal COSO akan membantu auditor internal untuk memahami
beberapa prinsip dasar audit internal, tetapi auditor internal juga memerlukan
pengetahuan tentang cara merencanakan dan melakukan audit internal yang
sebenarnya. Enam bab dalam Bagian Tiga termasuk beberapa informasi latar
belakang kinerja audit internal CBOK, dimulai dengan
Bab 8 tentang pedoman melakukan audit internal yang efektif. Bab ini
menekankan bahwa kemampuan untuk merencanakan dan melakukan audit internal
individu adalah persyaratan utama CBOK, apakah itu manajer audit internal atau
anggota staf audit. Bab 8 juga membahas pentingnya membangun dan menggunakan
program audit, prosedur langkah-demi-langkah yang harus digunakan oleh auditor
internal untuk melakukan tinjauan saat ini maupun di masa mendatang yang potensial
dalam bidang topik yang sama. Auditor internal harus melakukan tinjauan
menggunakan program audit, langkah-langkah terdokumentasi yang mencakup
prosedur audit untuk diikuti. Auditor internal di semua tingkatan harus memiliki
pemahaman CBOK tentang cara membangun dan menggunakan program audit untuk
dijadikan panduan untuk membangun tinjauan audit internal yang konsisten.
Pemahaman yang sangat kuat tentang Standar Internasional Institut Auditor
Internal untuk Praktik Profesional Audit Internal adalah persyaratan CBOK audit
internal yang penting. Standar-standar ini, diringkas dalam Bab 9, adalah aturan yang
menguraikan bagaimana auditor internal harus meluncurkan, melakukan, dan
mengelola setiap tinjauan, baik dalam audit yang membuktikan keterlibatannya atau
saat melayani sebagai konsultan internal. Ini adalah perintah berjalan audit internal,
dan pengetahuan serta pemahaman yang baik tentang mereka adalah persyaratan
CBOK yang kuat.
Sementara detail teknis mereka dapat menjadi tantangan bagi sebagian orang,
semua auditor internal harus memiliki pemahaman tingkat tinggi CBOK tentang
pengambilan sampel bukti audit dan teknik pengujian. Auditor internal harus tahu
bagaimana cara melihat dengan benar bukti badan audit, menarik dan meninjau
sampel item yang sesuai dari bukti itu, dan kemudian membuat keputusan audit dan
rekomendasi dari sampel itu. Pengujian, penilaian, dan evaluasi bukti audit dibahas
dalam Bab 10.
 Dengan pertumbuhan sistem yang sangat otomatis, sekarang menjadi praktik
yang cukup umum untuk membangun kontrol dalam sistem yang menandai
pengecualian audit dan peringatan lainnya. Auditor internal menghadapi situasi ini
ketika fungsi TI perusahaan mereka memberi tahu mereka bahwa mereka memiliki
terlalu banyak e-mail terbuka atau ketika penyedia kartu kredit memberi tahu mereka
bahwa mereka telah melampaui batas biaya kredit. Jenis kontrol dan monitor ini dapat
dibangun ke dalam sistem TI untuk menyediakan proses audit berkelanjutan. Meskipun
area ini bukan persyaratan pengetahuan CBOK, teknik audit kontinu ini, seperti
dijelaskan dalam Bab 11, adalah area di mana auditor internal harus memperoleh
pengetahuan umum yang baik.
Bab 12 membahas bidang penting lain di mana auditor internal harus memiliki
pengetahuan dan kemampuan untuk melakukan audit mandiri dan menilai bagaimana
kinerja kelompok sejawat lainnya dalam fungsi audit internal yang serupa. Disebut
penilaian mandiri kontrol dan pembandingan, ini adalah area pengetahuan CBOK audit
internal. Meskipun bukan persyaratan pengetahuan dalam arti standar Bab 9, proses
penilaian diri ini harus akrab dengan auditor internal. Ini adalah area lain di mana kami
membuat perbedaan antara apa yang kami rasakan sebagai persyaratan CBOK dan
apa yang kami rasa harus dipahami oleh auditor internal yang lebih umum.
Auditor internal dihadapkan dengan berbagai kandidat audit, area potensial
untuk ditinjau untuk organisasi mereka. Kebutuhan pengendalian internal, waktu,
permintaan manajemen komite audit, dan keterbatasan waktu dan sumber daya
mencegah audit internal untuk meluncurkan ulasan tersebut untuk setiap bidang dalam
perusahaan, dan auditor internal harus menetapkan apa yang disebut daftar atau
katalog semesta audit untuk perusahaan mereka. Bab 13 menjelaskan konsep audit
universe, area di mana semua auditor internal harus memiliki pemahaman CBOK
umum yang baik.
34.4 BAGIAN EMPAT: MENGELOLA DAN MENGELOLA AKTIVITAS AUDIT INTERNAL
PERSYARATAN CBOK
Lima bab dalam Bagian Empat membahas bidang-bidang CBOK penting tentang
bagaimana fungsi audit internal harus mengelola dan melakukan audit internal, serta
beberapa keterampilan audit internal individu. Mulai bagian ini, Bab 14 membahas
piagam audit, otorisasi komite audit perusahaan resmi untuk fungsi audit internal.
Piagam audit internal pada umumnya dirancang dan disetujui oleh komite audit dewan
direksi. Ini adalah jenis dokumen yang dapat digunakan oleh auditor internal ketika
aktivitasnya dipertanyakan dalam perikatan audit internal. Seperti dijelaskan dalam bab
ini, auditor internal harus memiliki pemahaman CBOK tentang tujuan dan pentingnya
piagam audit internal.
Bab 15 melanjutkan dengan membahas beberapa kompetensi audit internal
utama, jenis-jenis atribut yang harus dimiliki auditor internal agar efektif. Secara
khusus, bab ini menjelaskan pentingnya memahami dan menjadikan manajemen risiko
sebagai faktor yang perlu dipertimbangkan dalam setiap keterlibatan audit internal.
Mirip dengan Bab 14 dan 15 uraian kompetensi audit internal utama, Bab 16
dan 17 membahas kegiatan fungsi audit individu. Manajemen proyek, kegiatan CBOK
yang sangat penting, dipresentasikan dan dibahas dalam Bab 16. Setiap audit internal
harus dianggap sebagai proyek yang harus direncanakan dan diorganisir dalam
sebuah terstruktur dengan baik, konsisten. Bab ini memberikan tinjauan umum tentang
pemahaman manajemen proyek — persyaratan CBOK. Berfokus pada auditor internal
individual, Bab 16 membahas langkah-langkah umum CBOK yang diperlukan untuk
merencanakan dan melakukan audit internal individual, menggunakan contoh hipotetis.
Bab 17 membahas auditor internal penting bidang CBOK lainnya:
mendokumentasikan hasil audit melalui kertas kerja. Meskipun proses dan teknik
terperinci dapat bervariasi dari satu fungsi audit internal ke fungsi lainnya, semua
auditor internal harus memiliki pengetahuan dan pemahaman tentang bagaimana
mengembangkan kertas kerja yang efektif untuk menggambarkan dan
mendokumentasikan aktivitas audit individual mereka.
Meskipun format dapat bervariasi dari satu fungsi audit internal ke yang lain,
kemampuan untuk melaporkan hasil audit internal melalui laporan audit yang efektif
adalah persyaratan utama CBOK. Sementara sebagian besar upaya mengembangkan
dan menyampaikan laporan audit internal formal sering didelegasikan kepada anggota
tim audit internal yang lebih senior, semua auditor internal harus memiliki pemahaman
CBOK yang kuat tentang tujuan dan peran laporan audit internal perusahaan mereka.

Bagian ini ditutup dengan Bab 18 tentang pengembangan dan penerbitan

laporan audit internal yang efektif. Apakah penerimanya adalah auditee dari review
atau komite audit, laporan audit formal menggambarkan hasil review dan termasuk
rekomendasi untuk tindakan korektif. Meskipun laporan audit akhir mungkin
merupakan produk manajemen audit internal, setiap auditor internal harus memiliki
pemahaman CBOK tentang bagaimana mengembangkan dan menyiapkan laporan
audit internal yang efektif.
34.5 BAGIAN LIMA: DAMPAKNYA PADA PERSYARATAN CBOK AUDIT INTERNAL
Karena proses TI sangat penting untuk semua bidang bisnis dan operasi lainnya saat
ini, keenam bab Bagian Lima menjelaskan beberapa bidang CBOK yang sangat
penting. Bab 19 membahas pelaksanaan kontrol umum TI serta praktik terbaik
Infrastruktur Infrastruktur Teknologi Informasi (ITIL®) untuk memahami dan menginstal
prosedur kontrol infrastruktur TI. Ini adalah area CBOK di mana setiap auditor internal
harus memiliki pemahaman umum.
Sementara kontrol umum yang mencakup fungsi TI secara keseluruhan adalah
penting, kontrol internal yang mencakup aplikasi TI spesifik setidaknya sama
pentingnya. Untuk hampir semua auditor internal, pemahaman CBOK tentang konsep-
konsep kontrol TI ini sangat penting karena banyak aplikasi TI dan tanggung jawab
kontrol internal mereka telah beralih dari fungsi TI tradisional yang terpusat ke kontrol
individual yang dikelola pengguna. Auditor internal harus memiliki pemahaman CBOK
yang baik tentang kontrol aplikasi TI di lingkungan terminal nirkabel genggam dan
sumber daya penyimpanan berbasis cloud saat ini.
Dengan ketergantungan kami pada aplikasi dan proses TI serta penggunaan
Internet dan aplikasi yang banyak jaringan dan sumber daya TI, sumber daya TI yang
sama ini menghadapi banyak ancaman keamanan dan privasi. Bab 20 membahas
keamanan siber dan kontrol privasi TI. Sementara masalah keamanan TI seringkali
merupakan bidang yang sangat khusus dan kompleks, auditor internal harus mencoba
untuk mendapatkan pemahaman CBOK tingkat tinggi secara keseluruhan tentang
masalah pengendalian internal keamanan siber.
Teknologi TI selalu berubah dan beberapa bidang yang dianggap penting di
masa lalu hampir tidak ada perubahannya saat ini, sementara yang lain semakin
penting secara internal. Bab 21 memperkenalkan salah satu bidang baru ini, yang kami
sebut big data. Banyak sistem TI perusahaan tumbuh dengan kecepatan tinggi, dan
perusahaan, pelanggan mereka, dan sering kali regulator semakin mengharuskan
catatan TI yang besar dan historis dipertahankan. Big data menimbulkan masalah
kontrol internal, dan auditor internal harus memiliki pemahaman CBOK yang baik
tentang konsep-konsep ini.
Sama seperti auditor internal perlu memahami prinsip-prinsip kontrol internal
utama, mereka juga harus dapat menggunakan pemahaman itu untuk membiarkan
proses TI membantu mereka dalam prosedur audit internal mereka. Bab 22 membahas
 prosedur audit internal untuk meninjau kontrol manajemen aplikasi TI serta kontrol
internal manajemen perangkat lunak. Meskipun ada banyak pendekatan dan teknik
potensial di sini, auditor internal harus memiliki pemahaman umum CBOK tentang
kontrol aplikasi TI dasar serta penggunaan generator laporan dan alat kueri lainnya
yang berpotensi dapat membuat tinjauan aplikasi audit internal lebih efisien dan
produktif.
Sejumlah besar sistem aplikasi dan sumber daya TI yang terhubung ke Internet
melalui tautan nirkabel, kontrol akses, dan kerentanan keamanan semakin meningkat.
Bab 23 membahas kontrol internal keamanan dunia maya serta persyaratan kepatuhan
untuk beberapa undang-undang privasi penting. Kontrol keamanan siber TI adalah
area yang terus tumbuh dan lebih kompleks. Pengetahuan dan alat khusus diperlukan,
dan meskipun auditor internal tipikal tidak akan menjadi ahli TI dalam bidang
keamanan dan privasi ini, semua auditor internal harus memiliki pemahaman CBOK
yang baik tentang keamanan TI dan kontrol privasi.
Bab terakhir di Bagian Lima, Bab 24, membahas perencanaan kesinambungan
bisnis dan pemulihan bencana. Ini adalah area di mana teknologi telah membuatnya
jauh lebih mudah daripada tahun-tahun terakhir bagi perusahaan untuk menyimpan
data yang tersimpan IT untuk memulihkan operasi setelah kejadian yang tidak terduga.
Sementara ini dulunya sangat banyak bidang auditor spesialis TI, hari ini setiap auditor
internal harus memiliki pemahaman CBOK yang baik tentang perencanaan kontinuitas
TI dan operasi pemulihan.

34.6 BAGIAN ENAM: AUDIT INTERNAL DAN TATA KELOLA USAHA PERSYARATAN
CBOK
Telah ada pengakuan yang berkembang tentang pentingnya penipuan tingkat
perusahaan, dan masalah etika telah membuat banyak aspek dunia bisnis semakin
kompleks dan telah menambah kebutuhan CBOK auditor internal. Keempat bab di
Bagian Enam melihat pentingnya isu-isu GRC — tata kelola, risiko, dan kepatuhan —
serta bidang terkait di mana auditor internal harus mengembangkan pemahaman
umum CBOK.
Bab 25 membahas komunikasi dan hubungan audit internal dengan komite
audit dewan direksi. Walaupun ini merupakan persyaratan penting, terutama untuk
CAE, semua anggota fungsi audit internal harus memiliki pemahaman CBOK umum
tentang peran komite audit perusahaan mereka dalam operasi audit internal, dan
khususnya peran itu dalam perusahaan spesifik mereka sendiri. Sekali lagi, ini adalah
 area di mana semua auditor internal perlu mengembangkan pemahaman CBOK yang
baik tentang program yang efektif dan mengapa mereka penting untuk audit internal.
Dalam pengertian yang serupa, Bab 26 membahas etika perusahaan dan
program whistleblower, inisiatif penting di banyak perusahaan. Dimulai dengan kode
etik yang kuat yang mencakup semua pihak, eksekutif senior perusahaan harus
menyiarkan pesan nada-at-the-top tentang pentingnya kebijakan ini. Auditor internal
harus memiliki keterampilan CBOK untuk mencari kebijakan yang efektif dalam
tinjauan mereka dan juga harus menjadikan mereka bagian dari kegiatan audit internal
normal mereka. Ini benar-benar persyaratan CBOK, bukan bidang pengetahuan
umum.
Memahami deteksi dasar penipuan dan kontrol pencegahan, seperti dibahas
dalam Bab 27, harus menjadi persyaratan CBOK untuk semua auditor internal. Selama
bertahun-tahun, standar profesional tidak meminta auditor internal untuk memiliki
keterampilan mencari kecurangan. Banyak hal telah berubah. Sementara auditor
internal tipikal saat ini tidak perlu licik, semua auditor internal harus mendapatkan
tingkat keterampilan CBOK yang baik dalam meninjau dan mendeteksi indikator-
indikator merah yang menunjukkan kemungkinan kecurangan, sebagai bagian dari
prosedur tinjauan investigasi kecurangan audit internal audit umum.
Bab 27 memperkenalkan pentingnya program-program GRC yang efektif dalam
suatu perusahaan. Sementara konsep tata kelola, penilaian risiko, dan kepatuhan
terhadap peraturan dan peraturan perusahaan merupakan elemen penting dari semua
kegiatan audit internal, auditor internal di seluruh dunia harus mengembangkan
pemahaman CBOK tentang proses dan aturan yang mengatur kepatuhan di
perusahaan mereka sendiri serta dalam hal yang relevan negara dan lokasi.

34.7 BAGIAN TUJUH: PERSYARATAN CBOK PROFESIONAL AUDITOR INTERNAL

Sementara bagian lain dalam buku ini lebih fokus pada mengelola dan melakukan
audit internal, Bagian Tujuh melihat beberapa bidang CBOK penting lainnya. Bab 29
membahas sertifikasi profesional audit internal, dengan penekanan pada Auditor
Internal Bersertifikat (CIA) dan penunjukan Auditor Sistem Informasi (CISA)
Bersertifikat. Walaupun pencapaian ini tidak selalu merupakan persyaratan CBOK,
semua auditor internal setidaknya harus memiliki pemahaman tentang sertifikasi
profesional ini dan persyaratan untuk mencapainya. Semua auditor internal harus
berusaha untuk mencapai salah satu atau kedua kredensial ini.
 Bab 30 membahas peran auditor internal sebagai konsultan bisnis. Suatu
praktik yang dilarang oleh standar audit internal hingga beberapa tahun terakhir,
menjadi konsultan internal dapat menjadi peran yang sangat penting untuk audit
internal dan organisasi perusahaannya dalam banyak situasi. Auditor internal harus
memiliki pengetahuan CBOK umum yang baik tentang aturan standar audit internal
untuk melayani sebagai konsultan perusahaan.

34.8 BAGIAN DELAPAN: SISI LAIN DARI AUDIT INTERNAL: KONVERGENSI

PROFESIONAL PERSYARATAN CBOK
Bagian terakhir dari diskusi persyaratan CBOK kami memperkenalkan perlunya auditor
internal untuk memiliki pemahaman yang lebih besar tentang beberapa masalah audit
internal yang melampaui audit internal terkait-IIA dan standar-standarnya. Bab 31
memperkenalkan bidang audit kualitas internal ASQ. Prosedur audit internal ini
dikendalikan di Amerika Diberikan oleh American Society for Quality (ASQ), dan
memiliki banyak jalinan bersama dengan proses IIA yang dibahas di sebagian besar
buku ini. Hampir pasti akan ada konvergensi dari beberapa prosedur IIA dan ASQ di
masa depan, dan semua auditor internal harus mengembangkan setidaknya
pemahaman CBOK tentang standar dan prosedur audit internal kualitas ASQ.
Banyak auditor internal bekerja di bidang manufaktur dan proses yang terkait
dengan kontrol di mana konsep seperti Six Sigma dan apa yang disebut teknik Lean
sangat penting bagi perusahaan. Proses-proses ini, yang dibahas pada Bab 32, lebih
akrab di lantai produksi daripada di kantor administrasi. Bila perlu, auditor internal
harus memiliki pemahaman CBOK tingkat tinggi tentang konsep-konsep ini dan harus
memasukkan kepatuhan mereka dalam kegiatan peninjauan mereka.
Bab 33 memperkenalkan standar internasional Organisasi Internasional untuk
Standardisasi (ISO), dengan penekanan pada kualitas organisasi dan standar
manajemen TI. Standar dan upaya kepatuhan untuk memenuhinya telah diterapkan di
seluruh dunia selama beberapa tahun. Mereka semakin muncul di lingkungan A.S.,
dan auditor internal yang telah bekerja di lingkungan standar IIA selama bertahun-
tahun harus mendapatkan pemahaman CBOK yang lebih besar tentang standar ISO
ini dan konsep pendukungnya. Bab 33 juga sangat singkat memperkenalkan beberapa
standar akuntansi dan audit di seluruh dunia. Secara khusus, apa yang disebut
Standar Akuntansi Internasional telah menjadi standar yang disukai hampir di semua
tempat di dunia, dengan pengecualian Amerika Serikat, yang menggunakan apa yang
disebut prinsip akuntansi yang berlaku umum (GAAP). Amerika Serikat sekarang
 mengambil langkah untuk beralih dari GAAP ke standar internasional. Meskipun ini
tidak memiliki dampak besar pada prosedur audit internal, semua auditor internal harus
memiliki pemahaman CBOK tentang beberapa implikasi dari perubahan ini.

34.9 SEBUAH CBOK UNTUK AUDITOR INTERNAL MODERN

Topik yang dirangkum dalam bab ini dan disajikan secara lebih rinci di seluruh buku ini
menguraikan CBOK untuk auditor internal hari ini. Beberapa di antaranya, seperti Bab
3 tentang kerangka kerja pengendalian internal COSO atau Bab 9 tentang standar
audit internal IIA, adalah bidang pengetahuan CBOK yang penting. Banyak yang lain
mencakup bidang-bidang di mana auditor internal setidaknya harus memiliki
pemahaman umum yang baik.
Banyak bidang pengetahuan berada di luar kebutuhan dan persyaratan
mendesak dari banyak auditor internal. Namun, semua auditor internal, dari CAE yang
bertanggung jawab atas fungsi audit internal perusahaan yang besar kepada siswa
yang mempertimbangkan audit internal sebagai pilihan karier, dapat melihat kumpulan
besar pengetahuan yang merupakan bagian dari dunia audit internal.
Tampilan 34.1 merangkum keseluruhan topik CBOK yang dibahas di seluruh
buku ini, dengan referensi ke bab di mana dibahas dan apakah masalah tersebut harus
menjadi persyaratan atau bidang pemahaman.
Edisi ini telah melukiskan gambaran besar tentang dunia audit internal di dunia
kita yang selalu berubah saat ini. Sementara banyak persyaratan CBOK audit internal
yang diuraikan di seluruh bab ini akan terus menjadi penting dan signifikan, beberapa
bidang penekanan atau topik mungkin bertambah atau berkurang di tahun-tahun
mendatang. Edisi masa depan ini
MEMPERLIHATKAN 34.1 Ringkasan BUKU Audit Internal
Kebutuhan Pengetahuan Auditor
Internal CBOK Area Konsentrasi CBOK Pentingnya CBOK Bab Ref
Ulasan analitik Mengatur dan Mengelola Persyaratan Pengetahuan Bab 15
Kegiatan Audit Internal Audit Internal
Menilai risiko audit internal Merencanakan dan Melakukan Persyaratan Pengetahuan Bab 7
Audit Internal Audit Internal
Piagam komite audit Masalah Tata Kelola Pemahaman Umum Bab 14
Perusahaan Audit Internal
Tanggung jawab komite audit Mengatur dan Mengelola Pemahaman Umum Bab 14
Kegiatan Audit Internal
Mengatur dan Mengelola Kegiatan Masalah Tata Kelola Pemahaman Umum Bab 25
Audit Internal Perusahaan Audit Internal
Teknik pengambilan sampel audit Merencanakan dan Melakukan Pemahaman Umum Bab 10
Audit Internal
Konsep audit semesta Merencanakan dan Melakukan Pemahaman Umum Bab 13
Audit Internal
Merencanakan dan melakukan Audit Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 24
Internal Internal Audit Internal
Mengaudit untuk penipuan Masalah Tata Kelola Persyaratan Pengetahuan Bab 27
Perusahaan Audit Internal Audit Internal
Mengaudit proses GRC Masalah Tata Kelola Persyaratan Pengetahuan Bab 28
Perusahaan Audit Internal Audit Internal
Audit dalam lingkungan komputasi Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 20
nirkabel Internal Audit Internal
Mengaudit proses manajemen Dampak Sistem TI pada Audit Pemahaman Umum Bab 19
konfigurasi TI Internal
Mengaudit kontrol akses jaringan TI Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 23
Internal Audit Internal
Mengaudit kontrol privasi TI Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 23
Internal Audit Internal
Mengaudit infrastruktur TI Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 19
Internal Audit Internal
Membangun fungsi audit internal yang Mengatur dan Mengelola Pemahaman Umum Bab 15
efektif Kegiatan Audit Internal
Konsep BYOD Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 20
Internal Audit Internal
Panduan kontrol internal COBIT Pentingnya Kontrol Internal Persyaratan Pengetahuan Bab 6
Audit Internal
Konsep Umum Tubuh Pengetahuan Yayasan Audit Internal Pemahaman Umum Bab 2
Teknik audit berkelanjutan Merencanakan dan Melakukan Pemahaman Umum Bab 11
Audit Internal
Kontrol penilaian diri Merencanakan dan Melakukan Pemahaman Umum Bab 12
Audit Internal

Bab
Bab
Bab
Bab
Bab
Kebutuhan Pengetahuan
Auditor Internal CBOK Area Konsentrasi CBOK Pentingnya CBOK Bab Ref
Manajemen risiko COSO ERM Pentingnya Kontrol Internal Persyaratan Pengetahuan Bab 7
Audit Internal
Prinsip-prinsip kontrol internal Pentingnya Kontrol Internal Persyaratan Pengetahuan Bab 4
COSO Audit Internal
Kerangka kerja pengendalian Pentingnya Kontrol Internal Persyaratan Pengetahuan Bab 3
internal COSO Audit Internal
Definisi audit internal Yayasan Audit Internal Persyaratan Pengetahuan Bab 1
Audit Internal
Mengembangkan program audit Merencanakan dan Melakukan Persyaratan Pengetahuan Bab 8
Audit Internal Audit Internal
Pengujian rencana pemulihan Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 24
bencana Internal Audit Internal
Mendokumentasikan hasil audit Mengatur dan Mengelola Persyaratan Pengetahuan Bab 15
internal Kegiatan Audit Internal Audit Internal
Mendokumentasikan hasil audit Mengatur dan Mengelola Persyaratan Pengetahuan Bab 17
internal Kegiatan Audit Internal Audit Internal
Kontrol internal manajemen Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 21
konten perusahaan Internal Audit Internal
Keakraban dengan standar audit Konvergensi Profesional Audit Pemahaman Umum Bab 31
jaminan kualitas ASQ Internal
Keakraban dengan masalah Dampak Sistem TI pada Audit Pemahaman Umum Bab 23
malware dan peretasan TI Internal
Keakraban dengan kerangka kerja Dampak Sistem TI pada Audit Pemahaman Umum Bab 23
cybersecurity NIST Internal
Pentingnya kode etik perusahaan Masalah Tata Kelola Persyaratan Pengetahuan Bab 26
Perusahaan Audit Internal Audit Internal
Pentingnya program kepatuhan Masalah Tata Kelola Pemahaman Umum Bab 26
perusahaan Perusahaan Audit Internal
Latar belakang dan riwayat audit Yayasan Audit Internal Pemahaman Umum Bab 1
internal
Piagam audit internal Mengatur dan Mengelola Persyaratan Pengetahuan Bab 14
Kegiatan Audit Internal Audit Internal
Kode etik audit internal Merencanakan dan Melakukan Persyaratan Pengetahuan Bab 9
Audit Internal Audit Internal
Standar profesional audit internal Merencanakan dan Melakukan Persyaratan Pengetahuan Bab 9
Audit Internal Audit Internal
Tinjauan jaminan kualitas audit Konvergensi Profesional Audit Persyaratan Pengetahuan Bab 33
internal Internal Audit Internal
Teknik jaminan kualitas audit Merencanakan dan Melakukan Pemahaman Umum Bab 12
internal Audit Internal
Kertas kerja audit internal Mengatur dan Mengelola Persyaratan Pengetahuan Bab 17
Kegiatan Audit Internal Audit Internal
Alat dokumentasi kontrol internal Merencanakan dan Melakukan Persyaratan Pengetahuan Bab 8
Audit Internal Audit Internal
MEMPERLIHATKAN 34.1 (Lanjutan )
Kebutuhan Pengetahuan
Auditor Internal CBOK Area Konsentrasi CBOK Pentingnya CBOK Bab Ref
Standar audit internasional Konvergensi Profesional Audit Persyaratan Pengetahuan Bab 33
Internal Audit Internal
Kerangka Praktik Profesional Merencanakan dan Persyaratan Pengetahuan Bab 9
Internasional (IPPF) Melakukan Audit Internal Audit Internal
Standar audit kualitas ISO 9000 Konvergensi Profesional Audit Pemahaman Umum Bab 33
Internal
Standar ISO untuk kualitas Konvergensi Profesional Audit Pemahaman Umum Bab 31
Internal
Standar tata kelola TI Konvergensi Profesional Audit Persyaratan Pengetahuan Bab 34
Internal Audit Internal
Persyaratan CBOK audit internal Konvergensi Profesional Audit Persyaratan Pengetahuan Bab 27
modern Internal Audit Internal
Melakukan investigasi penipuan Masalah Tata Kelola Persyaratan Pengetahuan Bab 13
Perusahaan Audit Internal Audit Internal
Merencanakan dan menetapkan Merencanakan dan Persyaratan Pengetahuan Bab 8
area yang akan diaudit Melakukan Audit Internal Audit Internal
Menyiapkan laporan audit Mengatur dan Mengelola Persyaratan Pengetahuan Bab 18
Kegiatan Audit Internal Audit Internal
Mempersiapkan diagram alur audit Mengatur dan Mengelola Persyaratan Pengetahuan Bab 17
internal Kegiatan Audit Internal Audit Internal
Pemodelan proses Mengatur dan Mengelola Persyaratan Pengetahuan Bab 17
Kegiatan Audit Internal Audit Internal
Badan pengetahuan manajemen Mengatur dan Mengelola Pemahaman Umum Bab 16
proyek (PMBOK) Kegiatan Audit Internal
Melaporkan hasil audit internal Mengatur dan Mengelola Persyaratan Pengetahuan Bab 18
Kegiatan Audit Internal Audit Internal
Pelaporan ke komite audit Masalah Tata Kelola Persyaratan Pengetahuan Bab 25
perusahaan Perusahaan Audit Internal Audit Internal
Meninjau kontrol manajemen Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 22
perangkat lunak aplikasi Internal Audit Internal
Meninjau validitas big data dan Dampak Sistem TI pada Audit Pemahaman Umum Bab 21
kontrol internal volume Internal
Meninjau program etika dan Masalah Tata Kelola Persyaratan Pengetahuan Bab 26
whistleblower Perusahaan Audit Internal Audit Internal
Sarbanes - Oxley Act Persyaratan Pentingnya Kontrol Internal Persyaratan Pengetahuan Bab 5
kontrol internal Audit Internal
Konsep Six Sigma Black Belt Konvergensi Profesional Audit Pemahaman Umum Bab 32
Internal
Statistik dan pengambilan sampel Merencanakan dan Pemahaman Umum Bab 10
atribut Melakukan Audit Internal
Kebutuhan Pengetahuan
Auditor Internal CBOK Area Konsentrasi CBOK Pentingnya CBOK Bab Ref
Menguji rencana kesinambungan Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 24
bisnis Internal Audit Internal
Memahami attest versus peran Masalah Tata Kelola Persyaratan Pengetahuan Bab 30
konsultasi Perusahaan Audit Internal Audit Internal
Memahami aturan pelapor komite Masalah Tata Kelola Persyaratan Pengetahuan Bab 25
audit Perusahaan Audit Internal Audit Internal
Memahami tata kelola big data Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 21
Internal Audit Internal
Memahami CIA, CISA, dan Masalah Tata Kelola Pemahaman Umum Bab 29
sertifikasi lainnya Perusahaan Audit Internal
Memahami risiko kebocoran data Dampak Sistem TI pada Audit Pemahaman Umum Bab 21
Internal
Memahami rencana pemulihan Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 24
bencana Internal Audit Internal
Memahami masalah tata kelola Masalah Tata Kelola Pemahaman Umum Bab 28
perusahaan Perusahaan Audit Internal
Memahami standar audit penipuan Masalah Tata Kelola Persyaratan Pengetahuan Bab 27
IIA, AICPA, dan ACFE Perusahaan Audit Internal Audit Internal
Memahami pentingnya pernyataan Masalah Tata Kelola Pemahaman Umum Bab 26
misi Perusahaan Audit Internal
Memahami peran audit internal Masalah Tata Kelola Persyaratan Pengetahuan Bab 30
sebagai konsultan perusahaan Perusahaan Audit Internal Audit Internal
Memahami rencana tanggap Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 24
darurat TI Internal Audit Internal
Memahami kontrol umum TI Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 19
Internal Audit Internal
Memahami perjanjian tingkat Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 19
layanan TI Internal Audit Internal
Memahami praktik terbaik ITIL® Dampak Sistem TI pada Audit Pemahaman Umum Bab 19
Internal
Memahami proses audit kualitas Konvergensi Profesional Audit Pemahaman Umum Bab 31
ASQ Internal
Memahami kontrol cybersecurity Dampak Sistem TI pada Audit Pemahaman Umum Bab 23
dan privasi PCI DSS Internal
Memahami manajemen proyek Mengatur dan Mengelola Persyaratan Pengetahuan Bab 16
Kegiatan Audit Internal Audit Internal
Memahami risiko komputasi media Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 20
sosial Internal Audit Internal
Memahami perangkat lunak Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 22
sebagai fungsi layanan Internal Audit Internal
Memahami siklus hidup Dampak Sistem TI pada Audit Persyaratan Pengetahuan Bab 22
pengembangan sistem proses TI Internal Audit Internal
 buku mungkin melukiskan gambaran yang sedikit berbeda, tetapi kami telah mencoba
menyajikan dalam edisi ini CBOK untuk auditor internal hari ini untuk digunakan dalam
layanan audit internal mereka untuk kegiatan manajemen.

CATATAN
1. Institute of Internal Auditor Research Foundation, A Global Summary of Common
Body of Knowledge (Altamonte Springs, FL: 2006 diterbitkan lagi oleh IIARF
sebagai studi CBOK pada 2007). Namun, IIRF telah membersihkan studi ini dan
menghapus semua versi dari catatan publiknya.