Oleh:
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Referensi:
Hall, James A. 2011. Information Technology Auditing and Assurance. 3rd Ed. South Western
College Publishing, London.