Mengaudit Pengendalian Tata Kelola TI

Setelah mempelajari bab ini, Anda harus:

• Memahami risiko fungsi yang tidak sesuai dan bagaimana menyusun fungsi TI.

• Mengenal kontrol dan tindakan pencegahan yang diperlukan untuk memastikan

keamanan fasilitas komputer organisasi.

• Mengenal keuntungan, risiko, dan audit yang terkait dengan IT outsourcing.

Bab ini menyajikan risiko, kontrol, dan uji kontrol yang terkait dengan tata kelola TI. Ini
terbuka dengan mendefinisikan tata kelola TI dan elemen tata kelola TI yang memiliki
pengendalian internal dan implikasi pelaporan keuangan. Pertama, menyajikan eksposur yang
bisa timbul dari penataan fungsi TI yang tidak tepat. Selanjutnya, bab ini mengulas ancaman dan
kontrol pusat komputer, termasuk melindunginya dari kerusakan dan kerusakan akibat bencana
alam, suhu api, dan kelembaban. bab ini menghadirkan elemen kunci dari rencana pemulihan
bencana, termasuk menyediakan cadangan lokasi kedua, mengidentifikasi aplikasi kritis,
melakukan prosedur penyimpanan cadangan dan off-site, menciptakan tim pemulihan bencana,
dan menguji rencana tersebut. Bagian terakhir dari bab ini menyajikan isu-isu mengenai tren
yang berkembang menuju outsourcing TI. Logika di balik keputusan manajemen untuk
melakukan outsourcing dieksplorasi. Bab ini juga mengungkapkan harapan akan adanya manfaat
dan risiko yang terkait dengan lingkungan outsourcing dan peran laporan SAS 70.

TATA KELOLA TEKNIS INFORMASI

