Anda di halaman 1dari 23

CHAPTER 15 (I)

Kontrol IT Bagian I: Sarbanes-Oxley dan IT Governance

Adapun fokus bahasan terkait kontrol it bagian i: sarbanes-oxley dan it governance, yaitu :
a. Memahami fitur utama dari Bagian 302 dan 404 dari SarbanesOxley Act.
b. Memahami tanggung jawab manajemen dan auditor berdasarkan Bagian 302 dan
404.
c. Memahami risiko fungsi yang tidak sesuai dan bagaimana menyusun fungsi TI.
d. Kenali kontrol dan tindakan pencegahan yang diperlukan untuk memastikan
keamanan fasilitas komputer organisasi.
e. Memahami elemen kunci dari rencana pemulihan bencana. Kenali manfaat, risiko,
dan masalah audit terkait dengan outsourcing TI.

A. Gambaran Umum SOX Bagian 302 dan 404


Sarbanes-Oxley Act (SOA) merupakan sebuah produk hukum (Undang-Undang) di
Amerika Serikat (AS) yang mengatur tentang akuntabilitas, praktik akuntansi dan
keterbukaan informasi, termasuk tata cara pengelolaan data di perusahaan publik. Namun di
Indonesia baru sebagian kecil yang baru menerapkan aturan tersebut.
1. Seksi 302
SOX’s Act 2002 seksi 302 ini mewajibkan manajemen perusahaan (termasuk chief
executive officer [CEO]) untuk mengesahkan informasi keuangan dan informasi lainnya
yang terdapat dalam laporan tahunan dan tahunan organisasi. Aturan tersebut juga
mewajibkan mereka untuk mengesahkan pengendalian internal atas pelaporan keuangan.
Petugas sertifikasi diharuskan untuk merancang pengendalian internal, atau membuat
kontrol semacam itu dirancang, dan memberikan kepastian yang memadai mengenai
keandalan proses pelaporan keuangan. Selanjutnya, mereka harus mengungkapkan setiap
perubahan material dalam pengendalian internal perusahaan yang telah terjadi selama
kuartal fiskal terakhir.
2. Seksi 404
SOX’s Act seksi 404 ini berisi kewajiban bagi manajemen perusahaan untuk menilai
internal control yang sudah dilaksanakan atas laporan keuangannya;
1. Perusahaan harus mengevaluasi internal kontrol atas laporan keuangannya
setiap tahun. Manajemen harus menyimpulkan efektifitas dari internal kontrol
setiap akhir tahun. Pihak yang bertanggungjawab untuk mengevaluasi internal
kontrol perusahaan adalah departemen internal control/audit
2. Akuntan publik yang disewa perusahaan harus menegaskan dan melaporkan
hasil evaluasi atas internal kontrol atas laporan keuangan perusahaan.

Seksi 404 secara khusus


memberikan perhatian kepada
internal kontrol perusahaan atas
laporan keuangannya. Dalam
mengevaluasi internal kontrol yang
dilaksanakan perusahaan, manajemen
melalui departemen internal
kontrol/audit perlu menggunakan
kerangka yang disusun oleh COSO
(Committee of Sponsoring Organization
of the Tradeway Commission).

Hubungan Antara Kontrol Ti Dan Pelaporan Keuangan


Teknologi informasi mendorong proses pelaporan keuangan organisasi modern.
Sistem otomatis memulai, mengotorisasi, mencatat, dan melaporkan dampak dari transaksi
keuangan. Dengan demikian, elemen inextrica-ble dalam proses pelaporan keuangan yang
dipertimbangkan SOX dan harus dikendalikan. SAS 78 / COSO mengidentifikasi dua
pengelompokan kontrol sistem informasi yang luas: kontrol aplikasi dan kontrol umum.
Tujuan pengendalian aplikasi adalah untuk memastikan validitas, kelengkapan, dan
keakuratan transaksi keuangan. Kontrol ini dirancang khusus untuk aplikasi. Kelompok
kontrol kedua yang diketahui SAS 78 / COSO mengidentifikasi adalah kontrol umum.
Kontrol umum memiliki nama lain dalam kerangka kerja lain, termasuk kontrol komputer
umum dan kontrol teknologi informasi. Apapun nama yang digunakan, termasuk kontrol atas
tata kelola TI, infrastruktur TI, keamanan dan akses ke sistem operasi dan database, akuisisi
dan pengembangan aplikasi, dan perubahan program.
Pengendalian dan keamanan pusat komputer

Auditor secara rutin mempelajari lingkungan fisik pusat komputer sebagai bagian dari
audit. Dalam pembahasan ini terkait risiko kebakaran, banjir, kerusuhan, dan sabotase
berpotensi mengancam informasi, catatan akuntansi, kapabilitas pemrosesan transaksi, dan
kemampuan perusahaan untuk bertahan hidup.

Tujuan audit yang berkaitan dengan keamanan komputer:

Tujuan auditor adalah mengevaluasi pengendalian yang mengatur keamanan pusat


k6mputer. Secara khusus, auditor harus memverifikasi bahwa (1) pengendalian keamanan
fisik memadai untuk melindungi organisasi dan berbagai eksposur fisik; (2) jaminan asuransi
pada peralatan cukup untuk memberikan kompensasi pada perusahaan ketika terjadi
kerusakan, atau bencana, pada pusat komputer; (3) dokurnentasi operator tersebut memadai
untuk kegiatan operasi rutin dan ketika terjadi kegagalan sistem; dan (4) rencana pemulihan
kerusakan organisasi itu memadai dan layak.

1. Prosedur audit untuk menilai pengendalian keamanan fisik:


a) Pengujian Konstruksi Fisik
Auditor harus menentukan apakah pusat komputer dibangun dengan bahan yang
tahan api. Konstruksi ini juga harus memiliki saluran air di lantai atas, sehingga air
bisa mengalir jika terjadi musibah kebakaran di lantai atas atau dan sumber lainnya.
Selain itu, auditor harus mengevaluasi lokasi fisik dan pusat komputer. Fasilitas ini
harus terletak di wilayah yang cenderung tidak terkena eksposur kebakaran,
kerusuhan, dan kekacauan lainnya.
b) Pengujian Sistem Deteksi Kebakaran
Auditor harus memastikan bahwa peralatan pemadam dan pendeteksi api, baik
manual maupun otomatis, memang ada dan diuji secara berkala. Sistein pendetcksi
kebakaran ini harus bisa mendeteksi asap, panas, dari bahan yang rnudah terbakar.
Kecukupan peralatan ini dapat ditentukan dengan memeriksa catatan pengujian dari
petugas pemadam kebakaran resmi yang disimpan di pusat komputer.
c) Pengujian Pengendalian Akses
Auditor harus memastikan bahwa akses rutin ke pusat komputer tersebut dibatasi
hanya pada karyawan yang memiliki otorisasi. Perincian rentang akses pengunjung
(oleh programer dan lainnya), seperti waktu kedatangan dan keberangkatan, tujuan,
dan frekuensi akses, dapat diperoleh dengan memeriksa catatan harian akses. Untuk
menjaga keaslian dokumen ini, auditor dapat mengamati proses tersebut dan secara
tertutup mengamati akses mana saja yang diizinkan.
d) Pengujian Pasokan Listrik Cadangan
Pusat komputer harus melakukan pengujian secara berkala terhadap pasokan listrik
cadangan untuk memastikan pasokan listrik tersebut memiliki cukup kapasitas untuk
menjalankan komputer dan pendingin udara sekaligus ini adalah pengujian yang
sangat penting, dan hasilnya harus dicatat secara formal. Ketika fungsi komputer
perusahaan berkembang, listrik cadangan juga akan bertambah juga secara
proporsional. Tentu saja, tanpa pengujian seperti itu, perusahaan mungkin tidak
menyadari bahwa kapasitas listrik cadangannya tidak mencukupi sampai akhirnya
sudah terlambat.
2. Prosedur audit yang memverifikasi jaminan asuransi:
Setiap tahun auditor harus memeriksa jaminan asuransi perusahaan untuk peranti keras,
peranti lunak, dan fasilitas fisik komputernya. Auditor harus rnemverifikasi bahwa semua
akuisisi baru sudah tercantun dalam polis serta peralatan dan peranti lunak yang usang sudah
dihapus. Polis asuransi ini harus mencerminkan kebutuhan manajemen dalarn hal jaminan
asuransi dan biaya. Misalnya, perusahaan mungkin berharap agar diasuransikan sebagian dan
memerlukan jaminan minimum. Di samping itu, perusahaan mungkin juga membutuhkan
jaminan penggantian biaya yang lengkap.
3. Prosedur audit untuk memverifikasi kecukupan dokumentasi operator:
Operator komputer menggunakan dokumentasi yang disebut petunjuk operasi (run manual)
untuk menjalankan aspek-aspek tertentu dari sistem. Secara khusus, sistem batch skala besar
sering kali memerlukan perhatian khusus dari para operator. Selama jam kerja, operator
komputer mungkin menjalankan lusinan program komputer, yang masing-masing memproses
banyak file dan menghasilkan banyak laporan. Untuk mewujudkan operasi pemrosesan data
yang efektif, manual operasi harus diperinci secara memadai untuk mengarahkan operator
dalam menjalankan tugasnya. Auditor harus memvenifikasi juga bahwa dokumentasi sistem
lainnya, seperti bagan alir sistem, bagan alir logis, dan daftar kode program, bukan
merupakan bagian dan dokurnentasi operasi. Operator tidak boleh rnemiliki akses ke
perincian opërasional dan logika nternãl sistem.
4. Prosedur audit untuk menilai rencana pemulihan dari bencana:
Auditor harus memverifikasi bahwa rencana pemulihan dan bencana (disaster recovery
plan—DRP) yang dimiliki manajemen, realistis dalam menghadapi bencana yang akan
merusak sumber daya komputer organisasi. Pengujian berikut ini berkaitan dengan wilayah-
wilayah yang paling diperhatikan untuk DRP.

a) Cadangan Lokasi Kedu


Auditor harus mengevaluasi kecukupan pengaturan lokasi cadangan. Inkompatibilitas
sistem dan sifat manusia dapar sangat mengurangi efektivitas bantuan yang saling
menguntungkan. Auditor harus bersikap skeptis terhadap pengaturan seperti itu
karena dua alasan. Pertarna, kecanggihan sistem komputer akan menyulitkan untuk
menemukan mitra potensial yang konfigurasi sistem komputernya cocok. Kedua,
kebanyakan perusahaan tidak memiliki kapasitas berlebih yang diperlukan untuk
mendukung mitranya ketika terjadi kerusakan, sambil tetap memproses pekerjaannya
sendiri. Jika terjadi “kegentingan” (crunch), manajemen perusahaan yang tidak
mengalami kerusakan biasanya enggan berkorban demi menghorrnati perjanjian
tersebut.
b) Daftar Aplikasi Penting
Auditor dapat rneninjau daftar aplikasi penting untuk mcyakinkan bahwa hal tersebut
telah lengkap. Kehilangan aplikasi dapat benakibat terhadap kegagalan pemulihan
kembali. Akan tetapi, hal yang sama juga berlaku untuk pemulihan aplikasi yang
tidak perlu. Mencanturnkan aplikasi dalam daftar penting kritis yang tidak diperlukan
untuk mendapatkan kelangsungan dalarn jangka pendek dapat mengalihkan perhatian
dan tujuan utama selama periode pemulihan.
c) Cadangan untuk Aplikasi Pentin
Auditor harus memerifikasi bahwa salinan program yang penting disimpan di luar
lokasi (off-site). Ketika terjadi bencana atau kegagalan sistem, aplikasi program akan
dapat rnerekonstruksi versi cadangan dan sistern tersebut.
d) Cadangan File Data Penting
Auditor harus rnernveriflkasi bahwa file data penting dibuatkan cadangannya sesuai
dengan DRP. Prosedur pembuatan cadangan data didiskusikan dalarn pembahasan
pengendalian sumber daya data.
e) Cadangan Pasokan, Dokumen Sumber, dan Dokumentasi
Dokumentasi sistem, pasokan, dan dokumen sumber yang diperlukan untuk
mernulihkan dan menjalankan apliksi yang penting harus dibuarkan cadangannya,
dan disimpan di luar lokasi. Auditor harus memverifikasi bahwa jenis dan jumlah
barang tertentu dalam DRP berada di lokasi yang aman. Contoh pasokan penting
adalah stok buku cek, faktur, pesanan pembayaran, dan barang penting lainnya yang
tidak dapat diperoleh dengan mudah.
f) Tim Pemulihan dan Bencana
DRP harus secara jelas menyebutkan nama, alamat, dan nomor telepon penting pada
anggota tim DRP. Auditor harus memverifikasi bahwa anggota tim adalah karyawan
yang ada saat ini, dan mengetahui dengan pasti mengenai tanggung jawabnya. Pada
suatu ketika, ketika sedang meninjau DRP suatu perusahaan, penulis menemukan
bahwa pemimpin tim DRP yang tertulis dalam rencana tersebut telah meninggal
sembilan bulan lalu.

