TATA KELOLA AUDIT TI

Tata Kelola Teknologi Informasi

Tata kelola teknologi informasi (TI) adalah tata kelola perusahaan yang berfokus pada manajemen dan penilaian sumber daya strategis TI. Tujuan utama dari tata kelola TI adalah untuk mengurangi risiko dan memastikan bahwa investasi pada sumber daya teknologi informasi menambah nilai perusahaan. Sebelum Sarbanes-Oxley (SOX) Act, praktek umum mengenai investasi TI adalah untuk menunda semua keputusan untuk profesional TI perusahaan. Tata kelola TI modern, mengikuti filosofi bahwa semua pemangku kepentingan perusahaan, termasuk dewan direksi, manajemen puncak, dan pengguna departemen (yaitu, akuntansi dan keuangan) menjadi peserta aktif dalam keputusan kunci TI. Keterlibatan yang luas seperti ini mengurangi risiko dan meningkatkan kemungkinan bahwa keputusan TI akan sesuai dengan kebutuhan pengguna, kebijakan perusahaan, inisiatif strategis, dan persyaratan pengendalian internal di bawah SOX.

Pengendalian Tata Kelola TI

Meskipun semua masalah tata kelola TI penting bagi organisasi, tetapi tidak semua pengendalian internal di bawah SOX berpotensi mempengaruhi proses pelaporan keuangan. Dalam bab ini, kita mempertimbangkan tiga isu tata kelola TI yang ditangani oleh rerangka kerja pengendalian internal SOX dan COSO:

1.       Struktur organisasi dari fungsi TI

2.       Pusat operasi Komputer

3.       Perencanaan pemulihan bencana

Strukutur Fungsi Teknologi Informasi

Organisasifungsi TI berimplikasi pada sifat dan efektivitaspengendalian internal, yang, pada gilirannya, memiliki implikasi untukaudit. Pada bagian ini, beberapa masalah pengendalian yang terkait dengan struktur TI akan dibahas.

Pengolahan Data Terpusat

Dalam model pengolahan data terpusat, semua pengolahan data dilakukan oleh satu ataukomputer yang lebih besar yang bertempat di situs pusat yang berfungsi melayani seluruh penggunaorganisasi. Pengguna akhir bersaing untuk memperoleh sumber daya berdasarkan kebutuhannya. Layanan fungsi TI biasanya diperlakukan sebagai pusat biaya yang dibebankan kembali ke pengguna akhir. Layanan utama struktur TI yaitu

1.    Administrasi Database

Perusahaan dengan layanan terpusat mempertahankan sumber daya data mereka dalam lokasi pusat yang digunakan oleh semua pengguna akhir. Dalam pengaturan data bersama, sebuah kelompok independen yang dipimpin oleh database administrator (DBA) bertanggung jawab atas keamanan dan integritas database.

2.    Pengolahan Data

Kelompok pengolahan data mengelola sumber daya komputer yang digunakan untuk melakukan pengolahan transaksi setiap hari. Fungsi-fungsinya meliputi:

a)    konversi data, mentranskripsi data transaksi dari dokumen sumber hard copy ke inputkomputer,

b)    operasi komputer, file-file elektronik yang dihasilkan dalam konversi data kemudian diproses oleh komputer pusat, yang dikelola oleh kelompok operasi komputer.

