Anda di halaman 1dari 24

TUGAS RESUME KELOMPOK II

MATA KULIAH AUDIT SISTEM INFORMASI

“AUDITING IT GOVERNANCE CONTROLS”

Oleh:

Mella Fitria 1620532012


Yolla Meirina 1620532017
Winona Kumara Dewi 1620532019
Mekha Risa Putri Aulia 1620532027

PROGRAM STUDI MAGISTER AKUNTANSI


FAKULTAS EKONOMI
UNIVERSITAS ANDALAS
2017
CHAPTER 2 AUDITING IT GOVERNANCE CONTROLS

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

Pengendalian Tata Kelola IT


Meskipun semua masalah tata kelola IT penting bagi organisasi, tidak semuanya merupakan
masalah pengendalian internal di bawah SOX yang berpotensi mempengaruhi proses pelaporan
keuangan. Tiga masalah tata kelola IT yang ditangani oleh SOX dan kerangka pengendalian
internal COSO. Ini adalah:
1. Struktur organisasi fungsi IT
2. Operasi pada pusat komputer
3. Perencanaan pemulihan bencana
Pembahasan 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 perlu diverifikasi mengenai fungsi kontrol di
tempat. Akhirnya, contoh pengujian kontrol ditawarkan yang menjelaskan bagaimana auditor
dapat mengumpulkan bukti untuk memenuhi tujuan audit. Pengujian 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.

B. STRUKTUR FUNGSI TEKNOLOGI INFORMASI

Pengolahan Data Terpusat


Di bawah model pengolahan data terpusat, semua pengolahan data dilakukan oleh satu atau
lebih komputer besar yang ditempatkan di lokasi utama yang melayani pengguna di seluruh
organisasi. Gambar 2.1 mengilustrasikan pendekatan ini, di mana aktivitas layanan IT
dikonsolidasikan dan dikelola sebagai sumber organisasi bersama. Pengguna akhir bersaing untuk
mendapatkan sumber daya ini berdasarkan kebutuhan. Fungsi layanan IT biasanya diperlakukan
sebagai pusat biaya yang biaya operasinya dibebankan kembali ke pengguna akhir. Gambar 2.2
mengilustrasikan struktur layanan IT terpusat dan menunjukkan area layanan utamanya:
administrasi database, pengolahan data, dan pengembangan dan pemeliharaan sistem. Uraian
tentang fungsi utama masing-masing area berikut.

Administrasi Database
Perusahaan yang dikelola secara terpusat mempertahankan sumber data mereka di lokasi pusat yang
dimiliki oleh semua pengguna akhir. Dalam pengaturan data bersama ini, sebuah kelompok
independen yang dipimpin oleh Database Administrator (DBA) bertanggung jawab atas keamanan
dan integritas database.

Pengolahan Data
Kelompok pengolahan data mengelola sumber daya komputer yang digunakan untuk melakukan
pemrosesan transaksi sehari-hari. Ini terdiri dari fungsi organisasi berikut: data conversion, computer
operations, dan data library.
Data Conversion. Fungsi data conversion mentranskripsikan data transaksi dari dokumen sumber
hard copy menjadi input komputer. Misalnya, data conversion bisa melibatkan keystroking perintah
penjualan ke dalam aplikasi pesanan penjualan dalam sistem modern, atau mentranskripsikan data ke
media magnetik (tape atau disk) yang sesuai untuk pemrosesan komputer dalam sistem tipe warisan.
Computer Operations. File elektronik yang dihasilkan data conversion kemudian diproses oleh
komputer pusat, yang dikelola oleh grup operasi komputer. Aplikasi akuntansi biasanya dijalankan
sesuai jadwal yang ketat yang dikendalikan oleh sistem operasi komputer pusat.
Data Library. Data library adalah suatu ruangan yang berdekatan dengan pusat komputer yang
menyediakan penyimpanan yang aman untuk file data off-line. File-file itu bisa berupa backup atau
file data saat ini. Misalnya, data library dapat digunakan untuk menyimpan data cadangan pada DVD,
CD-ROM, kaset, atau perangkat penyimpanan lainnya. Ini juga bisa digunakan untuk menyimpan
file data operasional saat ini pada kaset magnetik dan paket disk yang dapat dilepas. Selain itu, data
library 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 (library).
Pustakawan mengeluarkan file data ke operator komputer sesuai dengan permintaan program dan
mengambil hak asuh file saat prosedur pemrosesan atau backup selesai. Tren dalam beberapa tahun
terakhir menuju pemrosesan real-time dan peningkatan penggunaan file akses langsung telah
mengurangi atau bahkan menghilangkan peran pustakawan data di banyak organisasi.

Pengembangan dan Pemeliharaan Sistem


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

Profesional Sistem, meliputi analis sistem, perancang database, dan programer yang merancang dan
membangun sistem. Profesional sistem mengumpulkan fakta tentang masalah pengguna,
menganalisis fakta, dan merumuskan solusi. Produk dari usaha mereka adalah sebuah sistem
informasi yang baru.

Pengguna Akhir (End Users) adalah mereka yang sistemnya dibangun. Mereka adalah manajer yang
menerima laporan dari sistem dan personil operasi yang bekerja secara langsung dengan sistem
tersebut sebagai bagian dari tanggung jawab harian mereka.
Pemangku Kepentingan (Stakeholders), adalah individu di dalam atau di luar perusahaan yang
memiliki kepentingan dalam sistem, namun bukan pengguna akhir. Mereka termasuk akuntan,
auditor internal, auditor eksternal, dan pihak lain yang mengawasi pengembangan sistem.
Begitu sistem baru telah dirancang dan diimplementasikan, kelompok pemeliharaan sistem
bertanggung jawab untuk mempertahankannya sesuai dengan kebutuhan pengguna. Istilah
pemeliharaan mengacu pada perubahan program logika untuk mengakomodasi perubahan 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 IT yang Tidak Kompatibel