Risiko Inherent It Itu Outsourcing


Kegiatan outsourcing IT skala besar adalah usaha yang berisiko, sebagian karena
ukuran semata dari kesepakatan keuangan ini, tetapi juga karena sifatnya. Tingkat risiko
terkait dengan tingkat kekhususan aset dari fungsi alih daya. Bagian berikut menguraikan
beberapa masalah terdokumentasi dengan baik.
a) Gagal tampil
Begitu perusahaan klien telah mengalihkan aset TI spesifiknya, kinerjanya menjadi
terkait dengan kinerja vendor. Implikasi negatif dari ketergantungan tersebut
diilustrasikan dalam masalah keuangan yang telah melanda vendor outsourcing besar
Electronic Data Systems Corp. (EDS).
b) Eksploitasi Vendor
Pengalihan TI berskala besar melibatkan pengiriman ke aset khusus vendor 'seperti
disain, pengembangan, dan pemeliharaan aplikasi bisnis unik yang penting bagi
kelangsungan hidup sebuah organisasi. Seiring kebutuhan TI klien berkembang dari
waktu ke waktu di luar persyaratan kontrak awal, risiko akan berlanjut jika layanan
baru atau tambahan akan dinegosiasikan dengan harga premium. Ketergantungan ini
dapat mengancam fleksibilitas jangka panjang klien, kelincahan, dan daya saing dan
mengakibatkan ketergantungan vendor yang lebih besar lagi.
c) Biaya Outsourcing Melebihi Manfaat
IT outsourcing telah dikritik karena biaya tak terduga muncul dan tingkat keuntungan
yang diharapkan tidak direalisasikan. Salah satu alasannya adalah bahwa klien
outsourcing sering gagal mengantisipasi biaya pemilihan vendor, kontrak, dan transisi
operasi TI ke vendor.
d) Mengurangi keamanan
Informasi yang diserahkan ke vendor TI di luar negeri menimbulkan pertanyaan unik
dan serius mengenai pengendalian internal dan perlindungan data pribadi yang
sensitif. Ketika sistem keuangan perusahaan dikembangkan dan dihosting di luar
negeri, dan kode program dikembangkan melalui antarmuka dengan jaringan
perusahaan induk, perusahaan A.S. berisiko kehilangan kendali atas informasi
mereka.
e) Hilangnya Keuntungan Strategis
IT outsourcing dapat mempengaruhi ketidaksesuaian antara perencanaan strategis TI
perusahaan dan fungsi perencanaan bisnisnya. Organisasi yang menggunakan TI
strategis harus menyelaraskan strategi bisnis dan strategi TI atau menjalankan risiko
penurunan kinerja bisnis.

Implikasi Audit It Outsourcing

Manajemen dapat mengalihkan fungsi TI organisasi mereka, namun mereka tidak dapat
mengalihkan tanggung jawab pengelolaan mereka di bawah SOX untuk memastikan
pengendalian internal TI yang memadai. Jika perusahaan audit meng-outsource fungsi TI-nya
ke vendor yang memproses transaksinya, menjadi tuan rumah data utama, atau melakukan
layanan penting lainnya, auditor harus melakukan evaluasi terhadap kontrol organisasi
vendor, atau dengan alternatif memperoleh laporan auditor SAS No. 70 dari organisasi
vendor.

Gambar 15-7 mengilustrasikan bagaimana laporan SAS 70 bekerja dalam kaitannya


dengan vendor, perusahaan klien, dan auditor mereka masing-masing. Vendor outsourcing
melayani klien 1, 2, 3, dan 4 dengan berbagai layanan TI. Kontrol internal atas layanan alih
daya berada di lokasi vendor. Mereka diaudit oleh auditor ven-dor, yang mengungkapkan
pendapat dan mengeluarkan laporan SAS 70 tentang kecukupan kontrol. Masing-masing
perusahaan klien diaudit oleh auditor berbeda A, B, C, dan D, masing-masing, yang sebagai
bagian dari audit masing-masing bergantung pada laporan SAS 70 vendor dan karenanya
tidak dipaksa untuk menguji secara terpisah kendali vendor. Mengingat bahwa vendor
mungkin memiliki ratusan atau bahkan ribuan klien, pengujian individual di bawah SOX
akan sangat mengganggu operasi vendor, mahal bagi klien, dan tidak praktis.
CHAPTER 16 (II)
PENGENDALIAN IT BAGIAN II : SECURITY AND ACCESS

Keamanan sistem operasi melibatkan kebijakan, prosedur, dan kontrol yang


menentukan siapa yang dapat mengakses sistem operasi, sumber daya mana (file, program,
printer) yang dapat mereka akses, dan tindakan apa yang dapat mereka lakukan. Komponen
keamanan berikut ditemukan di sistem operasi yang aman: prosedur log-on, token akses,
daftar kontrol akses, dan hak akses bebas discretionary.

Ancaman untuk Integritas Sistem Operasi


