Gambaran Umum SOX Bagian 302 dan 404

SOX tahun 2002 menetapkan peraturan dan standar tata kelola perusahaan baru untuk perusahaan
publik yang terdaftar di Securities and Exchange Commission (SEC). Meskipun tindakan tersebut
mengandung banyak bagian, bab ini dan dua bab berikut berkonsentrasi pada pengendalian internal
dan tanggung jawab audit sesuai dengan Bagian 302 dan 404.

Bagian 302 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.

Bagian 404 mewajibkan manajemen perusahaan publik untuk menilai efektivitas pengendalian
internal organisasi mereka atas pelaporan keuangan. Berdasarkan bagian tindakan ini, manajemen
diharuskan memberikan laporan tahunan yang membahas hal-hal berikut:

1. Jelaskan alur transaksi, termasuk aspek TI, dengan detail yang cukup untuk
mengidentifikasi titik di mana salah saji bisa timbul.
2. Dengan menggunakan pendekatan berbasis risiko, tentukan baik disain dan efektivitas
operasi pengendalian internal terpilih yang terkait dengan akun material.
3. Menilai potensi kecurangan dalam sistem dan mengevaluasi kontrol yang dirancang untuk
mencegah atau mendeteksi kecurangan.
4. Mengevaluasi dan menyimpulkan kecukupan pengendalian atas proses pelaporan laporan
keuangan.
5. Evaluasi kontrol keseluruhan entitas (umum) yang sesuai dengan komponen kerangka
Pernyataan Standar Auditing No. 78 (SAS 78) / COSO.

Mengenai poin terakhir, SEC telah membuat referensi khusus untuk SAS 78 / COSO sebagai kerangka
kontrol yang direkomendasikan. Selanjutnya, Standar Audit Pengawas Akuntansi Perusahaan (PCAOB)
No. 5 mendukung penggunaan SAS 78 / COSO sebagai kerangka kerja untuk penilaian kontrol.
Meskipun kerangka kerja lain yang sesuai telah diterbitkan, kerangka kerja apa pun yang digunakan
harus mencakup semua tema umum COSO. Kami membahas elemen kunci kerangka SAS 78 / COSO di
Bab 3. Fokus kami pada saat ini adalah pada kontrol TI (subset dari aktivitas pengendalian), yang
sebelumnya tidak dibahas. Aspek kerangka SAS 78 / COSO ini digunakan untuk menyajikan masalah
kontrol dan audit dalam bab ini dan dua bab berikut.

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-elemen tersebut tidak dapat dipisahkan dari proses pelaporan keuangan yang
dianggap 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. Contohnya meliputi:
  Pencairan dana rutin penyeimbang kas yang memverifikasi bahwa total pembayaran ke
vendor didamaikan dengan total pos ke buku besar pembantu piutang usaha.
 Prosedur penanggalan piutang piutang yang memvalidasi nomor rekening nasabah atas
transaksi penjualan.
 Cek batas sistem penggajian yang mengidentifikasi catatan kartu waktu karyawan dengan jam
kerja yang dilaporkan bekerja melebihi batas normal yang telah ditentukan.

Contoh-contoh ini menggambarkan bagaimana kontrol aplikasi memiliki dampak langsung terhadap
integritas data yang berhasil melalui berbagai sistem pemrosesan transaksi dan ke dalam proses
pelaporan keuangan. Kontrol aplikasi diperiksa secara rinci pada Bab 17.

Kelompok kontrol kedua yang diketahui SAS 78 / COSO mengidentifikasi adalah kontrol umum.
Mereka diberi nama begitu karena tidak spesifik aplikasi tapi lebih tepatnya, berlaku untuk semua
sistem. 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.

Sedangkan kontrol umum tidak mengendalikan transaksi tertentu, namun memiliki pengaruh
terhadap integritas transaksi. Misalnya, pertimbangkan sebuah organisasi dengan kontrol keamanan
database yang buruk. Dalam situasi seperti ini, bahkan data yang diproses oleh sistem dengan kontrol
aplikasi built-in yang memadai mungkin berisiko. Seseorang yang mampu menghindari keamanan
database (baik secara langsung atau melalui program jahat) dapat mengubah, mencuri, atau merusak
data transaksi yang tersimpan. Dengan demikian, kontrol umum diperlukan untuk mendukung
berfungsinya kontrol aplikasi, dan keduanya diperlukan untuk memastikan pelaporan keuangan yang
akurat.

IMPLIKASI AUDIT BAGIAN 302 DAN 404

Materi yang tercakup dalam sisa bab ini dan bab-bab berikut mengasumsikan pemahaman dasar
tentang proses audit. Secara khusus, pembaca harus:

 Mampu membedakan antara fungsi atest dan assurance.

 Pahami konsep asertif manajemen dan kenali hubungan antara asersi dan tujuan audit.
 Kenali perbedaan antara tes kontrol dan tes substantif dan pahami hubungan di antara
keduanya.

Lampiran pada bab ini berisi ikhtisar singkat tentang topik ini. Mereka yang kekurangan pengetahuan
ini harus meninjau lampiran sebelum melanjutkan dengan bagian ini.

Sebelum SOX, auditor eksternal tidak diharuskan untuk menguji pengendalian internal sebagai bagian
dari fungsi pengesahannya. Mereka diharuskan untuk mengenal kontrol internal organisasi klien,
namun memiliki pilihan untuk tidak bergantung pada mereka dan karena itu tidak melakukan tes
kontrol. Audit bisa, dan sering dilakukan, oleh karena itu terutama terdiri dari tes substantif.

Perundang-undangan SOX secara dramatis memperluas peran auditor eksternal dengan mewajibkan
mereka untuk menilai penilaian manajemen terhadap pengendalian internal. Ini merupakan
penerbitan opini audit terpisah di samping pendapat atas kewajaran laporan keuangan. Standar opini
audit baru ini tinggi. Memang, auditor dilarang mengeluarkan opini yang tidak wajar jika hanya satu
kelemahan material dalam pengendalian internal yang terdeteksi. Menariknya, auditor diijinkan untuk
sekaligus memberikan pendapat yang memenuhi syarat mengenai penilaian manajemen terhadap
pengendalian internal dan opini wajar tanpa pengecualian atas laporan keuangan. Dengan kata lain,
secara teknis mungkin bagi auditor untuk menemukan pengendalian internal atas pelaporan
keuangan menjadi lemah, namun disimpulkan melalui pengujian substantif bahwa kelemahan
tersebut tidak menyebabkan laporan keuangan menjadi salah secara material.

Sebagai bagian dari tanggung jawab pengesahan baru, Standar PCAOB No. 5 secara khusus
mengharuskan auditor memahami arus transaksi, termasuk kontrol yang berkaitan dengan bagaimana
transaksi diinisiasi, disahkan, dicatat, dan dilaporkan. Ini melibatkan pertama memilih akun keuangan
yang memiliki implikasi material untuk pelaporan keuangan. Kemudian, auditor perlu mengidentifikasi
kontrol aplikasi yang terkait dengan akun tersebut. Seperti yang dicatat sebelumnya, keandalan
kontrol aplikasi bergantung pada kontrol umum TI yang mendukungnya. Ini termasuk kontrol atas
akses ke database, sistem operasi, dan jaringan. Jumlah kontrol ini, baik aplikasi dan umum,
merupakan pengendalian internal yang relevan atas pelaporan keuangan yang perlu dikaji ulang.
Gambar 15-1 mengilustrasikan hubungan kontrol TI ini.

Kepatuhan terhadap Bagian 404 mewajibkan manajemen untuk memberikan kepada auditor
eksternal bukti terdokumentasi tentang pengendalian fungsi yang terkait dengan akun material
terpilih dalam laporannya mengenai efektivitas pengendalian. Fungsi audit internal organisasi atau
kelompok SOX khusus kemungkinan akan melakukan tes ini. Oleh karena itu, manajemen harus benar-
benar melakukan tes kontrolnya sendiri sebelum auditor melakukan kinerjanya.

Gambar 15-1

Bagian 302 juga membawa implikasi auditor yang signifikan. Selain mengungkapkan pendapat
mengenai efektivitas pengendalian internal, auditor memiliki tanggung jawab mengenai sertifikasi
kuartalan manajemen internal oleh manajemen. Secara khusus, auditor harus melakukan prosedur
berikut setiap tiga bulan untuk mengidentifikasi modifikasi material dalam kontrol atas pelaporan
keuangan:

 Manajemen wawancara mengenai adanya perubahan signifikan dalam perancangan atau

pengoperasian pengendalian internal yang terjadi setelah audit tahunan sebelumnya atau
tinjauan sebelumnya atas informasi keuangan sementara.
 Evaluasi implikasi salah saji yang diidentifikasi oleh auditor sebagai bagian dari tinjauan
interim yang terkait dengan pengendalian internal yang efektif.
 Menentukan apakah perubahan dalam pengendalian internal cenderung mempengaruhi
pengendalian internal atas pelaporan keuangan secara material.

Akhirnya, SOX menempatkan tanggung jawab pada auditor untuk mendeteksi aktivitas penipuan dan
menekankan pentingnya kontrol yang dirancang untuk mencegah atau mendeteksi kecurangan yang
dapat menyebabkan salah saji material atas laporan keuangan. Manajemen bertanggung jawab untuk
menerapkan kontrol semacam itu, dan auditor secara tegas diminta untuk mengujinya. Karena
komputer berada di jantung sistem pelaporan keuangan dan pelaporan organisasi modern, topik
penipuan komputer termasuk dalam tanggung jawab manajemen dan audit yang diberlakukan oleh
SOX. Bagian berikut membahas beberapa masalah penipuan komputer.

Penipuan Komputer