Secara khusus, tugas operasional harus dipisahkan menjadi:
1. Memisahkan otorisasi transaksi dari proses transaksi.
2. Memisahkan catatan dari asset custody.
3. Membagi tugas pemrosesan transaksi di antara individu-individu yang kekurangan kolusi
antara dua atau lebih kecurangan individu yang tidak akan mungkin dilakukan.
Lingkungan IT cenderung mengkonsolidasikan aktivitas. Aplikasi tunggal mungkin memberi
otorisasi, memproses, dan mencatat semua aspek transaksi. Dengan demikian, fokus kontrol
pemisahan bergeser dari tingkat operasional (tugas pemrosesan transaksi yang dilakukan komputer
sekarang) ke hubungan organisasi tingkat tinggi dalam fungsi layanan komputer. Dengan
menggunakan bagan organisasi pada Gambar 2.2 sebagai referensi, keterkaitan antara pengembangan
sistem, pemeliharaan sistem, administrasi database, dan aktivitas operasi komputer diperiksa
selanjutnya.

Memisahkan Pengembangan Sistem dari Operasi Komputer


Pemisahan 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 seharusnya tidak digabungkan. Profesional pengembangan dan pemeliharaan sistem
harus menciptakan (dan memelihara) sistem bagi pengguna, dan seharusnya tidak terlibat dalam
memasukkan data, atau menjalankan aplikasi (misal: operasi komputer). Staf operasi harus
menjalankan sistem ini dan tidak memiliki keterlibatan dalam desain mereka. Fungsi-fungsi ini pada
dasarnya tidak sesuai, dan konsolidasinya yang mengundang kesalahan dan kecurangan. Dengan
pengetahuan yang terperinci tentang logika dan parameter kontrol aplikasi dan akses ke sistem
operasi dan utilitas komputer, seseorang dapat membuat perubahan yang tidak sah terhadap aplikasi
selama eksekusi. Perubahan semacam itu mungkin bersifat sementara ("on the fly") dan akan hilang
tanpa jejak saat aplikasi berakhir.

Memisahkan Administrasi Database dari Fungsi Lain


Kontrol organisasi penting lainnya adalah pemisahan Database Administrator (DBA) dari fungsi
pusat komputer lainnya. Fungsi DBA bertanggung jawab atas sejumlah tugas penting yang berkaitan
dengan keamanan database, termasuk membuat skema database dan tampilan pengguna, menetapkan
otoritas akses database kepada pengguna, memantau penggunaan database, dan merencanakan
perluasan di masa depan. Mendelegasikan tanggung jawab ini kepada orang lain yang melakukan
tugas yang tidak kompatibel mengancam integritas database. Gambar 2.2 bagaimana fungsi DBA
bebas terhadap operasi, pengembangan sistem, dan pemeliharaan organisasi.

Memisahkan Pegembangan 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 desain terperinci dari sistem baru ini. Kelompok pemrograman
mengkodekan program sesuai dengan spesifikasi desain ini. Dengan pendekatan ini, programer yang
mengkode program asli juga memelihara sistem selama tahap pemeliharaan siklus hidup
pengembangan sistem. Meskipun pengaturan yang sama, pendekatan ini dikaitkan dengan dua jenis
masalah kontrol: dokumentasi yang tidak memadai dan potensi pada kecurangan program.

Dokumentasi yang Tidak Memadai. Dokumentasi sistem yang berkualitas buruk merupakan
masalah IT yang kronis dan tantangan yang signifikan bagi banyak organisasi yang mencari
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 menginterpretasikan, menguji, dan melakukan debug
(mengidentifikasi dan menghapus kesalahan dari hardware atau software komputer). Oleh karena itu,
programmer yang memahami sistem (orang yang mengkodeinya) mempertahankan kekuatan tawar-
menawar menjadi satu hal relatif yang sangat diperlukan. Ketika programmer meninggalkan
perusahaan, seorang programmer baru mewarisi tanggung jawab pemeliharaan terhadap sistem yang
tidak terdokumentasi. Tergantung pada kompleksitasnya, masa transisinya yang mungkin panjang
dan mahal.
Program Fraud. Bila programmer asli dari sebuah sistem juga diberi tanggung jawab pemeliharaan,
potensi untuk melakukan kecurangan (fraud) akan meningkat. Kecurangan program melibatkan
perubahan yang tidak sah pada modul program untuk tujuan dengan melakukan tindakan ilegal.
Programmer asli mungkin telah berhasil menyembunyikan kode palsu di antara ribuan baris kode
yang sah dan ratusan modul yang membentuk sebuah sistem. Untuk kecurangan yang bekerja dengan
berhasil, programmer harus bisa mengendalikan situasi melalui akses eksklusif dan tidak terbatas ke
program aplikasi. Programmer perlu melindungi kode palsu dari pendeteksi yang tidak disengaja oleh
programmer lain yang melakukan pemeliharaan atau oleh auditor yang menguji kontrol aplikasi
tersebut. Oleh karena itu, memiliki tanggung jawab penuh untuk pemeliharaan yang merupakan
elemen penting dalam menduplikat skema programmer. Melalui otoritas pemeliharaan ini,
programmer dapat dengan bebas mengakses sistem, menonaktifkan kode kecurangan selama audit
dan kemudian memulihkan kode saat semuanya sudah jelas. Kecurangan semacam ini bisa berlanjut
bertahun-tahun tanpa terdeteksi.

Struktur Unggulan untuk Pengembangan Sistem