Ancaman yang disengaja terhadap sistem operasi paling sering dilakukan untuk
mengakses data secara tidak sah atau melanggar privasi pengguna untuk keuntungan
finansial. Namun, ancaman yang berkembang adalah program yang merusak yang tidak ada
keuntungan nyata. Paparan ini berasal dari tiga sumber:

1. Keistimewaan personil yang menyalahgunakan kewenangannya. Sistem administrator


dan pemrogram sistem memerlukan akses tak terbatas ke sistem operasi untuk
melakukan perawatan dan pemulihan dari kegagalan sistem. Individu tersebut dapat
menggunakan otoritas ini untuk mengakses program pengguna dan file data.
2. Individu, baik internal maupun eksternal organisasi, yang menelusuri sistem operasi
untuk mengidentifikasi dan memanfaatkan kelemahan keamanan.
3. Individu yang sengaja (atau sengaja) memasukkan virus komputer atau bentuk
program destruktif lainnya ke dalam sistem operasi.

Pengendalian Cadangan

Tindakan berbahaya dari hacker eksternal, karyawan yang tidak puas, kegagalan disk,
kesalahan program, kebakaran, banjir, dan gempa bumi dapat merusak dan menghancurkan
data. Untuk pulih dari bencana tersebut, organisasi perlu merekonstruksi database untuk
mendapatkan status prefailure. Ini bisa dilakukan hanya jika database sudah dicadangkan
dengan benar di tempat pertama. Organisasi harus, oleh karena itu, menerapkan kebijakan,
prosedur, dan teknik yang secara sistematis dan rutin menyediakan salinan cadangan data
penting.
Cadangan Database. Fitur backup membuat cadangan periodik dari keseluruhan database.
Ini adalah prosedur otomatis yang harus dilakukan minimal sekali sehari. Cadangan salinan
kemudian harus disimpan di daerah terpencil yang aman.

Transaksi Log (Jurnal). Fitur log transaksi memberikan jejak audit atas semua transaksi
yang diproses. Ini daftar transaksi dalam file log transaksi dan mencatat perubahan yang
terjadi pada database dalam log perubahan database yang terpisah.

Fitur Checkpoint. Fitur pos pemeriksaan menunda semua pemrosesan data sementara sistem
mendamaikan log transaksi dan log perubahan database terhadap database. Pada titik ini,
sistem dalam keadaan sepi. Pos pemeriksaan terjadi secara otomatis beberapa kali dalam satu
jam. Jika terjadi kegagalan, biasanya mungkin untuk memulai kembali pemrosesan dari pos
pemeriksaan terakhir. Dengan demikian, hanya beberapa menit proses transaksi harus
diulang.

Modul Pemulihan. Modul pemulihan menggunakan berkas log dan cadangan untuk me-
restart sistem setelah terjadi kegagalan.

Pengendalian Jaringan
Topologi jaringan terdiri dari berbagai konfigurasi (1) jalur komunikasi (kabel twisted-
pair, kabel koaksial, gelombang mikro, dan serat optik), (2) komponen perangkat keras
(modem, multiplekser, server, dan prosesor front-end), dan (3 ) perangkat lunak (protokol dan
sistem kontrol jaringan).
Terkait pengendalian jaringan dilakukan untuk memverifikasi keamanan dan integritas
transaksi perdagangan elektronik dengan menentukan bahwa pengendalian (1) dapat
mendeteksi dan memperbaiki hilangnya pesan karena kegagalan peralatan, (2) dapat
mencegah dan mendleteksi akses ilegal, baik dari dalam organisasi maupun dari Internet, (3)
membuat setiap data yang berhasil ditangkap oleh penyusup menjadi data yang tidak
berguna, serta (4) memiadai untuk mempertahankan integritas dan kearnanan fisik dari data
yang dihubungkan ke jaringan.
Pengujian Pengendalian Komunikasi Data

Untuk mewujudkan tujuan pengendalian ini, auditor dapat melakukan uji pengendalian
berikut:

a) Memilih sampel pesan dan catatan harian (log) transaksi dan memeriksa
kemungkinan adanya pengaruh dan saluran yang tidak stabil. Auditor harus
memverifikasi bahwa semua pesan yang terkorupsi telah berhasil dikirim kembali.
b) Memeriksa catatan harian transaksi pesan untuk memverifikasi bahwa semua pesan
diterirna sesuai dengan urutannya.
c) Menguji operasi fitur memanggil kembali (call-back) dengan melakukan panggilan
yang tidak sah dari luar instalasi.
d) Memeriksa prosedur keamanan yang mengatur administrasi kunci enkripsi data.
e) Memverifikasi proses enkripsi dengan mengirimkan sebuah pesan pengujian dan
mempelajari isinya pada berbagai titik di sepanjang saluran tersebut, antara lokasi
pengirim dan penerima.
f) Memeriksa kecukupan firewall agar terwujud keseimbangan yang tepat antara
pengendalian dan kenyamanan berdasarkan tujuan bisnis organisasi dan potensi
risiko. Kriteria untuk menilai efektivitas firewall, antara lain:
1) Fleksibilitas. Firewall harus cukup fleksibel untuk mengakomodasi layanan
baru ketika kebutuhan keamanan perusahaan berubah.
2) Layanan proxy. Aplikasi proxy yang memadai harus ada untuk rnenyediakan
otentikasi atau pengesahan secara eksplisit terhadap layanan, aplikasi, dan data
yang sensitif.
3) Penyaringan. Teknik penyaringan yang kuat harus didesain untuk menolak
semua pelayanan yang secara eksplisit tidak diizinkan. Dengan kata lain,
firewall harus rnenyebutkan hanya pelayanan yang diizinkan untuk diakses,
bukan menyebutkan pelayanan yang ditolak.
4) Permisahan sistem. Sistem-sistem yang tidak memerlukan akses publik harus
dipisahkan dan Internet.
5) Peralatan Audit. Firewall harus menyediakan serangkaian peralatan audit dan
catatan harian yang lengkap untuk mengidentifikasi dan mencatat aktivitas-
aktivitas yang mencurigakan.
6) Pemeriksaan kelemahan. Untuk memvalidasi kearnanan, auditor (atau analis
keamanan profesional) secara berkala harus memeriksa kelernahank elemahan
firewall, seperti halnya seorang hacker yang akan melakukannya.
g) Memeriksa prosedur pengendalian kata sandi untuk memastikan bahwa kata sandi
tersebut diubah secara berkala dan kata sandi yang lemah diidentifikasi dan tidak
digunakan lagi. Memeriksa satu sampel kata sandi pengguna yang diambil dan file
kata sandi dapat memeniksa hal tersebut. Auditor juga harus rnemverifikasi bahwa
file kata sandi dienkripsikan dan kunci enkripsi disimpan dengan benar dalam tempat
yang aman.
h) Prosedur audit untuk memverifikasi cadangan yang memadai, antara lain:
1) Auditor harus memveriflkasi bahwa pembuatan cadangan dilakukan secara
rutin dan berkala untuk memfasilitasi pemulilian data yang hilang, hancur,
atau dikorupsi.
2) Basis data jaringan harus disalin dengan interval waktu yang teratur (mungkin
beberapa kali dalam satu jam). Keseimbangan harus dicari antara
ketidaknyamanan dalam aktivitas pembuatan cadangan secara berkala dan
kekacauan bisnis yang disebabkan oleh akrivitas pemrosesan kembali yang
berlebihan yang diperlukan untuk memulihkan basis data setelah terjadi
kegagalan.
3) Auditor harus memverifikasi bahwa.prosedur pembuatan cadangan otomatis
memang ada dan berjalan baik; dan bahwa salinan file dan basis data disimpan
di tempat yang terpisah untuk alasan kearnanan.