Kami melihat di Bab 3 bahwa perkiraan kerugian kecurangan untuk tahun 2008 melebihi $ 990 miliar.
Berapa banyak yang bisa ditelusuri ke kecurangan komputer ini sulit untuk dikatakan. Salah satu alasan
untuk ketidakpastian adalah bahwa kecurangan komputer tidak didefinisikan dengan baik. Misalnya,
kita melihat di bagian etika Bab 3 bahwa beberapa orang menganggap menyalin perangkat lunak
komputer komersial menjadi tidak etis atau ilegal. Di sisi lain dari masalah ini, vendor perangkat lunak
menganggap tindakan semacam itu sebagai kriminal.

Terlepas dari seberapa sempit atau secara umum kecurangan komputer didefinisikan, ini adalah
fenomena yang berkembang pesat. Untuk tujuan pembahasan kami, kecurangan komputer meliputi:

 Pencurian, penyalahgunaan, atau penyalahgunaan aset dengan mengubah catatan dan

file yang dapat dibaca komputer.
 Pencurian, penyalahgunaan, atau penyalahgunaan aset dengan mengubah logika
perangkat lunak komputer.
 Pencurian atau penggunaan ilegal informasi yang dapat dibaca oleh komputer.
 Pencurian, korupsi, penyalinan ilegal, atau perusakan perangkat lunak komputer yang
disengaja.
 Pencurian, penyalahgunaan, atau penyalahgunaan perangkat keras komputer.

Gambar 15-2

Model umum untuk sistem informasi akuntansi yang ditunjukkan pada Gambar 15-2 secara
konseptual menggambarkan tahap kunci dari sebuah sistem informasi. Setiap tahap dalam
pengumpulan data model, pengolahan data, pengelolaan basis data, dan generasi informasi -
merupakan area potensial risiko untuk jenis kecurangan komputer tertentu. Pada bagian ini kita hanya
memeriksa risikonya; teknik kontrol khusus yang diperlukan untuk mengurangi risikonya dibahas nanti
di bab ini dan di dua bab yang tersisa.

PENGUMPULAN DATA. Pengumpulan data merupakan tahap operasional pertama dalam sistem
informasi. Tujuan pengendaliannya adalah untuk memastikan bahwa data acara yang masuk dalam
sistem valid, lengkap, dan bebas dari kesalahan material. Dalam banyak hal, ini adalah tahap
terpenting dalam sistem. Jika transaksi yang keliru atau salah melewati pengumpulan data tidak
terdeteksi, organisasi menanggung risiko bahwa sistem akan memproses transaksi dan akan
berdampak pada laporan keuangan.

Titik akses yang paling umum untuk melakukan kecurangan komputer ada pada tahap pengumpulan
data. Penipuan jenis ini hanya membutuhkan sedikit atau tanpa keterampilan komputer dari pihak
penipu, namun memerlukan kontrol yang dirancang dengan buruk. Pelaku hanya perlu memahami
bagaimana sistem bekerja mengendalikan kelemahannya. Tindakan curang melibatkan memasukkan
data yang dipalsukan ke dalam sistem. Ini mungkin melibatkan penghapusan, pengubahan, atau
transaksi. Misalnya, untuk melakukan penipuan gaji, pelaku dapat memasukkan transaksi penggajian
yang tidak benar bersamaan dengan transaksi sah lainnya. Jika tidak ada kontrol internal untuk
mendeteksi penyisipan, sistem akan menghasilkan tambahan gaji untuk pelaku. Variasi jenis penipuan
ini adalah mengubah bidang Jam Kerja dalam transaksi penggajian yang sah untuk meningkatkan
jumlah gaji.

Masih ada varian lain dalam penipuan ini adalah menguangkan uang tunai untuk membayar hutang
palsu. Dengan memasukkan dokumen pendukung yang tidak benar (pesanan pembelian, laporan
penerimaan, dan faktur pemasok) pada tahap pengumpulan data sistem hutang, pelaku dapat
mengelabui sistem tersebut untuk membuat catatan hutang untuk pembelian yang tidak ada. Begitu
catatan dibuat, sistem akan menganggapnya sah dan, pada tanggal jatuh tempo, akan membubarkan
dana kepada pelaku untuk membayar kewajiban palsu.

Sistem jaringan mengekspos organisasi untuk melakukan transaksi penipuan dari lokasi terpencil.
Masquerading, piggybacking, dan hacking adalah contoh teknik penipuan semacam itu. Masquerading
melibatkan pelaku yang mendapatkan akses ke sistem dari lokasi terpencil dengan berpura-pura
menjadi pengguna yang berwenang. Ini biasanya membutuhkan akses otorisasi terlebih dulu.
Piggybacking adalah teknik di mana pelaku di lokasi terpencil mengetuk jalur telekomunikasi dan
memasukkannya ke pengguna yang berwenang yang masuk ke sistem. Begitu masuk dalam sistem,
pelaku bisa menyamar sebagai pengguna yang berwenang. Hacking mungkin melibatkan teknik
piggybacking atau masquerading. Hacker dibedakan dari penjahat komputer lainnya karena motif
mereka biasanya tidak menipu untuk keuntungan finansial. Lebih sering mereka termotivasi oleh
tantangan untuk masuk ke sistem daripada pencurian aset. Namun demikian, hacker telah
menyebabkan kerusakan dan kerugian yang besar pada organisasi dengan menghancurkan dan
merusak data perusahaan.

PENGOLAHAN DATA. Setelah terkumpul, data biasanya membutuhkan pengolahan untuk

menghasilkan informasi. Tugas dalam pengolahan data mencakup algoritma matematis (seperti
model pemrograman linier) yang digunakan untuk aplikasi penjadwalan produksi, teknik statistik
untuk peramalan penjualan, dan pembuatan laporan dan ringkasan yang digunakan untuk aplikasi
akuntansi. Kecurangan pengolahan data terbagi dalam dua kelas: penipuan program dan kecurangan
operasi.

Kecurangan program mencakup teknik berikut: (1) membuat program ilegal yang dapat mengakses
file data untuk mengubah, menghapus, atau memasukkan nilai ke dalam catatan akuntansi; (2)
menghancurkan atau merusak logika program menggunakan virus komputer; atau (3) mengubah
logika program sehingga aplikasi memproses data secara tidak benar. Misalnya, program yang
digunakan bank untuk menghitung bunga pada akun pelanggannya biasanya akan menghasilkan
kesalahan pembulatan karena ketepatan perhitungan bunga lebih besar daripada ketepatan
pelaporan. Oleh karena itu, angka minat yang dihitung ke beberapa desimal menghasilkan nilai hingga
sepersekian sen sen dan harus dibulatkan ke angka keseluruhan untuk tujuan pelaporan. Program
perhitungan bunga biasanya memiliki rutin pembulatan standar untuk melacak kesalahan pembulatan
sehingga total biaya bunga ke bank sama dengan jumlah kredit individual. Ini melibatkan penempatan
sementara jumlah pecahan yang tersisa dari setiap perhitungan dalam akumulator memori internal.
Bila jumlah akumulator mencapai satu sen (plus atau minus), maka jumlah penny akan ditambahkan
ke akun pelanggan tertentu yang sedang diproses pada saat itu. Dengan kata lain, satu sen
ditambahkan ke (atau dikurangkan dari) akun pelanggan secara acak. Suatu bentuk kecurangan
program yang disebut penipuan salami melibatkan modifikasi logika pembulatan program sehingga
tidak lagi menambahkan satu sen secara acak. Sebagai gantinya, program yang dimodifikasi selalu
menambahkan angka plus ke akun pelaku, namun masih menambahkan minus sen secara acak. Hal
ini dapat mengalihkan sejumlah uang ke pelaku, namun catatan akuntansi tetap seimbang untuk
menyembunyikan kejahatan tersebut.

Kecurangan operasi adalah penyalahgunaan atau pencurian sumber daya komputer perusahaan. Hal
ini sering melibatkan penggunaan komputer untuk melakukan bisnis pribadi. Sebagai contoh, seorang
programmer dapat menggunakan komputer perusahaan waktu untuk menulis perangkat lunak yang
ia jual secara komersial. BPA di kantor pengawas dapat menggunakan komputer perusahaan untuk
menyiapkan laporan pajak dan laporan keuangan untuk klien pribadinya. Demikian pula, pengacara
perusahaan dengan praktik pribadi di samping dapat menggunakan komputer perusahaan untuk
mencari kasus pengadilan dan keputusan dalam basis data komersial. Biaya untuk mengakses
database dibebankan ke organisasi dan disembunyikan di antara biaya sah lainnya.

MANAJEMEN DATABASE. Database organisasi adalah gudang fisik untuk data keuangan dan non
finansial. Kecurangan pengelolaan basis data mencakup mengubah, menghapus, merusak,
menghancurkan, atau mencuri data organisasi. Karena akses ke file database merupakan elemen
penting dari kecurangan ini, hal ini sering dikaitkan dengan penipuan transaksi atau program. Teknik
penipuan yang umum adalah dengan mengakses database dari situs remote dan mencari file untuk
mendapatkan informasi bermanfaat yang dapat disalin dan dijual ke pesaing. Karyawan yang tidak
puas telah diketahui menghancurkan file data perusahaan hanya untuk membahayakan organisasi.
Salah satu caranya adalah memasukkan rutinitas destruktif yang disebut logika bom ke dalam sebuah
program. Pada waktu tertentu, atau saat kondisi tertentu terpenuhi, bom logika menghapus file data
yang diakses oleh program. Misalnya, programmer yang tidak puas yang sedang mempertimbangkan
untuk meninggalkan sebuah organisasi memasukkan bom logika ke dalam sistem penggajian.
Beberapa minggu kemudian ketika sistem mendeteksi bahwa nama pemrogram telah dihapus dari file
penggajian, bom logika diaktifkan dan menghapus keseluruhan file penggajian.