Gambar 2.2 menyajikan struktur organisasi yang unggul dimana fungsi pengembangan sistem
dipisahkan menjadi dua kelompok yang berbeda: 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 sistem yang sedang berlangsung sampai pada kelompok pemeliharaan sistem.
Restrukturisasi ini memiliki implikasi yang secara langsung menangani dua masalah kontrol yang
baru saja dijelaskan.
Pertama, standar dokumentasi ditingkatkan karena kelompok pemeliharaan memerlukan
dokumentasi untuk melaksanakan tugas pemeliharaannya. Tanpa dokumentasi yang lengkap dan
memadai, transfer formal tanggung jawab sistem dari pengembangan sistem baru ke pemeliharaan
sistem tidak dapat terjadi.
Kedua, penolakan akses programmer asli di masa depan untuk mencegah program dari
kecurangan program. Bahwa kode yang curang, yang pernah disembunyikan di dalam sistem, tidak
sesuai dengan kontrol programmer dan nantinya dapat ditemukan seiring meningkatnya risiko yang
terkait dengan kecurangan program. Keberhasilan pengendalian ini bergantung 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, kala perekonomian yang luas menyukai komputer yang besar dan
kuat dan pemrosesan yang terpusat. Namun sekarang, sistem yang 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 IT pusat menjadi unit IT kecil yang berada di bawah kendali pengguna akhir. Unit
IT dapat didistribusikan sesuai dengan fungsi bisnis, lokasi geografis, atau keduanya. Semua atau
fungsi IT 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 pendekatan DDP alternatif.
Alternatif A sebenarnya adalah varian dari model terpusat; Perbedaannya adalah hal tersebut
terminal (atau mikrokomputer) yang didistribusikan ke pengguna akhir untuk menangani input dan
output. Ini menghilangkan kebutuhan akan kelompok konversi data terpusat, karena pengguna
sekarang melakukan tugas ini. Namun, di bawah model ini, pengembangan sistem, operasi komputer,
dan administrasi database 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 IT 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
kemungkinan struktur organisasi yang mencerminkan distribusi semua tugas pengolahan data
tradisional ke area pengguna akhir.
Risiko Terkait dengan DDP
Penggunaan Sumber Daya yang Tidak Efisien. DDP dapat mengekspos dan mengorganisir tiga
jenis risiko yang terkait dengan penggunaan sumber daya organisasi yang tidak efisien. Ini diuraikan
di bawah ini:
Pertama, adalah risiko salah urus sumber daya IT di seluruh organisasi oleh pengguna akhir.
Beberapa berpendapat bahwa ketika sumber daya keseluruhan organisasi melebihi jumlah ambang
batas, misalnya 5 persen dari total anggaran operasi, tata kelola IT yang efektif memerlukan
pengelolaan pusat dan pemantauan sumber daya semacam itu. Bagi banyak organisasi, layanan IT
termasuk operasi komputer, pemrograman, konversi data, dan pengelolaan database memenuhi atau
melampaui ambang batas ini.
Kedua, DDP 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 mengakibatkan setiap area pengguna menemukan
kembali roda daripada memanfaatkan pekerjaan orang lain. Misalnya, program aplikasi yang dibuat
oleh satu pengguna, yang bisa digunakan dengan sedikit atau tanpa perubahan oleh orang lain, akan
didesain ulang dari awal daripada dibagi. Demikian juga, data yang umum bagi banyak pengguna
dapat diciptakan kembali untuk masing-masing, menghasilkan tingkat redundansi data yang tinggi.
Keadaan ini berimplikasi pada akurasi data dan konsistensi.
Ketiga, lingkungan DDP menimbulkan risiko perangkat keras dan perangkat lunak yang tidak
kompatibel di antara fungsi pengguna akhir. Mendistribusikan tanggung jawab untuk pembelian IT
kepada pengguna akhir dapat mengakibatkan keputusan yang tidak terkoordinasi dan kurang
dipahami. Misalnya, pengambil keputusan di unit organisasi yang berbeda yang bekerja secara
independen dapat menyesuaikan diri dengan sistem operasi, platform, spreadsheet, pengolah kata,
dan paket database yang berbeda dan tidak kompatibel. Ketidaksesuaian perangkat keras dan
perangkat lunak dapat menurunkan dan mengganggu konektivitas antar unit, menyebabkan hilangnya
transaksi dan kemungkinan penghancuran audit trails.
Penghancuran Jejak Audit (Audit Trails). Jejak audit memberikan keterkaitan antara aktivitas
keuangan (transaksi) perusahaan dan laporan keuangan yang melapor pada kegiatan tersebut. Auditor
menggunakan jejak audit untuk melacak transaksi keuangan terpilih dari dokumen sumber yang
menangkap kejadian, melalui jurnal, buku besar pembantu, dan akun buku besar yang mencatat
kejadian tersebut, dan terakhir pada laporan keuangan itu sendiri. Jejak audit sangat penting untuk
jasa yang diungkapkan oleh auditor.
Dalam sistem DDP, jejak audit terdiri dari serangkaian file transaksi digital dan file induk
yang berada sebagian atau seluruhnya pada komputer pengguna akhir. Jika pengguna akhir secara
tidak sengaja menghapus salah satu file, jejak audit bisa dihancurkan dan tidak terpulihkan. Demikian
pula, jika pengguna akhir secara tidak sengaja memasukkan kesalahan transaksi ke dalam file jejak
audit, hal tersebut bisa menjadi rusak.

Pemisahan Tugas yang Tidak Memadai. Mencapai pemisahan tugas yang memadai kemungkinan
tidak terjadi di beberapa lingkungan yang terdistribusi. Distribusi layanan IT kepada pengguna dapat
menghasilkan penciptaan unit independen kecil yang tidak mengizinkan pemisahan fungsi yang tidak
sesuai dengan yang diinginkan. Misalnya, dalam satu unit, orang yang sama dapat menulis program
aplikasi, melakukan pemeliharaan program, memasukkan data transaksi ke komputer, dan
mengoperasikan peralatan komputer. Situasi seperti itu akan menjadi pelanggaran mendasar pada
pengendalian internal.