Pengujian Pengendalian Pertukaran Data Elektronik

Pertukaran data elekironik (electronic data interchange-,---EDI) adalah pertukaran


antarperusahaan mengenai informasi bisnis yang dapat diproses menggunakan komputer
dengan format standar. Transaksi EDI dilakukan secara otomatis oleh mitra usaha sistem
inlormasi. Dalam lingkungan EDT murni, tidak ada perantara manusia yang menyetujui atau
rnengesahkan transaksi. Tidak adanya campur tangan manusia menciptakan risiko audit yang
unik.

Tujuan audit yang berkaitan dengan EDI:

Tujuan auditor dalam melakukan audit yang berkaitan dengan EDI adalah untuk
memastikan bahwa :

a) Semua transaksi EDI disahkan, divalidasi, dan sesuai dengan perjanjian mitra usaha;
b) Tidak ada perusahaan yang tidak memiliki otorisasi dalam mendapatkan akses ke
record basis data;
c) Mitra usaha yang sah memiliki akses hanya ke data yang disetujui; dan
d) Pengendalian yang memadai digunakan untuk memastikan jejak audit yang lengkap
untuk sernua transaksi EDI.
Prosedur audit yang berkaitan dengan EDI:

Untuk rnencapai tujuan-tujuan pengendalian ini, auditor dapat melakukan uji pengendalian
berikut.

Uji Pengendalian Otorisasi dan Validasi. Auditor harus memastikan bahwa kode identifikasi
mitra usaha diverifikasi sebelum transaksi diproses. Untuk mencapai ini, auditor harus (1)
memeriksa perjanjian dengan fasilitas VAN untuk mernvalidasi transaksi dan memastikan
bahwa informasi yang berkaitan dengan mitra usaha yang sah sudah lengkap dan benar, dan
(2) rnemeriksa file mitra usaha yang sah dan organisasi untuk kelengkapan dan akurasinya.

Uji Pengendalian Akses. Kearnanan file dan basis data mitra perdagangan yang sah
merupakan hal yang utarna dalam kerangka pengendalian EDI.

a) Auditor dapat memverifikasi kecukupan pengendalian ini dengan cara: Memastikan


bahwa akses ke pemasok yang sah atau file pelanggan dibatasi pada karyawan yang
merniliki otoritas tersebut. Auditor harus mernverifikasi bahwa akses ke file ini
dikendalikan oleh kata sandi dan tabel otoritas dan datanya dienkripsikan.
b) Tingkat akses ke mitra usaha yang l?isa mencapai record basis data perusahaan
(seperti tingkat persediaan dan daftar harga) akan ditentukan oleh perjanjian
perdagangan. Auditor harus merekonsiliasi syarat-syarat perdagangan dengan hak
istirnewa akses dan mitra usaha yang dinyatakan dalarn tabel otoritas basis data.
c) Melakukan sirnulasi akses dengan sebuah sampel mitra usaha dan berusaha
melanggar hak istimewa akses tersebut.
Uji Pengendalian Jejak Audit. Auditor harus memverifikasi bahwa sistem EDI
menghasilkan catatan harian transaksi yang memuat jejak transaksi dan seluruh rahap
pernrosesan. Dengan memilih satu sampel transaksi dan mcnelusurinya melalui proses
tersebut, auditor dapat mcrnverifikasi nilai data kunci yang dicatat sccara benar pada setiap
titik.

CHAPTER 17 (III)
IT KONTROL BAGIAN III:
PENGEMBANGAN SISTEM, PERUBAHAN PROGRAM,
DAN KONTROL APLIKASI

Setelah mempelajari bab ini, Anda harus:

1. Mengetahui kontrol dan tes audit yang relevan dengan proses pengembangan sistem.
2. Memahami risiko dan kontrol yang terkait dengan prosedur perubahan program dan
peran sumber program perpustakaan.
3. Memahami teknik auditing (CAATTs) yang digunakan untuk memverifikasi fungsi
dari kontrol aplikasi.
4. Memahami teknik auditing yang digunakan untuk melakukan tes substantif di
lingkungan TI.

A. PROSES PENGEMBANGAN SISTEM.