GENERASI INFORMASI Generasi informasi adalah proses penyusunan, penyusunan, pemformatan, dan
penyajian informasi kepada pengguna. Informasi bisa berupa dokumen operasional seperti sales
order, laporan yang dikirim ke layar komputer, atau laporan keuangan yang diterbitkan.

Bentuk umum kecurangan komputer di tahap pembangkitan informasi adalah mencuri,

menyalahgunakan, atau menyalahgunakan keluaran komputer. Satu teknik rendah namun efektif
yang disebut pemulungan melibatkan pencarian melalui tempat sampah dari pusat komputer untuk
keluaran yang dibuang. Dengan demikian, pelaku dapat memperoleh informasi yang berguna dari
laporan hard copy yang ditolak selama pemrosesan. Terkadang laporan keluaran yang tidak sejajar di
atas kertas atau sedikit kacau saat dicetak akan dibuang ke tempat sampah.

Bentuk lain dari kecurangan yang disebut menguping meliputi mendengarkan transmisi output
melalui jalur telekomunikasi. Teknologi tersedia sehingga memungkinkan pelaku mencegat pesan
yang dikirim melalui saluran telepon tanpa kabel dan saluran microwave. Sebagian besar ahli sepakat
bahwa praktis tidak mungkin mencegah pelaku yang bertekad mengakses saluran komunikasi data.
Enkripsi data, bagaimanapun, dapat membuat data yang tidak berguna diambil dengan cara ini.

Dengan latar belakang ini, adegan diatur untuk melihat teknik kontrol dan tes kontrol yang mungkin
diperlukan di bawah SOX. Standar Audit Auditor PCAOB No. 5 menekankan bahwa manajemen dan
auditor menggunakan pendekatan berbasis risiko dan bukan pendekatan satu ukuran sesuai untuk
disain dan penilaian kontrol. Dengan kata lain, ukuran dan kompleksitas organisasi perlu
dipertimbangkan dalam menentukan sifat dan tingkat kontrol yang diperlukan. Pembaca harus
mengenali, oleh karena itu, bahwa kontrol yang disajikan dalam sisa bab ini dan dalam dua bab berikut
ini menggambarkan kebutuhan sebuah organisasi generik dan mungkin tidak berlaku dalam situasi
tertentu.

Kontrol Tata Kelola TI

Tata kelola TI adalah konsep yang luas yang berkaitan dengan hak keputusan dan akuntabilitas untuk
mendorong perilaku yang diinginkan dalam penggunaan TI. Meskipun penting, tidak semua elemen
tata kelola TI berhubungan secara khusus untuk mengendalikan masalah yang menjadi alamat SOX
dan yang diuraikan dalam kerangka COSO. Dalam bab ini, kami mempertimbangkan tiga masalah tata
kelola yang dilakukan: struktur organisasi fungsi TI, operasi komputer, dan perencanaan pemulihan
bencana.

Diskusi mengenai masing-masing masalah tata kelola ini dimulai dengan penjelasan tentang sifat risiko
dan deskripsi kontrol yang diperlukan untuk mengurangi risiko. Kemudian, tujuan audit disajikan. Ini
menetapkan apa yang perlu diverifikasi mengenai fungsi kontrol di tempat. Akhirnya, contoh tes
kontrol ditawarkan yang menjelaskan bagaimana auditor dapat mengumpulkan bukti untuk
memenuhi tujuan audit. Tujuan pengendalian dan tes terkait ini dapat dilakukan oleh auditor internal
yang memberikan bukti kepatuhan manajemen terhadap SOX atau oleh auditor eksternal sebagai
bagian dari fungsi penyokohan mereka. Dalam hal ini, kita tidak membedakan kedua peran tersebut.
Struktur Organisasi Pengendalian Bab-bab sebelumnya telah menekankan pentingnya memisahkan
tugas yang tidak sesuai dalam aktivitas manual. Secara khusus, tugas operasional harus dipisahkan
menjadi:

 Pisahkan tugas otorisasi transaksi dari proses transaksi.

 Pisahkan pencatatan dari penitipan aset.
 Bagilah tugas pemrosesan transaksi di antara individu sehingga kecurangan akan
membutuhkan kolusi antara dua orang atau lebih.

Kecenderungan dalam lingkungan TI adalah mengkonsolidasikan kegiatan. Aplikasi tunggal dapat

memberi otorisasi, memproses, dan mencatat semua aspek transaksi. Dengan demikian, fokus kontrol
segregasi bergeser dari tingkat operasional (tugas pemrosesan transaksi yang dilakukan program
komputer sekarang) ke hubungan organisasi tingkat tinggi dalam fungsi TI. Keterkaitan antara
pengembangan sistem, pemeliharaan aplikasi, administrasi database, dan aktivitas operasi komputer
menjadi perhatian khusus.

Bagian berikut membahas masalah pengendalian organisasi dalam konteks dua model generik - model
terpusat dan model terdistribusi. Untuk tujuan diskusi, ini disajikan sebagai struktur alternatif; Dalam
praktiknya, lingkungan TI kebanyakan perusahaan memiliki unsur-unsur keduanya.

SEGREGASI TUGAS DI DALAM PERUSAHAAN TENGAH

Gambar 15-3 menyajikan bagan organisasi fungsi TI terpusat. Bagan organisasi serupa disajikan pada
Bab 1 untuk memberikan dasar untuk membahas tugas-tugas TI. Ini dikaji ulang di sini untuk
mempelajari tujuan pengendalian di balik pemisahan tugas-tugas ini. Jika posisi yang ditunjukkan
dalam tabel ini tidak umum, Anda harus meninjau bagian yang relevan di Bab 1 sebelum melanjutkan.

Memisahkan Pengembangan Sistem dari Operasi Komputer

Pemisahan pengembangan sistem (baik pengembangan dan pemeliharaan sistem baru) dan kegiatan
operasi sangat penting. Tanggung jawab kelompok ini seharusnya tidak digabungkan. Profesional
pengembangan dan pemeliharaan sistem diperoleh (oleh pengembangan dan pembelian di dalam
rumah) dan memelihara sistem bagi pengguna. Staf operasi harus menjalankan sistem ini dan tidak
terlibat dalam disain dan implementasinya. Mengkonsolidasikan fungsi ini mengundang kecurangan.
Dengan pengetahuan rinci tentang parameter logika dan kontrol aplikasi beserta akses ke operasi
komputer, seseorang dapat membuat perubahan yang tidak sah terhadap logika aplikasi selama
eksekusi. Perubahan semacam itu mungkin bersifat sementara (on the fly) dan akan hilang dengan
sedikit atau tanpa jejak saat aplikasi berakhir.

Gambar 15-3

Memisahkan Administrator Database dari Fungsi Lain

Kontrol organisasi penting lainnya adalah pemisahan fungsi administrator database (DBA) dari fungsi
TI lainnya. DBA bertanggung jawab atas sejumlah tugas penting yang berkaitan dengan keamanan
database, termasuk membuat skema database, menciptakan tampilan pengguna (subschemas),
memberikan wewenang akses kepada pengguna, memantau penggunaan database, dan
merencanakan perluasan di masa depan. Mendelegasikan tanggung jawab ini kepada orang lain yang
melakukan tugas yang tidak sesuai mengancam integritas database. Gambar 15-3 menunjukkan
bagaimana fungsi DBA independen secara organisasi.
MEMPELAJARI DBA DARI PEMBANGUNAN SISTEM. Pemrogram membuat aplikasi yang mengakses,
memperbarui, dan mengambil data dari database. Bab 9 mengilustrasikan bagaimana kontrol akses
basis data dicapai melalui pembuatan tampilan pengguna, yang merupakan tanggung jawab DBA.
Untuk mencapai akses database, oleh karena itu, baik programmer maupun DBA perlu menyetujui
atribut dan tabel (tampilan pengguna) untuk menyediakan aplikasi (atau pengguna) yang
bersangkutan. Jika dilakukan dengan benar, ini memungkinkan dan memerlukan tinjauan formal
terhadap kebutuhan data pengguna dan masalah keamanan seputar permintaan tersebut.
Menugaskan tanggung jawab untuk definisi pandangan pengguna kepada individu dengan tanggung
jawab pemrograman menghilangkan kebutuhan ini untuk mencari persetujuan dan dengan demikian
secara efektif mengikis kontrol akses ke DBMS.

Memisahkan Sistem Baru Pembangunan dari Pemeliharaan

Beberapa perusahaan mengatur fungsi pengembangan sistem mereka menjadi dua kelompok: analisis
dan pemrograman sistem. Alternatif organisasi ini disajikan pada Gambar 15-4. Kelompok analisis
sistem bekerja dengan pengguna untuk menghasilkan perancangan detil sistem baru. Kelompok
pemrograman mengkodekan program sesuai dengan spesifikasi desain ini. Dengan pendekatan ini,
pemrogram yang mengkode program asli juga mempertahankannya selama fase pemeliharaan siklus
pengembangan sistem. Meskipun pengaturan yang populer, pendekatan ini mempromosikan dua
masalah potensial: dokumentasi dan kecurangan yang tidak memadai.

DOKUMENTASI YANG TIDAK SESUAI. Dokumentasi sistem yang berkualitas buruk adalah masalah TI
yang kronis dan tantangan yang signifikan bagi banyak organisasi yang menginginkan kepatuhan SOX.
Setidaknya ada dua penjelasan untuk fenomena ini. Pertama, mendokumentasikan sistem tidak
semenarik merancang, menguji, dan menerapkannya. Profesional sistem lebih memilih untuk beralih
ke proyek baru yang menarik daripada dokumen yang baru saja selesai. Alasan kedua untuk
dokumentasi yang buruk adalah keamanan kerja. Ketika sebuah sistem didokumentasikan dengan
buruk, sulit untuk menafsirkan, menguji, dan melakukan debug. Oleh karena itu, pemrogram yang
memahami sistem (orang yang mengodeinya) mempertahankan kekuatan tawar menawar dan
menjadi sangat diperlukan. Ketika programmer meninggalkan perusahaan, seorang programmer baru
mewarisi tanggung jawab pemeliharaan terhadap sistem yang tidak terdokumentasi. Bergantung pada
kompleksitasnya, masa transisi mungkin panjang dan mahal.

