Gambaran Umum SOX Bagian 302 dan 404 SOX tahun 2002 menetapkan peraturan dan standar tata kelola perusahaan baru untuk perusahaan publik yang terdaftar di Securities and Exchange Commission (SEC). Meskipun tindakan tersebut mengandung banyak bagian, bagian, bab ini dan dua bab berikut berkonsentrasi pada pengendalian pengendalian internal dan tanggung jawab audit sesuai dengan Bagian 302 dan 404. Bagian 302 mewajibkan manajemen perusahaan (termasuk chief executive officer [CEO]) untuk mengesahkan informasi keuangan dan informasi lainnya yang terdapat dalam laporan tahunan dan tahunan organisasi. Aturan tersebut juga mewajibkan mereka untuk mengesahkan pengendalian internal atas pelaporan keuangan. Petugas sertifikasi diharuskan untuk merancang pengendalian internal, atau membuat kontrol semacam itu dirancang, dan memberikan kepastian yang memadai mengenai keandalan proses pelaporan keuangan. Selanjutnya, mereka harus mengungkapkan mengungkapkan setiap perubahan material dalam pengendalian internal perusahaan yang telah terjadi selama kuartal fiskal terakhir. Bagian 404 mewajibkan manajemen perusahaan publik untuk menilai efektivitas pengendalian internal organisasi mereka atas pelaporan keuangan. Berdasarkan bagian tindakan ini, manajemen diharuskan memberikan laporan tahunan yang membahas membahas hal-hal berikut: 1. Jelaskan alur transaksi, termasuk aspek TI, dengan detail yang cukup untuk mengidentifikasi titik di mana salah saji bisa timbul. 2. Dengan menggunakan pendekatan berbasis risiko, tentukan baik disain dan efektivitas operasi pengendalian internal terpilih yang terkait dengan akun material. 3. Menilai potensi kecurangan dalam sistem dan mengevaluasi mengevaluasi kontrol yang dirancang untuk mencegah atau mendeteksi kecurangan. 4. Mengevaluasi dan menyimpulkan kecukupan pengendalian atas proses pelaporan laporan keuangan. 5. Evaluasi kontrol keseluruhan entitas (umum) yang sesuai dengan komponen kerangka Pernyataan Standar Auditing No. 78 (SAS 78) / COSO. Mengenai poin terakhir, SEC telah membuat referensi khusus untuk SAS 78 / COSO sebagai kerangka kontrol yang direkomendasikan. direkomendasikan. Selanjutnya, Standar Audit Pengawas Akuntansi Perusahaan (PCAOB) No. 5 mendukung penggunaan SAS 78 / COSO sebagai kerangka kerja untuk penilaian kontrol. Meskipun kerangka kerja lain yang sesuai telah diterbitkan, kerangka kerja apa pun yang digunakan harus mencakup semua tema umum COSO. Kami membahas elemen kunci kerangka SAS 78 / COSO di Bab 3. Fokus kami pada saat ini adalah pada kontrol TI (subset dari aktivitas pengendalian), yang sebelumnya tidak dibahas. Aspek kerangka SAS 78 / COSO ini digunakan untuk menyajikan masalah kontrol dan audit dalam bab ini dan dua bab berikut. HUBUNGAN ANTARA KONTROL TI DAN PELAPORAN KEUANGAN Teknologi informasi mendorong proses pelaporan keuangan organisasi modern. Sistem otomatis memulai, mengotorisasi, mencatat, dan melaporkan dampak dari transaksi keuangan. Dengan demikian, elemen-elemen tersebut tidak dapat dipisahkan dari proses pelaporan keuangan yang dianggap SOX dan harus dikendalikan. SAS 78 / COSO mengidentifikasi dua pengelompokan kontrol sistem informasi yang luas: kontrol aplikasi dan kontrol umum. Tujuan pengendalian aplikasi adalah untuk memastikan validitas, kelengkapan, dan keakuratan transaksi keuangan. Kontrol ini dirancang khusus untuk aplikasi. Contohnya meliputi:
Pencairan dana rutin penyeimbang kas yang memverifikasi bahwa total pembayaran ke vendor didamaikan dengan total pos ke buku besar pembantu piutang usaha. Prosedur penanggalan piutang piutang yang memvalidasi nomor rekening nasabah atas transaksi penjualan. Cek batas sistem penggajian yang mengidentifikasi catatan kartu waktu karyawan dengan jam kerja yang dilaporkan bekerja melebihi batas normal yang telah ditentukan.
Contoh-contoh Contoh-contoh ini i ni menggambarkan bagaimana kontrol aplikasi memiliki dampak langsung terhadap integritas data yang berhasil melalui berbagai sistem pemrosesan transaksi dan ke dalam proses pelaporan keuangan. Kontrol aplikasi diperiksa secara rinci pada Bab 17. Kelompok kontrol kedua yang diketahui SAS 78 / COSO mengidentifikasi adalah kontrol umum. Mereka diberi nama begitu karena tidak spesifik aplikasi tapi lebih tepatnya, berlaku untuk semua sistem. Kontrol umum memiliki nama lain dalam kerangka kerja lain, termasuk kontrol komputer umum dan kontrol teknologi informasi. Apapun nama yang digunakan, termasuk kontrol atas tata kelola TI, infrastruktur TI, keamanan dan akses ke sistem operasi dan database, akuisisi dan pengembangan pengembangan aplikasi, dan perubahan program. Sedangkan kontrol umum tidak mengendalikan transaksi tertentu, namun memiliki pengaruh terhadap integritas transaksi. Misalnya, pertimbangkan pertimbangkan sebuah organisasi dengan kontrol keamanan keamanan database yang buruk. Dalam situasi seperti ini, bahkan data yang diproses oleh sistem dengan kontrol aplikasi built-in yang memadai mungkin berisiko. Seseorang yang mampu menghindari keamanan database (baik secara langsung atau melalui program jahat) dapat mengubah, mencuri, atau merusak data transaksi yang tersimpan. Dengan demikian, kontrol umum diperlukan untuk mendukung berfungsinya kontrol aplikasi, dan keduanya diperlukan untuk memastikan memastikan pelaporan keuangan yang akurat. IMPLIKASI AUDIT BAGIAN 302 DAN 404 Materi yang tercakup dalam sisa bab ini dan bab-bab berikut mengasumsikan pemahaman dasar tentang proses audit. Secara khusus, pembaca harus:
Mampu membedakan antara fungsi atest dan assurance. Pahami konsep asertif manajemen dan kenali hubungan antara asersi dan tujuan audit. Kenali perbedaan antara tes kontrol dan tes substantif dan pahami hubungan di antara keduanya.
Lampiran pada bab ini berisi ikhtisar singkat tentang topik ini. Mereka yang kekurangan pengetahuan ini harus meninjau lampiran sebelum melanjutkan dengan bagian ini. Sebelum SOX, auditor eksternal tidak diharuskan untuk menguji pengendalian internal sebagai bagian dari fungsi pengesahannya. Mereka diharuskan untuk mengenal kontrol internal organisasi klien, namun memiliki pilihan untuk tidak bergantung pada mereka dan karena itu tidak melakukan tes kontrol. Audit bisa, dan sering dilakukan, di lakukan, oleh karena itu terutama terdiri dari tes substantif. Perundang-undangan SOX secara dramatis memperluas peran auditor eksternal dengan mewajibkan mereka untuk menilai penilaian manajemen terhadap pengendalian internal. Ini merupakan penerbitan opini audit terpisah di samping pendapat atas kewajaran laporan keuangan. keuangan. Standar opini audit baru ini tinggi. Memang, auditor dilarang mengeluarkan opini yang tidak wajar jika hanya satu kelemahan material dalam pengendalian pengendalian internal yang terdeteksi. Menariknya, auditor diijinkan diiji nkan untuk sekaligus memberikan pendapat yang memenuhi syarat mengenai penilaian manajemen terhadap pengendalian internal dan opini wajar tanpa pengecualian atas laporan keuangan. Dengan kata lain,
secara teknis mungkin bagi auditor untuk menemukan pengendalian internal atas pelaporan keuangan menjadi lemah, namun disimpulkan melalui pengujian substantif bahwa kelemahan tersebut tidak menyebabkan laporan keuangan menjadi salah secara material. Sebagai bagian dari tanggung jawab pengesahan baru, Standar PCAOB No. 5 secara khusus mengharuskan auditor memahami arus transaksi, termasuk kontrol yang berkaitan dengan bagaimana transaksi diinisiasi, disahkan, dicatat, dan dilaporkan. Ini melibatkan pertama memilih akun keuangan yang memiliki implikasi material untuk pelaporan keuangan. Kemudian, auditor perlu mengidentifikasi kontrol aplikasi yang terkait dengan akun tersebut. Seperti yang dicatat sebelumnya, keandalan kontrol aplikasi bergantung pada kontrol umum TI yang mendukungnya. Ini termasuk kontrol atas akses ke database, sistem operasi, dan jaringan. Jumlah kontrol ini, baik aplikasi dan umum, merupakan pengendalian internal yang relevan atas pelaporan keuangan yang perlu dikaji ulang. Gambar 15-1 mengilustrasikan hubungan kontrol TI ini. Kepatuhan terhadap Bagian 404 mewajibkan manajemen untuk memberikan kepada auditor eksternal bukti terdokumentasi tentang pengendalian fungsi yang terkait dengan akun material terpilih dalam laporannya mengenai efektivitas pengendalian. Fungsi audit internal organisasi atau kelompok SOX khusus kemungkinan akan melakukan tes ini. Oleh karena itu, manajemen harus benarbenar melakukan tes kontrolnya sendiri sebelum auditor melakukan kinerjanya. Gambar 15-1 Bagian 302 juga membawa implikasi auditor yang signifikan. Selain mengungkapkan pendapat mengenai efektivitas pengendalian internal, auditor memiliki tanggung jawab mengenai sertifikasi kuartalan manajemen internal oleh manajemen. Secara khusus, auditor harus melakukan prosedur berikut setiap tiga bulan untuk mengidentifikasi modifikasi material dalam kontrol atas pelaporan keuangan:
Manajemen wawancara mengenai adanya perubahan signifikan dalam perancangan atau pengoperasian pengendalian internal yang terjadi setelah audit tahunan sebelumnya atau tinjauan sebelumnya atas informasi keuangan sementara. Evaluasi implikasi salah saji yang diidentifikasi oleh auditor sebagai bagian dari tinjauan interim yang terkait dengan pengendalian internal yang efektif. Menentukan apakah perubahan dalam pengendalian internal cenderung mempengaruhi pengendalian internal atas pelaporan keuangan secara material.
Akhirnya, SOX menempatkan tanggung jawab pada auditor untuk mendeteksi aktivitas penipuan dan menekankan pentingnya kontrol yang dirancang untuk mencegah atau mendeteksi kecurangan yang dapat menyebabkan salah saji material atas laporan keuangan. Manajemen bertanggung jawab untuk menerapkan kontrol semacam itu, dan auditor secara tegas diminta untuk mengujinya. Karena komputer berada di jantung sistem pelaporan keuangan dan pelaporan organisasi modern, topik penipuan komputer termasuk dalam tanggung jawab manajemen dan audit yang diberlakukan oleh SOX. Bagian berikut membahas beberapa masalah penipuan komputer. Penipuan Komputer Kami melihat di Bab 3 bahwa perkiraan kerugian kecurangan untuk tahun 2008 melebihi $ 990 miliar. Berapa banyak yang bisa ditelusuri ke kecurangan komputer ini sulit untuk dikatakan. Salah satu alasan untuk ketidakpastian adalah bahwa kecurangan komputer tidak didefinisikan dengan baik. Misalnya, kita melihat di bagian etika Bab 3 bahwa beberapa orang menganggap menyalin perangkat lunak
komputer komersial menjadi tidak etis atau ilegal. Di sisi lain dari masalah ini, vendor perangkat lunak menganggap tindakan semacam itu sebagai kriminal. Terlepas dari seberapa sempit atau secara umum kecurangan komputer didefinisikan, ini adalah fenomena yang berkembang pesat. Untuk tujuan pembahasan kami, kecurangan komputer meliputi:
Pencurian, penyalahgunaan, atau penyalahgunaan aset dengan mengubah catatan dan file yang dapat dibaca komputer. Pencurian, penyalahgunaan, atau penyalahgunaan aset dengan mengubah logika perangkat lunak komputer. Pencurian atau penggunaan ilegal informasi yang dapat dibaca oleh komputer. Pencurian, korupsi, penyalinan ilegal, atau perusakan perangkat lunak komputer yang disengaja. Pencurian, penyalahgunaan, atau penyalahgunaan perangkat keras komputer.
Gambar 15-2 Model umum untuk sistem informasi akuntansi yang ditunjukkan pada Gambar 15-2 secara konseptual menggambarkan tahap kunci dari sebuah sistem informasi. Setiap tahap dalam pengumpulan data model, pengolahan data, pengelolaan basis data, dan generasi informasi merupakan area potensial risiko untuk jenis kecurangan komputer tertentu. Pada bagian ini kita hanya memeriksa risikonya; teknik kontrol khusus yang diperlukan untuk mengurangi risikonya dibahas nanti di bab ini dan di dua bab yang tersisa. PENGUMPULAN DATA. Pengumpulan data merupakan tahap operasional pertama dalam sistem informasi. Tujuan pengendaliannya adalah untuk memastikan bahwa data acara yang masuk dalam sistem valid, lengkap, dan bebas dari kesalahan material. Dalam banyak hal, ini adalah tahap terpenting dalam sistem. Jika transaksi yang keliru atau salah melewati pengumpulan data tidak terdeteksi, organisasi menanggung risiko bahwa sistem akan memproses transaksi dan akan berdampak pada laporan keuangan. Titik akses yang paling umum untuk melakukan kecurangan komputer ada pada tahap pengumpulan data. Penipuan jenis ini hanya membutuhkan sedikit atau tanpa keterampilan komputer dari pihak penipu, namun memerlukan kontrol yang dirancang dengan buruk. Pelaku hanya perlu memahami bagaimana sistem bekerja mengendalikan kelemahannya. Tindakan curang melibatkan memasukkan data yang dipalsukan ke dalam sistem. Ini mungkin melibatkan penghapusan, pengubahan, atau transaksi. Misalnya, untuk melakukan penipuan gaji, pelaku dapat memasukkan transaksi penggajian yang tidak benar bersamaan dengan transaksi sah lainnya. Jika tidak ada kontrol internal untuk mendeteksi penyisipan, sistem akan menghasilkan tambahan gaji untuk pelaku. Variasi jenis penipuan ini adalah mengubah bidang Jam Kerja dalam transaksi penggajian yang sah untuk meningkatkan jumlah gaji. Masih ada varian lain dalam penipuan ini adalah menguangkan uang tunai untuk membayar hutang palsu. Dengan memasukkan dokumen pendukung yang tidak benar (pesanan pembelian, laporan penerimaan, dan faktur pemasok) pada tahap pengumpulan data sistem hutang, pelaku dapat mengelabui sistem tersebut untuk membuat catatan hutang untuk pembelian yang tidak ada. Begitu catatan dibuat, sistem akan menganggapnya sah dan, pada tanggal jatuh tempo, akan membubarkan dana kepada pelaku untuk membayar kewajiban palsu. Sistem jaringan mengekspos organisasi untuk melakukan transaksi penipuan dari lokasi terpencil. Masquerading, piggybacking, dan hacking adalah contoh teknik penipuan semacam itu. Masquerading
melibatkan pelaku yang mendapatkan akses ke sistem dari lokasi terpencil dengan berpura-pura menjadi pengguna yang berwenang. Ini biasanya membutuhkan akses otorisasi terlebih dulu. Piggybacking adalah teknik di mana pelaku di lokasi terpencil mengetuk jalur telekomunikasi dan memasukkannya ke pengguna yang berwenang yang masuk ke sistem. Begitu masuk dalam sistem, pelaku bisa menyamar sebagai pengguna yang berwenang. Hacking mungkin melibatkan teknik piggybacking atau masquerading. Hacker dibedakan dari penjahat komputer lainnya karena motif mereka biasanya tidak menipu untuk keuntungan finansial. Lebih sering mereka termotivasi oleh tantangan untuk masuk ke sistem daripada pencurian aset. Namun demikian, hacker telah menyebabkan kerusakan dan kerugian yang besar pada organisasi dengan menghancurkan dan merusak data perusahaan. PENGOLAHAN DATA. Setelah terkumpul, data biasanya membutuhkan pengolahan untuk menghasilkan informasi. Tugas dalam pengolahan data mencakup algoritma matematis (seperti model pemrograman linier) yang digunakan untuk aplikasi penjadwalan produksi, teknik statistik untuk peramalan penjualan, dan pembuatan laporan dan ringkasan yang digunakan untuk aplikasi akuntansi. Kecurangan pengolahan data terbagi dalam dua kelas: penipuan program dan kecurangan operasi. Kecurangan program mencakup teknik berikut: (1) membuat program ilegal yang dapat mengakses
file data untuk mengubah, menghapus, atau memasukkan nilai ke dalam catatan akuntansi; (2) menghancurkan atau merusak logika program menggunakan virus komputer; atau (3) mengubah logika program sehingga aplikasi memproses data secara tidak benar. Misalnya, program yang digunakan bank untuk menghitung bunga pada akun pelanggannya biasanya akan menghasilkan kesalahan pembulatan karena ketepatan perhitungan bunga lebih besar daripada ketepatan pelaporan. Oleh karena itu, angka minat yang dihitung ke beberapa desimal menghasilkan nilai hingga sepersekian sen sen dan harus dibulatkan ke angka keseluruhan untuk tujuan pelaporan. Program perhitungan bunga biasanya memiliki rutin pembulatan standar untuk melacak kesalahan pembulatan sehingga total biaya bunga ke bank sama dengan jumlah kredit individual. Ini melibatkan penempatan sementara jumlah pecahan yang tersisa dari setiap perhitungan dalam akumulator memori internal. Bila jumlah akumulator mencapai satu sen (plus atau minus), maka jumlah penny akan ditambahkan ke akun pelanggan tertentu yang sedang diproses pada saat itu. Dengan kata lain, satu sen ditambahkan ke (atau dikurangkan dari) akun pelanggan secara acak. Suatu bentuk kecurangan program yang disebut penipuan salami melibatkan modifikasi logika pembulatan program sehingga tidak lagi menambahkan satu sen secara acak. Sebagai gantinya, program yang dimodifikasi selalu menambahkan angka plus ke akun pelaku, namun masih menambahkan minus sen secara acak. Hal ini dapat mengalihkan sejumlah uang ke pelaku, namun catatan akuntansi tetap seimbang untuk menyembunyikan kejahatan tersebut. Kecurangan operasi adalah penyalahgunaan atau pencurian sumber daya komputer perusahaan. Hal
ini sering melibatkan penggunaan komputer untuk melakukan bisnis pribadi. Sebagai contoh, seorang programmer dapat menggunakan komputer perusahaan waktu untuk menulis perangkat lunak yang ia jual secara komersial. BPA di kantor pengawas dapat menggunakan komputer perusahaan untuk menyiapkan laporan pajak dan laporan keuangan untuk klien pribadinya. Demikian pula, pengacara perusahaan dengan praktik pribadi di samping dapat menggunakan komputer perusahaan untuk mencari kasus pengadilan dan keputusan dalam basis data komersial. Biaya untuk mengakses database dibebankan ke organisasi dan disembunyikan di antara biaya sah lainnya. MANAJEMEN DATABASE. Database organisasi adalah gudang fisik untuk data keuangan dan non finansial. Kecurangan pengelolaan basis data mencakup mengubah, menghapus, merusak, menghancurkan, atau mencuri data organisasi. Karena akses ke file database merupakan elemen
penting dari kecurangan ini, hal ini sering dikaitkan dengan penipuan transaksi atau program. Teknik penipuan yang umum adalah dengan mengakses database dari situs remote dan mencari file untuk mendapatkan informasi bermanfaat yang dapat disalin dan dijual ke pesaing. Karyawan yang tidak puas telah diketahui menghancurkan file data perusahaan hanya untuk membahayakan organisasi. Salah satu caranya adalah memasukkan rutinitas destruktif yang disebut logika bom ke dalam sebuah program. Pada waktu tertentu, atau saat kondisi tertentu terpenuhi, bom logika menghapus file data yang diakses oleh program. Misalnya, programmer yang tidak puas yang sedang mempertimbangkan untuk meninggalkan sebuah organisasi memasukkan bom logika ke dalam sistem penggajian. Beberapa minggu kemudian ketika sistem mendeteksi bahwa nama pemrogram telah dihapus dari file penggajian, bom logika diaktifkan dan menghapus keseluruhan file penggajian. GENERASI INFORMASI Generasi informasi adalah proses penyusunan, penyusunan, pemformatan, dan penyajian informasi kepada pengguna. Informasi bisa berupa dokumen operasional seperti sales order, laporan yang dikirim ke layar komputer, atau laporan keuangan yang diterbitkan. Bentuk umum kecurangan komputer di tahap pembangkitan informasi adalah mencuri, menyalahgunakan, atau menyalahgunakan keluaran komputer. Satu teknik rendah namun efektif yang disebut pemulungan melibatkan pencarian melalui tempat sampah dari pusat komputer untuk keluaran yang dibuang. Dengan demikian, pelaku dapat memperoleh informasi yang berguna dari laporan hard copy yang ditolak selama pemrosesan. Terkadang laporan keluaran yang tidak sejajar di atas kertas atau sedikit kacau saat dicetak akan dibuang ke tempat sampah. Bentuk lain dari kecurangan yang disebut menguping meliputi mendengarkan transmisi output melalui jalur telekomunikasi. Teknologi tersedia sehingga memungkinkan pelaku mencegat pesan yang dikirim melalui saluran telepon tanpa kabel dan saluran microwave. Sebagian besar ahli sepakat bahwa praktis tidak mungkin mencegah pelaku yang bertekad mengakses saluran komunikasi data. Enkripsi data, bagaimanapun, dapat membuat data yang tidak berguna diambil dengan cara ini. Dengan latar belakang ini, adegan diatur untuk melihat teknik kontrol dan tes kontrol yang mungkin diperlukan di bawah SOX. Standar Audit Auditor PCAOB No. 5 menekankan bahwa manajemen dan auditor menggunakan pendekatan berbasis risiko dan bukan pendekatan satu ukuran sesuai untuk disain dan penilaian kontrol. Dengan kata lain, ukuran dan kompleksitas organisasi perlu dipertimbangkan dalam menentukan sifat dan tingkat kontrol yang diperlukan. Pembaca harus mengenali, oleh karena itu, bahwa kontrol yang disajikan dalam sisa bab ini dan dalam dua bab berikut ini menggambarkan kebutuhan sebuah organisasi generik dan mungkin tidak berlaku dalam situasi tertentu. Kontrol Tata Kelola TI
Tata kelola TI adalah konsep yang luas yang berkaitan dengan hak keputusan dan akuntabilitas untuk mendorong perilaku yang diinginkan dalam penggunaan TI. Meskipun penting, tidak semua elemen tata kelola TI berhubungan secara khusus untuk mengendalikan masalah yang menjadi alamat SOX dan yang diuraikan dalam kerangka COSO. Dalam bab ini, kami mempertimbangkan tiga masalah tata kelola yang dilakukan: struktur organisasi fungsi TI, operasi komputer, dan perencanaan pemulihan bencana. Diskusi mengenai masing-masing masalah tata kelola ini dimulai dengan penjelasan tentang sifat risiko dan deskripsi kontrol yang diperlukan untuk mengurangi risiko. Kemudian, tujuan audit disajikan. Ini menetapkan apa yang perlu diverifikasi mengenai fungsi kontrol di tempat. Akhirnya, contoh tes kontrol ditawarkan yang menjelaskan bagaimana auditor dapat mengumpulkan bukti untuk memenuhi tujuan audit. Tujuan pengendalian dan tes terkait ini dapat dilakukan oleh auditor internal
yang memberikan bukti kepatuhan manajemen terhadap SOX atau oleh auditor eksternal sebagai bagian dari fungsi penyokohan mereka. Dalam hal ini, kita tidak membedakan kedua peran tersebut. Struktur Organisasi Pengendalian Bab-bab sebelumnya telah menekankan pentingnya memisahkan tugas yang tidak sesuai dalam aktivitas manual. Secara khusus, tugas operasional harus dipisahkan menjadi:
Pisahkan tugas otorisasi transaksi dari proses transaksi. Pisahkan pencatatan dari penitipan aset. Bagilah tugas pemrosesan transaksi di antara individu sehingga kecurangan akan membutuhkan kolusi antara dua orang atau lebih.
Kecenderungan dalam lingkungan TI adalah mengkonsolidasikan kegiatan. Aplikasi tunggal dapat memberi otorisasi, memproses, dan mencatat semua aspek transaksi. Dengan demikian, fokus kontrol segregasi bergeser dari tingkat operasional (tugas pemrosesan transaksi yang dilakukan program komputer sekarang) ke hubungan organisasi tingkat tinggi dalam fungsi TI. Keterkaitan antara pengembangan sistem, pemeliharaan aplikasi, administrasi database, dan aktivitas operasi komputer menjadi perhatian khusus. Bagian berikut membahas masalah pengendalian organisasi dalam konteks dua model generik - model terpusat dan model terdistribusi. Untuk tujuan diskusi, ini disajikan sebagai struktur alternatif; Dalam praktiknya, lingkungan TI kebanyakan perusahaan memiliki unsur-unsur keduanya. SEGREGASI TUGAS DI DALAM PERUSAHAAN TENGAH Gambar 15-3 menyajikan bagan organisasi fungsi TI terpusat. Bagan organisasi serupa disajikan pada Bab 1 untuk memberikan dasar untuk membahas tugas-tugas TI. Ini dikaji ulang di sini untuk mempelajari tujuan pengendalian di balik pemisahan tugas-tugas ini. Jika posisi yang ditunjukkan dalam tabel ini tidak umum, Anda harus meninjau bagian yang relevan di Bab 1 sebelum melanjutkan. Memisahkan Pengembangan Sistem dari Operasi Komputer Pemisahan pengembangan sistem (baik pengembangan dan pemeliharaan sistem baru) dan kegiatan operasi sangat penting. Tanggung jawab kelompok ini seharusnya tidak digabungkan. Profesional pengembangan dan pemeliharaan sistem diperoleh (oleh pengembangan dan pembelian di dalam rumah) dan memelihara sistem bagi pengguna. Staf operasi harus menjalankan sistem ini dan tidak terlibat dalam disain dan implementasinya. Mengkonsolidasikan fungsi ini mengundang kecurangan. Dengan pengetahuan rinci tentang parameter logika dan kontrol aplikasi beserta akses ke operasi komputer, seseorang dapat membuat perubahan yang tidak sah terhadap logika aplikasi selama eksekusi. Perubahan semacam itu mungkin bersifat sementara (on the fly) dan akan hilang dengan sedikit atau tanpa jejak saat aplikasi berakhir. Gambar 15-3 Memisahkan Administrator Database dari Fungsi Lain Kontrol organisasi penting lainnya adalah pemisahan fungsi administrator database (DBA) dari fungsi TI lainnya. DBA bertanggung jawab atas sejumlah tugas penting yang berkaitan dengan keamanan database, termasuk membuat skema database, menciptakan tampilan pengguna (subschemas), memberikan wewenang akses kepada pengguna, memantau penggunaan database, dan merencanakan perluasan di masa depan. Mendelegasikan tanggung jawab ini kepada orang lain yang melakukan tugas yang tidak sesuai mengancam integritas database. Gambar 15-3 menunjukkan bagaimana fungsi DBA independen secara organisasi.
MEMPELAJARI DBA DARI PEMBANGUNAN SISTEM.
Pemrogram membuat aplikasi yang mengakses,
memperbarui, dan mengambil data dari database. Bab 9 mengilustrasikan bagaimana kontrol akses basis data dicapai melalui pembuatan tampilan pengguna, yang merupakan tanggung jawab DBA. Untuk mencapai akses database, oleh karena itu, baik programmer maupun DBA perlu menyetujui atribut dan tabel (tampilan pengguna) untuk menyediakan aplikasi (atau pengguna) yang bersangkutan. Jika dilakukan dengan benar, ini memungkinkan dan memerlukan tinjauan formal terhadap kebutuhan data pengguna dan masalah keamanan seputar permintaan tersebut. Menugaskan tanggung jawab untuk definisi pandangan pengguna kepada individu dengan tanggung jawab pemrograman menghilangkan kebutuhan ini untuk mencari persetujuan dan dengan demikian secara efektif mengikis kontrol akses ke DBMS.
Memisahkan Sistem Baru Pembangunan dari Pemeliharaan Beberapa perusahaan mengatur fungsi pengembangan sistem mereka menjadi dua kelompok: analisis dan pemrograman sistem. Alternatif organisasi ini disajikan pada Gambar 15-4. Kelompok analisis sistem bekerja dengan pengguna untuk menghasilkan perancangan detil sistem baru. Kelompok pemrograman mengkodekan program sesuai dengan spesifikasi desain ini. Dengan pendekatan ini, pemrogram yang mengkode program asli juga mempertahankannya selama fase pemeliharaan siklus pengembangan sistem. Meskipun pengaturan yang populer, pendekatan ini mempromosikan dua masalah potensial: dokumentasi dan kecurangan yang tidak memadai. Dokumentasi sistem yang berkualitas buruk adalah masalah TI yang kronis dan tantangan yang signifikan bagi banyak organisasi yang menginginkan kepatuhan SOX. Setidaknya ada dua penjelasan untuk fenomena ini. Pertama, mendokumentasikan sistem tidak semenarik merancang, menguji, dan menerapkannya. Profesional sistem lebih memilih untuk beralih ke proyek baru yang menarik daripada dokumen yang baru saja selesai. Alasan kedua untuk dokumentasi yang buruk adalah keamanan kerja. Ketika sebuah sistem didokumentasikan dengan buruk, sulit untuk menafsirkan, menguji, dan melakukan debug. Oleh karena itu, pemrogram yang memahami sistem (orang yang mengodeinya) mempertahankan kekuatan tawar menawar dan menjadi sangat diperlukan. Ketika programmer meninggalkan perusahaan, seorang programmer baru mewarisi tanggung jawab pemeliharaan terhadap sistem yang tidak terdokumentasi. Bergantung pada kompleksitasnya, masa transisi mungkin panjang dan mahal. DOKUMENTASI YANG TIDAK SESUAI.
Gambar 15-4 PROGRAM PENIPUAN. Bila pemrogram asli dari suatu sistem juga diberi tanggung jawab pemeliharaan, potensi penipuan meningkat. Kecurangan program melibatkan perubahan yang tidak sah pada modul program untuk tujuan melakukan tindakan ilegal. Pemrogram asli mungkin telah berhasil menyembunyikan kode palsu di antara ribuan baris kode yang sah dan ratusan modul yang membentuk sebuah sistem. Agar kecurangan berhasil, programmer harus bisa mengendalikan situasi melalui akses eksklusif dan tidak terbatas ke program aplikasi. Pemrogram perlu melindungi kode palsu dari deteksi yang tidak disengaja oleh pemrogram lain yang melakukan perawatan atau oleh auditor yang menguji kontrol aplikasi. Oleh karena itu, memiliki tanggung jawab penuh untuk pemeliharaan merupakan elemen penting dalam skema pemrogram duplikat. Melalui otoritas pemeliharaan ini, pemrogram dapat dengan bebas mengakses sistem, menonaktifkan kode penipuan selama audit dan kemudian mengembalikan kode saat pantai menjadi jelas. Penipuan semacam ini bisa berlanjut bertahun-tahun tanpa deteksi.
Struktur Unggulan untuk Pengembangan Sistem Gambar 15-3 menyajikan struktur organisasi yang unggul dimana fungsi pengembangan sistem dipisahkan menjadi dua kelompok independen: pengembangan sistem dan pemeliharaan sistem baru. Kelompok pengembangan sistem baru bertanggung jawab untuk merancang, memprogram, dan mengimplementasikan proyek sistem baru. Setelah berhasil diimplementasikan, tanggung jawab atas pemeliharaan berkelanjutan sistem ini sampai pada kelompok pemeliharaan sistem. Struktur ini membantu menyelesaikan dua masalah kontrol yang dijelaskan sebelumnya. Pertama, standar dokumentasi ditingkatkan karena kelompok pemeliharaan memerlukan dokumentasi yang memadai untuk melaksanakan tugas perawatan mereka. Tanpa dokumentasi lengkap, transfer formal tanggung jawab sistem dari pengembangan sistem baru ke pemeliharaan sistem tidak dapat terjadi. Kedua, menolak akses programmer asli masa depan untuk kode aplikasi menghalangi penipuan program. Kode penipuan dalam sebuah aplikasi, yang berada di luar kendali pelaku, meningkatkan risiko bahwa kecurangan akan ditemukan. Keberhasilan pengendalian ini bergantung pada adanya kontrol lain yang membatasi, mencegah, dan mendeteksi akses yang tidak sah terhadap program seperti kontrol perpustakaan program sumber yang dibahas di Bab 17. Sedangkan pemisahan organisasi saja tidak dapat menjamin bahwa kecurangan komputer tidak akan terjadi, namun penting untuk menciptakan lingkungan pengendalian yang diperlukan. MODEL DISTRIBUSI Bab 1 memeriksa dampak pada struktur organisasi yang beralih ke model pemrosesan data terdistribusi (DDP) di mana departemen pengguna akhir mengendalikan layanan TI. Efek dari ini adalah mengkonsolidasikan beberapa fungsi komputer yang secara tradisional dipisahkan dan untuk mendistribusikan beberapa aktivitas yang dikonsolidasikan di bawah model terpusat. Terlepas dari banyaknya kelebihan yang DDP berikan, pendekatan ini membawa implikasi pengendalian TI yang harus diakui oleh manajemen dan akuntan. Ini dibahas pada bagian berikut. Ketidakcocokan Mendistribusikan tanggung jawab untuk pembelian perangkat lunak dan perangkat keras dapat mengakibatkan keputusan yang tidak terkoordinasi dan kurang dipahami. Pengguna organisasi, yang bekerja secara independen, dapat memilih sistem operasi yang berbeda dan tidak kompatibel, platform teknologi, spreadsheet, pengolah kata, dan paket database, yang dapat mengganggu komunikasi internal. Redundansi Aktivitas pengembangan sistem otonom di seluruh perusahaan dapat menghasilkan penciptaan aplikasi dan database yang berlebihan. Program yang dibuat oleh satu pengguna yang dapat digunakan dengan sedikit atau tanpa perubahan oleh orang lain akan didesain ulang dari awal dan bukan dibagikan. Demikian juga, data yang umum bagi banyak pengguna dapat diproduksi ulang, menghasilkan tingkat redundansi data yang tinggi. Mengkonsolidasikan kegiatan yang tidak sesuai Redistribusi fungsi TI ke area pengguna dapat menghasilkan banyak unit yang sangat kecil. Mencapai pemisahan tugas yang memadai mungkin tidak layak secara ekonomi atau operasional dalam situasi ini. Dengan demikian, satu orang (atau kelompok kecil) mungkin bertanggung jawab atas pengembangan program, pemeliharaan program, dan operasi komputer.
Mendapatkan Profesional Berkualitas Pengguna akhir biasanya tidak memenuhi syarat untuk mengevaluasi kredensial teknis dan pengalaman yang relevan dari calon karyawan TI. Juga, karena unit organisasi yang menjadi kandidat kandidat ini kecil, peluang untuk pertumbuhan pribadi, pendidikan berkelanjutan, dan promosi terbatas. Untuk alasan ini, unit TI yang terdistribusi mungkin mengalami kesulitan untuk menarik personil berkualifikasi tinggi. Kurangnya Standar Untuk alasan yang disebutkan di atas, standar untuk pengembangan sistem, dokumentasi, dan penilaian kinerja cenderung tidak merata diterapkan atau tidak ada di lingkungan terdistribusi. MENCIPTAKAN FUNGSI TI PERUSAHAAN Model yang sepenuhnya terpusat dan terdistribusi sepenuhnya mewakili posisi ekstrim pada rangkaian alternatif struktural. Kebutuhan kebanyakan perusahaan berada di antara titik akhir ini. Bagi perusahaan-perusahaan ini, masalah kontrol yang terkait dengan DDP dapat, sampai batas tertentu, dapat diatasi dengan menerapkan fungsi TI perusahaan. Gambar 15-5 menggambarkan pendekatan organisasi ini. Fungsi TI perusahaan adalah unit yang lebih ramping dengan misi yang berbeda daripada fungsi TI terpusat yang ditunjukkan pada Gambar 15-4. Kelompok ini memberikan saran dan keahlian teknis untuk berbagai fungsi TI terdistribusi, sebagaimana garis putus-putus ditunjukkan pada Gambar 15-5. Beberapa layanan pendukung yang diberikan dijelaskan pada bagian berikut. Pengujian Pusat Perangkat Lunak dan Perangkat Lunak Komersial Kelompok TI perusahaan lebih mampu mengevaluasi kelebihan perangkat lunak dan perangkat keras vendor yang bersaing. Kelompok sentral yang secara teknis cerdik seperti ini dapat mengevaluasi fitur, kontrol, dan kompatibilitas sistem dengan standar industri dan organisasi yang paling efisien. Setelah melakukan pengujian, mereka dapat membuat rekomendasi ke area pengguna untuk memandu keputusan akuisisi. Layanan Pengguna Fitur berharga dari grup perusahaan adalah fungsi layanan penggunanya. Kegiatan ini memberikan bantuan teknis kepada pengguna selama pemasangan perangkat lunak baru dan dalam mengatasi masalah masalah perangkat keras dan perangkat lunak. Pembuatan papan buletin elektronik untuk pengguna adalah cara terbaik untuk mendistribusikan informasi tentang masalah umum dan memungkinkan berbagi program yang dikembangkan pengguna dengan orang lain di organisasi. Staf layanan pengguna sering mengajarkan kursus teknis untuk pengguna akhir, yang meningkatkan tingkat kesadaran pengguna dan mendorong berlakunya pendidikan tenaga teknis. Standard-Setting Body Menetapkan panduan pusat dapat memperbaiki lingkungan kontrol yang relatif buruk yang umum terjadi pada model terdistribusi. Kelompok perusahaan dapat menetapkan dan mendistribusikan ke area pengguna standar yang sesuai untuk pengembangan, pemrograman, dan dokumentasi sistem yang sesuai dengan persyaratan SOX.
Ulasan personalia Kelompok perusahaan lebih siap daripada pengguna untuk mengevaluasi kredensial teknis profesional sistem prospektif. Meskipun calon karyawan TI akan bekerja untuk kelompok pengguna terdistribusi, keterlibatan kelompok perusahaan dalam mengambil keputusan dapat memberikan layanan yang berharga bagi organisasi. Gambar 15-5 TUJUAN AUDIT YANG BERKAITAN DENGAN STRUKTUR ORGANISASI Tujuan auditor adalah untuk memverifikasi bahwa individu-individu di daerah yang tidak sesuai dipisahkan sesuai dengan tingkat risiko potensial dan dengan cara yang mempromosikan lingkungan kerja. Ini adalah lingkungan di mana hubungan formal, daripada santai, harus ada antara tugas yang tidak sesuai. PROSEDUR AUDIT YANG BERKAITAN DENGAN STRUKTUR ORGANISASI Tes kontrol berikut akan memungkinkan auditor mencapai tujuan pengendalian.
Dapatkan dan tinjau kembali kebijakan perusahaan tentang keamanan komputer. Verifikasi bahwa kebijakan keamanan dikomunikasikan ke karyawan dan supervisor yang bertanggung jawab. Tinjaulah dokumentasi yang relevan, termasuk bagan organisasi saat ini, pernyataan misi, dan uraian tugas untuk fungsi utama, untuk menentukan apakah individu atau kelompok melakukan fungsi yang tidak sesuai. Meninjau dokumentasi sistem dan catatan pemeliharaan untuk contoh aplikasi. Verifikasi bahwa pemrogram pemeliharaan yang ditugaskan untuk proyek tertentu juga bukan programmer desain asli. Melalui pengamatan, tentukan bahwa kebijakan segregasi sedang diikuti dalam praktik. Tinjau log akses ruang operasi untuk menentukan apakah pemrogram memasukkan fasilitas tersebut dengan alasan selain kegagalan sistem. Tinjau kembali hak dan hak pengguna untuk memverifikasi bahwa pemrogram memiliki hak akses yang sesuai dengan uraian tugas mereka.
Keamanan dan Kontrol Pusat Komputer Kebakaran, banjir, angin, sabotase, gempa bumi, atau bahkan pemadaman listrik dapat menghilangkan sebuah organisasi fasilitas pengolahan data dan menghentikan fungsi yang dilakukan atau dibantu oleh komputer. Meskipun kemungkinan kejadian bencana semacam itu jauh, konsekuensinya bagi organisasi bisa menjadi serius. Jika terjadi bencana, organisasi tidak hanya kehilangan investasinya di fasilitas pengolahan data, namun yang lebih penting, juga kehilangan kemampuannya untuk berbisnis. Tujuan dari bagian ini adalah untuk menyajikan kontrol pusat komputer yang membantu menciptakan lingkungan yang aman. Kita akan mulai dengan melihat kontrol yang dirancang untuk mencegah dan mendeteksi ancaman ke pusat komputer. Namun, tidak peduli berapa banyak yang diinvestasikan dalam kendali, beberapa bencana tidak dapat diantisipasi dan dicegah. Apa yang dilakukan perusahaan untuk mempersiapkan diri menghadapi acara semacam itu? Bagaimana itu akan pulih? Pertanyaan-pertanyaan ini merupakan inti dari rencana pemulihan bencana organisasi. Bagian
selanjutnya membahas secara khusus masalah-masalah yang berkaitan dengan pengembangan rencana pemulihan bencana. KONTROL PUSAT KOMPUTER Kelemahan dalam keamanan pusat komputer berpotensi berdampak pada fungsi pengendalian aplikasi terkait dengan proses pelaporan keuangan. Oleh karena itu, lingkungan fisik ini merupakan masalah kontrol untuk kepatuhan SOX. Berikut adalah beberapa fitur kontrol yang berkontribusi langsung pada keamanan pusat komputer. Lokasi fisik Lokasi fisik yang dipilih untuk pusat komputer dapat mempengaruhi risiko bencana. Sedapat mungkin, pusat komputer harus berada jauh dari bahaya buatan manusia dan alam, seperti pabrik pengolahan, sumber listrik gas dan air, bandara, daerah dengan tingkat kejahatan tinggi, dataran banjir, dan kesalahan geologi. Konstruksi Idealnya, pusat komputer harus ditempatkan di gedung berlantai satu konstruksi padat dengan akses terkontrol (dibahas pada bagian berikut). Utilitas (tenaga dan telepon) dan jalur komunikasi harus berada di bawah tanah. Jendela bangunan tidak boleh dibuka. Sistem penyaringan udara harus berada di tempat yang mampu menyingkirkan serbuk sari, debu, dan tungau debu. Mengakses Akses ke pusat komputer harus dibatasi oleh operator dan karyawan lain yang bekerja di sana. Pemrogram dan analis yang kadang-kadang perlu memperbaiki kesalahan program harus diminta masuk dan keluar. Pusat komputer harus menyimpan catatan akurat dari semua kejadian tersebut untuk memverifikasi fungsi kontrol akses. Pintu masuk utama ke pusat komputer harus melalui satu pintu saja, meski ada alarm darurat dengan alarm. Untuk mencapai tingkat keamanan yang lebih tinggi, kamera sirkuit tertutup dan sistem perekaman video harus memantau akses. AC Komputer berfungsi paling baik di lingkungan ber-AC. Untuk komputer mainframe, menyediakan AC yang memadai sering merupakan persyaratan garansi vendor. Komputer beroperasi paling baik pada kisaran suhu 70 sampai 75 derajat Fahrenheit dan kelembaban relatif 50 persen. Kesalahan logika dapat terjadi pada perangkat keras komputer saat suhu berangkat secara signifikan dari kisaran ini. Juga, risiko kerusakan rangkaian dari listrik statis meningkat saat kelembaban turun. Kelembaban tinggi, di sisi lain, dapat menyebabkan jamur tumbuh dan produk kertas (seperti dokumen sumber) hingga peralatan membengkak dan selai. Pemadam kebakaran Ancaman yang paling umum terhadap peralatan komputer perusahaan adalah kebakaran. Setengah dari perusahaan yang mengalami kebakaran gulung tikar karena kehilangan catatan kritis, seperti piutang usaha. Penerapan sistem pemadaman kebakaran yang efektif memerlukan konsultasi dengan spesialis. Beberapa fitur utama dari sistem seperti itu tercantum di bagian berikut. 1. Alarm otomatis dan manual harus ditempatkan di lokasi strategis di sekitar instalasi. Alarm ini harus dihubungkan ke stasiun pemadam kebakaran permanen.
2. Harus ada sistem pemadam kebakaran otomatis yang mengeluarkan jenis penekan (karbon dioksida atau halon) yang sesuai untuk lokasi tersebut. Misalnya, penyemprotan air dan bahan kimia tertentu di komputer bisa melakukan kerusakan sebanyak api. 3. Harus ada pemadam api manual yang ditempatkan di lokasi strategis. 4. Bangunan itu harus konstruksi yang bagus untuk menahan kerusakan air yang menyebabkan peralatan pemadam kebakaran. 5. Pintu keluar api harus ditandai dengan jelas dan diterangi saat terjadi kebakaran. Toleransi Toleransi Toleransi Toleransi kesalahan adalah kemampuan sistem untuk melanjutkan operasinya saat bagian dari sistem gagal karena kegagalan perangkat keras, kesalahan program aplikasi, atau kesalahan operator. Menerapkan komponen sistem yang berlebihan dapat mencapai berbagai tingkat toleransi kesalahan. Redundant disk dan power supplies adalah dua contoh umum. Array redundant disk independen (RAID) melibatkan penggunaan disk paralel yang mengandung elemen data dan aplikasi yang berlebihan. Jika satu disk gagal, data yang hilang secara otomatis direkonstruksi dari komponen berlebihan yang tersimpan pada disk lainnya. Uninterruptible power supplies membantu mencegah kehilangan data dan korupsi sistem. Jika terjadi kegagalan pasokan listrik, daya cadangan jangka pendek disediakan agar sistem dapat ditutup dengan cara yang terkendali. Menerapkan kontrol toleransi kesalahan memastikan bahwa tidak ada satu titik kegagalan sistem potensial. Kegagalan total hanya bisa terjadi jika terjadi kegagalan beberapa komponen.
Audit Objectives Relating to Computer Center Security The auditor’s objective is to evaluate the controls governing computer center security. Specifically,
the auditor must verify that (1) physical security controls are adequate to reasonably protect the organization from physical exposures; (2) insurance coverage on equipment is adequate to compensate the organization for the destruction of, or damage to, its computer center; and (3) operator documentation is adequate to deal with routine operations as well as system failures. Prosedur Audit untuk Menilai Kontrol Keamanan Fisik Berikut ini adalah tes kontrol keamanan fisik. UJI KONSTRUKSI FISIK. Auditor harus memperoleh rencana arsitektural untuk menentukan bahwa pusat komputer kokoh terbuat dari bahan tahan api. Harus ada drainase yang memadai di bawah lantai yang terangkat agar air mengalir jika terjadi kerusakan air dari api di lantai atas atau dari sumber lain. Selain itu, auditor harus menilai lokasi fisik pusat komputer. Fasilitas ini harus ditempatkan di area yang meminimalkan keterpaparannya terhadap kebakaran, kerusuhan sipil, dan bahaya lainnya. UJI SISTEM DETEKSI KEBAKARAN. Auditor harus menetapkan alat deteksi kebakaran dan penindasan, baik manual maupun otomatis, ada di tempat dan diuji secara berkala. Sistem deteksi kebakaran harus mendeteksi asap, panas, dan asap yang mudah terbakar. Buktinya dapat diperoleh dengan meninjau catatan tes api resmi dari tes yang disimpan di pusat komputer. UJI PENGENDALIAN AKSES Auditor harus menetapkan bahwa akses rutin ke pusat komputer dibatasi pada pegawai yang berwenang. Rincian tentang akses pengunjung (oleh pemrogram dan lainnya), seperti waktu kedatangan dan keberangkatan, tujuan, dan frekuensi akses, dapat diperoleh dengan meninjau log akses. Untuk menetapkan kebenaran dokumen ini, auditor dapat secara diam-diam mengamati proses dimana akses diizinkan.
Pengujian Toleransi Toleransi Toleransi SERANGAN. Banyak konfigurasi RAID menyediakan pemetaan grafis dari penyimpanan disk mereka yang berlebihan. Dari pemetaan ini, auditor harus menentukan apakah tingkat RAID yang ada memadai untuk organisasi, mengingat tingkat risiko bisnis yang terkait dengan kegagalan disk. Jika organisasi tidak menggunakan RAID, potensi satu titik kegagalan sistem ada. Auditor harus meninjau ulang dengan prosedur alternatif administrator sistem untuk pemulihan dari kegagalan disk. Cadangan bahan bakar. Auditor harus melakukan verifikasi dari catatan uji bahwa personil pusat komputer melakukan tes berkala terhadap catu daya cadangan untuk memastikan bahwa ia memiliki kapasitas yang cukup untuk menjalankan komputer dan penyejuk udara. Tes penting ini dan hasilnya harus dicatat secara formal. Prosedur Audit untuk Memeriksa Cakupan Asuransi Auditor setiap tahun harus meninjau cakupan asuransi organisasi di perangkat keras komputer, peralatan lunak, dan fasilitas fisiknya. Auditor harus memverifikasi bahwa semua akuisisi baru tercantum pada polis dan peralatan dan perangkat usang telah dihapus. Polis asuransi harus mencerminkan kebutuhan manajemen dalam hal cakupan. Misalnya, perusahaan mungkin ingin diasuransikan sebagian dan memerlukan pertanggungan minimum. Di sisi lain, perusahaan dapat mencari cakupan biaya penggantian yang lengkap. Prosedur Audit untuk Memeriksa Kecukupan Dokumentasi Operator Operator komputer menggunakan dokumentasi yang disebut run manual untuk menjalankan aspekaspek tertentu dari sistem. Secara khusus, sistem batch yang besar seringkali memerlukan perhatian khusus dari operator. Sepanjang hari, operator komputer dapat melakukan puluhan program komputer yang masing-masing memproses beberapa file dan menghasilkan banyak laporan. Untuk mencapai operasi pengolahan data yang efektif, manual yang dijalankan harus cukup rinci untuk memandu operator dalam tugas mereka. Auditor harus meninjau manual yang dijalankan untuk kelengkapan dan akurasi. Isi khas dari run manual meliputi:
Nama sistem, seperti '' Purchases System '' Jadwal lari (harian, mingguan, waktu dalam sehari) Perangkat perangkat keras yang dibutuhkan (kaset, disk, printer, atau perangkat keras khusus) Persyaratan berkas menentukan semua file (input) transaksi, file induk, dan file output yang digunakan dalam sistem Instruksi run-time yang menjelaskan pesan kesalahan yang mungkin muncul, tindakan yang akan diambil, dan nama dan nomor telepon pemrogram yang sedang dihubungi, jika sistem gagal Daftar pengguna yang menerima output dari pelarian
Selain itu, auditor harus memverifikasi bahwa dokumentasi sistem tertentu, seperti diagram alir sistem, diagram alur logika, dan daftar kode program, bukan merupakan bagian dari dokumentasi operator. Untuk alasan yang telah dibahas sebelumnya, operator seharusnya tidak memiliki akses terhadap rincian operasional logika internal sistem. Perencanaan Pemulihan Bencana Beberapa bencana tidak dapat dicegah atau dihindari. Peristiwa terkini meliputi angin topan, banjir meluas, gempa bumi, dan kejadian 11 September 2001. Kelangsungan hidup sebuah perusahaan yang
terkena dampak bencana bergantung pada bagaimana reaksi tersebut terjadi. Dengan perencanaan kontinjensi yang hati-hati, dampak bencana bisa diserap dan organisasi masih dapat pulih kembali. Rencana pemulihan bencana (DRP) adalah pernyataan komprehensif dari semua tindakan yang harus dilakukan sebelum, selama, dan setelah bencana, disertai prosedur yang terdokumentasi dan teruji yang akan menjamin kelangsungan operasi. Meskipun rincian masing-masing rencana unik untuk kebutuhan organisasi, semua rencana kerja memiliki fitur umum. Sisa bagian ini dikhususkan untuk diskusi mengenai masalah kontrol berikut: menyediakan cadangan situs kedua, mengidentifikasi aplikasi penting, melakukan prosedur penyimpanan cadangan dan off-site, membuat tim pemulihan bencana, dan menguji DRP. MENYEDIAKAN BACKUP KEDUA Bahan yang diperlukan dalam DRP adalah menyediakan fasilitas pengolahan data duplikat setelah terjadi bencana. Pilihan yang tersedia termasuk cangkang kosong, pusat operasi pemulihan, dan cadangan yang disediakan secara internal. Shell Kosong Rencana lokasi shell kosong atau cold site adalah pengaturan dimana perusahaan membeli atau menyewa bangunan yang akan berfungsi sebagai pusat data. Jika terjadi bencana, cangkangnya tersedia dan siap menerima perangkat keras apa pun yang dibutuhkan pengguna sementara untuk menjalankan sistem penting. Pendekatan ini, bagaimanapun, memiliki kelemahan mendasar. Pemulihan tergantung pada ketersediaan perangkat keras komputer yang diperlukan untuk mengembalikan fungsi pemrosesan data. Manajemen harus mendapatkan jaminan (kontrak) dari vendor perangkat keras yang jika terjadi bencana, vendor akan memberikan prioritas kebutuhan perusahaan. Permasalahan hardware yang tidak diantisipasi pada saat kritis ini bisa menjadi pukulan fatal. Pusat Operasi Pemulihan Pusat operasi pemulihan (ROC) atau situs yang panas adalah pusat data cadangan lengkap yang dimiliki banyak perusahaan. Selain fasilitas perangkat keras dan cadangan, penyedia layanan ROC menawarkan berbagai layanan teknis kepada klien mereka, yang membayar biaya tahunan untuk hak akses. Jika terjadi bencana besar, pelanggan dapat menempati lokasi dan, dalam beberapa jam, melanjutkan pemrosesan aplikasi penting. 11 September 2001, adalah ujian yang benar untuk keandalan dan efektivitas pendekatan ROC. Comdisco, penyedia ROC utama, memiliki 47 klien yang menyatakan 93 bencana yang berbeda pada hari serangan tersebut. Semua 47 perusahaan pindah dan bekerja di pusat pemulihan Comdisco. Pada satu titik, 3.000 karyawan klien bekerja di luar pusat kegiatan. Ribuan komputer dikonfigurasi untuk kebutuhan klien dalam 24 jam pertama, dan tim pemulihan sistem berada di tempat di mana pun polisi mengizinkan akses. Pada tanggal 25 September, hampir separuh klien dapat kembali ke fasilitas mereka dengan sistem yang berfungsi penuh. Masalah dengan pendekatan ini adalah potensi persaingan antar pengguna untuk sumber daya ROC. Bencana alam yang meluas, seperti banjir atau gempa bumi, dapat menghancurkan kemampuan pemrosesan data beberapa anggota ROC yang berada di wilayah geografis yang sama. Semua korban akan menemukan diri mereka bersaing untuk mendapatkan akses ke fasilitas terbatas yang sama. Karena beberapa penyedia layanan ROC memperluas kapasitas mereka dengan rasio 20: 1, situasinya serupa dengan kapal tenggelam yang memiliki jumlah sekoci yang tidak memadai.
Periode kebingungan setelah bencana bukanlah waktu yang ideal untuk menegosiasikan hak kepemilikan. Oleh karena itu, sebelum masuk ke dalam pengaturan ROC, manajemen harus mempertimbangkan potensi masalah kepadatan penduduk dan pengelompokan geografis keanggotaan saat ini. Backup yang diberikan secara internal Organisasi yang lebih besar dengan banyak pusat pemrosesan data sering memilih kemandirian yang menciptakan kapasitas kelebihan internal. Hal ini memungkinkan perusahaan untuk mengembangkan konfigurasi perangkat keras dan perangkat lunak standar, yang memastikan kompatibilitas fungsional di antara pusat pemrosesan data dan meminimalkan masalah pemotongan jika terjadi bencana. Pershing, sebuah divisi dari Donaldson, Lufkin & Jenrette Securities Corporation, memproses lebih dari 36 juta transaksi per hari, sekitar 2.000 per detik. Manajemen Pershing menyadari bahwa vendor ROC tidak dapat memberikan waktu pemulihan yang mereka inginkan dan butuhkan. Oleh karena itu, perusahaan membangun pusat data cermin jarak jauh sendiri. Fasilitas ini dilengkapi dengan perangkat penyimpanan berkapasitas tinggi yang mampu menyimpan lebih dari 20 terabyte data dan dua mainframe IBM yang menjalankan perangkat lunak salinan kecepatan tinggi. Semua transaksi yang proses sistem utama ditransmisikan secara real time bersama kabel serat optik ke fasilitas backup jarak jauh. Pada setiap titik waktu, pusat data cermin mencerminkan kejadian ekonomi saat ini dari perusahaan. Sistem cermin telah mengurangi waktu pemulihan data Pershing dari 24 jam menjadi 1 jam. MENGIDENTIFIKASI APLIKASI KRITIS Unsur penting lain dari DRP melibatkan prosedur untuk mengidentifikasi aplikasi kritis dan file data perusahaan yang akan dipulihkan. Akhirnya, semua aplikasi dan data harus dikembalikan ke tingkat aktivitas bisnis predisaster. Upaya pemulihan segera, bagaimanapun, harus berfokus pada pemulihan aplikasi dan data yang sangat penting bagi kelangsungan hidup jangka pendek organisasi. Dalam skenario bencana apapun, ini adalah survivabilitas jangka pendek yang menentukan kelangsungan hidup jangka panjang. Bagi kebanyakan organisasi, kelangsungan hidup jangka pendek memerlukan pemulihan fungsi-fungsi yang menghasilkan arus kas yang cukup untuk memenuhi kewajiban jangka pendek. Sebagai contoh, asumsikan bahwa fungsi berikut mempengaruhi posisi arus kas perusahaan tertentu:
Penjualan dan layanan pelanggan Pemenuhan kewajiban hukum Pemeliharaan dan penagihan piutang Produksi dan distribusi Pembelian Komunikasi antar cabang atau instansi Hubungan Masyarakat
Aplikasi komputer yang mendukung fungsi ini secara langsung sangat penting. Oleh karena itu, aplikasi ini harus diidentifikasi dan diprioritaskan dalam rencana pemulihan. Prioritas aplikasi dapat berubah dari waktu ke waktu, dan keputusan ini harus dinilai ulang secara teratur. Sistem terus direvisi dan diperluas untuk mencerminkan perubahan dalam persyaratan pengguna. Demikian pula, DRP harus diperbarui untuk mencerminkan perkembangan baru dan mengidentifikasi aplikasi penting. Prioritas yang up-to-date penting karena mempengaruhi aspek lain
dari rencana strategis. Misalnya, perubahan dalam prioritas aplikasi dapat menyebabkan perubahan pada sifat dan tingkat persyaratan cadangan kedua lokasi dan prosedur pencadangan tertentu. Tugas untuk mengidentifikasi dan memprioritaskan aplikasi kritis memerlukan partisipasi aktif manajemen, departemen pengguna, dan auditor internal. Terlalu sering, tugas ini salah dianggap sebagai masalah TI dan didelegasikan kepada profesional TI. Meskipun bantuan teknis dari personil sistem diperlukan, ini terutama keputusan bisnis dan yang paling siap untuk memahami masalah bisnis harus membuatnya. MELAKUKAN CADANGAN DAN CADANGAN PROSEDUR PENYIMPANAN SITUS Semua file data, dokumentasi aplikasi, dan persediaan yang dibutuhkan untuk melakukan fungsi kritis harus ditentukan dalam DRP. Personel pengolahan data harus secara rutin melakukan prosedur backup dan penyimpanan untuk melindungi sumber daya kritis ini. File data cadangan Backup state-of-the-art dalam backup database adalah situs mirror jarak jauh, yang telah dijelaskan sebelumnya, yang menyediakan data lengkap mata uang. Tidak semua organisasi bersedia atau mampu menginvestasikan sumber daya cadangan tersebut. Sebagai minimum, bagaimanapun, database harus disalin setiap hari ke tape atau disk dan diamankan di luar kantor. Jika terjadi gangguan, rekonstruksi database dicapai dengan memperbarui versi cadangan terbaru dengan data transaksi berikutnya. Demikian juga, file master dan file transaksi harus dilindungi. Dokumentasi cadangan Dokumentasi sistem untuk aplikasi kritis harus dicadangkan dan disimpan di luar lokasi dengan cara yang sama seperti file data. Volume material yang besar dan revisi aplikasi yang konstan mempersulit tugas tersebut. Prosesnya bisa dibuat lebih efisien melalui penggunaan alat dokumentasi teknik bantu komputer (CASE). Persediaan Cadangan dan Dokumen Perusahaan harus. Dan yang sumbernya digunakan dalam aplikasi kritis. Contoh persediaan kritis adalah cek saham, faktur, pesanan pembelian, dan bentuk penawaran khusus lainnya yang tidak dapat diperoleh dengan segera. MENCIPTAKAN TIM PEMULIHAN BENCANA Pemulihan dari bencana bergantung pada tindakan korektif yang tepat waktu. Gagal melakukan tugas penting (seperti mendapatkan file cadangan untuk aplikasi kritis) memperpanjang masa pemulihan dan mengurangi prospek pemulihan yang berhasil. Untuk menghindari kelalaian atau duplikasi upaya yang serius selama pelaksanaan rencana kontinjensi, tanggung jawab tugas individual harus didefinisikan secara jelas dan dikomunikasikan kepada personil yang terlibat. Gambar 15-6 menyajikan bagan organisasi yang menggambarkan kemungkinan komposisi tim pemulihan bencana. Anggota tim harus menjadi ahli di bidang mereka dan telah menugaskan tugas. Setelah bencana, anggota tim akan mendelegasikan subtugas ke bawahan mereka. Perlu dicatat bahwa masalah kontrol tradisional tidak berlaku dalam situasi ini. Lingkungan yang ditimbulkan bencana mungkin memerlukan pelanggaran kontrol normal seperti pemisahan tugas, kontrol akses, dan pengawasan. Pada titik ini, kontinuitas bisnis adalah pertimbangan utama. Gambar 15-6
PENGUJIAN DRP Aspek perencanaan kontinjensi yang paling diabaikan adalah menguji rencana. Meskipun demikian, tes DRP penting dan harus dilakukan secara berkala. Pengujian memberikan ukuran kesiapan personil dan mengidentifikasi kelalaian atau kemacetan dalam rencana. Sebuah tes paling berguna dalam bentuk simulasi kejutan gangguan. Saat bencana tiruan diumumkan, status semua pemrosesan yang harus didokumentasikan harus didokumentasikan. Ini memberikan tolok ukur untuk penilaian kinerja selanjutnya. Rencananya harus dilakukan sejauh layak secara ekonomi. Idealnya, ini termasuk penggunaan fasilitas dan persediaan cadangan. TUJUAN AUDIT: PENILAIAN PERENCANAAN PEMULIHAN BENCANA Auditor harus memverifikasi bahwa rencana pemulihan bencana manajemen memadai dan layak dilakukan untuk mengatasi bencana yang dapat menghambat pengorganisasian sumber daya komputasi. Tes berikut berfokus pada bidang yang menjadi perhatian terbesar. PROSEDUR AUDIT UNTUK MENILAI PERENCANAAN PEMULIHAN BENCANA Backup Situs Kedua Auditor harus mengevaluasi kecukupan pengaturan situs cadangan. Klien harus memiliki kontrak vendor yang menjamin pengiriman peralatan tepat waktu ke tempat yang dingin. Dalam hal keanggotaan ROC, auditor harus memperoleh informasi mengenai jumlah anggota dan penyebaran geografisnya. Bencana yang meluas dapat menciptakan permintaan bahwa fasilitas cadangan tidak dapat dipuaskan. Daftar Aplikasi Kritis Auditor harus meninjau daftar aplikasi kritis dan memastikannya lancar dan lengkap. Aplikasi yang hilang mungkin mengakibatkan kegagalan untuk pulih. Di sisi lain, mengembalikan aplikasi yang tidak kritis mengalihkan sumber daya langka ke tugas-tugas yang tidak produktif. Backup Aplikasi Kritis dan File Data Kritis Auditor harus memverifikasi bahwa organisasi memiliki prosedur yang ada untuk mendukung salinan aplikasi kritis dan data yang tersimpan di luar lokasi. Bukti ini dapat diperoleh dengan memilih contoh file data dan program dan menentukan apakah mereka didukung sesuai kebutuhan. Persediaan Cadangan, Dokumen Sumber, dan Dokumentasi Dokumentasi sistem, persediaan, dan dokumen sumber yang diperlukan untuk memulihkan dan menjalankan aplikasi penting harus dicadangkan dan disimpan di luar lokasi. Auditor harus memverifikasi bahwa jenis dan jumlah item yang ditentukan dalam DRP ada di lokasi yang aman.
Tim Pemulihan Bencana DRP harus secara jelas mencantumkan nama, alamat, dan nomor telepon darurat anggota tim pemulihan bencana. Auditor harus memverifikasi bahwa anggota tim adalah karyawan saat ini dan menyadari tanggung jawab mereka yang ditugaskan. Pada satu kesempatan, saat meninjau DRP sebuah perusahaan, penulis menemukan bahwa seorang pemimpin tim yang terdaftar dalam rencana tersebut telah meninggal dunia selama 9 bulan.
Outsourcing Fungsi TI Biaya, risiko, dan tanggung jawab yang terkait dengan pemeliharaan fungsi perusahaan yang efektif TI sangat penting. Oleh karena itu, banyak eksekutif memilih untuk mengalihkan fungsi TI mereka ke vendor pihak ketiga yang mengambil alih tanggung jawab atas pengelolaan aset dan staf TI dan untuk pengiriman layanan TI seperti entri data, operasi pusat data, pengembangan aplikasi, pemeliharaan aplikasi, dan jaringan pengelolaan. Seringkali dikutip manfaat outsourcing TI mencakup peningkatan kinerja bisnis inti, peningkatan kinerja TI (karena keahlian vendor), dan mengurangi biaya TI. Dengan memindahkan fasilitas TI ke luar negeri ke daerah dengan biaya tenaga kerja rendah dan / atau melalui skala ekonomis (dengan menggabungkan beberapa klien), vendor dapat melakukan fungsi alih daya lebih murah daripada yang dapat dilakukan oleh perusahaan klien. Penghematan biaya yang dihasilkan kemudian diteruskan ke organisasi klien. Selanjutnya, banyak pengaturan outsourcing TI melibatkan penjualan aset TI perusahaan klien, baik manusia dan mesin, ke vendor yang kemudian disewa oleh perusahaan klien. Transaksi ini menghasilkan infus tunai satu kali yang signifikan ke perusahaan. Logika yang mendasari TI outsourcing mengikuti teori kompetensi inti, yang berpendapat bahwa sebuah organisasi harus berfokus secara eksklusif pada kompetensi bisnis intinya, sementara memungkinkan vendor outsourcing mengelola wilayah non-inti secara efisien seperti fungsi TI. Premis ini, bagaimanapun, mengabaikan perbedaan penting antara komoditas dan aset TI spesifik. Aset TI komoditi tidak unik untuk organisasi tertentu dan dengan demikian mudah diperoleh di pasar.
Ini mencakup hal-hal seperti manajemen jaringan, operasi sistem, pemeliharaan server, dan fungsi help desk. Aset TI spesifik, sebaliknya, unik bagi organisasi dan mendukung tujuan strategisnya. Karena sifatnya yang istimewa, aset tertentu memiliki nilai yang kecil di luar penggunaan mereka saat ini. Aset semacam itu mungkin berwujud (peralatan komputer), intelektual (program komputer), atau manusia. Contoh aset spesifik meliputi pengembangan sistem, pemeliharaan aplikasi, pergudangan data, dan karyawan terampil yang terlatih untuk menggunakan perangkat lunak khusus organisasi. Teori Biaya Biaya Ekonomi (TCE) bertentangan dengan sekolah kompetensi inti dengan menyarankan
bahwa perusahaan harus mempertahankan aset TI non-inti spesifik tertentu di-rumah. Karena sifat esoteris mereka, aset spesifik tidak dapat dengan mudah diganti begitu mereka menyerah dalam pengaturan alih daya. Oleh karena itu, jika organisasi harus memutuskan untuk membatalkan kontrak outsourcing dengan vendornya, perusahaan tersebut mungkin tidak dapat kembali ke keadaan sebelum melakukan outsourcing. Di sisi lain, teori TCE mendukung outsourcing aset komoditas, yang mudah diganti atau diperoleh dari vendor alternatif. Tentu, persepsi CEO tentang apa yang merupakan komoditas aset TI memainkan peran penting dalam keputusan outsourcing TI. Seringkali ini berujung pada masalah definisi dan interpretasi. Sebagai contoh, kebanyakan CEO akan mendefinisikan fungsi TI mereka sebagai komoditas non-inti, kecuali jika mereka menjalankan bisnis untuk mengembangkan dan menjual aplikasi TI. Akibatnya, keyakinan bahwa semua TI dapat, dan seharusnya, dikelola oleh organisasi layanan besar cenderung menang. Kesalahan persepsi semacam itu mencerminkan, sebagian, keduanya tidak memiliki pendidikan eksekutif dan penyebaran informasi yang salah mengenai kebajikan dan keterbatasan TI outsourcing. RISIKO INHERENT IT ITU OUTSOURCING Kegiatan outsourcing IT skala besar adalah usaha yang berisiko, sebagian karena ukuran semata dari kesepakatan keuangan ini, tetapi juga karena sifatnya. Tingkat risiko terkait dengan tingkat kekhususan aset dari fungsi alih daya. Bagian berikut menguraikan beberapa masalah terdokumentasi dengan baik.
Gagal tampil Begitu perusahaan klien telah mengalihkan aset TI spesifiknya, kinerjanya menjadi terkait dengan kinerja vendor. Implikasi negatif dari ketergantungan tersebut diilustrasikan dalam masalah keuangan yang telah melanda vendor outsourcing besar Electronic Data Systems Corp. (EDS). Dalam usaha pemotongan biaya, EDS menghentikan tujuh ribu karyawan, yang berdampak pada kemampuannya untuk melayani klien lainnya. Setelah harga saham terendah 11 tahun, pemegang saham EDS mengajukan gugatan class action kepada perusahaan tersebut. Jelas, vendor yang mengalami masalah keuangan dan hukum yang serius juga mengancam kelangsungan hidup klien mereka. Eksploitasi Vendor Pengalihan TI berskala besar melibatkan pemindahan aset khusus vendor 'seperti disain, pengembangan, dan pemeliharaan aplikasi bisnis unik yang penting bagi kelangsungan hidup sebuah organisasi. Aset khusus, yang bernilai bagi klien, tidak banyak berpengaruh pada vendor di luar kontrak langsung dengan klien. Memang, mereka mungkin tidak berharga jika organisasi klien gulung tikar. Karena vendor mengasumsikan risiko dengan mengakuisisi aset dan tidak dapat mencapai skala ekonomi dengan mempekerjakan mereka di tempat lain, organisasi klien akan membayar premi untuk mentransfer fungsi tersebut ke pihak ketiga. Selanjutnya, setelah perusahaan klien melepaskan diri dari aset spesifik tersebut, hal itu menjadi tergantung pada vendor. Vendor dapat memanfaatkan ketergantungan ini dengan menaikkan tarif layanan ke tingkat selangit. Seiring kebutuhan TI klien berkembang dari waktu ke waktu di luar persyaratan kontrak awal, risiko akan berlanjut jika layanan baru atau tambahan akan dinegosiasikan dengan harga premium. Ketergantungan ini dapat mengancam fleksibilitas jangka panjang klien, kelincahan, dan daya saing dan mengakibatkan ketergantungan vendor yang lebih besar lagi. Biaya Outsourcing Melebihi Manfaat IT outsourcing telah dikritik karena biaya tak terduga muncul dan tingkat keuntungan yang diharapkan tidak direalisasikan. Satu survei mengungkapkan bahwa 47 persen dari 66 perusahaan yang disurvei melaporkan bahwa biaya outsourcing TI melebihi keuntungan outsourcing. Salah satu alasannya adalah bahwa klien outsourcing sering gagal mengantisipasi biaya pemilihan vendor, kontrak, dan transisi operasi TI ke vendor. Mengurangi keamanan Informasi yang diserahkan ke vendor TI di luar negeri menimbulkan pertanyaan unik dan serius mengenai pengendalian internal dan perlindungan data pribadi yang sensitif. Ketika sistem keuangan perusahaan dikembangkan dan dihosting di luar negeri, dan kode program dikembangkan melalui antarmuka dengan jaringan perusahaan induk, perusahaan A.S. berisiko kehilangan kendali atas informasi mereka. Untuk sebagian besar, perusahaan A.S. bergantung pada langkah-langkah keamanan vendor outsourcing, kebijakan akses data, dan undang-undang privasi negara tuan rumah. Sebagai contoh, seorang wanita di Pakistan memperoleh data medis pasien-sensitif dari University of California Medical Center di San Francisco. Dia mendapatkan akses ke data dari seorang penjual transkripsi medis untuk siapa dia bekerja. Wanita itu mengancam akan menerbitkan catatan di Internet jika dia tidak mendapatkan kenaikan gaji. Terorisme di Asia dan Timur Tengah menimbulkan masalah keamanan tambahan bagi perusahaan yang meng-outsource teknologi lepas pantai. Misalnya, pada tanggal 5 Maret 2005, polisi di Delhi, India, menangkap sel dari tersangka teroris yang berencana untuk menyerang perusahaan outsourcing di Bangalore, India.
Hilangnya Keuntungan Strategis IT outsourcing dapat mempengaruhi ketidaksesuaian antara perencanaan strategis TI perusahaan dan fungsi perencanaan bisnisnya. Organisasi yang menggunakan TI strategis harus menyelaraskan strategi bisnis dan strategi TI atau menjalankan risiko penurunan kinerja bisnis. Untuk mempromosikan keselarasan tersebut, perusahaan membutuhkan manajer TI dan chief information officer (CIO) yang memiliki pengetahuan kerja yang kuat mengenai bisnis organisasi. Sebuah survei terhadap 213 manajer TI di industri jasa keuangan memastikan bahwa kepemimpinan TI perusahaan harus disesuaikan dengan strategi persaingan perusahaan. Memang, ada yang berpendapat bahwa kompetensi bisnis CIO lebih penting daripada kompetensi TI mereka dalam memfasilitasi kongruensi strategis. Untuk mencapai keselarasan tersebut, diperlukan adanya hubungan kerja yang erat antara manajemen perusahaan dan manajemen TI dalam pengembangan strategi bisnis dan TI bersamaan. Namun, ini sulit dilakukan ketika perencanaan TI dialihkan secara geografis ke lepas pantai atau bahkan di dalam negeri. Lebih jauh lagi, karena pembenaran finansial untuk outsourcing TI bergantung pada vendor yang mencapai skala ekonomis, vendor secara alami didorong untuk mencari solusi umum yang dapat digunakan oleh banyak klien daripada menciptakan solusi unik untuk masingmasing perusahaan. Dasar mendasar dari outsourcing TI ini tidak konsisten dengan usaha mengejar keuntungan strategis di pasar. IMPLIKASI AUDIT IT OUTSOURCING Manajemen dapat melakukan outsourcing fungsi TI organisasi mereka, namun mereka tidak dapat mengalihkan tanggung jawab manajemen mereka di bawah SOX untuk memastikan pengendalian internal TI yang memadai. PCAOB secara khusus menyatakan dalam Standar Audit No. 2, '' Penggunaan organisasi layanan tidak mengurangi tanggung jawab manajemen untuk mempertahankan pengendalian internal yang efektif atas pelaporan keuangan. Sebaliknya, manajemen pengguna harus mengevaluasi kontrol pada organisasi layanan, serta kontrol terkait di perusahaan pengguna, saat melakukan penilaian tentang pengendalian internal atas pelaporan keuangan. '' Oleh karena itu, jika perusahaan audit meng-outsource fungsi TI-nya ke vendor yang memproses transaksinya, menjadi tuan rumah data utama, atau melakukan layanan significan lainnya, auditor perlu melakukan evaluasi terhadap kontrol organisasi vendor, atau secara alternatif mendapatkan laporan auditor SAS No. 70 dari organisasi vendor. Pernyataan Standar Audit No. 70 (SAS 70) adalah standar definitif dimana auditor organisasi klien
dapat memperoleh pengetahuan bahwa kontrol pada vendor pihak ketiga memadai untuk mencegah atau mendeteksi kesalahan material yang dapat mempengaruhi laporan keuangan klien. Laporan SAS 70, yang disiapkan oleh auditor vendor, membuktikan kecukupan kontrol internal vendor. Ini adalah cara dimana vendor outsourcing dapat memperoleh satu laporan audit yang dapat digunakan oleh auditor kliennya dan dengan demikian menghalangi kebutuhan setiap auditor perusahaan auditor untuk melakukan audit sendiri terhadap pengendalian internal organisasi vendor. Gambar 15-7 mengilustrasikan bagaimana laporan SAS 70 bekerja dalam kaitannya dengan vendor, perusahaan klien, dan auditor mereka masing-masing. Vendor outsourcing melayani klien 1, 2, 3, dan 4 dengan berbagai layanan TI. Kontrol internal atas layanan alih daya berada di lokasi vendor. Mereka diaudit oleh auditor vendor, yang mengungkapkan pendapat dan mengeluarkan laporan SAS 70 tentang kecukupan kontrol. Masing-masing perusahaan klien diaudit oleh auditor berbeda A, B, C, dan D, masing-masing, yang sebagai bagian dari audit masing-masing bergantung pada laporan SAS 70 vendor dan karenanya tidak dipaksa untuk menguji secara terpisah kendali vendor. Mengingat bahwa
vendor mungkin memiliki ratusan atau bahkan ribuan klien, pengujian individual di bawah SOX akan sangat mengganggu operasi vendor, mahal bagi klien, dan tidak praktis. Auditor penyedia layanan mengeluarkan dua jenis laporan SAS 70. Laporan SAS 70 Type I kurang ketat dari keduanya dan hanya berkomentar mengenai kesesuaian desain kontrol. Laporan SAS 70 Type II berjalan lebih jauh dan menilai apakah pengendalian beroperasi secara efektif berdasarkan tes yang dilakukan oleh auditor organisasi vendor. Sebagian besar laporan SAS 70 yang diterbitkan adalah Tipe II. Karena Bagian 404 memerlukan pengujian kontrol secara eksplisit, SAS 70 Tipe I tidak bernilai sedikit di dunia pasca-SOX. Gambar 15-7