Mempekerjakan Profesional yang Berkualitas. Manajer pengguna akhir mungkin memiliki


pengetahuan IT yang kurang untuk mengevaluasi surat kepercayaan (credentials) teknis dan
pengalaman kandidat yang relevan yang berlaku untuk posisi profesional IT. Juga, jika unit organisasi
masuk menjadi suatu karyawan baru yang kecil, peluang untuk pertumbuhan pribadi, pendidikan
lanjutan, dan promosi mungkin terbatas. Untuk alasan ini, manajer mungkin mengalami kesulitan
menarik personil yang 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 merata diterapkan atau
bahkan tidak ada. Lawan dari DDP berpendapat bahwa risiko yang terkait dengan perancangan dan
pengoperasian sistem DDP hanya dapat dilakukan jika standar tersebut diterapkan secara konsisten.

Keuntungan dari DDP


Pengurangan Biaya. Selama bertahun-tahun, pencapaian skala ekonomi merupakan justifikasi utama
untuk pendekatan pengolahan data terpusat. Perekonomian dari pengolahan data disukai pada
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 dapat melakukan fungsi khusus
telah mengubah ekonomi dari pengolahan data secara dramatis. Selain itu, biaya unit penyimpanan
data, yang dulunya merupakan pembenaran untuk mengkonsolidasikan data di lokasi terpusat, sudah
tidak menjadi pertimbangan utama. Selain itu, kepindahan ke DDP telah mengurangi biaya di dua
bidang lainnya: (1) data dapat diedit dan dimasukkan oleh pengguna akhir, sehingga menghilangkan
tugas terpusat dari persiapan data; dan (2) kompleksitas aplikasi dapat dikurangi, yang pada
gilirannya mengurangi biaya pengembangan dan pemeliharaan sistem.

Tanggung Jawab Kontrol 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 tentang sumber daya yang mempengaruhi
keseluruhan keberhasilan mereka. Ketika manajer dilarang membuat keputusan yang diperlukan
untuk mencapai tujuan mereka, kinerjanya dapat dipengaruhi secara negatif. Manajemen yang kurang
agresif dan kurang efektif dapat berkembang.
Pendukung dari 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 IT memang penting bagi keberhasilan operasi bisnis,
maka manajemen harus diberi kontrol atas sumber daya ini. Argumen ini membantah diskusi
sebelumnya yang mendukung pemusatan sumber daya organisasi yang luas.
Peningkatan 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 dalam model
terpusat: (1) pengguna ingin mengendalikan sumber daya yang mempengaruhi keuntungan mereka;
(2) pengguna menginginkan profesional sistem (analis, programmer, dan operator komputer) untuk
bersikap responsif terhadap situasi spesifik mereka; dan (3) pengguna ingin lebih aktif terlibat dalam
pengembangan dan penerapan sistem mereka sendiri.

Fleksibilitas Backup. Argumen terakhir yang mendukung DDP adalah kemampuan untuk
mendukung fasilitas komputasi untuk melindungi dari potensi bencana seperti kebakaran, banjir,
sabotase, dan gempa bumi. Satu-satunya cara untuk mendukung sebuah situs komputer utama
melawan bencana tersebut adalah dengan menyediakan fasilitas komputer kedua. Model yang
terdistribusi menawarkan fleksibilitas organisasi untuk menyediakan cadangan. Setiap unit IT yang
terpisah secara geografis dapat dirancang dengan kapasitas berlebih. Jika sebuah bencana
menghancurkan satu situs, situs lain dapat menggunakan kelebihan kapasitas mereka untuk
memproses transaksi situs yang hancur. Tentu, pengaturan ini memerlukan koordinasi yang erat
antara manajer pengguna akhir untuk memastikan bahwa mereka tidak menerapkan perangkat keras
dan perangkat lunak yang tidak kompatibel.

Mengontrol Lingkungan DDP

Mengimplementasikan Fungsi IT Perusahaan


Model yang sepenuhnya terpusat dan model yang terdistribusi mewakili posisi ekstrim pada
rangkaian alternatif struktural. Kebutuhan dari kebanyakan perusahaan berada 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 IT perusahaan menyediakan pengembangan sistem dan pengelolaan
database untuk seluruh sistem entitas selain saran teknis dan keahlian kepada komunitas IT yang
terdistribusi. Peran dari laporan ini ditunjukkan oleh garis putus-putus pada Gambar 2.5. Beberapa
jasa yang diberikan dijelaskan selanjutnya.

Pengujian Pusat Software dan Hardware Komersial. Kelompok IT perusahaan terpusat lebih siap
daripada pengguna akhir untuk mengevaluasi kelebihan perangkat lunak komersial dan produk
perangkat keras yang bersaing yang sedang dipertimbangkan. Kelompok terpusat yang secara teknis
lihay seperti ini dapat mengevaluasi fitur, kontrol, dan kompatibilitas sistem dengan standar industri
dan organisasi. Hasil pengujian kemudian dapat didistribusikan ke area pengguna sebagai standar
untuk membimbing keputusan akuisisi. Hal ini memungkinkan organisasi untuk secara efektif
memusatkan akuisisi, pengujian, dan implementasi software dan hardware dan menghindari banyak
masalah yang dibahas sebelumnya.
Layanan Pengguna. Fitur yang 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 dalam organisasi. Selain itu, ruang obrolan bisa dibuat untuk memberikan diskusi berulir,
frequently asked questions (FAQs), dan dukungan intranet. Fungsi IT perusahaan juga bisa
menyediakan suatu help desk, 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 pada personil teknis.

Standard-Setting Body. Lingkungan pengendalian yang relatif buruk yang diberlakukan oleh model
DDP 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 pendokumentasian sistem.

Personnel Review. Grup perusahaan seringkali lebih siap dibandingkan pengguna untuk
mengevaluasi kepercayaan teknis profesional dari 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.