1. Kegiatan Pembangunan Sistem Pengendalian
Beberapa kegiatan terkendali yang membedakan proses pengembangan sistem yang efektif
yaitu kesepakatan dengan otorisasi, pengembangan, dan implementasi sistem baru. Kontrol
atas pemeliharaan sistem disajikan pada bagian berikutnya.
a) Kegiatan Otorisasi Sistem
Semua sistem harus diberi wewenang yang benar untuk memastikan pembenaran dan
kelayakan ekonomi mereka.
b) Spesifikasi Pengguna Kegiatan
Pengguna perlu dilibatkan secara aktif dalam proses pengembangan sistem.
Kompleksitas teknis sistem seharusnya tidak melumpuhkan keterlibatan pengguna.
Terlepas dari teknologi yang terlibat, pengguna harus membuat deskripsi tertulis rinci
tentang kebutuhannya.
c) Kegiatan Desain Teknis
Ruang lingkup kegiatan ini meliputi analisis sistem, analisis kelayakan, dan
perancangan sistem terperinci. Kecukupan kegiatan ini diukur dengan kualitas
dokumentasi yang muncul dari setiap tahap. Dokumentasi adalah kontrol dan bukti
kontrol dan sangat penting untuk kesuksesan jangka panjang sistem.
d) Partisipasi Internal Audit
Untuk memenuhi harapan manajemen terkait manajemen di SOX, departemen audit
internal organisasi harus independen, obyektif, dan berkualitas secara teknis. Dengan
demikian, auditor internal dapat memainkan peran penting dalam pengendalian
kegiatan pengembangan sistem. Auditor internal dapat berfungsi sebagai penghubung
antara pengguna dan profesional sistem untuk memastikan transfer pengetahuan yang
efektif.
e) Pengujian Program
Semua modul program harus diuji secara menyeluruh sebelum diimplementasikan.
Hasil pengujian kemudian dibandingkan terhadap hasil yang telah ditentukan untuk
mengidentifikasi kesalahan pemrograman dan logika. Pengujian sebenarnya akan
ekstensif dan melibatkan banyak transaksi yang menguji semua aspek logika modul.
f) Prosedur Uji dan Penerimaan Pengguna
Tim uji harus terdiri dari personil pengguna, profesional sistem, dan auditor internal.
Rincian tes yang dilakukan dan hasilnya harus didokumentasikan dan dianalisis secara
formal. Banyak yang menganggap uji formal dan penerimaan peristiwa menjadi
kontrol terpenting dalam proses pengembangan sistem.
2. Tujuan Audit Berkaitan dengan Pengembangan Sistem
Tujuan auditor adalah untuk memastikan bahwa
a) kegiatan pengembangan sistem diterapkan secara konsisten dan sesuai dengan
kebijakan manajemen terhadap semua proyek pengembangan sistem;
b) sistem yang diimplementasikan awalnya bebas dari kesalahan material dan
kecurangan;
c) sistem dinilai perlu dan dibenarkan di berbagai pos pemeriksaan di seluruh
SDLC; dan
d) dokumentasi sistem cukup akurat dan lengkap untuk memudahkan kegiatan audit
dan pemeliharaan.
3. Pengujian Kontrol Pengembangan Sistem
Auditor harus memilih contoh proyek yang telah selesai (selesai pada periode
sekarang dan periode sebelumnya) dan meninjau dokumentasi untuk bukti kepatuhan
terhadap kebijakan pengembangan sistem yang berlaku. Poin khusus untuk tinjauan
harus mencakup penentuan bahwa:
a) Manajemen layanan pengguna dan komputer memberi wewenang yang benar atas
proyek tersebut.
b) Sebuah studi kelayakan awal menunjukkan bahwa proyek tersebut memiliki
kelebihan.
c) Analisis rinci tentang kebutuhan pengguna dilakukan yang menghasilkan desain
konseptual alternatif.
d) Analisis biaya-manfaat dilakukan dengan menggunakan angka yang cukup akurat.
e) Desain rinci adalah solusi tepat dan akurat untuk masalah pengguna.
f) Hasil pengujian menunjukkan bahwa sistem diuji secara menyeluruh baik pada modul
individual maupun tingkat sistem total sebelum implementasi. (Untuk
mengkonfirmasi hasil tes ini, auditor dapat memutuskan untuk menguji ulang elemen
aplikasi yang dipilih.)
g) Ada daftar masalah spesifik yang terdeteksi selama masa konversi, beserta bukti
bahwa mereka diperbaiki dalam tahap pemeliharaan.
h) Dokumentasi sistem sesuai dengan persyaratan dan standar organisasi.

B. LINGKUNGAN SPL CONTROLLED


1. Prosedur audit untuk mengidentifikasi kesalahan aplikasi:
Auditor dapat menentukan bahwa program-program bebas dan kesalahan yang sifatnya
material dengan melakukan tiga jenis uji pengendalian: merekonsiliasi kode sumber,
memeriksa hasil tes, dan menguji ulang program.
2. Merekonsiliasi Kode Sumber. Setiap file permanen aplikasi harus berisi daftar program saat
ini dan daftar semua perubahan yang dibuat pada aplikasi tersebut. Dokumen-dokumen ini
menjelaskan secara terperinci sejarah pemeliharaan aplikasi. Selain itu, sifat perubahan
program harus dinyatakan dengan jelas pada dokumen otorisasi perubahan program.
Auditor harus memilih sebuah sampel aplikasi dan merekonsiliasikan setiap perubahan
program dengan dokumen otorisasi yang tepat. Pendekatan modular ke desain sistem
(menciptakan aplikasi yang terdiri atas banyak modul program diskrit) sangat memfasilitasi
teknik pengujian ini. Berkurangnya kompleksitas modul ini meningkatkan kemampuan
auditor untuk menentukan situasi tidak normal yang menunjukkan terjadinya kesalahan,
penghapusan data, dan kode pemrogramn yang berpotensi mengacaukan.
3. Memeriksa Hasil Pengujian. Setiap perubahan harus diuji secara menyeluruh sebelum
diimplementasikan. Prosedur pengujian program harus didokumentasikan dengan benar
menurut tujuan pengujian, data pengujian, dan hasil pemrosesan, yang mendukung
keputusan para programer untuk mengimplementasikan perubahan tersebut. Auditor harus
memeriksa catatan ini untuk setiap perubahan program yang penting, memastikan bahwa
pengujian tersebut cukup tegas untuk menunjukkan setiap kesalahan.
4. Menguji Ulang Program. Auditor dapat menguji ulang aplikasi untuk mengonfirmasikan
integnitasnya. Kita akan mempelajari beberapa teknik untuk menguji aplikasi dalam bagian-
bagian berikut ini.