Gambar 15-4

PROGRAM PENIPUAN. Bila pemrogram asli dari suatu sistem juga diberi tanggung jawab
pemeliharaan, potensi penipuan meningkat. Kecurangan program melibatkan perubahan yang tidak
sah pada modul program untuk tujuan melakukan tindakan ilegal. Pemrogram asli mungkin telah
berhasil menyembunyikan kode palsu di antara ribuan baris kode yang sah dan ratusan modul yang
membentuk sebuah sistem. Agar kecurangan berhasil, programmer harus bisa mengendalikan situasi
melalui akses eksklusif dan tidak terbatas ke program aplikasi. Pemrogram perlu melindungi kode
palsu dari deteksi yang tidak disengaja oleh pemrogram lain yang melakukan perawatan atau oleh
auditor yang menguji kontrol aplikasi. Oleh karena itu, memiliki tanggung jawab penuh untuk
pemeliharaan merupakan elemen penting dalam skema pemrogram duplikat. Melalui otoritas
pemeliharaan ini, pemrogram dapat dengan bebas mengakses sistem, menonaktifkan kode penipuan
selama audit dan kemudian mengembalikan kode saat pantai menjadi jelas. Penipuan semacam ini
bisa berlanjut bertahun-tahun tanpa deteksi.
Struktur Unggulan untuk Pengembangan Sistem

Gambar 15-3 menyajikan struktur organisasi yang unggul dimana fungsi pengembangan sistem
dipisahkan menjadi dua kelompok independen: pengembangan sistem dan pemeliharaan sistem baru.
Kelompok pengembangan sistem baru bertanggung jawab untuk merancang, memprogram, dan
mengimplementasikan proyek sistem baru. Setelah berhasil diimplementasikan, tanggung jawab atas
pemeliharaan berkelanjutan sistem ini sampai pada kelompok pemeliharaan sistem. Struktur ini
membantu menyelesaikan dua masalah kontrol yang dijelaskan sebelumnya.

Pertama, standar dokumentasi ditingkatkan karena kelompok pemeliharaan memerlukan

dokumentasi yang memadai untuk melaksanakan tugas perawatan mereka. Tanpa dokumentasi
lengkap, transfer formal tanggung jawab sistem dari pengembangan sistem baru ke pemeliharaan
sistem tidak dapat terjadi.

Kedua, menolak akses programmer asli masa depan untuk kode aplikasi menghalangi penipuan
program. Kode penipuan dalam sebuah aplikasi, yang berada di luar kendali pelaku, meningkatkan
risiko bahwa kecurangan akan ditemukan. Keberhasilan pengendalian ini bergantung pada adanya
kontrol lain yang membatasi, mencegah, dan mendeteksi akses yang tidak sah terhadap program
seperti kontrol perpustakaan program sumber yang dibahas di Bab 17. Sedangkan pemisahan
organisasi saja tidak dapat menjamin bahwa kecurangan komputer tidak akan terjadi, namun penting
untuk menciptakan lingkungan pengendalian yang diperlukan.

MODEL DISTRIBUSI

Bab 1 memeriksa dampak pada struktur organisasi yang beralih ke model pemrosesan data
terdistribusi (DDP) di mana departemen pengguna akhir mengendalikan layanan TI. Efek dari ini adalah
mengkonsolidasikan beberapa fungsi komputer yang secara tradisional dipisahkan dan untuk
mendistribusikan beberapa aktivitas yang dikonsolidasikan di bawah model terpusat. Terlepas dari
banyaknya kelebihan yang DDP berikan, pendekatan ini membawa implikasi pengendalian TI yang
harus diakui oleh manajemen dan akuntan. Ini dibahas pada bagian berikut.

Ketidakcocokan

Mendistribusikan tanggung jawab untuk pembelian perangkat lunak dan perangkat keras dapat
mengakibatkan keputusan yang tidak terkoordinasi dan kurang dipahami. Pengguna organisasi, yang
bekerja secara independen, dapat memilih sistem operasi yang berbeda dan tidak kompatibel,
platform teknologi, spreadsheet, pengolah kata, dan paket database, yang dapat mengganggu
komunikasi internal.

Redundansi

Aktivitas pengembangan sistem otonom di seluruh perusahaan dapat menghasilkan penciptaan

aplikasi dan database yang berlebihan. Program yang dibuat oleh satu pengguna yang dapat
digunakan dengan sedikit atau tanpa perubahan oleh orang lain akan didesain ulang dari awal dan
bukan dibagikan. Demikian juga, data yang umum bagi banyak pengguna dapat diproduksi ulang,
menghasilkan tingkat redundansi data yang tinggi.

Mengkonsolidasikan kegiatan yang tidak sesuai

Redistribusi fungsi TI ke area pengguna dapat menghasilkan banyak unit yang sangat kecil. Mencapai
pemisahan tugas yang memadai mungkin tidak layak secara ekonomi atau operasional dalam situasi
ini. Dengan demikian, satu orang (atau kelompok kecil) mungkin bertanggung jawab atas
pengembangan program, pemeliharaan program, dan operasi komputer.
Mendapatkan Profesional Berkualitas

Pengguna akhir biasanya tidak memenuhi syarat untuk mengevaluasi kredensial teknis dan
pengalaman yang relevan dari calon karyawan TI. Juga, karena unit organisasi yang menjadi kandidat
kandidat ini kecil, peluang untuk pertumbuhan pribadi, pendidikan berkelanjutan, dan promosi
terbatas. Untuk alasan ini, unit TI yang terdistribusi mungkin mengalami kesulitan untuk menarik
personil berkualifikasi tinggi.

Kurangnya Standar

Untuk alasan yang disebutkan di atas, standar untuk pengembangan sistem, dokumentasi, dan
penilaian kinerja cenderung tidak merata diterapkan atau tidak ada di lingkungan terdistribusi.

MENCIPTAKAN FUNGSI TI PERUSAHAAN

Model yang sepenuhnya terpusat dan terdistribusi sepenuhnya mewakili posisi ekstrim pada
rangkaian alternatif struktural. Kebutuhan kebanyakan perusahaan berada di antara titik akhir ini. Bagi
perusahaan-perusahaan ini, masalah kontrol yang terkait dengan DDP dapat, sampai batas tertentu,
dapat diatasi dengan menerapkan fungsi TI perusahaan. Gambar 15-5 menggambarkan pendekatan
organisasi ini.

Fungsi TI perusahaan adalah unit yang lebih ramping dengan misi yang berbeda daripada fungsi TI
terpusat yang ditunjukkan pada Gambar 15-4. Kelompok ini memberikan saran dan keahlian teknis
untuk berbagai fungsi TI terdistribusi, sebagaimana garis putus-putus ditunjukkan pada Gambar 15-5.
Beberapa layanan pendukung yang diberikan dijelaskan pada bagian berikut.

Pengujian Pusat Perangkat Lunak dan Perangkat Lunak Komersial

Kelompok TI perusahaan lebih mampu mengevaluasi kelebihan perangkat lunak dan perangkat keras
vendor yang bersaing. Kelompok sentral yang secara teknis cerdik seperti ini dapat mengevaluasi fitur,
kontrol, dan kompatibilitas sistem dengan standar industri dan organisasi yang paling efisien. Setelah
melakukan pengujian, mereka dapat membuat rekomendasi ke area pengguna untuk memandu
keputusan akuisisi.

Layanan Pengguna

Fitur berharga dari grup perusahaan adalah fungsi layanan penggunanya. Kegiatan ini memberikan
bantuan teknis kepada pengguna selama pemasangan perangkat lunak baru dan dalam mengatasi
masalah masalah perangkat keras dan perangkat lunak. Pembuatan papan buletin elektronik untuk
pengguna adalah cara terbaik untuk mendistribusikan informasi tentang masalah umum dan
memungkinkan berbagi program yang dikembangkan pengguna dengan orang lain di organisasi. Staf
layanan pengguna sering mengajarkan kursus teknis untuk pengguna akhir, yang meningkatkan
tingkat kesadaran pengguna dan mendorong berlakunya pendidikan tenaga teknis.

Standard-Setting Body

Menetapkan panduan pusat dapat memperbaiki lingkungan kontrol yang relatif buruk yang umum
terjadi pada model terdistribusi. Kelompok perusahaan dapat menetapkan dan mendistribusikan ke
area pengguna standar yang sesuai untuk pengembangan, pemrograman, dan dokumentasi sistem
yang sesuai dengan persyaratan SOX.
Ulasan personalia

Kelompok perusahaan lebih siap daripada pengguna untuk mengevaluasi kredensial teknis profesional
sistem prospektif. Meskipun calon karyawan TI akan bekerja untuk kelompok pengguna terdistribusi,
keterlibatan kelompok perusahaan dalam mengambil keputusan dapat memberikan layanan yang
berharga bagi organisasi.

Gambar 15-5

TUJUAN AUDIT YANG BERKAITAN DENGAN STRUKTUR ORGANISASI

Tujuan auditor adalah untuk memverifikasi bahwa individu-individu di daerah yang tidak sesuai
dipisahkan sesuai dengan tingkat risiko potensial dan dengan cara yang mempromosikan lingkungan
kerja. Ini adalah lingkungan di mana hubungan formal, daripada santai, harus ada antara tugas yang
tidak sesuai.