Tujuan Audit
Tujuan auditor adalah untuk memverifikasi bahwa struktur fungsi IT sedemikian rupa sehingga
individu-individu di daerah yang tidak kompatibel dipisahkan sesuai dengan tingkat risiko potensial
dan dengan cara yang mendorong lingkungan kerja. Ini adalah lingkungan di mana hubungan formal,
daripada santai, hubungan yang dibutuhkan untuk eksis antara tugas yang tidak sesuai.

Prosedur Audit
Prosedur audit berikut akan berlaku untuk sebuah organisasi dengan fungsi IT 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.
 Meninjau dokumentasi sistem dan catatan pemeliharaan untuk contoh aplikasi. Verifikasi bahwa
program pemeliharaan yang ditugaskan untuk proyek tertentu juga bukan perancang desain asli.
 Pastikan bahwa operator komputer tidak memiliki akses menuju rincian operasional logika internal
sistem. Dokumentasi sistem, seperti sistem flowcharts, logic flowcharts, dan daftar kode program,
tidak boleh menjadi bagian dari dokumentasi operasi.
 Melalui pengamatan, menentukan bahwa kebijakan pemisahan sedang diikuti dalam praktik.
Meninjau akses log ruang operasi untuk menentukan apakah programmer memasukkan fasilitas
tersebut dengan alasan selain kegagalan sistem.
Prosedur audit berikut akan berlaku untuk organisasi dengan suatu fungsi IT yang
terdistribusi:
 Meninjau bagan organisasi saat ini, pernyataan misi, dan uraian tugas pada fungsi kunci untuk
menentukan apakah individu atau kelompok melakukan tugas yang tidak kompatibel.
 Memverifikasi bahwa kebijakan dan standar perusahaan untuk perancangan sistem, dokumentasi,
dan akuisisi hardware dan software dipublikasikan dan diserahkan ke unit IT yang terdistribusi.
 Memverifikasi kontrol kompensasi, seperti pemantauan pengawasan dan manajemen, dipekerjakan
bila pemisahan tugas tidak kompatibel secara ekonomi tidak layak.
 Mengkaji ulang dokumentasi sistem untuk memverifikasi bahwa aplikasi, prosedur, dan database
dirancang dan berfungsi sesuai dengan standar perusahaan.

C. 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, sumber listrik, gas dan air, bandara, daerah dengan tingkat
kejahatan yang tinggi, dataran banjir, dan kesalahan geologi. Pusat harus jauh dari lalu lintas
normal, seperti lantai atas bangunan atau bangunan terpisah sendiri. Menempatkan komputer di
gedung bawah tanah meningkatkan risikonya terhadap banjir.

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

Access
Akses ke pusat komputer harus dibatasi pada operator dan karyawan lain yang bekerja di sana.
Kontrol fisik, seperti pintu terkunci, harus digunakan untuk membatasi akses menuju pusat. Akses
harus dikontrol dengan papan tombol atau kartu gesek, melalui fire exits dengan dengan alarm
penting. 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 programmer dan analis yang memerlukan akses untuk memperbaiki kesalahan program.
Pusat komputer harus menyimpan catatan akurat tentang semua lalu lintas tersebut.

Air Conditioning
Komputer berfungsi paling baik di lingkungan ber-AC dan menyediakan udara yang memadai.
Komputer beroperasi paling baik pada kisaran suhu 70 sampai 75 derajat Fahrenheit dan
kelembaban relatifnya sebesar 50 persen. Jika suhu berubah secara signifikan dari jangkauan
optimal maka dapat menyebabkan terjadinya kesalahan logika pada perangkat keras komputer dan
juga meningkatnya risiko kerusakan rangkaian dari listrik statis saat kelembaban turun.
Sebaliknya, jika kelembaban tinggi dapat menyebabkan tumbuhnya jamur hingga pembengkakan
peralatan.

Pencegahan Kebakaran
Kebakaran di pusat komputer dapat menyebabkan perusahaan kehilangan catatan kritis seperti
piutang usaha. Penerapan sistem pencegahan kebakaran yang efektif memerlukan konsultasi
dengan spesialis. Namun, beberapa fitur utama dari sistem seperti ini adalah sebagai berikut:
1. Adanya alarm otomatis dan manual yang ditempatkan di lokasi yang strategis di sekitar
instalasi yang dihubungkan ke stasiun pemadam kebakaran permanen.
2. Harus ada sistem pemadam kebakaran otomatis yang mengeluarkan jenis penekan yang
sesuai untuk lokasi tersebut. Misalnya, menyemprotkan air dan bahan kimia tertentu ke
komputer.
3. Pemadam api manual harus ditempatkan di lokasi yang strategis.
4. Konstruksi bangunan yang bagus untuk menahan kerusakan air yang disebabkan oleh
peralatan pemadam kebakaran.
5. Keluar api harus ditandai dengan jelas dan diterangi saat terjadi kebakaran.

Toleransi Kesalahan
Toleransi kesalahan adalah kemampuan sistem untuk melanjutkan operasi ketika bagian dari
sistem gagal karena kegagalan hardware, kesalahan program aplikasi, atau kesalahan operator.
Tujuannya yaitu untuk memastikan bahwa tidak ada satu titik kegagalan sistem potensial.
Kegagalan total dapat terjadi hanya jika beberapa komponen gagal. Dua contoh teknologi
toleransi kesalahan yaitu:
1. Redundant Arrays of Independent Disk (RAID). Raid melibatkan menggunakan disk
paralel yang mengandung unsur berlebihan dari data dan aplikasi. Jika salah satu disk gagal,
data yang hilang secara otomatis direkonstruksi dari redundant component stored yang
disimpan pada disk lainnya.
2. Uninterruptible Power Supplies. Daya listrik komersial menyajikan beberapa masalah
yang dapat mengganggu operasi pusat computer, termasuk jumlah gangguan listrik,
brownouts, fluktuasi daya, dan variasi frekuensi. Peralatan yang digunakan untuk
mengontrol masalah ini termasuk regulator tegangan, gelombang pelindung, generator, dan
baterai cadangan. Dalam hal terjadi pemadaman listrik, perangkat ini menyediakan tenaga
cadangan untuk jangka waktu yang wajar untuk memungkinkan pemulihan layanan listrik.
Dalam hal suatu pemadaman listrik diperpanjang, kekuatan cadangan akan memungkinkan
sistem komputer untuk menutup secara terkendali dan mencegah kehilangan data dan korupsi
yang dinyatakan akan dihasilkan dari suatu sistem crash yang tidak terkendali.