Tata kelola teknologi informasi (TI) merupakan subjet yang relatif baru dari tata kelola
perusahaan yang berfokus pada pengelolaan dan penilaian sumber daya TI strategis. Tujuan
utama tata kelola TI adalah mengurangi risiko dan memastikan investasi sumber daya TI
memberi nilai tambah bagi korporasi. Sebelum Undang-Undang Sarbanes-Oxley (SOX), praktik
umum mengenai investasi TI adalah untuk menunda semua keputusan terhadap profesional TI
perusahaan. Tata kelola TI modern, bagaimanapun, mengikuti filosofi bahwa semua pemangku
kepentingan perusahaan, termasuk dewan direksi, manajemen puncak, dan pengguna departemen
(yaitu, keuangan akuntansi menjadi peserta aktif dalam keputusan TI utama. Keterlibatan
berbasis luas tersebut mengurangi risiko dan meningkatkan kemungkinan bahwa Keputusan TI
akan sesuai dengan kebutuhan pengguna, kebijakan perusahaan, halal strategis, dan persyaratan
pengendalian internal di bawah SOX.

PENGENDALIAN TATA KELOLA TI

Meskipun semua masalah tata kelola TI penting bagi organisasi, tidak semuanya merupakan
masalah pengendalian internal di bawah SOX yang berpotensi mempengaruhi proses pelaporan
keuangan. Dalam bab ini, kami mempertimbangkan tiga masalah tata kelola TI yang ditangani
oleh SOX dan kerangka pengendalian internal COSO ini adalah:

• Struktur organisasi fungsi TI

• Operasi di pusat komputer

• 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, yang menetapkan apa yang harus diverifikasi mengenai fungsi kontrol di tempat.
Akhirnya, contoh, tes kontrol ditawarkan yang menjelaskan bagaimana auditor dapat
mengumpulkan bukti untuk memenuhi tujuan audit. Tes ini dapat dilakukan oleh auditor
eksternal sebagai bagian dari layanan pengabdian mereka atau oleh auditor internal (atau
profesional penasehat layanan) yang memberikan bukti kepatuhan manajemen terhadap SOX.
Dalam hal ini, kita tidak membedakan antara dua jenis layanan.
STRUKTUR FUNGSI TEKNOLOGI INFORMASI

Organisasi fungsi TI memiliki implikasi untuk sifat dan efektivitas pengendalian internal, yang
pada gilirannya memiliki implikasi untuk audit. Pada bagian ini, beberapa masalah kontrol
penting yang terkait dengan struktur TI diperiksa. Ini diilustrasikan melalui dua model organisasi
ekstrim - pendekatan terpusat dan pendekatan pendistribusian. Risiko, kontrol, dan masalah audit
yang terkait dengan masing-masing model dibahas.

PENGOLAHAN DATA CENTRALIZED

Di bawah model PENGOLAHAN DATA CENTRALIZED, semua pemrosesan data dilakukan

oleh rumah komputer besar atau raksasa di lokasi pusat yang berfungsi digunakan di seluruh
organisasi.

hal38-39

pengolahan data, dan pengembangan sistem dan pemeliharaan. deskripsi fungsi kunci dari
masing-masing bidang berikut.

Administrasi Database

Perusahaan yang dikelola secara sentral mempertahankan sumber data mereka di lokasi sentral
yang dikomandoi oleh semua pengguna akhir. Dalam pengaturan data bersama ini, goup
independen yang dipimpin oleh administrator database (DBA) bertanggung jawab atas ketajaman
dan keterkaitan database.

Pengolahan data

Kelompok pengolahan data mengelola sumber daya komputer yang digunakan untuk melakukan
pemrosesan transaksi sehari-hari. Ini terdiri dari fungsi organisasi followinf: konversi data,
operasi komputer, dan perpustakaan data.

Konversi data. Fungsi konversi data mentranskripsikan data transaksi dari dokumen sumber hard
copy menjadi input komputer: misalnya, konversi data bisa membuat perintah penjualan ke
dalam aplikasi pesanan penjualan dalam sistem modern, atau mentranskripsikan data ke dalam
media magnetik (tape atau disk) yang sesuai untuk pengolahan komputer dalam sistem tipe
warisan.

Operasi Komputer. File elektronik yang dihasilkan dalam konversi data kemudian diproses
oleh komputer pusat, yang dikelola oleh kelompok operasi komputer. Aplikasi akuntansi
biasanya dijalankan sesuai jadwal yang ketat yang dikontrol oleh sistem operasi komputer pusat.

Perpustakaan data. Perpustakaan data adalah ruangan yang berdekatan dengan pusat komputer
yang menyediakan penyimpanan penyimpanan untuk file data off-line. File-file itu bisa berupa
backup atau file data saat ini. Misalnya, perpustakaan data digunakan untuk menyimpan file data
operasional saat ini pada kaset magnetik dan paket disk yang dapat dilepas. Selain itu,
perpustakaan data digunakan untuk menyimpan salinan asli perangkat lunak komersial dan
lisensi mereka untuk penyimpanan. seorang pustakawan data, yang bertanggung jawab atas
penerimaan, penyimpanan, pengambilan, dan penyimpanan file data, mengendalikan akses ke
perpustakaan. pustakawan mengeluarkan file data ke operator komputer sesuai dengan
permintaan program dan mengambil hak asuh saat memproses atau prosedur backup selesai.
Kecenderungan dalam beberapa tahun terakhir terhadap pemrosesan ral-waktu dan penggunaan
file akses langsung yang berhasil telah mengurangi atau bahkan menghilangkan peran
pustakawan data di banyak organisasi.

Pengembangan dan Pemeliharaan Sistem.

Sistem informasi kebutuhan pengguna dipenuhi oleh dua fungsi terkait: pengembangan sistem
dan pemeliharaan sistem. Kelompok terdahulu bertanggung jawab untuk menganalisis kebutuhan
pengguna dan merancang syetem baru untuk memenuhi kebutuhan tersebut. Peserta dalam
kegiatan pengembangan sistem meliputi profesional sistem, pengguna akhir, dan pemangku
kepentingan.

Sistem professional meliputi analis sistem, perancang database, dan programer yang
merancang dan membangun sistem. profesional sistem mengumpulkan fakta tentang
masalah pengguna, menganalisis fakta, dan merumuskan solusi. hasil usaha mereka adalah
sebuah sistem informasi baru.
 Pengguna akhir adalah mereka yang sistemnya dibangun. Mereka adalah manajer yang
menerima laporan dari sistem dan personil operasi yang bekerja secara langsung dengan
sistem sebagai bagian dari tanggung jawab harian mereka.

Pemangku kepentingan adalah individu di dalam atau di luar perusahaan yang memiliki
interst dalam sistem, namun bukan pengguna akhir. mereka termasuk akuntan, auditor
internal, auditor eksternal, dan pihak lain yang mengawasi pengembangan sistem.

Begitu sistem telah dirancang dan diterapkan, kelompok pemeliharaan sistem bertanggung
jawab untuk mempertahankannya saat ini dengan kebutuhan pengguna. istilah
pemeliharaan mengacu pada perubahan program logika untuk mengakomodasi pergeseran
kebutuhan pengguna dari waktu ke waktu. Selama perjalanan hidup sistem (seringkali
beberapa tahun), sebanyak 80 atau 90 persen dari total biaya dapat dikeluarkan melalui
kegiatan pemeliharaan.

Pemisahan Fungsi TI Yang Tidak Kompatibel

Bab sebelumnya menekankan pentingnya memisahkan tugas yang tidak sesuai dalam
aktivitas manual. Secara spesifik, tugas operasional harus dipisahkan menjadi:

1. memisahkan otorisasi transaksi dari proses transaksi,

2. pencatatan terpisah dari penitipan aset

3. Bagi tugas pemrosesan transaksi di antara individu-individu yang kekurangan kolusi antara
dua atau lebih kecurangan individu tidak akan mungkin dilakukan.

Lingkungan TI cenderung mengkonsolidasikan kegiatan. Aplikasi tunggal dapat memberi

otorisasi, memproses, dan mencatat semua aspek transaksi dari transaksi dengan perusahaan,
fokus kontrol segregasi bergeser dari tingkat operasional. Dengan menggunakan bagan
organisasi pada Gambar 2.2 sebagai rujukan, keterkaitan antara pengembangan sistem,
pemeliharaan sistem. administrasi database, dan kegiatan operasi komputer yang diperiksa
selanjutnya.

Pengembangan sistem sengketa dari operasi komputer.

 segregasi pengembangan sistem (baik pengembangan dan pemeliharaan sistem baru) dan
kegiatan operasi sangat penting. hubungan antara kelompok-kelompok ini harus sangat formal,
dan tanggung jawab mereka tidak akan digabungkan. pengembangan sistem dan profesional
pemeliharaan harus menciptakan (dan memelihara) sistem bagi pengguna, dan seharusnya tidak
terlibat dalam memasukkan data, atau menjalankan aplikasi (i, e., operasi komputer). Staf operasi
harus menjalankan sistem ini dan tidak memiliki keterlibatan dalam desain mereka. fungsi ini
inherentlu tidak kompatibel dan mengkonsolidasikan m mengundang kesalahan dan kecurangan.
dengan pengetahuan rinci tentang parameter aplikasi dan parameter pengarsipan dan akses ke
sistem operasi dan utilitas komputer, seseorang dapat membuat perubahan yang tidak sah pada
aplikasi selama pelaksanaannya.

Dari transaksi dengan perusahaan, fokus kontrol segregasi bergeser dari tingkat
operasional. Dengan menggunakan bagan organisasi pada Gambar 2.2 sebagai rujukan,
keterkaitan antara pengembangan sistem, pemeliharaan sistem. administrasi database, dan
kegiatan operasi komputer yang diperiksa selanjutnya.

Pengembangan sistem sengketa dari operasi komputer.

segregasi pengembangan sistem (baik pengembangan dan pemeliharaan sistem baru) dan
kegiatan operasi sangat penting. hubungan antara kelompok-kelompok ini harus sangat formal,
dan tanggung jawab mereka tidak akan digabungkan. pengembangan sistem dan profesional
pemeliharaan harus menciptakan (dan memelihara) sistem bagi pengguna, dan seharusnya tidak
terlibat dalam memasukkan data, atau menjalankan aplikasi (i, e., operasi komputer). Staf operasi
harus menjalankan sistem ini dan tidak memiliki keterlibatan dalam desain mereka. fungsi ini
inherentlu tidak kompatibel dan mengkonsolidasikan m mengundang kesalahan dan kecurangan.
dengan pengetahuan rinci tentang parameter aplikasi dan parameter kontrol dan akses ke sistem
operasi dan utilitas komputer, seseorang dapat membuat perubahan yang tidak sah pada aplikasi
selama eksekusi. Perubahan semacam itu mungkin bersifat sementara ("pada flay") dan akan
hilang tanpa jejak saat aplikasi semacam itu terjadi. memisahkan administrasi database dari
fungsi oyyher

Kontrol organisasi dan pengarsipan lainnya adalah pemisahan administrator database

(DBA) dari fungsi pusat komputer lainnya yang bertanggung jawab atas sejumlah tugas penting
yang berkaitan dengan keamanan database kto, termasuk membuat skema database dan wiew
pengguna, menetapkan otoritas akses satabase kepada pengguna, memantau penggunaan
database , dan merencanakan ekspansi ke depan. Mendelegasikan tanggung jawab ini kepada
orang lain yang melakukan tugas yang tidak sesuai mengancam integratif database. kita lihat dari
gambar 2.2

hal40-41

Memisahkan Pembangunan Sistem Baru dari Pemeliharaan

Beberapa perusahaan mengatur fungsi pengembangan sistem in-house mereka menjadi dua
kelompok: analisis dan pemrograman sistem (lihat gambar 2.3). kelompok analisis sistem
bekerja dengan pengguna untuk menghasilkan perancangan detil sistem baru. Kelompok
pemrograman mengkodekan program sesuai dengan spesifikasi desain ini. Dengan pendekatan
ini, programir yang mengkode program asli juga memelihara sistem selama tahap pemeliharaan
siklus hidup pengembangan sistem (dibahas di Bab 5). Meskipun pengaturan yang sama,
pendekatan ini dikaitkan dengan dua jenis masalah kontrol: dokumentasi dan potensi kecurangan
program yang tidak memadai. Dokumentasi yang tidak memadai 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. Para profesional sistem lebih memilih untuk beralih ke proyek baru yang
menarik daripada mendokumentasikan dokumen yang baru saja selesai.

Kemungkinan kedua untuk dokumentasi yang buruk adalah keamanan kerja. Ketika sebuah
sistem didokumentasikan dengan buruk, sulit untuk menafsirkan, menguji dan debug. Oleh
karena itu, pemrogram yang memahami sistem (orang yang mengodeinya) memelihara selang
tawar 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.
Kecurangan program bila programmer asli dari suatu sistem juga diberi tanggung jawab
pemeliharaan, potensi kecurangan meningkat. Kecurangan program melibatkan perubahan yang
dilakukan pada modul program untuk tujuan melakukan tindakan ilegal, pemrogram asli
mungkin telah berhasil menyembunyikan kode palsu di antara seribu baris kode yang sah dan
hunderds modul yang membentuk sebuah sistem. Agar kecurangan berhasil, programmar harus
mampu mengendalikan situasi melalui akses eksklusif dan tidak terbatas terhadap program
aplikasi. Progres perlu melindungi kode yang tidak benar dari pendeteksian yang tidak disengaja
oleh programmaer lain yang melakukan perawatan atau dengan menguji kontrol aplikasi auditor.
Oleh karena itu, memiliki tanggung jawab penuh untuk pemeliharaan merupakan elemen penting
dalam skema programmer duplikat. Melalui otoritas pemeliharaan ini, pemrogram dapat dengan
bebas mengakses sistem, menonaktifkan kode penipuan selama audit dan mengembalikan kode
saat pantai jelas. Penipuan semacam ini bisa berlanjut selama bertahun-tahun tanpa deteksi.

Struktur Unggulan Untuk Pengembangan Sistem

Gambar 2.2 menyajikan struktur organisasi yang superior dimana fungsi pengembangan sistem
dipisahkan menjadi dua kelompok yang berbeda: pengembangan sistem baru dan pemeliharaan
sistem. Kelompok pengembangan sistem baru bertanggung jawab untuk merancang,
memprogram, dan mengimplementasikan proyek sistem baru. Dengan implementasi yang
berhasil, tanggung jawab untuk pemeliharaan sistem terus berlanjut sampai ke kelompok
pemeliharaan sistem.

Restrukturisasi ini berimplikasi secara langsung terhadap dua masalah kontrol yang baru saja
dijelaskan
Pertama, standar dokumentasi ditingkatkan karena kelompok pemeliharaan memerlukan
dokumentasi untuk melaksanakan tugas perawatannya. Tanpa dokumentasi yang lengkap dan
memadai, transfer formal tanggung jawab sistem dari pengembangan sistem baru ke
pemeliharaan sistem tidak dapat terjadi.

Kedua, menolak akses programmer yang asli ke program menghalangi kendali pemrogram dan
mungkin ditemukan meningkatkan risiko yang terkait dengan kecurangan program. Keberhasilan
pengendalian ini tergantung pada adanya kontrol lain yang membatasi, mencegah, dan
mendeteksi akses tidak sah ke program (seperti kontrol perpustakaan program sumber).
Meskipun pemisahan organisasi saja tidak dapat menjamin bahwa kecurangan komputer tidak
akan terjadi, namun penting untuk menciptakan lingkungan pengendalian yang diperlukan.

Model terdistribusi

Selama bertahun-tahun, skala ekonomi menyukai komputer besar dan kuat dan pemrosesan
terpusat. Namun sekarang, sistem kecil, kuat, dan murah telah mengubah gambar ini secara
dramatis. Alternatif model terpusat adalah konsep distributed data processing (DDP). Topik DDP
cukup luas, menyentuh topik terkait seperti komputasi pengguna akhir, perangkat lunak
komersial, jaringan, dan otomasi kantor. Secara sederhana, DDP melibatkan reorganisasi fungsi
TI pusat menjadi unit TI kecil yang berada di bawah kendali pengguna akhir. Unit TI dapat
didistribusikan sesuai dengan fungsi bisnis, lokasi geografis, atau keduanya. Semua atau fungsi
TI yang ditunjukkan pada gambar 2.2 dapat didistribusikan. Tingkat dimana mereka
didistribusikan akan bervariasi tergantung pada filosofi dan tujuan manajemen organisasi.
Gambar 2.4 menyajikan dua alternatif pendekatan DDP.

Alternatif A sebenarnya adalah varian dari model terpusat; Perbedaannya adalah bahwa terminal
(atau mikrokomputer) didistribusikan ke pengguna akhir untuk menangani input dan output. Ini
membuat kebutuhan akan kelompok konversi data terpusat, karena pengguna sekarang
melakukan tugas ini. Namun, di bawah model ini, pengembangan sistem, operasi komputer, dan
administrasi basis data tetap terpusat.

Alternatif B adalah keberangkatan yang signifikan dari model terpusat. Alternatif ini
mendistribusikan semua layanan komputer kepada pengguna akhir, di mana mereka beroperasi
sebagai unit mandiri. Hasilnya adalah penghapusan fungsi TI pusat dari struktur organisasi.
Perhatikan interkoneksi antara unit terdistribusi pada gambar 2.4. koneksi ini mewakili
pengaturan jaringan yang memungkinkan komunikasi dan transfer data antar unit. Gambar 2.5
menunjukkan sebuah struktur organisasi yang mungkin mencerminkan distribusi semua tugas
pengolahan data tradisional ke area pengguna akhir.

Hal42-43

Risiko yang terkait dengan DDP

Bagian ini membahas risiko yang perlu dipertimbangkan saat menerapkan DDP. Diskusi
berfokus pada isu-isu penting yang membawa implikasi pengendalian yang harus diakui auditor.
Masalah yang potensial meliputi ketidakefisienan sumber daya, peniadaan/penghilangan jejak
audit, pemisahan tugas yang tidak memadai, potensi peningkatan kesalahan pemrograman dan
kegagalan sistem dan kurangnya standar.

Penggunaan Sumber Daya yang tidak efisien

DDP dapat mengekspos dan mengorganisir tiga jenis risiko yang terkait dengan penggunaan
sumber daya organisasi yang tidak efisien. Diuraikan di bawah ini.

Pertama adalah risiko salah kelola sumber daya TI di seluruh organisasi oleh pengguna akhir,
beberapa berpendapat bahwa ketika sumber daya keseluruhan organisasi melebihi jumlah yang
diramalkan, misalnya 5 persen dari total anggaran operasi, tata kelola TI yang efektif
memerlukan sentral pengelolaan dan pemantauan sumber daya semacam itu. Bagi banyak
organisasi, layanan TI dalam menggabungkan operasi komputer, pemrograman, konversi data,
dan pengelolaan basis data memenuhi ambang ini.

Kedua, DPP dapat meningkatkan risiko inefisiensi operasional karena adanya tugas berlebihan
yang dilakukan dalam komite pengguna akhir. Inisiatif pengembangan sistem otonom yang
didistribusikan ke seluruh perusahaan dapat menghasilkan setiap area pengguna yang
menciptakan roda daripada memanfaatkannya dari pekerjaan. Misalnya, program aplikasi yang
dibuat oleh satu pengguna, yang bisa digunakan dengan link atau tidak ada perubahan oleh pihak
lain, akan didesain ulang dari awal daripada dibagi. Demikian juga, data yang umum bagi
banyak pengguna mungkin diciptakan kembali untuk masing-masing, menghasilkan tingkat
redundansi data yang tinggi. Keadaan ini berimplikasi pada akurasi data dan konsistensi.
Ketiga, ruang lingkup DPP berisiko terhadap sistem operasi, platform teknologi, spreadsheet,
pengolah kata dan paket database yang tidak sesuai. Perangkat keras dan perangkat lunak tidak
kompatibel dapat menurunkan dan mengganggu konektivitas antar unit, menyebabkan hilangnya
transaksi dan kemungkinan penghilangan/peniadaan jejak audit.

Penghilangan jejak audit

Jejak audit memberikan keterkaitan antara aktivitas keuangan (transaksi) perusahaan sebuah
laporan keuangan yang melaporkan kegiatan tersebut. Auditor menggunakan jejak audit untuk
melacak transaksi keuangan terpilih dari dokumen sumber yang menangkap kejadian tersebut,
melalui jurnal, buku besar pembantu

Hal44-45

dan akun buku besar yang mencatat kejadian tersebut, dan akhirnya pada laporan keuangan itu
sendiri. Jejak audit sangat penting bagi auditor untuk membuktikan layanannya.

Dalam sistem DDP, jejak audit terdiri dari satu set file transaksi digital yang merupakan file
induk (bab 6 membahas teknik pemrosesan transaksi) yang berada sebagian atau seluruhnya pada
komputer pengguna akhir jika pengguna akhir secara tidak sengaja menghapus file tersebut, Uji
coba audit bisa dihancurkan dan tidak terpulihkan. Demikian pula, jika pengguna akhir secara
tidak sengaja memasukkan kesalahan transaksi ke dalam file jejak audit, itu bisa menjadi rusak.

Segregasi tugas yang tidak memadai. Mencapai pemisahan tugas yang memadai mungkin
tidak dapat dilakukan di beberapa lingkungan terdistribusi. distribusi layanan TI kepada
pengguna dapat menghasilkan penciptaan unit independen kecil yang tidak mengizinkan
pemisahan fungsi yang tidak sesuai yang diinginkan. Misalnya, dalam satu unit orang yang sama
dapat menulis program aplikasi, melakukan perawatan program, memasukkan data transaksi ke
komputer, dan mengoperasikan peralatan komputer. situasi seperti itu akan menjadi pelanggaran
mendasar pengendalian internal.

Mempekerjakan profesional yang berkualitas. Manajer pengguna akhir mungkin tidak

memiliki pengetahuan TI untuk mengevaluasi kredensial teknis dan pengalaman kandidat yang
relevan yang berlaku untuk posisi profesional TI. Juga, jika unit organisasi tempat karyawan
baru masuk adalah kecil, peluang untuk pertumbuhan pribadi, pendidikan lanjutan, dan promosi
mungkin terbatas. Untuk alasan ini, manajer mungkin mengalami kesulitan menarik personil
berkualifikasi tinggi. Risiko kesalahan pemrograman dan kegagalan sistem meningkat secara
langsung dengan tingkat ketidakmampuan karyawan.

Kurangnya standar. Karena distribusi tanggung jawab di lingkungan DDP, standar untuk
mengembangkan dan mendokumentasikan sistem, memilih bahasa pemrograman, memperoleh
perangkat keras dan perangkat lunak, dan mengevaluasi kinerja mungkin tidak rata diterapkan
atau bahkan tidak ada. Penentang DDP berpendapat bahwa risiko yang terkait dengan
perancangan dan pengoperasian sistem DDP dapat dilakukan hanya jika standar tersebut
diterapkan secara konsisten.

Kelebihan DDP

Bagian ini mempertimbangkan keunggulan potensial DDP, termasuk pengurangan biaya,

pengendalian biaya yang ditingkatkan, peningkatan kepuasan pengguna, dan cadangan.

Pengurangan Biaya.Selama bertahun-tahun, mencapai skala ekonomi merupakan justifikasi

utama untuk pendekatan pengolahan data terpusat. Ekonomi pengolahan data disukai komputer
besar, mahal, dan kuat. Berbagai macam kebutuhan bahwa sistem terpusat diharapkan dapat
memuaskan juga menyerukan komputer yang sangat umum dan menggunakan sistem operasi
yang kompleks. Biaya overhead yang terkait dengan menjalankan sistem semacam itu,
bagaimanapun, dapat mengurangi keuntungan dari kekuatan pemrosesan mentahnya. Jadi, bagi
banyak pengguna, sistem terpusat yang besar merepresentasikan jumlah berlebihan yang mahal
sehingga mereka harus melarikan diri.

Mikrokomputer canggih dan murah dan minicomputer yang bisa melakukan fungsi
khusus telah mengubah ekonomi pengolahan data secara dramatis. Selain itu, biaya unit
penyimpanan data, yang dulunya merupakan pembenaran untuk mengkonsolidasikan data di
lokasi sentral, sudah tidak menjadi pertimbangan utama. Selain itu, pindah ke DDP telah
mengurangi biaya ke area lain: (1) data dapat diedit dan dimasukkan oleh pengguna akhir,
sehingga menghilangkan tugas terpusat dari persiapan data; (2) kompleksitas aplikasi dapat
dikurangi, yang pada gilirannya akan mengurangi biaya pengembangan dan pemeliharaan sistem.
Tanggung jawab pengendalian biaya yang lebih baik. manajer pengguna akhir bertanggung
jawab atas keberhasilan operasi mereka. tanggung jawab ini mengharuskan mereka diberi
wewenang yang benar dengan wewenang untuk membuat keputusan mengenai sumber daya
yang mempengaruhi keberhasilan mereka secara keseluruhan. ketika manajer dilarang membuat
keputusan yang diperlukan untuk mencapai tujuan mereka, kinerjanya dapat terpengaruh secara
negatif. Manajemen yang kurang aggresive dan kurang efektif dapat berkembang.

Pendukung DDP berpendapat bahwa manfaat dari sikap manajemen yang lebih baik lebih
besar daripada biaya tambahan yang dikeluarkan untuk mendistribusikan sumber daya ini.
mereka berpendapat bahwa jika kemampuan TI memang penting bagi keberhasilan operasi
busnis, maka manajemen harus diberi kontrol atas sumber daya ini. Argumen ini membantah
diskusi sebelumnya yang mendukung pemusatan sumber daya organisasi.

Meningkatkan kepuasan pengguna. Mungkin manfaat DDP yang paling sering dikutip adalah
peningkatan kepuasan pengguna. Pendukung DDP mengklaim bahwa sistem pendistribusian ke
pengguna akhir memperbaiki tiga bidang kebutuhan yang sering kali tidak terpuaskan pada
model terpusat: (1) seperti yang dinyatakan sebelumnya, pengguna ingin mengendalikan sumber
daya yang mempengaruhi profitabilitas mereka: (2) pengguna menginginkan profesional sistem (
analis, programmer dan komputer dan operator) untuk bersikap responsif terhadap situasi
spesifik mereka; dan (3) pengguna ingin lebih terlibat secara aktif dalam mengembangkan dan
menerapkan sistem mereka sendiri.

Fleksibilitas cadangan. Argumen terakhir yang mendukung DDP adalah kemampuan untuk
mendukung fasilitas komputasi untuk melindungi dari potensi bencana sep
erti kebakaran, banjir, sabotase, dan gempa bumi. satu-satunya cara untuk mendukung sebuah
situs komputer utama melawan bencana tersebut adalah dengan menyediakan fasilitas komputer
kedua. Kemudian di bab ini kami memeriksa perencanaan pemulihan bencana untuk kontinjensi
semacam itu. model terdistribusi menawarkan fleksibilitas organisasi untuk menyediakan
cadangan. setiap unit TI geoprafik terpisah dapat dirancang dengan kapasitas berlebih. Jika
bencana menghancurkan satu situs, situs lain dapat menggunakan kelebihan kapasitas mereka
untuk memproses transaksi di situs yang hancur. Secara alami, pengaturan ini memerlukan
koordinasi yang erat antara manajer pengguna akhir untuk memastikan bahwa mereka tidak
menerapkan perangkat keras dan perangkat lunak yang tidak kompatibel.

Mengendalikan lingkungan DDP

DDP membawa nilai prestise mutakhir tertentu, yang selama analisis pro dan kontranya, dapat
membebani pertimbangan penting tentang manfaat ekonomi dan kelayakan operasional.
beberapa organisasi telah beralih ke DDP tanpa mempertimbangkan secara matang apakah
struktur organisasi terdistribusi akan mencapai tujuan bisnis mereka dengan lebih baik. banyak
inisiatif DDP terbukti tidak efektif, dan bahkan kontraproduktif, karena keputusan membuat
sistem nilai-nilai ini menjadi lebih simbolis daripada nyata. Sebelum mengambil langkah yang
tidak dapat dipulihkan, pengambil keputusan harus menilai manfaat sebenarnya dari DDP untuk
organisasinya. Namun, perencanaan dan pelaksanaan kontrol yang hati-hati dapat mengurangi
beberapa risiko DDP yang telah dibahas sebelumnya. Bagian ini mengulas beberapa perbaikan
model DDP yang ketat

Menerapkan fungsi IT perusahaan

Model yang sepenuhnya terpusat dan model terdistribusi mewakili posisi ekstrim pada rangkaian
alternatif struktural. kebutuhan sebagian besar perusahaan jatuh di antara titik akhir ini.
Seringkali, masalah kontrol yang telah dijelaskan sebelumnya dapat diatasi dengan menerapkan
fungsi IT perusahaan seperti yang diilustrasikan pada gambar 2.5

Fungsi ini sangat berkurang dalam ukuran dan status dari model terpusat yang
ditunjukkan pada gambar 2.2 kelompok TI perusahaan menyediakan pengembangan sistem dan
pengelolaan basis data untuk sistem keseluruhan entitas selain saran teknis dan keahlian kepada
komunitas TI terdistribusi. Peran penasehat ini ditunjukkan oleh garis putus-putus pada gambar
2.5. beberapa layanan yang diberikan dijelaskan selanjutnya

Hal46-47
Pengujian Pusat Perangkat Lunak dan Perangkat Lunak Komersial. Grup TI perusahaan
terpusat lebih siap daripada dan pengguna mengevaluasi kelebihan perangkat lunak komersial
dan produk perangkat keras yang bersaing yang sedang dipertimbangkan. Kelompok sentral yang
secara teknis cerdik seperti ini dapat mengevaluasi fitur, kontrol, dan kompatibilitas sistem
dengan standar industri dan organisasi. Hasil uji kemudian dapat didistribusikan ke area
pengguna sebagai standar untuk membimbing keputusan akuisisi. Hal ini memungkinkan
organisasi untuk secara efektif memusatkan akuisisi, pengujian, dan implementasi perangkat
lunak dan perangkat keras dan menghindari banyak masalah yang dibahas sebelumnya.

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 ada dalam program yang dikembangkan pengguna
dengan orang lain di organisasi. Selain itu ruang obrolan bisa dibuat untuk memberikan diskusi
berulir, tanya jawab (FAQs), dan dukungan intranet. Fungsi TI perusahaan juga bisa
menyediakan meja bantuan, di mana pengguna dapat menelepon dan mendapat tanggapan cepat
terhadap pertanyaan dan masalah. Di banyak organisasi, staf layanan pengguna mengajarkan
kursus teknis untuk pengguna akhir dan juga untuk petugas layanan komputer. Hal ini
meningkatkan tingkat kesadaran pengguna dan mendorong berlanjutnya pendidikan tenaga
teknis.

Standard-Setting Body. Lingkungan pengendalian yang relatif buruk yang diberlakukan oleh
model DPD dapat ditingkatkan dengan menetapkan beberapa panduan utama. Kelompok
perusahaan dapat berkontribusi pada tujuan ini dengan menetapkan dan mendistribusikan ke area
pengguna sesuai standar untuk pengembangan, pemrograman, dan dokumentasi sistem.

Ulasan personalia. Kelompok perusahaan seringkali lebih siap daripada pengguna untuk
mengevaluasi kredensial teknis profesional sistem prospektif. Meskipun profesional sistem
sebenarnya akan menjadi bagian dari kelompok pengguna akhir, keterlibatan kelompok
perusahaan dalam keputusan kerja dapat memberikan layanan yang berharga bagi organisasi.

PROCEDUR AUDIT
 Prosedur audit berikut akan berlaku untuk sebuah organisasi dengan fungsi TI terpusat:

 Meninjau 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.
 Review dokumentasi dan catatan pemeliharaan sistem untuk contoh aplikasi. Verifikasi
bahwa pemrogram pemeliharaan yang ditugaskan ke proyek tertentu juga bukan
pemrogram desain asli.
 Pastikan operator komputer tidak memiliki akses ke rincian operasional logika internal
sistem. Dokumentasi sistem, seperti diagram alir sistem, diagram alur logika, dan daftar
kode program, tidak boleh menjadi bagian dari dokumentasi operasi.
 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.

Prosedur audit berikut akan berlaku untuk organisasi dengan fungsi TI terdistribusi:

 Tinjau bagan organisasi saat ini, pernyataan misi, dan uraian tugas untuk fungsi utama
untuk menentukan apakah individu atau kelompok melakukan tugas yang tidak sesuai.
 Verifikasi bahwa kebijakan dan standar perusahaan untuk sistem yang dirancang, disain,
dokumentasi, dan akuisisi perangkat keras dan perangkat lunak dipublikasikan dan
diserahkan ke unit TI terdistribusi.
 Pastikan kontrol kompensasi, seperti pemantauan pengawasan dan manajemen,
dipekerjakan bila pemisahan tugas yang tidak kompatibel secara ekonomi tidak layak
dilakukan.
 Mengkaji ulang dokumentasi sistem untuk memverifikasi bahwa aplikasi, prosedur, dan
database dirancang dan berfungsi sesuai dengan standar perusahaan.

PUSAT KOMPUTER

Akuntan secara rutin memeriksa lingkungan fisik pusat komputer sebagai bagian dari audit
tahunan mereka. Tujuan dari bagian ini adalah untuk menyajikan risiko pusat komputer dan
kontrol yang membantu mengurangi risiko dan menciptakan lingkungan yang aman. Berikut ini
adalah area eksposur potensial yang dapat mempengaruhi kualitas informasi, catatan akuntansi,
pemrosesan transaksi, dan efektivitas pengendalian internal lainnya yang lebih konvensional.

Lokasi fisik

Lokasi fisik pusat komputer secara langsung mempengaruhi risiko kerusakan akibat bencana
alam atau buatan manusia. Sedapat mungkin, pusat komputer harus jauh dari bahaya buatan
manusia dan alam, seperti pabrik pengolahan, gas dan air, bandara, daerah dengan tingkat
kejahatan tinggi, dataran banjir, dan kesalahan geologi. Pusat harus jauh dari lalu lintas normal,
seperti lantai atas bangunan atau bangunan terpisah yang terpisah. Menemukan komputer di
gedung bawah tanah meningkatkan risikonya banjir.

Konstruksi
Idealnya, pusat komputer harus berada dalam satu lantai konstruksi padat dengan akses
terkontrol (dibahas selanjutnya). Saluran utilitas (listrik dan telepon) harus berada di bawah
tanah. Jendela bangunan tidak boleh terbuka dan sistem filtrasi yang adil harus ada yang mampu
mengeluarkan serbuk sari, debu, dan tungau debu.

Mengakses
Akses ke pusat komputer harus dibatasi oleh operator dan karyawan lain yang bekerja di sana.
Kontrol fisik, seperti pintu terkunci, harus digunakan untuk membatasi akses ke pusat. Akses
harus dikontrol dengan keypad atau kartu gesek, meski menyala ...,.

Hal48-49

Keluar dengan alarm diperlukan. Untuk mencapai tingkat keamanan yang lebih tinggi, akses
harus dipantau dengan kamera sirkuit tertutup dan sistem perekaman video, Pusat komputer juga
harus menggunakan log masuk untuk pemrogram dan analis yang menemukan akses pada
kesalahan program wabah. Pusat komputer harus menyimpan catatan akurat tentang semua lalu
lintas tersebut.

Kondisi udara
Komputer berfungsi paling baik di lingkungan ber-AC, dan menyediakan pendingin ruangan
yang memadai sering menjadi 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 optimal ini. Juga, risiko kerusakan rangkaian dari listrik statis meningkat saat
kelembaban turun. Sebaliknya, kelembaban tinggi dapat menyebabkan jamur tumbuh dan produk
kertas (seperti dokumen sumber) hingga peralatan membengkak dan selai.

Pemadam Kebakaran

Api adalah ancaman paling serius terhadap peralatan komputer perusahaan. Banyak perusahaan
yang menderita kebakaran di pusat komputer gulung tikar karena kehilangan catatan kritis,
seperti piutang usaha. Implementasi sistem pemadaman kebakaran yang efektif dengan spesialis.
Namun, beberapa fitur utama dari sistem konsistensi semacam ini mencakup hal-hal berikut:

1. Alarm otomatis dan manual harus ditempatkan di lokasi-lokasi strategis di sekitar terminal.
Alarm ini harus dihubungkan ke stasiun pemadam kebakaran permanen,

2. Harus ada sistem pemadam kebakaran otomatis yang mengeluarkan jenis penekan yang sesuai
untuk lokasi. Misalnya. penyemprotan air dan mikrofon tertentu pada komputer bisa melakukan
kerusakan sebanyak api.

3.Pemadam api manual harus diletakkan di lokasi yang strategis.

4. Bangunan harus konstruksi yang baik untuk menahan kerusakan air yang disebabkan oleh
peralatan penindas api.

5. Pintu keluar api harus ditandai dengan jelas dan diterangi saat terjadi kebakaran.

Toleransi Fault

Toleransi kesalahan adalah kemampuan sistem untuk melanjutkan operasinya saat sebagian
sistem gagal karena kegagalan perangkat keras, program aplikasi error, atau kesalahan operator
lmplementing fault kontrol toleransi memastikan bahwa tidak ada satu titik kegagalan sistem
potensial yang ada. Kegagalan total hanya dapat terjadi jika beberapa komponen fa Dua contoh
teknologi toleransi kesalahan dibahas selanjutnya.

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

Hal50-51

Pengujian Uninterruptible Power Supply.

Pusatkomputerharusmelakukantesberkalaterhadapcadangancatudayagunamemastikankapasitasny
amemadaiuntukmenjalankankomputerdanpendinginruangan. Iniadalahtes yang sangatpenting,
danhasilnyaharusdicatatsecara formal.
Seiringberkembangnyasistemkomputerperusahaandanketergantungannyameningkat,
kebutuhandayalistrikcadangancenderungtumbuhsecaraproporsional. Memang,
tanpatessemacamini,sebuahorganisasimungkintidakmenyadaribahwasystem informasi yang
dikembangkantelahmelampauikapasitascadangannya

PengujianUntukCakupanAsuransi.

Auditor setiaptahunharusmeninjauulangperlindunganasuransiuntukperangkatkeraskomputer,
perangkatlunak, danfasilitasfisikperusahaan. Auditor
harusmemverifikasibahwasemuaakuisisibarudicantumkanpada polis
danperangkatusangtelahdihapus. Polis
asuransiharusmencerminkanpengelolaankebutuhandalamhalcakupan yang dibutuhkan.

PERENCANAAN DARI PENCEGAHAN BENCANA

Bencanasepertigempabumi, banjir, sabotase,

danbahkankegagalanlistrikbisamenjadibencanabagipusatkomputerdansisteminformasiperusahaan
. Gambar 2.6 menggambarkantigakategoribencana yang
dapatmerampoksebuahorganisasisumberdaya TI-nya:
 Kebakaran
Jenis-
JenisBenca
na Alam Banjir

Tornado

Sabotase
Bencana AkibatManusia

Eror

KehabisanDa
ya

Kegagalansist KegagalnHar
em ddrive

Kegagalan
Software

bencanaalam, bencanabuatanmanusia, dankegagalansistem. Bencanaalamsepertiangintopan,

banjir yang menyebarluas, dangempabumiadalah yang paling
berpotensimenghancurkantigadariperspektifsosialkarenasecarabersamaandapatmempengaruhiban
yakorganisasi di wilayahgeografis yang terkenadampak. Bencanabuatanmanusia,
sepertisabotaseataukesalahan, bisasamamerusaknyadenganorganisasi individual,
namuncenderungterbataspadalingkupdampaknya.
Kegagalansistemsepertipemadamanlistrikataukegagalan hard drive umumnyakurangparah,
namunkemungkinanbesarbisaterjadi.

Semuabencanainidapatmenghilangkansebuahfasilitaspengolahan data organisasi,

menghentikanfungsibisnis yang dilakukanataudibantuolehkomputer,
danmengganggukemampuanorganisasiuntukmemberikanprodukataulayanannya. Dengan kata
lain, perusahaankehilangankemampuannyauntukberbisnis.
Semakintergantungsebuahorganisasibergantungpadateknologiakansemakinrentanterhadapjenisris
ikoini. Untukbisnisseperti Amazon.com atau eBay, kehilanganbeberapa jam
sajakemampuanpemrosesankomputerbisamenjadibencanabesar.

Bencanaseperti yang diuraikan di atasbiasanyatidakdapatdicegahataudihindari. Begituterjadi,

kelangsunganhidupperusahaankorbanakanditentukanolehseberapabaikdanseberapacepatreaksidal
ammengatasinya. Olehkarenaitu, denganperencanaankontinjensi yang hati-hati,
dampakbencanaterburukbisadiserapdanorganisasidapatpulihkembali.
Untukbertahandalamkeadaansemacamitu,
perusahaanmengembangkanprosedurpemulihandanmemformalkannyamenjadirencanapemulihan
bencana (Disaster Recovery Plant/DRP). Iniadalahpernyataankomprehensifdarisemuatindakan
yang harusdilakukansebelum,selama, dansetelahterjadinyadalambencanaapapun.
Meskipunrincianmasing-masingrencanauntukkebutuhanorganisasiberbeda-beda,
semuarencanakerjatetapmemilikiempatciriumum:

 Identifikasiaplikasikritis
 Buattimpemulihanbencana
 Menyediakan backup situs.
 Tentukanprosedurpenyimpanan backup dan off-site

Sisadaribagianinidikhususkanuntukdiskusitentangelemenpentingdari DRP yang efektif.

MengidentifikasiAplikasiKritis

Elemenpentingpertamadari DRP adalahuntukmengidentifikasiaplikasipentingperusahaandan file

data yang terkait. Upayapemulihanharusberkonsentrasipadapemulihanaplikasi yang
sangatpentingbagikelangsunganhiduporganisasijangkapendek. Tentunya, dalamjangkapanjang,
semuaaplikasiharusdikembalikanketingkataktivitasbisnissebelumterjadinyabencana. DRP,
bagaimanapunadalahdokumenjangkapendek yang
seharusnyatidakberusahamengembalikanfasilitaspemrosesan data
organisasikekapasitaspenuhsegerasetelahbencana.
Untukmelakukannyaakanmengalihkansumberdayadari area kritisdanmenundapemulihan.
Olehkarenaitu, rencanatersebutharusberfokuspadakelangsunganhidupjangkapendek, yang
berisikodalamskenariobencanaapapun.
Bagikebanyakanorganisasi, kelangsunganhidupjangkapendekmemerlukanpemulihanfungsi-
fungsi yang menghasilkanaruskas yang cukupuntukmemenuhikewajibanjangkapendek.
Sebagaicontoh, asumsikanbahwafungsiberikutmempengaruhiposisiaruskasperusahaantertentu:

 Penjualandanlayananpelanggan
 Pemenuhankewajibanhukum
 Pemeliharaandanpengumpulanpiutangproduksi
 Keputusanproduksidandistribusi
 Fungsipembelian
 Pencairanuangtunai (akunperdagangandangaji)

Hal52-53

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

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 terbaru penting, karena hal
itu mempengaruhi aspek lain dari rencana strategis. Misalnya, perubahan dalam prioritas aplikasi
dapat menyebabkan perubahan pada sifat dan tingkat persyaratan cadangan kedua lokasi dan
prosedur backup spesifik, yang akan dibahas kemudian.

Tugas untuk mengidentifikasi item penting dan memprioritaskan aplikasi memerlukan

partisipasi aktif dari departemen pengguna, akuntan, dan auditor. Terlalu sering, tugas ini salah
dilihat sebagai masalah teknis komputer dan oleh karena itu didelegasikan untuk profesional TI.
Meskipun bantuan teknis profesional TI akan diperlukan, tugas ini adalah keputusan bisnis dan
harus dibuat oleh mereka yang paling siap untuk memahami masalah bisnis.

Membentuk Tim Pemulihan kendala/ hambatan

 Pemulihan dari hambatan bergantung pada tindakan korektif yang tepat waktu.
Penundaan dalam melakukan tugas penting memperpanjang masa pemulihan dan mengurangi
prospek pemulihan yang berhasil. Untuk menghindari kelalaian atau duplikasi usaha yang serius
selama pelaksanaan rencana kontinjensi, tanggung jawab tugas harus didefinisikan secara jelas
dan dikomunikasikan kepada personil yang terlibat.

Gambar 2.7 menyajikan bagan organisasi yang menggambarkan komposisi tim

pemulihan kendala. Anggota tim harus menjadi ahli di bidang mereka dan telah menugaskan
tugas. Setelah kendala, anggota tim akan mendelegasikan subtugas ke bawahan mereka. Perlu
dicatat bahwa masalah kontrol tradisional tidak berlaku dalam situasi ini. Lingkungan yang
diciptakan oleh kendala mungkin perlu untuk melanggar prinsip-prinsip pengendalian seperti
pemisahan tugas, kontrol akses, dan pengawasan

Menyiapkan Backup Cadangan

Bahan yang diperlukan dalam DRP adalah menyediakan fasilitas pengolahan data duplikat
setelah terjadi kendala. Di antara pilihan yang tersedia, yang paling umum adalah pakta
bantuan bersama; situs kosong atau dingin; pusat operasi pemulihan atau situs yang panas;
dan cadangan yang disediakan secara internal. Masing-masing dibahas pada bagian berikut.
Pakta Reksa Dana. Pakta bantuan bersama adalah kesepakatan antara dua atau lebih organisasi
(dengan fasilitas komputer yang kompatibel) untuk saling membantu dengan kebutuhan
pengolahan data mereka jika terjadi kendala. Dalam acara seperti itu, perusahaan induk harus
mengganggu jadwal pemrosesannya untuk memproses transaksi kritis perusahaan yang dilanda
dasater. Akibatnya, perusahaan induk itu sendiri harus masuk ke mode operasi darurat dan
mengurangi pemrosesan aplikasi dengan prioritas lebih rendah untuk mengakomodasi kenaikan
permintaan TI yang mendadak.

Popularitas kesepakatan timbal balik ini didorong oleh ekonomi; mereka relatif bebas
biaya untuk diimplementasikan. Sebenarnya, pakta bantuan timbal balik bekerja lebih baik dalam
teori daripada dalam praktik. Jika terjadi kendala, perusahaan yang terkena dampak tidak
memiliki jaminan bahwa perusahaan mitra akan memenuhi janjinya untuk mendapatkan bantuan.
Untuk mengandalkan pengaturan semacam itu untuk bantuan substantif selama suatu kendala
memerlukan tingkat kepercayaan dan kepercayaan yang belum teruji yang tidak seperti
manajemen yang canggih dan auditornya.

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 kendala,
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 melalui kontrak dengan vendor perangkat keras yang, jika terjadi kendala, vendor akan
memberi prioritas pada kebutuhan perusahaan. Masalah pasokan perangkat keras yang tak
terduga pada titik kritis ini bisa menjadi pukulan fatal.

Pusat Operasi Pemulihan. Pusat operasi pemulihan (ROC) atau situs yang panas adalah pusat
data cadangan sepenuhnya yang dimiliki banyak perusahaan. Selain fasilitas perangkat keras dan
cadangan, penyedia layanan ROC menawarkan berbagai layanan teknis untuk layanan mereka.

Hal54-55

klien, yang membayar iuran 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 karyawan perusahaan sedang 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.

Meskipun cerita Comdisco menggambarkan kesuksesan ROC, namun juga menunjukkan potensi
masalah dengan pendekatan ini. 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 perusahaan korban akan mendapati 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. Ini
memungkinkan perusahaan mengembangkan konfigurasi perangkat keras dan perangkat lunak
standar, yang memastikan kompatibilitas fungsional di antara pusat pemrosesan data mereka dan
meminimalkan masalah cutover dalam kejadian 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 RPC 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.

Backup dan Off-Site Storage Procedures

Semua file data, aplikasi, dokumentasi, dan persediaan yang diperlukan untuk melakukan fungsi
kritis harus dicadangkan secara otomatis dan disimpan di tempat yang aman di luar lokasi.
Personel pengolahan data harus secara rutin melakukan prosedur backup dan penyimpanan untuk
mendapatkan dan mengamankan sumber daya kritis ini.

Cadangan Sistem Operasi. Jika perusahaan menggunakan situs yang dingin atau metode backup
situs lainnya yang tidak termasuk sistem operasi yang kompatibel (O / S), prosedur untuk
mendapatkan versi sistem operasi saat ini harus ditentukan secara jelas. Data pustakawan satu
ada, akan menjadi orang kunci untuk terlibat dalam melakukan tugas ini selain aplikasi dan
prosedur backup data yang dibahas selanjutnya.

Cadangan Aplikasi. Berdasarkan hasil yang diperoleh pada tahap aplikasi kritis yang telah
dibahas sebelumnya, DRP harus mencakup prosedur untuk membuat salinan dari aplikasi kritis
versi terkini. Dalam kasus perangkat lunak komersial, ini melibatkan pembelian salinan
cadangan dari upgrade perangkat lunak terbaru yang digunakan oleh organisasi. Untuk aplikasi
in-house yang dikembangkan, prosedur backup harus menjadi langkah integral dalam
pengembangan sistem dan program, proses perubahan, yang dibahas secara rinci pada Bab 5.

File Data Cadangan. Backup state-of-the-art dalam backup database adalah situs mirror jarak
jauh, yang menyediakan data lengkap mata uang. Tidak semua organisasi bersedia atau mampu
menginvestasikan sumber daya cadangan tersebut. Minimal, bagaimanapun, database harus
disalin setiap hari ke media berkapasitas tinggi dan berkecepatan tinggi, seperti tape atau CD /
DVD dan diamankan di luar lokasi. 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 beserta aplikasi. Dokumentasi sistem dapat merupakan jumlah material
yang signifikan dan proses backup semakin rumit oleh perubahan aplikasi yang sering terjadi
(lihat Bab 5). Backup dokumentasi mungkin, bagaimanapun, dengan disederhanakan dan dibuat
lebih efisien melalui penggunaan alat dokumentasi Computer Aided Software Engineering
(CASE). DRP juga harus menyertakan ketentuan yang mendukung manual pengguna akhir
karena pemrosesan transaksi individual dalam kondisi bencana mungkin bukan staf biasa yang
terbiasa dengan sistem.

Persediaan Cadangan dan Dokumen Sumber. Organisasi harus membuat persediaan cadangan
persediaan dan dokumen sumber yang digunakan dalam memproses transaksi penting. Contoh
persediaan kritis adalah cek saham, faktur, pesanan pembelian, dan bentuk tujuan khusus lainnya
yang tidak dapat diperoleh dengan segera. DRP harus menentukan jenis dan jumlah yang
dibutuhkan dari barang-barang khusus ini. Karena ini adalah elemen rutin dari operasi sehari-
hari, karena sering kali diabaikan oleh perencana kontinjensi bencana. Pada intinya, perlu dicatat
bahwa salinan dokumen DRP saat ini juga harus disimpan di luar lokasi di lokasi yang aman.

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

Tes yang paling berguna saat simulasi gangguan adalah kejutan. Ketika bencana tiruan
diumumkan, status semua pemrosesan yang terkena dampaknya harus didokumentasikan.
Pendekatan ini memberikan tolok ukur untuk penilaian kinerja selanjutnya. Rencana tersebut
harus dilakukan sejauh memungkinkan secara ekonomi. Idealnya, itu termasuk penggunaan
fasilitas dan persediaan cadangan.

Kemajuan rencana harus dicatat pada poin-poin kunci selama periode pengujian. Pada akhir
pengujian, hasilnya kemudian dapat dianalisis dan laporan kinerja DRP disiapkan. Tingkat
kinerja yang dicapai memberikan masukan untuk keputusan untuk memodifikasi DRP atau
menjadwalkan tes tambahan. Manajemen organisasi harus mencari ukuran kinerja di masing-
masing bidang berikut: (1) keefektifan personil tim DRP dan tingkat pengetahuan mereka; (2)
tingkat keberhasilan konversi (yaitu, jumlah catatan yang hilang); (3) perkiraan kerugian
finansial karena kehilangan catatan atau fasilitas; dan (4) efektivitas prosedur backup dan
pemulihan program, data, dan dokumentasi.

Hal56-57

Tujuan audit

Auditor harus memverifikasi bahwa rencana pemulihan bencana manajemen memadai

dan layak untuk menghadapi malapetaka yang dapat menghilangkan oganisasi sumber daya
komputasinya.

Prosedur audit

Dalam memverifikasi bahwa DRP magement adalah soluion yang realistis untuk
menghadapi malapetaka, tes berikut dapat dilakukan.

Cadangan situs Auditor harus mengevaluasi kecukupan pengaturan situs cadangan.

Sistem yang tidak sesuai dan sifat manusia sangat mengurangi efektifitas pakta bantuan matual.
Auditor harus skeptis terhadap pengaturan semacam itu karena dua alasan. Pertama, kecanggihan
sistem komputer bisa menyulitkan mencari pasangan potensial dengan konfigurasi yang
kompatibel. Kedua, yang paling teguh tidak memiliki kelebihan kapasitas yang diperlukan untuk
mendukung mitra yang malang dan saat memproses pekerjaan mereka sendiri. Ketika sampai
pada krisis, manajemen perusahaan yang tidak tersentuh oleh bencana kemungkinan akan
memiliki keinginan judul untuk pengorbanan yang harus dilakukan untuk menghormati
kesepakatan tersebut.
Pilihan yang lebih layak namun mahal adalah cangkang kosong dan pusat operasi pemulihan. Ini
juga harus diperiksa dengan hati-hati. Jika organisasi klien menggunakan metode shell kosong,
maka auditor perlu memverifikasi adanya kontrak yang valid dengan vendor perangkat keras
yang menjamin pengiriman perangkat keras komputer yang dibutuhkan dengan penundaan
minimum setelah bencana. Jika klien adalah anggota ROC, auditor harus memperhatikan jumlah
anggota ROC dan penyebaran geografisnya. Bencana yang meluas dapat menciptakan
permintaan yang tidak dapat dipenuhi oleh fasilitas ROC.

Daftar Aplikasi Kritis Auditor harus meninjau daftar aplikasi penting untuk
memastikannya selesai. Aplikasi yang hilang bisa mengakibatkan kegagalan untuk pulih. Hal
yang sama juga berlaku untuk mengembalikan aplikasi yang tidak termasuk. Untuk memasukkan
aplikasi pada daftar kritis yang tidak diperlukan untuk mencapai kelangsungan hidup jangka
pendek dapat salah kaprah dan mengalihkan perhatian dari tujuan utama selama masa pemulihan.

Backup Perangkat Lunak. Auditor memastikan bahwa salinan aplikasi penting dan sistem
operasi disimpan di luar lokasi. Auditor juga harus memverifikasi bahwa aplikasi yang disimpan
di luar lokasi sekarang dengan membandingkan nomor versi mereka dengan aplikasi aktual yang
digunakan. Nomor versi aplikasi diekspos secara rinci di Bab 5.

Cadangan data. Auditor harus memverifikasi bahwa file data penting dicadangkan sesuai
dengan DRP. Prosedur pencadangan data spesifik untuk kedua file flat dan database relasional
dibahas secara rinci di Bab 4.

Persediaan Cadangan, Dokumen, dan Dokumentasi. Dokumentasi sistem, persediaan, dan

dokumen sumber yang dibutuhkan memproses transaksi penting harus dicadangkan dan
disimpan di luar lokasi. Auditor harus memverifikasi bahwa typest dan jumlah item yang
ditentukan dalam DRP thr seperti stock cek, faktur, pesanan pembelian, dan bentuk tujuan
khusus 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 ulang sebuah perusahaan DRP, auditor menemukan bahwa seorang
pemimpin tim yang terdaftar dalam rencana tersebut telah meninggal dunia selama sembilan
bulan.

Biaya, risiko, dan tanggung jawab yang terkait dengan pemeliharaan fungsi korporat
perusahaan yang efektif sangat penting. Oleh karena itu, banyak eksekutif memilih untuk
menggunakan futsal TI mereka ke vendor pihak ketiga yang mengambil alih tanggung jawab
untuk memilih melakukan outsourcing untuk pengelolaan aset dan staf TI dan untuk pengiriman
layanan TI, seperti entri data, operasi data center, pengembangan aplikasi, aplikasi pemeliharaan,
dan manajemen jaringan. Manfaat IT Outsourcing yang sering dikutip 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 bisa dilakukan oleh perusahaan klien.
Penghematan biaya yang dihasilkan kemudian diteruskan ke organisasi klien. Selanjutnya,
banyak pengaturan outsourcing TI dalam menjual aset TI perusahaan klien - baik manusia
maupun 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 untuk secara efisien mengelola area non-inti
seperti fungsi TI. Premis ini, bagaimanapun, mengabaikan perbedaan penting antara com-modity
dan aset TI yang spesifik.

Aset TI komoditi tidak unik untuk organisasi tertentu dan mudah didapat 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 spesifik memiliki sedikit nilai di luar penggunaan mereka
saat ini. Aset semacam itu bisa saja berwujud (peralatan komputer), intelektualitas (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 negara bagian sebelum melakukan pembayaran. Di sisi lain,
teori TCE mendukung outsourcing aset komoditas, yang mudah diganti atau diperoleh dari
vendor alternatif.

Tentu, sebuah 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, kepercayaan bahwa semua TI dapat, dan seharusnya, dikelola oleh
pendidikan layanan besar cenderung berlaku. Kesalahan persepsi semacam itu mencerminkan,
sebagian, keduanya tidak memiliki pendidikan eksekutif dan penyebaran informasi yang salah
mengenai kebajikan dan keterbatasan TI outsourcing.

Hal58-60

Risiko yang melekat pada IT 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.

Kegagalan untuk melakukan

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 upaya pemotongan biaya, EDS termina memiliki 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 ke vendor "aset khusus", seperti

perancangan, 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 terealisasi. Satu survei mengungkapkan bahwa 47 persen dari 66 perusahaan
yang disurvei melaporkan bahwa biaya outsourcing TI melebihi keuntungan outsourcing. Salah
satu alasannya adalah ketika perusahaan outsourcing sering gagal mengantisipasi biaya
pemilihan vendor, kontrak, dan konsekuensi operasi TI kepada 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 keamanan vendor luar negeri, kebijakan akses data, dan undang-undang privasi
negara tuan rumah. Misalnya, seorang wanita di Pakistan mendapatkan data medis 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. Selanjutnya, 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 klien untuk meraih posisi strategis di pasar.
Implikasi Audit IT Outsourcing

Manajemen dapat mengalihkan fungsi TI perusahaannya, namun tidak dapat mengalihkan

tanggung jawab pengelolaannya di bawah SOX untuk memastikan pengendalian internal TI yang
memadai. PCAOB secara khusus menyatakan dalam Standar Auditing No. 2, "Penggunaan
organisasi layanan tidak mengurangi tanggung jawab manajemen untuk mempertahankan
pengendalian internal yang efektif atas pelaporan keuangan. Sebaliknya, manajemen pengguna
harus mengevaluasi pengendalian di organisasi layanan, dan juga kontrol terkait di perusahaan
pengguna, saat melakukan penilaian tentang pengendalian internal atas pelaporan keuangan.
"Oleh karena itu, jika perusahaan audit mengalihkan fungsi TI-nya kepada vendor yang
memproses transaksinya, menjadi tuan rumah data utama, atau melakukan layanan penting
lainnya, auditor perlu melakukan evaluasi terhadap kontrol organisasi vendor, atau dengan
alternatif memperoleh 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 2.8 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.

Melaporkan 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, pengetesan 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
adalah kurang ketatnya keduanya dan hanya berkomentar mengenai kesesuaian desain kontrol.
Laporan SAS 70 Type II berjalan lebih jauh dan menilai bahwa kontrol 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, laporan tipe SAS 70 tidak bernilai sedikit di dunia pasca-SOX.

Ringkasan

Bab ini menyajikan risiko dan kontrol yang terkait dengan tata kelola TI. Ini dimulai dengan
definisi singkat tentang tata kelola TI dan mengidentifikasi implikasinya terhadap pengendalian
internal dan pelaporan keuangan. Selanjutnya disajikan eksposur yang bisa timbul dari penataan
fungsi IT yang tidak tepat dalam organisasi. Bab ini beralih ke ulasan tentang ancaman dan
kontrol pusat komputer, termasuk melindunginya dari kerusakan dan perusakan dari rencana
pemulihan bencana alam. Beberapa faktor perlu dipertimbangkan dalam rencana seperti itu,
termasuk menyediakan cadangan situs kedua, mengidentifikasi aplikasi penting, melakukan
prosedur penyimpanan cadangan dan off-site, menciptakan tim pemulihan bencana, dan menguji
DRP. Bagian terakhir bab ini membahas masalah seputar tren yang berkembang terhadap
outsourcing TI. Secara khusus, ditinjau logika yang mendasari outsourcing dan manfaat yang
diharapkan. Pengambilalihan TI juga diasosiasikan dengan risiko signifikan, yang ditangani. Bab
ini diakhiri dengan diskusi tentang masalah audit di lingkungan outsourcing.