PROSEDUR AUDIT YANG BERKAITAN DENGAN STRUKTUR ORGANISASI

Tes kontrol berikut akan memungkinkan auditor mencapai tujuan pengendalian.

 Dapatkan dan tinjau kembali kebijakan perusahaan tentang keamanan komputer. Verifikasi
bahwa kebijakan keamanan dikomunikasikan ke karyawan dan supervisor yang bertanggung
jawab.
 Tinjaulah dokumentasi yang relevan, termasuk bagan organisasi saat ini, pernyataan misi, dan
uraian tugas untuk fungsi utama, untuk menentukan apakah individu atau kelompok
melakukan fungsi yang tidak sesuai.
 Meninjau dokumentasi sistem dan catatan pemeliharaan untuk contoh aplikasi. Verifikasi
bahwa pemrogram pemeliharaan yang ditugaskan untuk proyek tertentu juga bukan
programmer desain asli.
 Melalui pengamatan, tentukan bahwa kebijakan segregasi sedang diikuti dalam praktik. Tinjau
log akses ruang operasi untuk menentukan apakah pemrogram memasukkan fasilitas tersebut
dengan alasan selain kegagalan sistem.
 Tinjau kembali hak dan hak pengguna untuk memverifikasi bahwa pemrogram memiliki hak
akses yang sesuai dengan uraian tugas mereka.

Keamanan dan Kontrol Pusat Komputer

Kebakaran, banjir, angin, sabotase, gempa bumi, atau bahkan pemadaman listrik dapat
menghilangkan sebuah organisasi fasilitas pengolahan data dan menghentikan fungsi yang dilakukan
atau dibantu oleh komputer. Meskipun kemungkinan kejadian bencana semacam itu jauh,
konsekuensinya bagi organisasi bisa menjadi serius. Jika terjadi bencana, organisasi tidak hanya
kehilangan investasinya di fasilitas pengolahan data, namun yang lebih penting, juga kehilangan
kemampuannya untuk berbisnis.

Tujuan dari bagian ini adalah untuk menyajikan kontrol pusat komputer yang membantu menciptakan
lingkungan yang aman. Kita akan mulai dengan melihat kontrol yang dirancang untuk mencegah dan
mendeteksi ancaman ke pusat komputer. Namun, tidak peduli berapa banyak yang diinvestasikan
dalam kendali, beberapa bencana tidak dapat diantisipasi dan dicegah. Apa yang dilakukan
perusahaan untuk mempersiapkan diri menghadapi acara semacam itu? Bagaimana itu akan pulih?
Pertanyaan-pertanyaan ini merupakan inti dari rencana pemulihan bencana organisasi. Bagian
selanjutnya membahas secara khusus masalah-masalah yang berkaitan dengan pengembangan
rencana pemulihan bencana.

KONTROL PUSAT KOMPUTER

Kelemahan dalam keamanan pusat komputer berpotensi berdampak pada fungsi pengendalian
aplikasi terkait dengan proses pelaporan keuangan. Oleh karena itu, lingkungan fisik ini merupakan
masalah kontrol untuk kepatuhan SOX. Berikut adalah beberapa fitur kontrol yang berkontribusi
langsung pada keamanan pusat komputer.

Lokasi fisik

Lokasi fisik yang dipilih untuk pusat komputer dapat mempengaruhi risiko bencana. Sedapat mungkin,
pusat komputer harus berada jauh dari bahaya buatan manusia dan alam, seperti pabrik pengolahan,
sumber listrik gas dan air, bandara, daerah dengan tingkat kejahatan tinggi, dataran banjir, dan
kesalahan geologi.

Konstruksi

Idealnya, pusat komputer harus ditempatkan di gedung berlantai satu konstruksi padat dengan akses
terkontrol (dibahas pada bagian berikut). Utilitas (tenaga dan telepon) dan jalur komunikasi harus
berada di bawah tanah. Jendela bangunan tidak boleh dibuka. Sistem penyaringan udara harus berada
di tempat yang mampu menyingkirkan serbuk sari, debu, dan tungau debu.

Mengakses

Akses ke pusat komputer harus dibatasi oleh operator dan karyawan lain yang bekerja di sana.
Pemrogram dan analis yang kadang-kadang perlu memperbaiki kesalahan program harus diminta
masuk dan keluar. Pusat komputer harus menyimpan catatan akurat dari semua kejadian tersebut
untuk memverifikasi fungsi kontrol akses. Pintu masuk utama ke pusat komputer harus melalui satu
pintu saja, meski ada alarm darurat dengan alarm. Untuk mencapai tingkat keamanan yang lebih
tinggi, kamera sirkuit tertutup dan sistem perekaman video harus memantau akses.

AC

Komputer berfungsi paling baik di lingkungan ber-AC. Untuk komputer mainframe, menyediakan AC
yang memadai sering merupakan persyaratan garansi vendor. Komputer beroperasi paling baik pada
kisaran suhu 70 sampai 75 derajat Fahrenheit dan kelembaban relatif 50 persen. Kesalahan logika
dapat terjadi pada perangkat keras komputer saat suhu berangkat secara signifikan dari kisaran ini.
Juga, risiko kerusakan rangkaian dari listrik statis meningkat saat kelembaban turun. Kelembaban
tinggi, di sisi lain, dapat menyebabkan jamur tumbuh dan produk kertas (seperti dokumen sumber)
hingga peralatan membengkak dan selai.

Pemadam kebakaran

Ancaman yang paling umum terhadap peralatan komputer perusahaan adalah kebakaran. Setengah
dari perusahaan yang mengalami kebakaran gulung tikar karena kehilangan catatan kritis, seperti
piutang usaha. Penerapan sistem pemadaman kebakaran yang efektif memerlukan konsultasi dengan
spesialis. Beberapa fitur utama dari sistem seperti itu tercantum di bagian berikut.

1. Alarm otomatis dan manual harus ditempatkan di lokasi strategis di sekitar instalasi. Alarm ini
harus dihubungkan ke stasiun pemadam kebakaran permanen.
 2. Harus ada sistem pemadam kebakaran otomatis yang mengeluarkan jenis penekan (karbon
dioksida atau halon) yang sesuai untuk lokasi tersebut. Misalnya, penyemprotan air dan bahan
kimia tertentu di komputer bisa melakukan kerusakan sebanyak api.
3. Harus ada pemadam api manual yang ditempatkan di lokasi strategis.
4. Bangunan itu harus konstruksi yang bagus untuk menahan kerusakan air yang menyebabkan
peralatan pemadam kebakaran.
5. Pintu keluar api harus ditandai dengan jelas dan diterangi saat terjadi kebakaran.

Toleransi Toleransi Toleransi

Toleransi kesalahan adalah kemampuan sistem untuk melanjutkan operasinya saat bagian dari sistem
gagal karena kegagalan perangkat keras, kesalahan program aplikasi, atau kesalahan operator.
Menerapkan komponen sistem yang berlebihan dapat mencapai berbagai tingkat toleransi kesalahan.
Redundant disk dan power supplies adalah dua contoh umum.

Array redundant disk independen (RAID) melibatkan penggunaan disk paralel yang mengandung
elemen data dan aplikasi yang berlebihan. Jika satu disk gagal, data yang hilang secara otomatis
direkonstruksi dari komponen berlebihan yang tersimpan pada disk lainnya.

Uninterruptible power supplies membantu mencegah kehilangan data dan korupsi sistem. Jika terjadi
kegagalan pasokan listrik, daya cadangan jangka pendek disediakan agar sistem dapat ditutup
dengan cara yang terkendali. Menerapkan kontrol toleransi kesalahan memastikan bahwa tidak ada
satu titik kegagalan sistem potensial. Kegagalan total hanya bisa terjadi jika terjadi kegagalan
beberapa komponen.

Audit Objectives Relating to Computer Center Security

The auditor’s objective is to evaluate the controls governing computer center security. Specifically,
the auditor must verify that (1) physical security controls are adequate to reasonably protect the
organization from physical exposures; (2) insurance coverage on equipment is adequate to
compensate the organization for the destruction of, or damage to, its computer center; and (3)
operator documentation is adequate to deal with routine operations as well as system failures.

Prosedur Audit untuk Menilai Kontrol Keamanan Fisik

Berikut ini adalah tes kontrol keamanan fisik.

UJI KONSTRUKSI FISIK. Auditor harus memperoleh rencana arsitektural untuk menentukan bahwa
pusat komputer kokoh terbuat dari bahan tahan api. Harus ada drainase yang memadai di bawah
lantai yang terangkat agar air mengalir jika terjadi kerusakan air dari api di lantai atas atau dari sumber
lain. Selain itu, auditor harus menilai lokasi fisik pusat komputer. Fasilitas ini harus ditempatkan di
area yang meminimalkan keterpaparannya terhadap kebakaran, kerusuhan sipil, dan bahaya lainnya.

UJI SISTEM DETEKSI KEBAKARAN. Auditor harus menetapkan alat deteksi kebakaran dan penindasan,
baik manual maupun otomatis, ada di tempat dan diuji secara berkala. Sistem deteksi kebakaran harus
mendeteksi asap, panas, dan asap yang mudah terbakar. Buktinya dapat diperoleh dengan meninjau
catatan tes api resmi dari tes yang disimpan di pusat komputer.

UJI PENGENDALIAN AKSES Auditor harus menetapkan bahwa akses rutin ke pusat komputer dibatasi
pada pegawai yang berwenang. Rincian tentang akses pengunjung (oleh pemrogram dan lainnya),
seperti waktu kedatangan dan keberangkatan, tujuan, dan frekuensi akses, dapat diperoleh dengan
meninjau log akses. Untuk menetapkan kebenaran dokumen ini, auditor dapat secara diam-diam
mengamati proses dimana akses diizinkan.
Pengujian Toleransi Toleransi Toleransi