C. PENGUJIAN TERHADAP PENGENDALIAN APLIKASI KOMPUTER


Teknik yang umumnya digunakan dalam mengaudit aplikasi komputer umumnya
digolongkan kedalam 2 (dua) kelas :
1. Teknik untuk menguji pengendalian aplikasi.
Teknik yang digunkan untuk menguji pengendalian program komputer menyediakan
informasi tentang akurasi dan kelengkapan proses aplikasi. Uji ini mengikuti 2 (dua)
pendekatan umum:
a. Pendekatan kotak hitam
Dalam melakukan pengujian kotak hitam auditor tidak bergantung pada pengetahuan
terperinci mengenai logika internal aplikasi. Tetapi mereka berusaha untuk memahami
karakteristik fungsional aplikasi dengan menganalisis bagan alir dan mewancarai
personel-personel yang berpengetahuan luas dalam perusahaan klien. Dengan
pemahaman tentang apa yang harus dilakukan oleh aplikasi tersebut auditor menguji
aplikasi dengan merekonsiliasi transaksi input produksi yang diproses oleh aplikasi
dengan outpunya. Hasil output digunakan untuk memverifikasi kecocokan aplikasi
dengan prasyaratan fungsionalnya.
b. Pendekatan kotak putih
Pendekatan kotak putih bergantung pada pemahaman yang mendalam tentang logika
internal aplikasi yang sedang diuji. Pendekatan kotak putih mencakup beberapa teknik
untuk menguji logika aplikasi secara langsung. Jenis-jenis uji penendalian yang paling
umum antara lain:
a) Uji Otensitas, yang memverifikasikan bahwa seorang individu, prosedur
terprogram, atau pesan yang berusaha mengakses sebuah sistem itu otentik,
termasuk juga otentikasi kata sandi, kode pemasok yang sah, dan tabel otoritas.
b) Uji Akurasi, yang memastikan bahwa sistem hanya memproses nilai-nilai data
yang sesuai dengan toleransi yang sudah ditentukan.
c) Uji Kelengkapan, yang menunjukkan data-data yang hilang dalam sebuah record
tunggal dan semua record yang hilang dari sebuah batch.
d) Uji redundansi, yang memastikan bahwa sebuah aplikasi hanya satu kali
memproses sebuah record. Pengendalian proses yang berlebih (redundan) antara
lain rekonsiliasi total batch, perhitungan record, total hash, dan total
pengendalian keungan.
e) Uji Akses, yang memastikan bahwa aplikasi mencegah pengguna yang sah dari
akses yang tidak sah ke data. Termasuk kata sandi, tabel otoritas, prosedur yang
ditentukan oleh pengguna, enkripsi data, dan pengendalian inferensi.
f) Uji Jejak Audit, yang memastikan bahwa aplikasi membuat jejak audit yang
memadai. Termasuk dalam hal ini bukti bahwa aplikasi mencatat semua transaksi
dalam catatan harian transaksi, membukukan nilai data ke akun-akun byang tepat,
menghasilkan daftar transaksi yang lengkap, dan file serta laporan kesalahan
untuk semua pengecualian.
g) Uji Kesalahan Pembulatan, yang memverifikasi kebenaran prosedur pembulatan,
kesalahan pembulatan terjadi dalam informasi akuntansi ketika tingkat presisi
yang digunakan dalam perhitungan lebih besar dari yang digunakan dalam
laporan.

D. TEKNIK PENGUJIAN KUALITAS


Untuk mengilustrasikan bagaimana pengendalian-pengendalian aplikasi diuji, ada 5
(lima) pendekatan teknik dan perangkat audit dengan bantuan komputer (Computer Assisted
Audit Tools and Techniques – CAATT), yaitu:
1. Metode Data Uji
Metode data uji (test data method) digunakan untuk menetukan integritas aplikasi
dengan memproses serangkaian data input yang secara khusus dipersiapkan melalui
aplikasi produksi yang sedang diperiksa. Hasil dari setiap pengujian kemudian
dibandingkan dengan hasil yang sebelumnya sudah ditentukan untuk mendapatkan
evaluasi yang objektif terhadap logika aplikasi dan efektifitas pengendalian.
Untuk melakukan teknik data uji ini sebuah salinan aplikasi terkini harus didapatkan
oleh auditor. Selain itu file transaksi dan file master pengujian harus dibuat. Hasil
pengujian ini dibandingkan dengan hasil yang diharapkan auditor untuk memastikan
apakah aplikasi tersebut berjalan dengan baik.
2. Evaluasi Sistem Kasus Dasar

Evaluasi sistem kasus dasar merupakan salah satu jenis dari data teknik data uji.
Untuk data uji yang bersifat komprehensif teknik tersebut dinamakan Evaluasi Sistem
Kasus Dasar (base case system evaluation – BCSE) dilakukan dengan serangkaian
transaksi pengujian yang berisi semua jenis transaksi yang mungkin. Transaksi-
transaksi ini diproses melalui pengulangan terus menerus selama pengujian
pengembangan sistem sampai hasil yang konsisten dan sah didapatkan yang kemudian
menjadi kasus dasar.

3. Penelusuran Jejak

Teknik ini menjelajahi logika internal aplikasi secara elektronik. Prosedur


penelusuran jejak melalui 3 (tiga) langkah :

a. Aplikasi yang diperiksa harus disusun secara khusus untuk mengaktifkan pilihan
penelusuran jejak.
b. Transaksi atau jenis transaksi tertentu dibuat sebagai data uji
c. Transaksi data uji ditelusuri di semua tahap pemrosesan program, dan daftar yang
berisi semua instruksi program dihasilkan selama pengujian tersebut.
4. Fasilitas Uji Terpadu