c)    Perpustakaan data, ruang yang berdekatan dengan pusat komputer yang menyediakan penyimpanan yang aman untuk file data off-line (file back up atau file saat ini dalam bentuk DVD, CD-Rom, kaset, atau perangkat penyimpanan lainnya. Pustakawan data, bertanggung jawab untuk menerima, menyimpan, mencari, dan mempertahankan filedata dan kontrol akses ke perpustakaan.

3.    Pengembangan Sistem dan Pemeliharaan

Kebutuhan sistem informasi dari pengguna dipenuhi oleh dua fungsi yang terkait: pengembangan sistem dan sistem pemeliharaan. Kelompok pertama bertanggung jawab untuk menganalisis kebutuhan pengguna dan merancang sistem baru untuk memenuhi kebutuhan tersebut. Anggota pengembangan sistem mencakup sistem profesional, pengguna akhir, dan stakeholder. Sistem profesional (sistem analis, desainer database, dan programmer) merancang dan membangun sistem. Sistem profesional mengumpulkan fakta tentang masalah pengguna, menganalisis fakta-fakta, dan merumuskan solusi. Produk dari usaha mereka adalah sistem informasi baru. Pengguna akhir adalah untuk siapa sistem dibangun. Mereka adalah manajer yang menerima laporan dari sistem dan personil operasi yang bekerja secara langsung dengan sistem sebagai bagian dari tanggung jawab sehari-hari mereka. Stakeholder adalah individu dalam atau di luar perusahaan yang memiliki kepentingan dalam sistem, tetapi tidak pengguna akhir. Mereka termasuk akuntan, auditor internal, eksternal auditor, dan lain-lain yang mengawasi pengembangan sistem. Setelah sistem baru telah dirancang dan diimplementasikan, kelompok sistem pemeliharaan bertanggung jawab untuk menjaga sistem saat ini dengan kebutuhan pengguna.

Pemisahan Fungsi TI yang Tidak Sesuai

Lingkungan TI cenderung untuk mengkonsolidasikan kegiatan. Sebuah aplikasi tunggal dapat mengotorisasi, memproses, dan merekam semua aspek transaksi. Dengan demikian, fokus pengendalian bergeser dari tingkat operasional (tugas pemrosesan transaksi) ke tingkat yang lebih tinggi dalam fungsi layanan komputer dalam organisasi.

Memisahkan Pengembang Sistem dari Operasi Komputer

Pemisahan pengembang sistem (baik pengembangan sistem baru dan pemeliharaan) dan kegiatan operasi adalah hal yang penting. Hubungan antara kelompok-kelompok ini harus sangat formal, dan tanggung jawab mereka tidak boleh bercampur. Pengembang dan pemelihara sistem profesional harus menciptakan (dan mempertahankan) sistem bagi pengguna, dan seharusnya tidak memiliki keterlibatan dalam memasukkan data, atau menjalankan aplikasi (yakni, operasi komputer). Staf operasional harus menjalankan sistem ini dan tidak memiliki keterlibatan dalam desain mereka. Fungsi-fungsi ini secara bawaan tidak kompatibel, dan mengkonsolidasikan mereka mengundang kesalahan dan penipuan. Dengan pengetahuan rinci tentang logika aplikasi dan parameter pengendalian serta akses ke sistem operasi komputer dan utilitas, seorang individu bisa membuat perubahan tidak sah terhadap aplikasi selama pelaksanaannya. Perubahan tersebut mungkin bersifat sementara ("on the fly") dan akan hilang tanpa jejak saat aplikasi berakhir.

Memisahkan Administrasi Database dari Fungsi Lain

Pengendalian organisasi lain yang penting adalah pemisahan administrasi database (DBA) dari fungsi komputer lainnya. DBA bertanggung jawab untuk sejumlah tugas-tugas penting yang berkaitan dengan keamanan database, termasuk membuat skema database dan tampilan bagi user, menetapkan kewenangan akses database untuk pengguna, pemantauanpenggunaan database, dan perencanaan untuk ekspansi masa depan.

Memisahkan Pengembang Sistem Baru dari Perawatan

Beberapa perusahaan mengatur fungsi pengembangan sistem menjadi dua kelompok: analisis sistem dan pemrograman. Kelompok analisis sistem bekerja sama dengan pengguna untuk menghasilkan desain rinci dari sistem yang baru. Kelompok pemrograman membuat kode program sesuai dengan spesifikasi desain ini. Dalam pendekatan ini, programmer yang membuat kode program yang asli juga mempertahankan sistem selama fase pemeliharaan siklus hidup pengembangan sistem (dibahas dalam Bab 5). Meskipun pengaturan yang umum, pendekatan ini dikaitkan dengan dua jenis  masalah pengendalian:

1.    Dokumentasi yang tidak memadai. Dokumentasi sistem yang rendah adalah masalah kronis TI dan tantangan yang signifikan bagi banyak organisasi. Setidaknya ada dua penjelasan untuk fenomena ini. Pertama, pendokumentasian sistem tidak semenarik merancang, menguji, dan menerapkannya. Profesional sistem lebih memilih untuk pindah ke sebuah proyek baru yang menarik daripada mendokumentasikannya saat selesai. Alasan kedua yang mungkin untuk rendahnya dokumentasi adalah keamanan kerja. Ketika sistem kurang didokumentasikan, akan sulit untuk menafsirkan, menguji, dan menggunakannya. Oleh karena itu, programer yang mengerti sistem mempertahankan daya tawar dan menjadi relatif sangat diperlukan. Ketika programmer meninggalkan perusahaan, programmer baru mewarisi tanggung jawab pemeliharaan sistem yang tidak berdokumen.

2.    Program Penipuan. Ketika programmer asli dari sistem juga ditugaskan untuk pemeliharaan, potensi kecurangan meningkat. Penipuan program melibatkan pembuatan perubahan yang tidak sah untuk program modul dengan tujuan melakukan tindakan ilegal. Programmer asli mungkin telah berhasil menyembunyikan kode curang diantara ribuan baris kode yang sah dan ratusan modul yang merupakan sebuah kesatuan. Agar penipuan berjalan dengan sukses, programmer harus mampu mengendalikan situasi melalui akses khusus dan terbatas untuk program aplikasi. Pemrogram perlu melindungi kode penipuan dari deteksi oleh orang lain, programmer yang melakukan perawatan atau dengan pengujian pengendalian aplikasi oleh auditor.

Struktur Unggul untuk Pengembangan Sistem

Fungsi pengembangan sistem dipisahkan menjadi dua kelompok berbeda: pengembangan sistem baru dan sistem pemeliharaan. Kelompok pengembangan sistem baru bertanggung jawab untuk merancang, pemrograman,
dan melaksanakan proyek-proyek sistem baru. Setelah pelaksanaan berhasil, tanggung jawab untuk pemeliharaan sistem yang sedang berlangsung jatuh ke kelompok pemeliharaan sistem. Restrukturisasi ini memiliki implikasi yang langsung menangani dua masalah pengendalian.

Pertama, standar dokumentasi ditingkatkan karena kelompok pemeliharaan membutuhkan dokumentasi untuk melakukan tugas pemeliharaan. Tanpa dokumentasi yang lengkap dan memadai, transfer tanggung jawab sistem baru dari pengembang sistem ke pemeliharaan tidak dapat terjadi.

Kedua, menghalangi akses programmer asli untuk menghalangi program penipuan. Kode curang, sering kali tersembunyi dalam sistem, dan berada diluar pengendalain programmer dan mungkin kemudian ditemukan sehingga meningkatkan risiko program penipuan. Keberhasilan pengendalian ini tergantung pada keberadaan kontrol lain yang membatasi, mencegah, dan mendeteksi akses tidak sah ke program (seperti kontrol program perpustakaan sumber).

Model Terdistribusi (DDP)

Secara sederhana, DDP melibatkan reorganisasi fungsi TI pusat ke unit TI kecil yang ditempatkan di bawah kendali pengguna akhir. Unit TI dapat didistribusikan menurut fungsi bisnis, lokasi geografis, atau keduanya tergantung pada filosofi dan tujuan organisasi manajemen.

Risiko yang Berkaitan dengan DDP

Potensi masalah DDP yaitu penggunaan sumber yang tidak efisien, penghancuran jejak audit, pemisahan tugas yang tidak memadai, meningkatkan potensi kesalahan pemrograman dan kegagalan sistem, dan kurangnya standar.

Tidak efisien dalam penggunaan sumber daya. Terdapat tiga risiko `DDP:

1.    Risiko kesalahan manajemen sumber daya organisasi TI oleh pengguna akhir.Beberapa berpendapat bahwa ketika sumber organisasi TI melebihi jumlah ambang batas, tata kelola TI yang efektif memerlukan pusat pengelolaan dan pemantauan sumber daya tersebut.

2.    DDP dapat meningkatkan risiko inefisiensi operasional karena tugas yang berlebihan dilakukan dalam komite pengguna akhir.

3.    Lingkungan DDP menimbulkan risiko hardware dan perangkat lunak tidak kompatibel antara fungsi pengguna akhir. Mendistribusikan tanggung jawab untuk pembelian TI kepada pengguna akhir dapat mengakibatkan keputusan yang tidak terkoordinasi dan kurang dipahami.

Penghancuran Jejak Audit. Jejak audit menyediakan hubungan kegiatan keuangan antara perusahaan (transaksi) dan laporan keuangan mereka. Auditor menggunakan jejak audit untuk melacak transaksi keuangan yang dipilih dari dokumen sumber yang merekam peristiwa, melalui jurnal, buku besar pembantu, dan rekening buku besar yang mencatat peristiwa, dan akhirnya ke laporan keuangan itu sendiri. Jejak audit sangat penting untuk jasa atestasi auditor.

Dalam sistem DDP, jejak audit terdiri dari satu set filetransaksi digital dan  file master (Bab 6 penawaran dengan teknik pemrosesan transaksi) yang sebagian atau sepenuhnya berada pada komputer pengguna akhir. Jika pengguna akhir secara tidak sengaja menghapus salah satu file, jejak audit dapat dihancurkan dan tidak dapat dipulihkan. Demikian pula, jika pengguna akhir secara tidak sengaja menyisipkan kesalahan transaksi ke file jejak audit.

Pemisahan Tugas yang Tidak Memadai. Mencapai sebuah pembagian tugas yang memadai tidak mungkin dalam lingkungan terdistribusi. Distribusi layanan TI untuk pengguna dapat mengakibatkan pembentukan unit-unit independen kecil yang tidak mengizinkan pemisahan yang diinginkan dari fungsi yang tidak kompatibel. Misalnya, dalam satu unit, orang yang sama dapat menulis program aplikasi, melakukan perawatan program, masukkan data transaksi ke dalam komputer, dan mengoperasikan peralatan komputer. Situasi seperti itu akan menjadi pelanggaran fundamental dalam pengendalian internal.

Mempekerjakan Profesional Berkualitas. Manajer pengguna akhir mungkin tidak memiliki pengetahuan TI untuk mengevaluasi teknis dan pengalaman yang relevan dari calon pelamar posisi profesional TI. Juga, jika karyawan memasuki unit organisasi baru yang kecil, kesempatan untuk berkembang, pendidikan berkelanjutan, dan promosi mungkin terbatas. Untuk alasan ini, manajer mungkin mengalami kesulitan untuk menarik personil yang berkualitas. Risiko kesalahan pemrograman dan kegagalan sistem meningkat secara langsung dengan tingkat ketidakmampuan karyawan.

Kurangnya Standar. Karena distribusi tanggung jawab dalam lingkungan DDP, standar untuk mengembangkan dan mendokumentasikan sistem, memilih bahasa pemrograman, memperoleh hardwaredan software, dan mengevaluasi kinerja mungkin tidak diterapkan secara merata atau bahkan tidak ada. Penentang DDP berpendapat bahwa risiko yang berkaitan dengan desain dan operasi dari sistem DDP dibuat bertoleransi hanya jika standar tersebut secara konsisten diterapkan.

Keuntungan dari DDP

Berikut iuni terdapat beberapa keuntungan dari penerapan DDP:

1.    Pengurangan Biaya. Mikrocomputer dan minicomputer yang kuat dan murah yang dapat melakukan fungsi khusus telah mengubah ekonomis pengolahan data secara dramatis. Biaya unit penyimpanan data, yang pernah menjadi pembenaran untuk mengkonsolidasikan data dalam lokasi pusat, tidak lagi menjadi pertimbangan utama. Selain itu, DDP telah mengurangi biaya dalam dua wilayah lainnya: (1) data dapat diedit dan dimasukkan oleh pengguna akhir, sehingga menghilangkan tugas terpusat persiapan data; dan (2) kompleksitas aplikasi dapat berkurang, yang pada gilirannya mengurangi pengembangan sistem dan biaya pemeliharaan.

2.    Peningkatan Tanggung Jawab Pengendalian Biaya. Manajer pengguna akhir memiliki tanggung jawab untuk keberhasilan finansial operasi mereka. Tanggung jawab ini mengharuskan mereka untuk lebih tegas dalam membuat keputusan tentang sumber daya yang mempengaruhi keberhasilan mereka secara keseluruhan. Ketika manajer dilarang membuat keputusan yang diperlukan untuk mencapai tujuan mereka, kinerja mereka bisa dipengaruhi secara negatif. Para pendukung DDP berpendapat bahwa manfaat dari perbaikan sikap manajemen lebih besar daripada biaya tambahan yang timbul dari penyebaran sumber daya ini. Mereka berpendapat bahwa jika kemampuan TI memang penting untuk keberhasilan operasi bisnis,
maka manajemen harus diberikan kontrol atas sumber daya tersebut.

3.    Peningkatan Kepuasan Pengguna. Pendukung DDP mengklaim bahwa penyebaran sistem untuk pengguna akhir
meningkatkan tiga bidang kebutuhan: (1) keinginan pengguna untuk mengontrol sumber daya yang mempengaruhi profitabilitas mereka; (2) pengguna ingin sistem profesional (analis, programmer, dan operator komputer) responsif terhadap situasi mereka; dan (3) pengguna ingin menjadi lebih aktif terlibat dalam mengembangkan dan menerapkan sistem mereka sendiri.

4.    Fleksibilitas Cadangan. Argumen terakhir dalam mendukung DDP adalah kemampuan untuk membuat fasilitas cadangan komputasi untuk melindungi terhadap potensi bencana, seperti kebakaran, banjir, sabotase, dan gempa bumi. Satu-satunya cara untuk membuat cadangan situs komputer pusat terhadap bencana adalah menyediakan fasilitas komputer kedua. Model distribusi menawarkan organisasi untuk menyediakan cadangan yang fleksibel. Tentu, konfigurasi ini membutuhkan koordinasi yang erat antara manajer pengguna akhir untuk memastikan bahwa mereka tidak menerapkan perangkat keras dan perangkat lunak yang tidak kompatibel.

Mengontrol Lingkungan DDP

Beberapa perbaikan untuk DDP agar lebih sempurna

1.    Pengujian Terpusat untuk Software dan Hardware komersial. Pertimbangan mengevaluasi hardware dan software komersial lebih baik diberikan kepada kelompok pusat daripada pengguna akhir. Kelompok ini dapat mengevaluasi fitur sistem, pengendalian, dan kecocokan dengan industri dan standar organisasi. Hasil uji kemudian dapat didistribusikan ke daerah-daerah pengguna sebagai standar untuk mengarahkan keputusan akuisisi. Hal ini memungkinkan organisasi untuk secara efektif melakukan sentralisasi untuk akuisisi, pengujian, dan implementasi perangkat lunak dan perangkat keras.

2.    Pengguna Jasa. Sebuah fitur yang berharga dari kelompok perusahaan adalah fungsi layanan bagi pengguna. Kegiatan ini memberikan bantuan teknis kepada pengguna selama instalasi perangkat lunak dan
perangkat keras yang baru yang mengalami masalah. Penciptaan buletin elektronik untuk pengguna adalah cara terbaik untuk mendistribusikan informasi tentang masalah umum dan memungkinkan pengguna berbagi program dengan orang lain dalam organisasi. Selain itu, chat roomdapat didirikan untuk memberikan diskusi,  pertanyaan yang sering diajukan (FAQ), dan dukungan intranet. Fungsi TI perusahaan juga dapat memberikan help desk, di mana pengguna bisa menelepon dan mendapatkan respon yang cepat untuk pertanyaan dan masalah.

3.    Badan Penyusun Standar. Lingkungan pengendalian yang relatif terbatas yang diakibatkan oleh model DDP dapat ditingkatkan dengan mendirikan beberapa petunjuk pusat. Kelompok korporasi dapat berkontribusi untuk tujuan ini dengan membentuk dan mendistribusikan standar ke daerah pengguna yang sesuai untuk pengembangan sistem, pemrograman, dan dokumentasi.

4.    Ulasan Personil. Kelompok perusahaan sering lebih siap daripada pengguna untuk mengevaluasi calon profesional teknis sistem. Meskipun sistem profesional akan benar-benar menjadi bagian dari kelompok pengguna akhir, keterlibatan kelompok dalam keputusan kerja dapat membuat layanan yang berharga bagi organisasi.

Tujuan Audit

Tujuan auditor adalah untuk memverifikasi bahwa struktur fungsi TI adalah seperti individu di daerah yang tidak kompatibel yang dipisahkan sesuai dengan tingkat potensi risiko dan dengan cara mempromosikan lingkungan kerja.

Prosedur Audit

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

1.    Ulasan dokumentasi yang relevan, termasuk bagan organisasi, pernyataan misi, dan deskripsi pekerjaan untuk fungsi-fungsi kunci

2.    Ulasan dokumentasi sistem dan catatan pemeliharaan untuk sampel aplikasi.

3.    Pastikan operator komputer tidak memiliki akses ke rincian operasional dari logika internal sistem

4.    Melalui pengamatan, tentukan bahwa kebijakan segregasi diikuti dalam praktek.

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

1.    Tinjau bagan organisasi, pernyataan misi, dan deskripsi pekerjaan untuk
fungsi kunci untuk menentukan apakah individu atau kelompok yang melakukan tugas yang kompatibel

2.    Pastikan bahwa kebijakan dan standar perusahaan untuk desain sistem, dokumentasi, dan akuisisi perangkat keras dan perangkat lunak diterbitkan dan diberikan kepada unit TI yang terdistribusi.

3.    Pastikan kompensasi pengendalian yang dilakukan

4.    Ulasan sistem dokumentasi untuk memverifikasi bahwa aplikasi, prosedur, dan database dirancang dan berfungsi sesuai dengan standar perusahaan.

PUSAT KOMPUTER

Akuntan secara rutin memeriksa lingkungan fisik dari pusat komputer sebagai bagian dari audit tahunan mereka. Bagian ini menyajikan risiko pusat komputer dan pengendalian yang membantu untuk mengurangi risiko dan menciptakan lingkungan yang aman.

Lokasi Fisik

Lokasi fisik dari pusat komputer langsung mempengaruhi risiko kerusakan alami atau buatan manusia. Sedapat mungkin, pusat komputer harus jauh dari bahaya buatan manusia dan alam, seperti pabrik pengolahan, gas dan air
induk, bandara, daerah kejahatan tinggi, dataran banjir, dan kesalahan geologi.

Konstruksi

Idealnya, sebuah pusat komputer harus terletak di sebuah bangunan satu lantai dari bangunan yang kokoh dengan akses dikendalikan (dibahas berikutnya). Utilitas (listrik dan telepon) baris harus dibawah tanah. Bangunan jendela tidak harus terbuka dan sistem penyaringan udara harus di tempat yang mampu mengekstrak serbuk sari, debu, dan tungau debu.

Akses

Akses ke pusat komputer harus terbatas pada operator dan karyawan lainnya yang bekerja di sana. Kontrol fisik, seperti pintu terkunci, harus digunakan untuk membatasi akses ke pusat. Akses harus dikontrol oleh keypad atau menggesek kartu, meskipun api keluar dengan alarm yang diperlukan. Untuk mencapai tingkat keamanan yang lebih tinggi, akses harus dipantau oleh kamera sirkuit tertutup dan sistem perekaman video. Pusat komputer juga harus menggunakan sign-in log untuk programmer dan analis yang membutuhkan akses untuk memperbaiki
kesalahan program.

AC
Komputer berfungsi dengan baik di lingkungan ber-AC, dan penyediaan udara pendingin yang memadai sering merupakan persyaratan garansi pemasok. Komputer beroperasi dengan baik dikisaran suhu 70 sampai 75 derajat Fahrenheit dan kelembaban relatif 50 persen. Kesalahan logika dapat terjadi pada hardware komputer saat suhu pergi secara signifikan dari jarak optimal ini. Risiko kerusakan sirkuit dari listrik statis juga meningkat ketika kelembaban turun.

Api merupakan ancaman paling serius untuk peralatan komputer perusahaan. Banyak perusahaan yang menderita kebakaran pusat komputer keluar dari bisnis karena hilangnya catatan penting, seperti piutang. Pelaksanaan sistem pencegah kebakaran yang efektif membutuhkan konsultasi dengan spesialis. Namun, beberapa fitur utama dari sistem tersebut meliputi:

1.    Alarm otomatis dan manual harus ditempatkan di lokasi strategis di sekitar instalasi. Alarm ini harus terhubung ke stasiun staf pemadam kebakaran secara permanen

2.    Harus ada sistem pemadam api otomatis yang dibagikan sesuai jenis penekan untuk lokasi.

3.    Alat pemadam kebakaran manual harus ditempatkan di lokasi-lokasi strategis.

4.    Bangunan harus dari konstruksi yang dapat menahan kerusakan air yang disebabkan oleh peralatan pemadaman kebakaran.

5.    Api yang keluar harus ditandai dengan jelas dan diterangi selama kebakaran.

Toleransi Kesalahan

Toleransi kesalahan adalah kemampuan sistem untuk melanjutkan operasi ketika terdapat kegagalan dari bagian sistem karena kegagalan hardware, kesalahan program aplikasi, atau kesalahan operator. Menerapkan pengendalian toleransi kesalahan dilakukan untuk memastikan bahwa tidak ada satu titik kegagalan sistem potensial. Kegagalan total dapat terjadi hanya jika beberapa komponen gagal.

Tujuan Audit

Tujuan auditor adalah untuk mengevaluasi pengendalian yang mengatur keamanan pusat komputer. Secara khusus, auditor harus memverifikasi bahwa:

1.    Pengendalian keamanan fisik yang memadai untuk melindungi organisasi dari eksposur fisik

2.    Asuransi pada peralatan untuk mengkompensasi organisasi jika terjadi penghancuran, atau kerusakan pada pusat komputer.

Prosedur Audit

Berikut ini adalah uji pengendalian keamanan fisik.

Tes Konstruksi Fisik. Auditor harus memperoleh rencana arsitektur untuk menentukan bahwa pusat komputer dibangun dengan kokoh dari bahan tahan api. Selain itu, auditor harus menilai lokasi fisik dari pusat komputer. Fasilitas ini harus berada di daerah yang meminimalkan paparan terhadap kebakaran, kerusuhan sipil, dan bahaya lainnya.

Pengujian Sistem Deteksi Api. Auditor harus menetapkan bahwa deteksi kebakaran dan peralatan penyelamatan, baik manual dan otomatis, berada di tempat dan diuji secara teratur. Sistem deteksi api harus mendeteksi asap, panas, dan asap yang mudah terbakar. Bukti dapat diperoleh dengan meninjau catatan marshal api resmi, yang disimpan di pusat komputer.

Pengujian Pengendalian Akses. Auditor harus menetapkan bahwa akses rutin ke komputer pusat dibatasi untuk karyawan yang berwenang. Rincian tentang akses pengunjung (oleh programmer dan lain-lain), seperti kedatangan dan keberangkatan, tujuan, dan frekuensi akses, dapat diperoleh dengan meninjau log akses. Untuk membangun kebenaran dokumen ini, auditor dapat diam-diam mengamati proses dimana akses diizinkan, atau meninjau rekaman video dari kamera pada titik akses, pada saat sedang digunakan.

Pengujian Penggrebekan. Kebanyakan sistem yang menggunakan RAID memberikan pemetaan grafis dari penyimpanan disk yang berlebihan. Dari pemetaan ini, auditor harus menentukan apakah tingkat RAID di tempat memadai bagi organisasi, mengingat tingkat risiko bisnis terkait dengan kegagalan disk. Jika organisasi tidak menggunakan RAID, potensi untuk satu titik kegagalan sistem ada.

Pengujian Daya yang Tidak Teerganggu. Pusat komputer harus melakukan pengujian periodik catu daya cadangan untuk memastikan bahwa ia memiliki kapasitas yang cukup untuk menjalankan komputer dan pendingin udara. Ini adalah pengujian yang sangat penting, dan hasilnya harus secara resmi dicatat. Meningkatnya sistem komputer perusahaan, meningkatkan ketergantungannya terhadap kebutuhan listrik cadangan secara proporsional.

Pengujian Perlindungan Asuransi. Auditor setiap tahun meninjau  pertanggungan asuransi organisasi pada perangkat keras komputer, perangkat lunak, dan fasilitas fisik. Auditor harus memverifikasi bahwa semua akuisisi baru tercantum pada kebijakan dan peralatan dan perangkat lunak yang usang telah dihapus. Polis asuransi harus mencerminkan kebutuhan manajemen dalam hal luasnya cakupan.

PERENCANAAN PEMULIHAN BENCANA (DRP)

Bencana seperti gempa bumi, banjir, sabotase, dan bahkan gangguan listrik dapat menjadi bencana untuk pusat komputer dan sistem informasi organisasi. Ada tiga kategori bencana yang dapat menghancurkan sumber daya TI organisasi:

1.    bencana alam, seperti angin topan, banjir, dan gempa bumi,

2.    bencana buatan manusia, seperti sabotase atau kesalahan

3.    kegagalan sistem seperti listrik padam atau kegagalan hard-drive

Semua bencana ini bisa menghilangkan pengolahan data organisasi, menghentikan fungsi-fungsi bisnis yang dilakukan atau dibantu oleh komputer, dan merusak kemampuan organisasi untuk memberikan produk atau jasa. Semakin tergantung sebuah organisasi pada teknologi, makin rentan terhadap risiko.

Bencana dari jenis yang diuraikan di atas biasanya tidak dapat dicegah atau dihindari. Meskipun kebutuhan tiap organisasi berbeda, berikut ini komponen yang secara umum harus ada dalam rencana organisasi:

1.    Mengidentifikasi aplikasi kritis

2.    Membuat tim pemulihan bencana

3.    Memberikan situs cadangan

4.    Menentukan backup dan prosedur penyimpanan

Mengidentifikasi Aplikasi Kritis

Elemen penting pertama dari DRP adalah untuk mengidentifikasi aplikasi perusahaan yang kritis dan file data terkait. Upaya pemulihan harus berkonsentrasi pada pemulihan aplikasi tersebut. Semua aplikasi harus dikembalikan ke tingkat aktivitas bisnis prabencana. Bagi kebanyakan organisasi, kelangsungan hidup jangka pendek membutuhkan pemulihan fungsi-fungsi yang menghasilkan arus kas yang cukup untuk memenuhi kewajiban jangka pendek. Oleh karena itu, aplikasi ini harus diidentifikasi dan diprioritaskan dalam rencana restorasi. Prioritas aplikasi dapat berubah dari waktu ke waktu, dan keputusan ini harus dinilai ulang teratur. Sistem terus direvisi dan diperluas untuk mencerminkan perubahan dalam kebutuhan pengguna. Tugas mengidentifikasi item kritis dan memprioritaskan aplikasi memerlukan partisipasi aktif dari departemen pengguna, akuntan, dan auditor. Tugas ini sering kali  salah dipandang sebagai masalah teknis komputer dan karena itu didelegasikan kepada profesional TI. Meskipun bantuan teknis profesional TI akan diperlukan, tugas ini adalah keputusan bisnis dan harus dilakukan oleh orang-orang yang memahami masalah bisnis.

Membuat Tim Pemulihan Bencana

Pemulihan dari bencana bergantung pada tindakan korektif tepat waktu. Penundaan dalam melaksanakan tugas penting memperpanjang periode pemulihan dan mengurangi suksenya prospek pemulihan. Untuk menghindari kelalaian serius atau duplikasi usaha selama pelaksanaan rencana, tanggung jawab harus jelas dan disampaikan kepada personil yang terlibat.

Menyediakan Situs Cadangan

Salah satu hal yang diperlukan dalam DRP adalah tersedianya fasilitas pengolahan data ganda setelah bencana. Di antara banyak pilihan yang tersedia, yang paling umum digunakan adalah

1.    Perjanjian Saling Bantu. Perjanjian saling membantu adalah perjanjian antara dua atau lebih organisasi (dengan fasilitas komputer yang kompatibel) untuk saling membantu satu sama lain dalam pengolahan data mereka dalam hal kebutuhan bencana.

2.    Shell Kosong. Shell kosong atau situs rencana dingin adalah pengaturan dimana perusahaan membeli ataumenyewa sebuah bangunan yang akan berfungsi sebagai pusat data. Dalam hal terjadi bencana, shelltersedia dan siap untuk menerima hardware apa pun sesuai kebutuhan pengguna sementara untuk menjalankan sistem penting. Pendekatan ini, bagaimanapun, memiliki kelemahan mendasar. Pemulihan tergantung pada ketersediaan waktu yang tepat dari perangkat keras komputeryang diperlukan untuk mengembalikanfungsi pengolahan data. Manajemen harus memperoleh jaminan melalui kontrak dengan pemasok perangkat keras, di mana, kebutuhan perusahaan menjadi prioritas. Masalahpasokan hardware yang tak terduga di titik kritis inibisa menjadi pukulan fatal.

3.    Pusat Operasi Pemulihan (ROC). Pusat operasi pemulihan (ROC) atau situs panas adalahpusat cadangan data perusahaan yang dapat dibagi antar organisasi. Selain perangkat keras dan sarana pendukung, penyedia layanan ROC menawarkan berbagai layanan teknis untuk klien mereka, yang membayar biaya tahunan untuk hak akses. Dalam hal terjadi bencana besar, pelanggan dapat menempati tempat dan, dalam beberapa jam, melanjutkan pengolahan aplikasi yang penting.

4.    Cadangan yang Dibuat secara Internal. Organisasi yang lebih besar dengan beberapa pengolahan pusat data seringkali lebih suka menciptakan kapasitas cadangan internal. Ini memungkinkan perusahaan untuk mengembangkan konfigurasi standar perangkat keras dan perangkat lunak, yang menjamin kecocokan fungsional antara pusat pengolahan data dan meminimalkan pemisahan masalah dalam hal bencana.

Prosedur Backup dan Penyimpanan Off-Site

Semua file data, aplikasi, dokumentasi, dan perlengkapan yang dibutuhkan untuk melakukan fungsi penting harus secara otomatis didukung dan disimpan di lokasi off-site yang aman. Personil pengolahan data harus secara rutin melakukan prosedur backup dan penyimpanan untuk mendapatkan dan mengamankan sumber daya yang penting.

Sistem Operasi Backup. Jika perusahaan menggunakan situs dingin atau metode lain dari situs cadangan yang tidak termasuk sistem operasi yang kompatibel (O / S), prosedur untuk memperoleh sistem operasi versi saat ini harus jelas ditentukan. Pustakawan data, jika ada, akan menjadi orang kunci yang terlibat dalam melakukan tugas backup data dan aplikasi.

Aplikasi Backup. Dalam hal perangkat lunak komersial, ini melibatkan pembelian salinan cadangan dari upgrade software terbaru yang digunakan oleh organisasi, prosedur backupharus menjadi langkah integral dalam pengembangan sistem dan proses perubahan program, yang dibahas secara rinci dalam Bab 5.

Backup Data File. Tidak semua organisasi bersedia atau mampu berinvestasi dalam sumber daya backup. Database harus disalin paling tidak setiap hari dengan kapasitas tinggi, media kecepatan tinggi, seperti kaset atau CD / DVD dan offsite aman. Dalam hal gangguan, rekonstruksi databasedicapai dengan memperbarui versi data cadangan terbaru dengan data transaksi berikutnya. Demikian juga, file master dan file transaksi harus dilindungi.

Dokumentasi Cadangan. Sistem dokumentasi untuk aplikasi kritis harus didukung dan disimpan pada off-site bersama dengan aplikasi. Dokumentasi sistem dapat berjumlah besar dan proses backup rumit oleh perubahan aplikasi (lihat Bab 5). Dokumentasi cadangan mungkin disederhanakan dan dibuat lebih efisien melalui penggunaan alat dokumentasi Computer Aided Software Engineering (CASE). DRP juga harus mencakup dukungan terhadap penyediaan manual untuk pengguna akhir karena individu memproses transaksi dalam kondisi bencana yang mungkin tidak biasa bagi staf yang akrab dengan sistem biasa.

Cadngan Persediaan dan Dokumen Sumber. Organisasi harus membuat cadangan persediaan dan dokumen sumber yang penting yang digunakan dalam pengolahan transaksi. Contohnya faktur, pesanan pembelian, dan bentuk lainnya yang tidak dapat diperoleh dengan segera. DRP harus menentukan jenis dan jumlah barang-barang khusus yang dibutuhkan. Karena ini adalah elemen rutin dari operasi sehari-hari, hal ini sering diabaikan oleh perencana darurat bencana. Pada titik ini, perlu dicatat bahwa salinan dokumen DRP harus juga disimpan dalam off-site di lokasi yang aman.

Pengujian DRP. Aspek yang paling sering diabaikan dari perencanaan kontingensi adalah pengujian DRP. Namun demikian, pengujian DRP penting dan harus dilakukan secara berkala. Pengujian untuk mengukur kesiapan personil dan mengidentifikasi kelalaian atau hambatan dalam rencana. Pengujian paling berguna dilaksanakan ketika simulasi gangguan bersifat tiba-tiba. Ketika bencana mock diumumkan, status semua proses yang terkena harus didokumentasikan. Pendekatan ini memberikan patokan untuk penilaian kinerja selanjutnya. Rencana tersebut harus dilakukan secara ekonomi. Idealnya, penggunaan fasilitas backup dan persediaan. Kemajuan rencana tersebut harus dicatat pada titik-titik kunci selama periode uji berlangsung. Pada akhir pengujian, hasilnya dapat dianalisis dan laporan kinerja DRP disiapkan. Tingkat kinerja yang dicapai menjadi masukan untuk keputusan dalam memodifikasi DRP atau melaksanakan jadwal pengujian tambahan. Manajemen organisasi harus mencari ukuran kinerja di masing-masing bidang berikut: (1) efektivitas personel tim DRP dan tingkat pengetahuan; (2) tingkat keberhasilan konversi (yaitu, jumlah recordyang hilang); (3) perkiraan kerugian finansial karena catatan atau fasilitas hilang; dan (4) efektivitas program, data, dan backup dokumentasi dan prosedur pemulihan.

Tujuan Audit

Auditor harus memverifikasi bahwa manajemen rencana pemulihan bencana memadai dan layak untuk menangani bencana yang bisa menghilangkan sumber komputasi organisasi.

Prosedur Audit

Dalam memverifikasi bahwa DRP adalah solusi yang realistis untuk menangani bencana, pengujian berikut dapat dilakukan.

Situs Cadangan. Auditor harus mengevaluasi kecukupan pengaturan situs cadangan. Ketidakcocokan sistem dan sifat manusia sangat mengurangi efektivitas perjanjian saling membantu. Auditor harus skeptis terhadap pengaturan tersebut karena dua alasan. Pertama, kecanggihan sistem komputer dapat membuat auditor kesulitan untuk menemukan potensi bermitra dengan konfigurasi yang kompatibel. Kedua, sebagian besar perusahaan tidak memiliki kelebihan kapasitas untuk mendukung pasangan yang terkena bencana dan juga memproses pekerjaannya.
Pilihan yang lebih layak dan mahal adalah shellkosong dan pemulihan pusat operasi. Jika organisasi klien menggunakan metode shell kosong, maka auditor perlu memverifikasi keberadaan kontrak yang sah dengan hardware
pemasok yang menjamin pengiriman perangkat keras komputer yang dibutuhkan dengan keterlambatan minimal setelah bencana. Jika klien adalah anggota dari ROC, auditor harus memperhatikan tentang jumlah anggota ROC dan dispersi geografis mereka. Bencana yang luas mungkin mengakibatkan permintaan tidak bisa dipenuhi oleh fasilitas ROC.

Daftar Aplikasi Kritis. Auditor harus meninjau daftar aplikasi kritis untuk memastikan kelengkapannya. Aplikasi yang hilang dapat mengakibatkan kegagalan untuk dipulihkan. Hal yang sama berlaku, untuk memulihkan aplikasi yang tidak diperlukan. Untuk menyertakan aplikasi yang tidak diperlukan untuk mencapai kelangsungan hidup jangka pendek dalam daftar penting dapat menyesatkan dan mengalihkan perhatian dari tujuan utama selama periode pemulihan.

Software Backup. Auditor harus memverifikasi bahwa salinan aplikasi kritis dan sistem operasi disimpan dalam off-site. Auditor juga harus memverifikasi bahwa aplikasi yang saat ini disimpan dalam off-site dengan membandingkan nomor versi mereka dengan yang digunakan oleh orang lain.

BackupData. Auditor harus memverifikasi bahwa file data yang penting didukung sesuai dengan DRP.

Cadangan Perlengkapan, Dokumen, dan Dokumentasi. Dokumentasi sistem, persediaan, dan dokumen sumber yang diperlukan untuk memproses transaksi penting harus didukung dan disimpan dalam off-site. Auditor harus memverifikasi jenis dan jumlah item yang ditentukan dalam DRP seperti memeriksa saham, faktur, pesanan pembelian, dan setiap bentuk khusus ada di lokasi yang aman.

Tim Pemulihan Bencana. DRP harus jelas mencantumkan nama, alamat, dan nomor telepon darurat dari anggota tim pemulihan bencana. Auditor harus memverifikasi bahwa anggota tim adalah karyawan saat ini dan menyadari tugas dan tanggung jawab mereka.

OUTSOURCING FUNGSI TI

Biaya, risiko, dan tanggung jawab berkaitan secara signifikan dengan efektivitas fungsi TI perusahaan. Oleh karena itu, banyak eksekutif memilih untuk melakukan outsourcing fungsi TI mereka ke pihak ketiga yang mengambil alih tanggung jawab atas pengelolaan aset TI dan staf untuk pengiriman layanan TI, seperti memasukkan data, operasi pusat data, pengembangan aplikasi, aplikasi pemeliharaan, dan pengelolaan jaringan. Manfaat outsourcing TI termasuk peningkatan kinerja bisnis inti dan mengurangi biaya TI. Melalui skala ekonomi, dengan menggabungkan kebutuhan beberapa klien, vendor dapat melakukan fungsi outsourcing yang lebih murah daripada perusahaan klien. Penghematan biaya yang dihasilkan kemudian diteruskan ke organisasi klien.

Berikut ini akan dibahas logika dan teori yang mendasari outsourcing TI:

1.    Teori kompetensi inti, berpendapat bahwa organisasi harus fokus secara eksklusif pada kompetensi bisnis inti, sementara outsourcingpemasok untuk secara efisien mengelola kegiatan non-inti seperti fungsi TI. Premis ini, mengabaikan perbedaan penting antara komoditas dan aset TI yang spesifik. Aset komoditas TI tidak unik untuk sebuah organisasi tertentu dan dengan demikian mudah diperoleh di pasar. Ini termasuk hal-hal seperti manajemen jaringan, operasi sistem, pemeliharaan server, dan fungsi help-desk. Sebaliknya set TI yang spesifik, yang unik mendukung tujuan strategis organisasi. Karena sifatnya yang istimewa, aset tertentu memiliki nilai diluar penggunaannya saat ini. Aset seperti itu mungkin berwujud (peralatan komputer), intelektual (program komputer), atau manusia. Contoh aset tertentu meliputi pengembangan sistem, pemeliharaan aplikasi, pergudangan data, dan karyawan yang sangat terampil dilatih untuk menggunakan software khusus bagi organisasinya.

2.    Biaya Transaksi Ekonomis (TCE), teori ini bertentangan dengan teori kompetensi inti dengan menyarankan bahwa perusahaan harus mempertahankan aset TI non-inti spesifik. Karena sifat esoteris mereka, aset tertentu tidak dapat dengan mudah diganti dalam pengaturan outsourcing. Oleh karena itu, jika organisasi harus memutuskan untuk membatalkan kontrak outsourcing dengan pemasok, mungkin tidak dapat kembali seperti semula. Di sisi lain, teori TCE mendukung outsourcing komoditas aset, yang dengan mudah diganti atau diperoleh dari pemasok alternatif. Tentu, persepsi CEO dari apa yang merupakan aset komoditas TI memainkan peran penting dalam keputusan outsourcing TI. Sering kali berkaitan dengan definisi dan interpretasi.

Risiko Bawaan Outsourcing TI

Outsourcing TI dalam skala besar berisiko karena masalah keungan dan sifatnya. Tingkat risiko berkaitan dengan tingkat spesifisitas aset fungsi outsourcing. Berikut ini masalah yang didokumentasikan berkaitan dengan outsourcing TI

Kegagalan Kinerja

Setelah sebuah perusahaan klien selesai mengoutsourcing aset TI tertentu, kinerjanya menjadi berkaitan dengan kinerja pemasok. Implikasi ketergantungan negatif seperti diilustrasikan dalam masalah keuangan yang telah melanda pemasok perusahaan outsourcing besar EDS. Dalam upaya pemotongan biaya, EDS menghentikan tujuh ribu karyawan, yang berdampak pada kemampuannya untuk melayani klien lain. Setelah 11 tahun harga saham terpuruk, pemegang saham EDS mengajukan gugatan class actionterhadap perusahaan. Jelas, pemasok mengalami masalah keuangan dan hukum yang serius dan mengancam kelangsungan hidup mereka klien juga.

Eksploitasi Pemasok

Skala besar outsourcing TI melibatkan transfer "aset tertentu" ke pemasok seperti desain, pengembangan, dan pemeliharaan aplikasi bisnis yang unik yang sangat penting untuk kelangsungan hidup organisasi. Aset tertentu, sangat berharga untuk klien, tetapi tidak untuk pemasok. Karena pemasok mengasumsikan risiko
dengan mengakuisisi aset dan dapat mencapai skala tidak ekonomi dengan menggunakannya di tempat lain, organisasi klien akan membayar premi untuk mentransfer fungsi seperti ini untuk pihak ketiga. Selanjutnya, setelah perusahaan klien telah mendivestasi diri dari aset tertentu seperti menjadi tergantung pada pemasok. Pemasok dapat memanfaatkan ketergantungan ini dengan menaikkan tarif layanan.

Biaya Outsourcing Melebihi Manfaatnya

Outsourcing TI telah dikritik dengan alasan bahwa biaya tak terduga muncul dan manfaat yang diharapkan tidak terwujud. Salah satu alasan untuk ini adalah bahwa outsourcing klien sering gagal untuk mengantisipasi biaya seleksi pemasok, kontrak, dan transisi dari operasi TI pemasok.

Mengurangi Keamanan

Informasi outsourcing ke pemasok T menimbulkan pertanyaan yang unik dan serius mengenai pengendalian internal dan perlindungan data pribadi yang sensitif. Ketika sistem keuangan perusahaan dikembangkan dan diselenggarakan di luar, dan kode program dikembangkan melalui antarmuka dengan jaringan host perusahaan, perusahaan-perusahaan beresiko kehilangan pengendalian informasi mereka.

Kehilangan Keuntungan Strategis

Outsourcing TI dapat mempengaruhi ketidaksesuaian antara perencanaan strategis TI perusahaan dengan fungsi perencanaan bisnis. Organisasi yang menggunakan TI strategis harus menyelaraskan strategi bisnis dan strategi TI. Agar dapat menjalankan keselarasan tersebut, perusahaan perlu manajer dan kepala petugas informasi (CIO) yang memiliki pengetahuan TI yang kuat dari bisnis organisasi.

Untuk mencapai keselarasan seperti ini memerlukan hubungan kerja yang erat antara manajemen perusahaan dan manajemen TI dalam pengembangan bersamaan bisnis dan strategi TI. Namun, sulit untuk mencapainya ketika merencanakan TI lintas geografis. Selanjutnya, karena pembenaran keuangan untuk outsourcing TI tergantung pada skala ekonomi yang dicapai pemasok, dimana pemasok secara alami didorong untuk mencari solusi umum yang dapat digunakan oleh banyak klien daripada menciptakan solusi yang unik untuk masing-masing. Dasar dari outsourcing TI tidak konsisten dengan keuntungan strategis klien di pasar.

Implikasi Audit dari Outsourcing TI

Manajemen mungkin melakukan outsourcing fungsi TI organisasinya, tetapi tidak dapat mengoutsourcingtanggung jawab manajemen di bawah SOX untuk memastikan pengendalian intern TI memadai. PCAOB dalam Standar Auditing No 2 secara khusus menyatakan, "Penggunaan layanan sebuah organisasi tidak mengurangi tanggung jawab manajemen untuk mempertahankan pengendalian internal yang efektif atas pelaporan keuangan. Sebaliknya, manajemen pengguna harus mengevaluasi pengendalian di layanan organisasi, serta pengendalian terkait di perusahaan pengguna, ketika membuat penilaian  tentang pengendalian internal atas pelaporan keuangan.