SERANGAN. Banyak konfigurasi RAID menyediakan pemetaan grafis dari penyimpanan disk mereka
yang berlebihan. Dari pemetaan ini, auditor harus menentukan apakah tingkat RAID yang ada
memadai untuk organisasi, mengingat tingkat risiko bisnis yang terkait dengan kegagalan disk. Jika
organisasi tidak menggunakan RAID, potensi satu titik kegagalan sistem ada. Auditor harus meninjau
ulang dengan prosedur alternatif administrator sistem untuk pemulihan dari kegagalan disk.

Cadangan bahan bakar. Auditor harus melakukan verifikasi dari catatan uji bahwa personil pusat
komputer melakukan tes berkala terhadap catu daya cadangan untuk memastikan bahwa ia memiliki
kapasitas yang cukup untuk menjalankan komputer dan penyejuk udara. Tes penting ini dan hasilnya
harus dicatat secara formal.

Prosedur Audit untuk Memeriksa Cakupan Asuransi

Auditor setiap tahun harus meninjau cakupan asuransi organisasi di perangkat keras komputer,
peralatan lunak, dan fasilitas fisiknya. Auditor harus memverifikasi bahwa semua akuisisi baru
tercantum pada polis dan peralatan dan perangkat usang telah dihapus. Polis asuransi harus
mencerminkan kebutuhan manajemen dalam hal cakupan. Misalnya, perusahaan mungkin ingin
diasuransikan sebagian dan memerlukan pertanggungan minimum. Di sisi lain, perusahaan dapat
mencari cakupan biaya penggantian yang lengkap.

Prosedur Audit untuk Memeriksa Kecukupan Dokumentasi Operator

Operator komputer menggunakan dokumentasi yang disebut run manual untuk menjalankan aspek-
aspek tertentu dari sistem. Secara khusus, sistem batch yang besar seringkali memerlukan perhatian
khusus dari operator. Sepanjang hari, operator komputer dapat melakukan puluhan program
komputer yang masing-masing memproses beberapa file dan menghasilkan banyak laporan. Untuk
mencapai operasi pengolahan data yang efektif, manual yang dijalankan harus cukup rinci untuk
memandu operator dalam tugas mereka. Auditor harus meninjau manual yang dijalankan untuk
kelengkapan dan akurasi. Isi khas dari run manual meliputi:

 Nama sistem, seperti '' Purchases System ''

 Jadwal lari (harian, mingguan, waktu dalam sehari)
 Perangkat perangkat keras yang dibutuhkan (kaset, disk, printer, atau perangkat keras khusus)
 Persyaratan berkas menentukan semua file (input) transaksi, file induk, dan file output yang
digunakan dalam sistem
 Instruksi run-time yang menjelaskan pesan kesalahan yang mungkin muncul, tindakan yang
akan diambil, dan nama dan nomor telepon pemrogram yang sedang dihubungi, jika sistem
gagal
 Daftar pengguna yang menerima output dari pelarian

Selain itu, auditor harus memverifikasi bahwa dokumentasi sistem tertentu, seperti diagram alir
sistem, diagram alur logika, dan daftar kode program, bukan merupakan bagian dari dokumentasi
operator. Untuk alasan yang telah dibahas sebelumnya, operator seharusnya tidak memiliki akses
terhadap rincian operasional logika internal sistem.

Perencanaan Pemulihan Bencana

Beberapa bencana tidak dapat dicegah atau dihindari. Peristiwa terkini meliputi angin topan, banjir
meluas, gempa bumi, dan kejadian 11 September 2001. Kelangsungan hidup sebuah perusahaan yang
terkena dampak bencana bergantung pada bagaimana reaksi tersebut terjadi. Dengan perencanaan
kontinjensi yang hati-hati, dampak bencana bisa diserap dan organisasi masih dapat pulih kembali.

Rencana pemulihan bencana (DRP) adalah pernyataan komprehensif dari semua tindakan yang harus
dilakukan sebelum, selama, dan setelah bencana, disertai prosedur yang terdokumentasi dan teruji
yang akan menjamin kelangsungan operasi. Meskipun rincian masing-masing rencana unik untuk
kebutuhan organisasi, semua rencana kerja memiliki fitur umum. Sisa bagian ini dikhususkan untuk
diskusi mengenai masalah kontrol berikut: menyediakan cadangan situs kedua, mengidentifikasi
aplikasi penting, melakukan prosedur penyimpanan cadangan dan off-site, membuat tim pemulihan
bencana, dan menguji DRP.

MENYEDIAKAN BACKUP KEDUA

Bahan yang diperlukan dalam DRP adalah menyediakan fasilitas pengolahan data duplikat setelah
terjadi bencana. Pilihan yang tersedia termasuk cangkang kosong, pusat operasi pemulihan, dan
cadangan yang disediakan secara internal.

Shell Kosong

Rencana lokasi shell kosong atau cold site adalah pengaturan dimana perusahaan membeli atau
menyewa bangunan yang akan berfungsi sebagai pusat data. Jika terjadi bencana, cangkangnya
tersedia dan siap menerima perangkat keras apa pun yang dibutuhkan pengguna sementara untuk
menjalankan sistem penting. Pendekatan ini, bagaimanapun, memiliki kelemahan mendasar.
Pemulihan tergantung pada ketersediaan perangkat keras komputer yang diperlukan untuk
mengembalikan fungsi pemrosesan data. Manajemen harus mendapatkan jaminan (kontrak) dari
vendor perangkat keras yang jika terjadi bencana, vendor akan memberikan prioritas kebutuhan
perusahaan. Permasalahan hardware yang tidak diantisipasi pada saat kritis ini bisa menjadi pukulan
fatal.

Pusat Operasi Pemulihan

Pusat operasi pemulihan (ROC) atau situs yang panas adalah pusat data cadangan lengkap yang
dimiliki banyak perusahaan. Selain fasilitas perangkat keras dan cadangan, penyedia layanan ROC
menawarkan berbagai layanan teknis kepada klien mereka, yang membayar biaya tahunan untuk hak
akses. Jika terjadi bencana besar, pelanggan dapat menempati lokasi dan, dalam beberapa jam,
melanjutkan pemrosesan aplikasi penting.

11 September 2001, adalah ujian yang benar untuk keandalan dan efektivitas pendekatan ROC.
Comdisco, penyedia ROC utama, memiliki 47 klien yang menyatakan 93 bencana yang berbeda pada
hari serangan tersebut. Semua 47 perusahaan pindah dan bekerja di pusat pemulihan Comdisco. Pada
satu titik, 3.000 karyawan klien bekerja di luar pusat kegiatan. Ribuan komputer dikonfigurasi untuk
kebutuhan klien dalam 24 jam pertama, dan tim pemulihan sistem berada di tempat di mana pun
polisi mengizinkan akses. Pada tanggal 25 September, hampir separuh klien dapat kembali ke fasilitas
mereka dengan sistem yang berfungsi penuh.

Masalah dengan pendekatan ini adalah potensi persaingan antar pengguna untuk sumber daya ROC.
Bencana alam yang meluas, seperti banjir atau gempa bumi, dapat menghancurkan kemampuan
pemrosesan data beberapa anggota ROC yang berada di wilayah geografis yang sama. Semua korban
akan menemukan diri mereka bersaing untuk mendapatkan akses ke fasilitas terbatas yang sama.
Karena beberapa penyedia layanan ROC memperluas kapasitas mereka dengan rasio 20: 1, situasinya
serupa dengan kapal tenggelam yang memiliki jumlah sekoci yang tidak memadai.
Periode kebingungan setelah bencana bukanlah waktu yang ideal untuk menegosiasikan hak
kepemilikan. Oleh karena itu, sebelum masuk ke dalam pengaturan ROC, manajemen harus
mempertimbangkan potensi masalah kepadatan penduduk dan pengelompokan geografis
keanggotaan saat ini.

Backup yang diberikan secara internal

Organisasi yang lebih besar dengan banyak pusat pemrosesan data sering memilih kemandirian yang
menciptakan kapasitas kelebihan internal. Hal ini memungkinkan perusahaan untuk mengembangkan
konfigurasi perangkat keras dan perangkat lunak standar, yang memastikan kompatibilitas fungsional
di antara pusat pemrosesan data dan meminimalkan masalah pemotongan jika terjadi bencana.

Pershing, sebuah divisi dari Donaldson, Lufkin & Jenrette Securities Corporation, memproses lebih dari
36 juta transaksi per hari, sekitar 2.000 per detik. Manajemen Pershing menyadari bahwa vendor ROC
tidak dapat memberikan waktu pemulihan yang mereka inginkan dan butuhkan. Oleh karena itu,
perusahaan membangun pusat data cermin jarak jauh sendiri. Fasilitas ini dilengkapi dengan
perangkat penyimpanan berkapasitas tinggi yang mampu menyimpan lebih dari 20 terabyte data dan
dua mainframe IBM yang menjalankan perangkat lunak salinan kecepatan tinggi. Semua transaksi
yang proses sistem utama ditransmisikan secara real time bersama kabel serat optik ke fasilitas backup
jarak jauh. Pada setiap titik waktu, pusat data cermin mencerminkan kejadian ekonomi saat ini dari
perusahaan. Sistem cermin telah mengurangi waktu pemulihan data Pershing dari 24 jam menjadi 1
jam.

MENGIDENTIFIKASI APLIKASI KRITIS