Tujuan Audit
Tujuan auditor adalah untuk mengevaluasi kontrol yang mengatur keamanan komputer
pusat. Secara khusus, auditor harus memverifikasi bahwa:
● Kontrol keamanan fisik yang memadai yang cukup untuk melindungi organisasi dari eksposur
fisik.
● Cakupan asuransi pada peralatan memadai untuk mengkompensasi organisasi untuk
penghancuran, atau kerusakan komputer pusat.

Prosedur Audit
Berikut ini adalah tes kontrol keamanan fisik antara lain:
1. Tes Konstruksi Fisik.
Auditor harus memperoleh rencana arsitektur untuk menentukan bahwa pusat komputer yang
kokoh dibangun dari bahan tahan api. Harus ada drainase yang memadai di bawah lantai untuk
memungkinkan air mengalir jauh dalam hal kerusakan air dari api di lantai atas atau dari
beberapa sumber lain. Selain itu, auditor harus menilai lokasi fisik dari pusat komputer.
Fasilitas ini harus ditempatkan di daerah yang meminimalkan eksposur api, kerusuhan sipil,
dan bahaya lainnya.
2. Pengujian Sistem Deteksi Api.
Auditor harus menetapkan bahwa deteksi kebakaran dan peralatan penindasan, baik manual
dan otomatis berada di tempat dan diuji secara teratur. Sistem deteksi kebakaran harus
mendeteksi asap, panas, dan asap yang mudah terbakar.
3. Pengujian Access Control.
Auditor harus menetapkan bahwa akses rutin ke pusat komputer dibatasi untuk karyawan
yang berwenang. Rincian tentang akses pengunjung seperti kedatangan dan keberangkatan,
tujuan, dan frekuensi akses, dapat diperoleh dengan meninjau log akses. Untuk membangun
kebenaran dokumen auditor dapatvmengamati proses dimana akses diizinkan, atau review
rekaman video dari kamera di titik akses jika mereka sedang digunakan.
4. Tes Raid.
Sistem yang menggunakan RAID menyediakan pemetaan grafis penyimpanan disk berlebihan
mereka. Dari pemetaan ini, auditor harus menentukan apakah tingkat RAID di tempat
memadai untuk organisasi, mengingat tingkat risiko bisnis terkait dengan kegagalan disk.
5. Tes dari Uninterruptible Power Supply.
Pusat komputer harus melakukan tes periodik dari catu daya cadangan untuk memastikan
bahwa ia memiliki kapasitas yang cukup untuk menjalankan komputer dan pendingin udara.
6. Pengujian Cakupan Asuransi.
Auditor harus meninjau setiap tahunnya asuransi organisasi pada perangkat keras komputer,
perangkat lunak, dan fasilitas fisik. Auditor harus memverifikasi bahwa semua akuisisi baru
terdaftar pada kebijakan dan bahwa peralatan usang dan perangkat lunak telah dihapus. Polis
asuransi harus mencerminkan kebutuhan manajemen dalam hal luasnya cakupan.

D. PERENCANAAN PEMULIHAN BENCANA


Bencana seperti gempa bumi, banjir, sabotase, dan bahkan kegagalan listrik bisa menjadi
bencana bagi pusat komputer dan sistem informasi perusahaan. Gambar 2.6 menggambarkan tiga
kategori bencana yang dapat merampok sebuah organisasi sumber daya IT-nya: 1) Bencana alam, 2)
Bencana buatan manusia, dan 3) Kegagalan sistem.

Bencana alam seperti angin topan, banjir yang menyebar luas, dan gempa bumi adalah yang
paling berpotensi menghancurkan tiga dari perspektif masyarakat karena secara simultan dapat
mempengaruhi banyak organisasi di wilayah geografis yang terkena dampak. Sementara itu Bencana
buatan manusia seperti sabotase atau kesalahan, bisa sama merusaknya dengan organisasi individual,
namun cenderung terbatas pada lingkup dampaknya. Dan Kegagalan sistem seperti pemadaman
listrik atau kegagalan hard drive umumnya kurang parah, namun kemungkinan besar akan terjadi.
Semua bencana ini dapat menghilangkan sebuah fasilitas pengolahan data organisasi,
menghentikan fungsi bisnis yang dilakukan atau dibantu oleh komputer, dan mengganggu
kemampuan organisasi untuk memberikan produk atau layanannya. Dengan kata lain, perusahaan
kehilangan kemampuannya untuk berbisnis. Semakin tergantung sebuah organisasi bergantung pada
teknologi, semakin rentan terhadap jenis risiko ini. Untuk bisnis seperti Amazon.com atau eBay,
hilangnya beberapa jam kemampuan pemrosesan komputer bisa menjadi bencana besar.
Untuk bertahan dalam peristiwa seperti itu, perusahaan mengembangkan prosedur pemulihan
dan memformalkannya menjadi rencana pemulihan bencana (DRP). Ini adalah pernyataan
komprehensif dari semua tindakan yang harus dilakukan sebelum, selama, dan setelah untuk semua
jenis bencana. Adapun 4 ciri umum rencana kerja yaitu:
1. Identifikasi aplikasi kritis
2. Membuat tim pemulihan bencana
3. Menyediakan backup situs
4. Tentukan prosedur penyimpanan cadangan dan off-site