Fasilitas pengujian terpadu (integrated test facility – ITF) merupakan sebuah teknik
otomatis yang memungkinkan auditor menguji logika dan perangkat penendalian
aplikasi selama aktifitas operasi normal. ITF merupakan salah satu atau lebih modul
audit yang didesain ke dalam aplikasi selama proses pengembangan sistem. Basis data
ITF berisi imitasi atau dummy record file master uji yang diintegrasikan dengan record
yang sah. Sebagian perusahaan membuat imitasi dimana transaksi uji dibukukan. Selain
operasi normal, transaksi uji disatukan dengan arus input transaksi (produksi) reguler,
dan diproses dengan file perusahaan imitasi tersebut

Simulasi Paralel

Simulasi paralel mengharuskan auditor untuk menulis sebuah program yang menyimulasikan
berbagai fitur utama atau proses aplikasi yang sedang diperiksa. Aplikasi simulasi ini
kemudian digunakan untuk memproses ulang transaksi yang sebelumnya diproses oleh
aplikasi produksi. Hasil yang didapatkan dari simulasi ini kemudian direkomendasikan
dengan hasil-hasil dan proses produksi awal untuk membangun basis untuk menarik
kesimpulan tentang kualitas dari proses dan pengendalian aplikasi.
Prgram aplikasi umumnya tidak terlalu rumit, karena simulasi hanya berisi proses aplikasi,
perhitungan, dan pengendalian yang relevan dengan tujuan audit tertentu, auditor secara hati-
hati harus mengevaluasi perbedaan yang terdapat antara hasil pengujian dan hasil produksi.
1. Teknik untuk memeriksa perincian transaksi dan saldo akun (Pengujian Substantif)
Pengujian substantif merupakan pembuktian jumlah nominal saldo dalam saldo akun.
Pengujian substantif biasanya mencakup, tetapi tidak terbatas pada:
a. Menentukan nilai persediaan yang benar
b. Menetukan akurasi pembayaran dimuka dan akrual
c. Mengonfirmasi piutang usaha dengan pelanggan
d. Mencari kewajiban yang tidak tercatat.
Dalam menyeleksi, mengakses, dan mengelola data yang digunakan untuk melakukan
uji substantif, auditor umumnya menggunakan teknik berbasis komputer yaitu:
a. Teknik Modul Audit Yang Dilekatkan (Embedded Audit Module - EAM)
Teknik ini menggunakan satu atau lebih modul program khusus yang dilekatkan
dalam aplikasi klien untuk memilih dan mencatat jenis-jenis transaksi yang
sebelumnya sudah ditetapkan untuk dianalisis lebih lanjut. Ketika transaksi yang
dipilih tersebut diproses oleh aplikasi klien, satu salinan transaksi disimpan dalam
sebuah file audit untuk diperiksa lebih lanjut. Pendekatan EAM memungkinkan
berbagai transaksi penting ditangkap selama periode audit. Transaksi-transaksi yang
ditangkap ini tersedia untuk auditor pada akhir periode atau setiap waktu selama
periode tersebut, jadi secara signifikan mengurangi jumlah kerja yang harus dilakukan
seorang auditor untuk menentukan transaksi-transaksi signifikan yang akan menjalani
pengujian substantif.
b. Peranti Lunak Yang Digeneralisasikan (Generalized Audit Software - GAS)
GAS merupakan perangkat audit terkomputerisasi (CAATT) yang paling banyak
digunakan untuk mengaudit sistem informasi. GAS memungkinkan auditor untuk
mengakses file data berkode secara elektronik dan melakukan berbagai aktifitas
operasi. Aktifitas audit yang dapat dilakukan dengan GAS antara lain:
1. Membuat catatan kaki dan menyeimbangkan semua file atau item data tertentu
2. Memilih dan melaprkan perincian data yang terdapat dalamfile
3. Memilih sampel statistik dengan stratifikasi dari file data
4. Memformat hasil pengujian ke dalam lapran
5. Mencetak konfirmasi dengan bentuk standar atau catatan khusus
6. Memilih data dan secara selektif memasukkan atau mengeluarkan item
7. Membandingkan dua file dan mengidentifikasikan perbedaannya
8. Menghitungkembali field data.

GAS dapat digunakan untuk mengakses struktur sederhana maupun struktur yang
komplek:
1. Menggunakan GAS untuk mengakses struktur sederhana
Mendapatkan akses kestruktur file datar merupakan sebuah proses yang
sederhana. Misalnya dalam sebuah file persediaaan dibaca langsung oleh GAS
yang mengambil informasi penting yang diperlukan untuk audit, termasuk
jumlah barang di gudang, nilai uang, dan lokasi gudang di setiap item
persediaan. Tugas auditor adalah memverifikasi keberadaan dan nilai
persediaan dengan melakukan perhitungan fisik pada sampel yang mewakili
jumlah barang di gudang. Jadi, atas dasar batas materialitas yang ditetapkan
auditor, GAS memilih record sampel dan menyiapkan laporan dengan
informasi penting.
2. Menggunakan GAS untuk mengakses struktur kompleks
Mendapatkan akses ke struktur kompleks seperti yang dipelihara oleh sistem
manajemen basis data menghadapkan auditor pada lebih dari sekedar satu
masalah. Tidak semua produk GAS di pasar dapat mengakses setiap jenis
struktur file. Namun demikian kebanyakan DBMS memiliki fitur utilitas yang
akan membentuk kembali struktur kompleks menjadi file datar. Struktur
kompleks tidak langsung diakses, melainkan sebuah file datar perantara dibuat
yang diakses GAS.

Struktur basis data ini menggunakan penunjuk (pointer) untuk menyatukan tiga file
yang saling berkaitan – pelanggan, faktur penjualan, dan item garis – dalam aturan
yang bersifat hirarkis. Akan menjadi sulit untuk mendapatkan bukti-bukti audit dari
sebuah struktur yang kompleks dengan menggunakan GAS.