Unsur penting lain dari DRP melibatkan prosedur untuk mengidentifikasi aplikasi kritis dan file data
perusahaan yang akan dipulihkan. Akhirnya, semua aplikasi dan data harus dikembalikan ke tingkat
aktivitas bisnis predisaster. Upaya pemulihan segera, bagaimanapun, harus berfokus pada pemulihan
aplikasi dan data yang sangat penting bagi kelangsungan hidup jangka pendek organisasi. Dalam
skenario bencana apapun, ini adalah survivabilitas jangka pendek yang menentukan kelangsungan
hidup jangka panjang.

Bagi kebanyakan organisasi, kelangsungan hidup jangka pendek memerlukan pemulihan fungsi-fungsi
yang menghasilkan arus kas yang cukup untuk memenuhi kewajiban jangka pendek. Sebagai contoh,
asumsikan bahwa fungsi berikut mempengaruhi posisi arus kas perusahaan tertentu:

 Penjualan dan layanan pelanggan

 Pemenuhan kewajiban hukum
 Pemeliharaan dan penagihan piutang
 Produksi dan distribusi
 Pembelian
 Komunikasi antar cabang atau instansi
 Hubungan Masyarakat

Aplikasi komputer yang mendukung fungsi ini secara langsung sangat penting. Oleh karena itu, aplikasi
ini harus diidentifikasi dan diprioritaskan dalam rencana pemulihan.

Prioritas aplikasi dapat berubah dari waktu ke waktu, dan keputusan ini harus dinilai ulang secara
teratur. Sistem terus direvisi dan diperluas untuk mencerminkan perubahan dalam persyaratan
pengguna. Demikian pula, DRP harus diperbarui untuk mencerminkan perkembangan baru dan
mengidentifikasi aplikasi penting. Prioritas yang up-to-date penting karena mempengaruhi aspek lain
dari rencana strategis. Misalnya, perubahan dalam prioritas aplikasi dapat menyebabkan perubahan
pada sifat dan tingkat persyaratan cadangan kedua lokasi dan prosedur pencadangan tertentu.

Tugas untuk mengidentifikasi dan memprioritaskan aplikasi kritis memerlukan partisipasi aktif
manajemen, departemen pengguna, dan auditor internal. Terlalu sering, tugas ini salah dianggap
sebagai masalah TI dan didelegasikan kepada profesional TI. Meskipun bantuan teknis dari personil
sistem diperlukan, ini terutama keputusan bisnis dan yang paling siap untuk memahami masalah bisnis
harus membuatnya.

MELAKUKAN CADANGAN DAN CADANGAN PROSEDUR PENYIMPANAN SITUS

Semua file data, dokumentasi aplikasi, dan persediaan yang dibutuhkan untuk melakukan fungsi kritis
harus ditentukan dalam DRP. Personel pengolahan data harus secara rutin melakukan prosedur
backup dan penyimpanan untuk melindungi sumber daya kritis ini.

File data cadangan

Backup state-of-the-art dalam backup database adalah situs mirror jarak jauh, yang telah dijelaskan
sebelumnya, yang menyediakan data lengkap mata uang. Tidak semua organisasi bersedia atau
mampu menginvestasikan sumber daya cadangan tersebut. Sebagai minimum, bagaimanapun,
database harus disalin setiap hari ke tape atau disk dan diamankan di luar kantor. Jika terjadi
gangguan, rekonstruksi database dicapai dengan memperbarui versi cadangan terbaru dengan data
transaksi berikutnya. Demikian juga, file master dan file transaksi harus dilindungi.

Dokumentasi cadangan

Dokumentasi sistem untuk aplikasi kritis harus dicadangkan dan disimpan di luar lokasi dengan cara
yang sama seperti file data. Volume material yang besar dan revisi aplikasi yang konstan mempersulit
tugas tersebut. Prosesnya bisa dibuat lebih efisien melalui penggunaan alat dokumentasi teknik bantu
komputer (CASE).

Persediaan Cadangan dan Dokumen

Perusahaan harus. Dan yang sumbernya digunakan dalam aplikasi kritis. Contoh persediaan kritis
adalah cek saham, faktur, pesanan pembelian, dan bentuk penawaran khusus lainnya yang tidak dapat
diperoleh dengan segera.

MENCIPTAKAN TIM PEMULIHAN BENCANA

Pemulihan dari bencana bergantung pada tindakan korektif yang tepat waktu. Gagal melakukan tugas
penting (seperti mendapatkan file cadangan untuk aplikasi kritis) memperpanjang masa pemulihan
dan mengurangi prospek pemulihan yang berhasil. Untuk menghindari kelalaian atau duplikasi upaya
yang serius selama pelaksanaan rencana kontinjensi, tanggung jawab tugas individual harus
didefinisikan secara jelas dan dikomunikasikan kepada personil yang terlibat.

Gambar 15-6 menyajikan bagan organisasi yang menggambarkan kemungkinan komposisi tim
pemulihan bencana. Anggota tim harus menjadi ahli di bidang mereka dan telah menugaskan tugas.
Setelah bencana, anggota tim akan mendelegasikan subtugas ke bawahan mereka. Perlu dicatat
bahwa masalah kontrol tradisional tidak berlaku dalam situasi ini. Lingkungan yang ditimbulkan
bencana mungkin memerlukan pelanggaran kontrol normal seperti pemisahan tugas, kontrol akses,
dan pengawasan. Pada titik ini, kontinuitas bisnis adalah pertimbangan utama.

Gambar 15-6
PENGUJIAN DRP

Aspek perencanaan kontinjensi yang paling diabaikan adalah menguji rencana. Meskipun demikian,
tes DRP penting dan harus dilakukan secara berkala. Pengujian memberikan ukuran kesiapan personil
dan mengidentifikasi kelalaian atau kemacetan dalam rencana.

Sebuah tes paling berguna dalam bentuk simulasi kejutan gangguan. Saat bencana tiruan diumumkan,
status semua pemrosesan yang harus didokumentasikan harus didokumentasikan. Ini memberikan
tolok ukur untuk penilaian kinerja selanjutnya. Rencananya harus dilakukan sejauh layak secara
ekonomi. Idealnya, ini termasuk penggunaan fasilitas dan persediaan cadangan.

TUJUAN AUDIT: PENILAIAN PERENCANAAN PEMULIHAN BENCANA

Auditor harus memverifikasi bahwa rencana pemulihan bencana manajemen memadai dan layak
dilakukan untuk mengatasi bencana yang dapat menghambat pengorganisasian sumber daya
komputasi. Tes berikut berfokus pada bidang yang menjadi perhatian terbesar.

PROSEDUR AUDIT UNTUK MENILAI PERENCANAAN PEMULIHAN BENCANA

Backup Situs Kedua

Auditor harus mengevaluasi kecukupan pengaturan situs cadangan. Klien harus memiliki kontrak
vendor yang menjamin pengiriman peralatan tepat waktu ke tempat yang dingin. Dalam hal
keanggotaan ROC, auditor harus memperoleh informasi mengenai jumlah anggota dan penyebaran
geografisnya. Bencana yang meluas dapat menciptakan permintaan bahwa fasilitas cadangan tidak
dapat dipuaskan.

Daftar Aplikasi Kritis

Auditor harus meninjau daftar aplikasi kritis dan memastikannya lancar dan lengkap. Aplikasi yang
hilang mungkin mengakibatkan kegagalan untuk pulih. Di sisi lain, mengembalikan aplikasi yang tidak
kritis mengalihkan sumber daya langka ke tugas-tugas yang tidak produktif.

Backup Aplikasi Kritis dan File Data Kritis

Auditor harus memverifikasi bahwa organisasi memiliki prosedur yang ada untuk mendukung salinan
aplikasi kritis dan data yang tersimpan di luar lokasi. Bukti ini dapat diperoleh dengan memilih contoh
file data dan program dan menentukan apakah mereka didukung sesuai kebutuhan.

Persediaan Cadangan, Dokumen Sumber, dan Dokumentasi

Dokumentasi sistem, persediaan, dan dokumen sumber yang diperlukan untuk memulihkan dan
menjalankan aplikasi penting harus dicadangkan dan disimpan di luar lokasi. Auditor harus
memverifikasi bahwa jenis dan jumlah item yang ditentukan dalam DRP ada di lokasi yang aman.

Tim Pemulihan Bencana

DRP harus secara jelas mencantumkan nama, alamat, dan nomor telepon darurat anggota tim
pemulihan bencana. Auditor harus memverifikasi bahwa anggota tim adalah karyawan saat ini dan
menyadari tanggung jawab mereka yang ditugaskan. Pada satu kesempatan, saat meninjau DRP
sebuah perusahaan, penulis menemukan bahwa seorang pemimpin tim yang terdaftar dalam rencana
tersebut telah meninggal dunia selama 9 bulan.
Outsourcing Fungsi TI

Biaya, risiko, dan tanggung jawab yang terkait dengan pemeliharaan fungsi perusahaan yang efektif TI
sangat penting. Oleh karena itu, banyak eksekutif memilih untuk mengalihkan fungsi TI mereka ke
vendor pihak ketiga yang mengambil alih tanggung jawab atas pengelolaan aset dan staf TI dan untuk
pengiriman layanan TI seperti entri data, operasi pusat data, pengembangan aplikasi, pemeliharaan
aplikasi, dan jaringan pengelolaan. Seringkali dikutip manfaat outsourcing TI mencakup peningkatan
kinerja bisnis inti, peningkatan kinerja TI (karena keahlian vendor), dan mengurangi biaya TI. Dengan
memindahkan fasilitas TI ke luar negeri ke daerah dengan biaya tenaga kerja rendah dan / atau melalui
skala ekonomis (dengan menggabungkan beberapa klien), vendor dapat melakukan fungsi alih daya
lebih murah daripada yang dapat dilakukan oleh perusahaan klien. Penghematan biaya yang
dihasilkan kemudian diteruskan ke organisasi klien. Selanjutnya, banyak pengaturan outsourcing TI
melibatkan penjualan aset TI perusahaan klien, baik manusia dan mesin, ke vendor yang kemudian
disewa oleh perusahaan klien. Transaksi ini menghasilkan infus tunai satu kali yang signifikan ke
perusahaan.