Identifikasi Aplikasi Kritis


Elemen penting pertama dari DRP adalah mengidentifikasi aplikasi penting perusahaan dan file data
terkait. Upaya pemulihan harus berkonsentrasi pada pemulihan aplikasi yang penting bagi
kelangsungan hidup organisasi jangka pendek. DRP adalah dokumen jangka pendek yang seharusnya
tidak berusaha mengembalikan fasilitas pemrosesan data organisasi ke kapasitas penuh segera setelah
bencana terjadi. Untuk melakukannya akan mengalihkan sumber daya dari area kritis dan menunda
pemulihan. Oleh karena itu, rencana tersebut harus berfokus pada kelangsungan hidup jangka pendek,
yang berisiko dalam hal apapun skenario bencana.
Kelangsungan hidup jangka pendek memerlukan pemulihan fungsi-fungsi yang menghasilkan
arus kas yang cukup untuk memenuhi kewajiban jangka pendek, misalnya:
 Penjualan dan layanan pelanggan
 Pemenuhan kewajiban hukum
 Pemeliharaan dan penagihan piutang
 Keputusan produksi dan distribusi
 Fungsi pembelian
 Pencairan uang tunai (rekening perdagangan dan gaji)
DRP harus diperbarui untuk mencerminkan perkembangan baru dan mengidentifikasi aplikasi
penting. Prioritas terkini sampai saat ini penting, karena hal itu mempengaruhi aspek lain dari rencana
strategis. Misalnya, perubahan dalam prioritas aplikasi dapat menyebabkan perubahan sifat dan
tingkat persyaratan cadangan kedua lokasi dan prosedur pencadangan spesifik. Tugas untuk
mengidentifikasi item penting dan memprioritaskan aplikasi memerlukan partisipasi aktif dari
departemen pengguna, akuntan, dan auditor.

Membuat Tim Pemulihan Bencana


Memulihkan dari bencana 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.
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 pengaturan ini. Lingkungan yang diciptakan oleh
bencana mungkin perlu untuk melanggar prinsip-prinsip pengendalian seperti pemisahan tugas,
kontrol akses, dan pengawasan.
Menyediakan Backup Situs Kedua
Bahan yang diperlukan dalam DRP adalah menyediakan fasilitas pengolahan data duplikat setelah
terjadi bencana,antara lain :

Mutual Aid Pact / Bantuan 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 bencana. Dalam hal ini, perusahaan induk harus
mengganggu jadwal pemrosesannya untuk memproses transaksi kritis perusahaan yang dilanda
bencana tersebut. Akibatnya, perusahaan induk itu sendiri harus masuk ke mode operasi darurat dan
mengurangi pemrosesan aplikasi dengan prioritas lebih rendah untuk mengakomodasi kenaikan
permintaan yang mendadak untuk sumber daya TI-nya.

Empty Shell / 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. Kelemahannya adalah pemulihan tergantung
pada ketersediaan perangkat keras komputer yang diperlukan untuk mengembalikan fungsi
pemrosesan data.

Recovery Operations Center / Pusat Operasi Pemulihan. Pusat operasi pemulihan (ROC) atau situs
yang panas dilengkapi dengan pusat data cadangan yang banyak perusahaan saling berbagi. 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.

Internally Provided Backup / Cadangan yang disediakan 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 pemotongan jika terjadi bencana.

Prosedur Penyimpanan Backup dan Offsite


Semua file data, aplikasi, dokumentasi, dan persediaan yang diperlukan untuk melakukan fungsi
penting harus dicadangkan secara otomatis dan disimpan di lokasi 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 cold site atau metode backup situs lainnya
yang tidak termasuk sistem operasi yang kompatibel (O / S), prosedur untuk mendapatkan versi
sistem operasi saat ini yang ditentukan secara jelas.

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.

Backup File Data. Database harus disalin setiap hari ke media berkapasitas tinggi berkecepatan
tinggi, seperti tape atau CD / DVD dan di luar kantor yang aman. Jika terjadi gangguan, rekonstruksi
database dicapai dengan memperbarui versi cadangan terbaru dengan data transaksi berikutnya.
Demikian juga, file induk dan file transaksi harus dilindungi.

Dokumentasi Cadangan. Dokumentasi sistem untuk aplikasi kritis harus dicadangkan dan disimpan
di luar lokasi beserta aplikasi. Backup dokumentasi mungkin 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 individu yang
memproses transaksi dalam kondisi bencana mungkin bukan staf biasa yang terbiasa dengan sistem.

Persediaan Cadangan dan Dokumen Sumber. Organisasi harus membuat inventori cadangan 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
khusus ini. Karena ini adalah elemen rutin dari operasi sehari-hari yang sering kali diabaikan oleh
perencana kontinjensi bencana. Pada titik ini, perlu dicatat bahwa salinan dokumen DRP saat ini juga
harus disimpan di lokasi yang aman.

Menguji DRP. 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. Saat bencana tiruan diumumkan, status semua pemrosesan yang
terkena dampaknya harus didokumentasikan. Pendekatan ini memberikan tolok ukur untuk penilaian
kinerja selanjutnya. Rencananya 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 recovery program, data, dan dokumentasi.
Tujuan Audit
Auditor harus memverifikasi bahwa rencana pemulihan bencana manajemen memadai dan layak
untuk menghadapi malapetaka yang dapat menghambat pengorganisasian sumber daya
komputasinya.

Prosedur Audit
Dalam memverifikasi bahwa DRP manajemen adalah solusi realistis untuk menghadapi malapetaka,
maka tes yang dapat dilakukan:

Site Backup / Situs Cadangan. Auditor harus mengevaluasi kecukupan pengaturan situs cadangan.
Ketidaksesuaian sistem dan sifat manusia keduanya sangat mengurangi keefektifan pakta bantuan
bersama. Auditor harus skeptis terhadap pengaturan tersebut karena dua alasan yaitu: Pertama,
kecanggihan sistem komputer mungkin menyulitkan menemukan pasangan potensial dengan
konfigurasi yang kompatibel. Kedua, kebanyakan perusahaan tidak memiliki kelebihan kapasitas
yang diperlukan untuk mendukung mitra yang mengalami bencana dan juga memproses pekerjaan
mereka sendiri.
Pilihan yang lebih layak namun mahal adalah empty shell dan pemulihan pusat operasi. 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.

Critical Applications List / Daftar Aplikasi Penting. 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 perlu.

Software Backup / Cadangan Perangkat Lunak. Auditor harus memverifikasi bahwa salinan
aplikasi penting dan sistem operasi disimpan di luar lokasi. Auditor juga harus memverifikasi bahwa
aplikasi yang tersimpan di luar lokasi saat ini dengan membandingkan nomor versi mereka dengan
aplikasi aktual yang digunakan.

Data Backup / Cadangan Data. Auditor harus memverifikasi bahwa file data penting dicadangkan
sesuai dengan DRP.

Backup Supplies, Document, and Documentation. Dokumentasi sistem, persediaan, dan dokumen
sumber yang diperlukan untuk memproses transaksi penting harus dicadangkan dan disimpan di luar
lokasi. Auditor harus memverifikasi bahwa jenis dan jumlah barang yang ditentukan dalam DRP
seperti cek, faktur, pesanan pembelian, dan bentuk khusus apapun ada di lokasi yang aman.
Disaster Recovery Team / 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.

E. OUTSOURCING THE IT FUNCTION


Biaya, risiko, dan tanggung jawab yang terkait dengan pemeliharaan fungsi perusahaan
korporat yang efektif sangat penting. Oleh karena itu, banyak eksekutif memilih untuk melakukan
outsourcing fungsi IT mereka kepada vendor pihak ketiga yang mengambil alih tanggung jawab atas
pengelolaan aset dan staf IT dan untuk pengiriman layanan IT, seperti entri data, operasi data center,
pengembangan aplikasi, pemeliharaan aplikasi, dan manajemen jaringan.
Manfaat IT outsourcing yang disamakan mencakup peningkatan kinerja bisnis inti,
meningkatkan kinerja IT (karena keahlian vendor), dan mengurangi biaya IT. Dengan memindahkan
fasilitas IT 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 IT melibatkan
penjualan aset IT 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.
Aset IT komoditi tidak unik untuk organisasi tertentu dan mudah diperoleh di pasar mencakup
hal-hal seperti manajemen jaringan, operasi sistem, pemeliharaan server, dan fungsi help desk.
Sedangkan Aset IT spesifik adalah sebaliknya, bersifat 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.

Resiko yang Melekat pada IT Outsourcing


Kegiatan outsourcing IT skala besar adalah usaha yang berisiko. Tingkat risiko terkait dengan
tingkat kekhususan aset dari fungsi alih daya. Beberapa masalah yang terdokumentasi antara lain:

Gagal untuk Tampil


Begitu perusahaan klien telah mengalihkan aset IT 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 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 Penjual
Pengalihan IT berskala besar melibatkan pemindahan ke vendor "aset spesifik", seperti perancangan,
pengembangan, dan pemeliharaan aplikasi bisnis unik yang penting bagi kelangsungan hidup sebuah
organisasi. Aset spesifik yang berharga bagi klien, tidak bernilai bagi 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. Ketergantungan ini dapat
mengancam fleksibilitas, kelincahan, dan daya saing jangka panjang klien dan mengakibatkan
ketergantungan vendor yang lebih besar lagi.

Biaya Outsourcing yang Melebihi Keuntungan


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 IT melebihi keuntungan outsourcing. Salah satu
alasannya adalah bahwa klien outsourcing sering gagal mengantisipasi biaya pemilihan vendor,
kontrak, dan transisi operasi IT ke vendor.

Keamanan yang Berkurang


Informasi yang diserahkan ke vendor IT menimbulkan pertanyaan unik dan serius mengenai
pengendalian internal dan perlindungan data pribadi yang sensitif.

Hilangnya Keuntungan Strategis


IT outsourcing dapat mempengaruhi ketidaksesuaian antara perencanaan strategis IT perusahaan dan
fungsi perencanaan bisnisnya. Organisasi yang menggunakan IT secara strategis harus
menyelaraskan strategi bisnis dan strategi IT atau menjalankan risiko penurunan kinerja bisnis. Untuk
mempromosikan keselarasan tersebut, perusahaan membutuhkan manajer IT dan Chief Information
Officer (CIO) yang memiliki pengetahuan kerja yang kuat mengenai bisnis organisasi.
Untuk mencapai keselarasan tersebut, diperlukan adanya hubungan kerja yang erat antara
manajemen perusahaan dan manajemen IT dalam pengembangan strategi bisnis dan IT bersamaan.
Namun, ini sulit dilakukan ketika perencanaan IT dialihkan secara geografis. Selanjutnya, karena
pembenaran keuangan untuk outsourcing IT 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
IT ini tidak konsisten dengan usaha mengejar keuntungan strategis di pasar.

Audit Implications of IT Outsourcing


Manajemen dapat mengalihkan fungsi IT perusahaannya, namun tidak dapat mengalihkan
tanggung jawab pengelolaannya di bawah SOX untuk memastikan pengendalian internal IT 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.
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 menggambarkan 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 IT. 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 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.

Referensi:

Hall, James A. 2011. Information Technology Auditing and Assurance. 3rd Ed. South Western
College Publishing, London.

Anda mungkin juga menyukai