Logika yang mendasari TI outsourcing mengikuti teori kompetensi inti, yang berpendapat bahwa
sebuah organisasi harus berfokus secara eksklusif pada kompetensi bisnis intinya, sementara
memungkinkan vendor outsourcing mengelola wilayah non-inti secara efisien seperti fungsi TI. Premis
ini, bagaimanapun, mengabaikan perbedaan penting antara komoditas dan aset TI spesifik.

Aset TI komoditi tidak unik untuk organisasi tertentu dan dengan demikian mudah diperoleh di pasar.
Ini mencakup hal-hal seperti manajemen jaringan, operasi sistem, pemeliharaan server, dan fungsi
help desk. Aset TI spesifik, sebaliknya, unik bagi organisasi dan mendukung tujuan strategisnya. Karena
sifatnya yang istimewa, aset tertentu memiliki nilai yang kecil di luar penggunaan mereka saat ini. Aset
semacam itu mungkin berwujud (peralatan komputer), intelektual (program komputer), atau
manusia. Contoh aset spesifik meliputi pengembangan sistem, pemeliharaan aplikasi, pergudangan
data, dan karyawan terampil yang terlatih untuk menggunakan perangkat lunak khusus organisasi.

Teori Biaya Biaya Ekonomi (TCE) bertentangan dengan sekolah kompetensi inti dengan menyarankan
bahwa perusahaan harus mempertahankan aset TI non-inti spesifik tertentu di-rumah. Karena sifat
esoteris mereka, aset spesifik tidak dapat dengan mudah diganti begitu mereka menyerah dalam
pengaturan alih daya. Oleh karena itu, jika organisasi harus memutuskan untuk membatalkan kontrak
outsourcing dengan vendornya, perusahaan tersebut mungkin tidak dapat kembali ke keadaan
sebelum melakukan outsourcing. Di sisi lain, teori TCE mendukung outsourcing aset komoditas, yang
mudah diganti atau diperoleh dari vendor alternatif.

Tentu, persepsi CEO tentang apa yang merupakan komoditas aset TI memainkan peran penting dalam
keputusan outsourcing TI. Seringkali ini berujung pada masalah definisi dan interpretasi. Sebagai
contoh, kebanyakan CEO akan mendefinisikan fungsi TI mereka sebagai komoditas non-inti, kecuali
jika mereka menjalankan bisnis untuk mengembangkan dan menjual aplikasi TI. Akibatnya, keyakinan
bahwa semua TI dapat, dan seharusnya, dikelola oleh organisasi layanan besar cenderung menang.
Kesalahan persepsi semacam itu mencerminkan, sebagian, keduanya tidak memiliki pendidikan
eksekutif dan penyebaran informasi yang salah mengenai kebajikan dan keterbatasan TI outsourcing.

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.
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). Dalam usaha
pemotongan biaya, EDS menghentikan tujuh ribu karyawan, yang berdampak pada kemampuannya
untuk melayani klien lainnya. Setelah harga saham terendah 11 tahun, pemegang saham EDS
mengajukan gugatan class action kepada perusahaan tersebut. Jelas, vendor yang mengalami masalah
keuangan dan hukum yang serius juga mengancam kelangsungan hidup klien mereka.

Eksploitasi Vendor

Pengalihan TI berskala besar melibatkan pemindahan aset khusus vendor 'seperti disain,
pengembangan, dan pemeliharaan aplikasi bisnis unik yang penting bagi kelangsungan hidup sebuah
organisasi. Aset khusus, yang bernilai bagi klien, tidak banyak berpengaruh pada vendor di luar kontrak
langsung dengan klien. Memang, mereka mungkin tidak berharga jika organisasi klien gulung tikar.
Karena vendor mengasumsikan risiko dengan mengakuisisi aset dan tidak dapat mencapai skala
ekonomi dengan mempekerjakan mereka di tempat lain, organisasi klien akan membayar premi untuk
mentransfer fungsi tersebut ke pihak ketiga. Selanjutnya, setelah perusahaan klien melepaskan diri
dari aset spesifik tersebut, hal itu menjadi tergantung pada vendor. Vendor dapat memanfaatkan
ketergantungan ini dengan menaikkan tarif layanan ke tingkat selangit. 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.

Biaya Outsourcing Melebihi Manfaat

IT outsourcing telah dikritik karena biaya tak terduga muncul dan tingkat keuntungan yang diharapkan
tidak direalisasikan. Satu survei mengungkapkan bahwa 47 persen dari 66 perusahaan yang disurvei
melaporkan bahwa biaya outsourcing TI melebihi keuntungan outsourcing. Salah satu alasannya
adalah bahwa klien outsourcing sering gagal mengantisipasi biaya pemilihan vendor, kontrak, dan
transisi operasi TI ke vendor.

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. Untuk sebagian besar, perusahaan A.S. bergantung pada langkah-langkah
keamanan vendor outsourcing, kebijakan akses data, dan undang-undang privasi negara tuan rumah.
Sebagai contoh, seorang wanita di Pakistan memperoleh data medis pasien-sensitif dari University of
California Medical Center di San Francisco. Dia mendapatkan akses ke data dari seorang penjual
transkripsi medis untuk siapa dia bekerja. Wanita itu mengancam akan menerbitkan catatan di
Internet jika dia tidak mendapatkan kenaikan gaji. Terorisme di Asia dan Timur Tengah menimbulkan
masalah keamanan tambahan bagi perusahaan yang meng-outsource teknologi lepas pantai.
Misalnya, pada tanggal 5 Maret 2005, polisi di Delhi, India, menangkap sel dari tersangka teroris yang
berencana untuk menyerang perusahaan outsourcing di Bangalore, India.
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. Untuk
mempromosikan keselarasan tersebut, perusahaan membutuhkan manajer TI dan chief information
officer (CIO) yang memiliki pengetahuan kerja yang kuat mengenai bisnis organisasi. Sebuah survei
terhadap 213 manajer TI di industri jasa keuangan memastikan bahwa kepemimpinan TI perusahaan
harus disesuaikan dengan strategi persaingan perusahaan. Memang, ada yang berpendapat bahwa
kompetensi bisnis CIO lebih penting daripada kompetensi TI mereka dalam memfasilitasi kongruensi
strategis.

Untuk mencapai keselarasan tersebut, diperlukan adanya hubungan kerja yang erat antara
manajemen perusahaan dan manajemen TI dalam pengembangan strategi bisnis dan TI bersamaan.
Namun, ini sulit dilakukan ketika perencanaan TI dialihkan secara geografis ke lepas pantai atau
bahkan di dalam negeri. Lebih jauh lagi, karena pembenaran finansial untuk outsourcing TI bergantung
pada vendor yang mencapai skala ekonomis, vendor secara alami didorong untuk mencari solusi
umum yang dapat digunakan oleh banyak klien daripada menciptakan solusi unik untuk masing-
masing perusahaan. Dasar mendasar dari outsourcing TI ini tidak konsisten dengan usaha mengejar
keuntungan strategis di pasar.

IMPLIKASI AUDIT IT OUTSOURCING

Manajemen dapat melakukan outsourcing fungsi TI organisasi mereka, namun mereka tidak dapat
mengalihkan tanggung jawab manajemen mereka di bawah SOX untuk memastikan pengendalian
internal TI yang memadai. PCAOB secara khusus menyatakan dalam Standar Audit No. 2, ''
Penggunaan organisasi layanan tidak mengurangi tanggung jawab manajemen untuk
mempertahankan pengendalian internal yang efektif atas pelaporan keuangan. Sebaliknya,
manajemen pengguna harus mengevaluasi kontrol pada organisasi layanan, serta kontrol terkait di
perusahaan pengguna, saat melakukan penilaian tentang pengendalian internal atas pelaporan
keuangan. '' Oleh karena itu, jika perusahaan audit meng-outsource fungsi TI-nya ke vendor yang
memproses transaksinya, menjadi tuan rumah data utama, atau melakukan layanan significan lainnya,
auditor perlu melakukan evaluasi terhadap kontrol organisasi vendor, atau secara alternatif
mendapatkan laporan auditor SAS No. 70 dari organisasi vendor.

Pernyataan Standar Audit No. 70 (SAS 70) adalah standar definitif dimana auditor organisasi klien
dapat memperoleh pengetahuan bahwa kontrol pada vendor pihak ketiga memadai untuk mencegah
atau mendeteksi kesalahan material yang dapat mempengaruhi laporan keuangan klien. Laporan SAS
70, yang disiapkan oleh auditor vendor, membuktikan kecukupan kontrol internal vendor. Ini adalah
cara dimana vendor outsourcing dapat memperoleh satu laporan audit yang dapat digunakan oleh
auditor kliennya dan dengan demikian menghalangi kebutuhan setiap auditor perusahaan auditor
untuk melakukan audit sendiri terhadap pengendalian internal 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 vendor, 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.

Auditor penyedia layanan mengeluarkan dua jenis laporan SAS 70. Laporan SAS 70 Type I kurang ketat
dari keduanya dan hanya berkomentar mengenai kesesuaian desain kontrol. Laporan SAS 70 Type II
berjalan lebih jauh dan menilai apakah pengendalian beroperasi secara efektif berdasarkan tes yang
dilakukan oleh auditor organisasi vendor. Sebagian besar laporan SAS 70 yang diterbitkan adalah Tipe
II. Karena Bagian 404 memerlukan pengujian kontrol secara eksplisit, SAS 70 Tipe I tidak bernilai sedikit
di dunia pasca-SOX.

Gambar 15-7