Resume Sistem Informasi Akuntansi dari buku Andrew Hawker

Unknown On Rabu, 04 Desember 2013

Nama : Ulul Ami

NIM : C1C012003

Kelas : Akuntansi A 2012

Tugas : Resume Sistem Informasi Akuntansi dari buku Andrew Hawker

BAB 11

Pendahuluan : Pemeriksaan komputer

Beberapa topik yang akan dibahas dalam bab ini :

· Mendefinisikanperan danstatusauditorkomputer

· Bagianmana yang dimainkan olehauditorkomputerdalam memilih danmengembangkan sistem

· Sejauh manaauditorkomputerharus memainkanperan aktif dalampengkodeandan desainkerja

· Aspekpengujiansistemdan“pemotongan lebih”ke sistem baruyangharus
menjadi perhatiankhususuntukauditorkomputer

Keamanan dankontrol tujuan :

· Memaksimalkanauditability

11. 1 Peran Auditor Komputer

Ketika pertama kali perusahaan mulai bergerak pada sistem akuntansi mereka dengan cepat mengetahui bahwa beberapa pendekatan tradisional untuk audit tidak akan bekerja. Proses yang sebelumnya bergantung pada bentuk dan memo,sekarang sedang tersembunyi 'di balik selimut' dari komputer. Dalam rangka untuk memeriksa apa yang sedang terjadi, maka perlu mempertimbangkan logika program yang berjalan di dalamnya. Di respon, jenis baru spesialis muncul, dikenal awalnya sebagai EDP auditor (untuk 'Electronic Data Processing'). EDP adalah istilah yang terkaitdengan sistem pokok utama, dan sebagai komputasi penyebaran dan diversifikasi itu menjadi lebih tepat untuk mengubah nama untuk 'komputer auditor'. itu
Istilah 'IS auditor' juga kadang-kadang digunakan.

Audit harus dilakukan oleh seseorang yang benar-benar independen dari mereka yang bertanggung jawab untuk menginstal atau menjalankan sistem , dan status ini diasumsikan dalam bab-bab yang mengikuti.

Idealnya , tata kelola perusahaan akan lebih baik dilayani jika audit komputer
membuat bagian integral dari fungsi audit internal , dan dilakukan di bawah
arahnya dalam kerangka yang lebih luas dari pengendalian internalyang pada gilirannya akan ditinjau oleh auditor eksternal .

Dalam prakteknya , orang-orang yang mengambil peran auditor komputer biasanya pindah di seberang dari pekerjaan dalam pemrograman dan desain sistem . mereka sering dimulai dengan hanya pengetahuan dasar aturan dan metode audit, tetapi dengan bekerja dalam tim audit yang mereka miliki memperoleh keterampilan ini melalui pengalaman praktis .

Bidang audit komputer terus mengembangkan pesat , namun banyak ketidakpastian tetap, apakah pemeriksaan komputer sebenarnya dapat dianggap sebagai karir atau profesi dalam dirinya sendiri . Untuk itu tidak banyak akal di era informasi untuk memiliki jenis auditor yang merasa mampu menangani setidaknyaaspek-aspek dasar dari komputasi . Ini telah diakui oleh badan akuntansi profesional di seluruh dunia , yang telah terus memperkenalkan lebih elemen yang berhubungan dengan IT dalam kurikulum mereka . Namun, masih sangat sulit untuk menjadi benar-benar mahir dalam kedua mengaudit dan IT , terutama ketika datang untuk mengikuti perkembangan konstan inovasi di sisi teknologi . Oleh karena itu kemungkinan bahwa tim audit yang masih perlu untuk mengkooptasi dan melatih orang-orang yang keahliannya terutama teknis .

IT telah memiliki dampak besar pada karya auditor internal maupun eksternal , tapi penunjukan ' komputer auditor ' biasanya diperuntukkan bagi mereka yang bekerja dalam tim audit internal . Perusahaan audit eksternal layanan telah diambil untuk mempekerjakan dan melatih sejumlah besar ahli IT , sebagian untuk membantu dalam mengembangkan sela-sela berkembang mereka dalam konsultasi . Karena audit eksternal adalah bisnis yang sangat kompetitif , juga telah datang untuk bergantung pada alat-alat berbasis komputer , yang membantu untuk meningkatkan efisiensi dengan yang audit dapat direncanakan dan hasilnya dianalisis dan disajikan . Auditor yang bekerja di daerah-daerah mungkin tetap tidak melihat diri mereka
sebagai auditor komputer dengan cara tertentu . Hal ini karena mereka mengambil begitu saja bahwa saat ini mereka akan harus berurusan dengan sistem komputer untuk sebagian besar klien mereka , dan sebagian karena hukum dan profesi akuntansi mendefinisikan dengan jelas apa harus dicapai dalam audit publik - memiliki versi murni ' komputer ' dari itu tidak masuk akal .

Audit eksternal dapat ditelusuri kembali ke tahun-tahun penutupan abad kesembilan belas abad , ketika akuntansi badan-badan profesional yang didirikan di beberapa negara , dan pemerintah mulai membuat wajib audit , sebagai cara melindungi kepentingan pemegang saham . Fokus audit eksternal tetap publikasi laporan dan rekening di akhir setiap tahun keuangan . Penekanannya adalah pada memberikan jaminan bagi para pemegang saham bahwa sumber daya mereka sedang digunakan secara efisien , dan mengkonfirmasikan bahwainformasi dalam rekening yangditerbitkan tersebut ternoda oleh kecurangan atau kesalahan ( Sherer dan Kent 1983) . Ini mensyaratkan bahwa kerja klien sistem akuntansi sepenuhnya dipahami , tetapi pada saat yang sama eksternal auditor akan sering harus bergantung pada cek dan kontrol yang telah ditetapkan dan dijamin oleh auditor internal . Tekanan waktu dan sumber daya membuat sulit bagi auditor eksternal untuk menyelidiki keamanan dan kontrol mekanisme dalam kedalaman nyata .

Audit Internal , dengan perbandingan , profesi yang jauh lebih muda . The Institute Auditor Internal di Amerika Serikat , misalnya , didirikan pada tahun 1941 .
Peran auditor internal telah berkembang dengan cara yang pragmatis , menanggapi
kebutuhan dirasakan oleh organisasi , terutama yang lebih besar , bahwa mereka
harus memiliki beberapa cara untuk memeriksa bahwa aturan-aturan dan prosedur yang sedang diikuti dengan benar . Ini terbaik dapat dilakukan dengan membuat tanggung jawab seseorang atau departemen yang bekerja agak terpisah dari orang lain ,
dan siapa yang bisa memberikan pandangan yang independen . Independensi ini mungkin diperkuat dengan memiliki auditor melaporkan langsung ke komite audit meskipun khasiat ini telah dipertanyakan ( Wolnizer 1995) ) . Atau , audit internal mungkin memiliki garis pelaporan yang lebih konvensional , biasanya untuk direktur keuangan . Dalam kasus terburuk mungkin sedikit lebih dari kehadiran tanda , berdasarkan nyaris tak terlihat dan sangat paruh waktu tanggung jawab yang ditugaskan untuk beberapa orang malang di departemen account .

Audit internal terutama berkaitan dengan transaksi keuangan , tetapi dapat meluas ke area lain dari administrasi . Perannya tidak didefinisikan oleh undang-undang , dan sebagainya organisasi bebas untuk mengaturnya dengan apa pun mengampuni
mereka lebih suka . Mereka mungkin , misalnya , memutuskan bahwa auditor harus
terlibat pada tahap yang sangat awal dalam pemilihan dan desain baru
sistem , dan mengharapkan mereka untuk berkontribusi bagi seluruh tahapan berikutnya , tepat melalui implementasi akhir . Dalam kasus lain , mereka mungkin ingin auditor
untuk lebih menonjolkan diri , dan memberikan nasihat hanya sebagai dan ketika diminta . Tidaklah penting bahwa auditor harus terlibat dalam semua proyek sistem , hanya bahwa mereka terlibat dalam cara yang tepat dalam proyek-proyek yang relevan .
Implikasi dari hal ini dibahas dalam bagian yang mengikuti.

Auditor internal telah lama dilihat dengan kecurigaan oleh beberapa lainnya karyawan , yang diasumsikan memiliki ' kepolisian ' peran , terutama dalam hal mengendus penipuan . Namun, satu buku terkemuka ( Venables dan Impey 1991) menunjukkan mereka harus memiliki setidaknya empat tanggung jawab lain :

· pencegahan dan deteksi kesalahan ;

· menghilangkan limbah ( dari penyebab seperti perencanaan dan kontrol miskin , dan kurangnya perawatan aset ) ;

· memastikan bahwa laporan manajemen didasarkan pada akurat dan dapat diandalkan informasi;

· memeriksa kepatuhan terhadap peraturan perundang-undangan yang relevan .

Auditor internal tidak bisa berharap untuk beroperasi di semua bidang tanpa melanggar batas wilayah orang lain . Sebagai contoh, manajemen akuntan prihatin dengan menghasilkan laporan , dan sebagian besar manajer melihatnya sebagai tanggung jawab mereka untuk menyerang limbah , terutama jika mereka terlibat dalam bidang-bidang seperti manajemen operasi atau jaminan kualitas . Audit internal yang baik didasarkan pada rasa kolaborasi antara semua berbagai pihak , dengan auditor beralih ke saluran yang lebih konfrontatif hanya ketika hal-hal serius terpaut . Sebuah fitur menarik dari tanggung jawab dalam daftar di atas adalah bahwa mereka semua melibatkan beberapa persyaratanuntuk memeriksa integritas dan keamanan sistem informasi . karenanya peran auditor komputer cocok di sini cukup alami .

Cara fitur dalam audit internal dan eksternal komputasi diringkas
pada Gambar 11.1 . Seperti Gambar 11.1 menyiratkan , Auditor Komputer akan
titik yang berguna kontak dengan ahli IS di perusahaan audit eksternal . Dia akan dapat membantu dalam penggalian data dari sistem , dalam menjalankan tes pada nama auditor eksternal , dan menemukan dokumentasi teknis (seperti flowchart Program ) yang mereka butuhkan . Jika organisasi tersebut sistem yang beroperasi secara internasional berjalan , dia juga harus mampu memberikan pandangan terkoordinasi jaringan , dan setiap kontrol otomatis yang berlaku di seluruh batas-batas nasional . Banyak perusahaan audit eksternal juga memiliki lengan konsultasi , yang akan bersemangat untuk membantu dalam melaksanakan kontrol dan penanggulangan baru . Hal ini dapat menimbulkan pertanyaan etis halus apakah audit digunakan sebagai ' memancing perjalanan ' untuk konsultasi bisnis . Sekali lagi , keahlian auditor dapat berguna dalam memutuskan apakah konsultasi tersebut akan berguna .

11.2 AUDIT PENGEMBANGAN SISTEM

Kematian custom- built atau ' dipesan lebih dahulu ' perangkat lunak yang telah diperkirakan dari waktu ke waktu , terutama oleh pemasok solusi dikemas , tapi ada terus ada banyak situasi di mana perusahaan lebih memilih untuk mengambil rute ini . untuk Misalnya , sebuah departemen pemerintah mungkin harus menerapkan sistem dalam sesuai dengan aturan dan perundang-undangan yang berlaku unik dalam negara , atau bisnis mungkin telah menetapkan sendiri tujuan menciptakan unik layanan untuk tingkatan yg lebih tinggi pesaingnya . Software yang dibangun sering besar dalam skala , dan penting untuk satu atau lebih dari kegiatan inti organisasi . sekarangOleh karena itu diharapkan bahwa pertanyaan tentang auditability nya , dan kontrol mekanisme harus dirancang untuk itu , harus diperdebatkan pada tahap awal .

Dua pandangan yang berbeda dapat diambil mengenai apakah auditor komputer harus terlibat dalam tahap awal . Di satu sisi , keterlibatan awal harus memastikan bahwa semua kontrol yang tepat dimasukkan sebagai bagian dari desain dasar , dan tidak harus ' melesat di ' nanti sebagai renungan . Karena setiap penambahan dan perubahan cenderung untuk mendapatkan semakin lebih mahal sebagai proyek software hasil untuk tahap-tahap selanjutnya , hal ini menunjukkan bahwa intervensi dini oleh auditor komputer harus membantu untuk menjaga biaya pengembangan ke bawah . Di sisi lain , jika auditor menjadi sangat terlibat dengan proyek ini , mungkin sulit baginya untuk melestarikan nya independensi dan imparsialitas . Dia mungkin menemukan bahwa sikap dalam tim pengembangan menggosok off pada dirinya : misalnya , tim dapat mengatur toko besar pada memenuhi tenggat waktu , membawa tentang suasana di mana risiko lebih mungkin untuk diterima dan jalan pintas yang diambil .

Sebuah studi auditor internal di sebuah perusahaan terkemuka AS menyarankan memberikan mereka peran ' partisipatif ' dalam proyek-proyek secara signifikan meningkatkan kepuasan kerja mereka ( Allen 1996) . Ini kenikmatan dari 'hands -on ' peran sama mungkin untuk mengajukan auditor komputer . Dalam proses berkontribusi secara aktif untuk desain dan pengembangan , namun, ada bahaya nyata bahwa mereka akan kehilangan objektivitas ketika datang untuk menyelidiki kelemahan sistem pada tahap berikutnya , terutama jika kualitas atau kesesuaian kontrol built -in sedang dipertanyakan .

Apapun keterlibatan auditor komputer adalah menjadi , penting bahwa ruang lingkup didefinisikan di awal, dan disepakati oleh semua orang yang bersangkutan . Mitchell ( 1995) menunjukkan bahwa proyek harus dimasukkan ke dalam salah satu empat kelas , di mana nilai terendah menunjukkan proyek-proyek kecil sensitivitas , dengan sedikit atau tanpa masukan dari auditor yang diperlukan , dan nilai tertinggi menyiratkan keterlibatan teratur dan berkelanjutan . Dalam kasus terakhir , keputusan harus dibuat tentang yang rapat auditor komputer harus hadir , yang daftar sirkulasi untuk memasukkan dia di , dan sebagainya . Perjanjian juga harus dicapai pada aspek-aspek pembangunan yang jatuh dalam hal auditor komputer acuan . Daftar mungkin daerah tanggung jawab diberikan dalam Tabel 11.1 .

Tabel 11.1tanggung jawabauditorKomputerselamaSystem Development LifeCycle(SDLC)

SDLCtahap	Areaketerlibatanauditoruntukkomputer
Inisiasi	Ulasankebutuhan keamanan, menyelidikialternatif, danmempersiapkan proposaluntukalternatif yang lebih disukai
Spesifikasi kebutuhan	Memberikandefinisipersyaratan keamanan, menentukanbagaimanajaminan kualitasyang akanditerapkan padapengembangan fiturkeamanan
Desain	Tentukanfitur keamanansecara lebih rinci, dan menyarankanmetode untukmengujiefektivitas mereka
Konstruksi	Membantudalam mengembangkanfitursoftware, mengawasiawalpengujian, danmemastikan bahwa fiturterintegrasidengan benardengan sisaperangkat lunak
Implementasidan pengujian	Melakukantes akhirpada fiturkeamanan dimasing-masingmodul dandalam sistemyang terintegrasi. Memastikan bahwa semualangkah-langkah keamanandan kontrolsepenuhnyadidokumentasikan
Diadaptasi dariHayamdanOz(1993).

11.3 PENDEKATAN NON - TRADISIONAL : MEMPERHITUNGKAN PAKET DAN PENGGUNA AKHIR

Dengan pengembangan perangkat lunak, auditor komputer setidaknya memiliki pilihan untuk mengambil bagian dalam desain dan keputusan yang dapat mempengaruhi coding keamanan. Namun, sebagian besar perkembangan terakhir di industri perangkat lunak telah bersekongkol untuk mengambil pilihan ini. Sebaliknya , auditor komputer dihadapkan dengan keharusan untuk melakukan evaluasi dari beberapa jarak jauh , dan tidak selalu dari sudut pandang yang sangat baik .

Di satu sisi, ada 'meninggalkan sesuatu' sifat komersial menghasilkan paket . Ini mungkin mengklaim memiliki fasilitas untuk akses kontrol, generasi back- up , enkripsi file dan pesan , dan sebagainya. Memverifikasi klaim ini sangat sulit , karena sebagian besar pemasok menganggap rincian terdalam dari produk mereka sebagai hak milik.

Pada ekstrem yang lain ada yang ' melakukan sesuatu untuknya ' pemrograman yang dapat digunakan untuk membuat aplikasi sederhana pada PC , seperti Visual Basic dan Java . Ada juga banyak pilihan untuk ' penyesuaian ' yang dibangun untuk paket seperti word -processor dan spreadsheet . Pilihan ini dapat membuktikan dan sangat menggoda untuk departemen yang frustasi oleh keterlambatan jasa program pusat, dan yang ingin mengumpulkan beberapa fasilitas disesuaikan sederhana .

Antara dua ekstrem sejumlah pilihan lain , sebagian besar yang menimbulkan banyak masalah seperti kontrol . Paket perangkat lunak mungkin datang dengan beberapa modul yang standar dan lain-lain untuk memenuhi kebutuhan pelanggan . Auditor komputer sekarang harus mengembangkan strategi untuk memastikan bahwa perkembangan semua sistem informasi , bahkan mereka yang pada awalnya tampak dari sangat sedikit konsekuensi , dibawa dalam yurisdiksi mereka .

Beberapa masalah lain yang dapat menghadapi auditor komputer meliputi :

1. Persyaratan merayap . Hal ini terjadi ketika mereka yang komisioning perangkat lunak mulai mengubah pikiran mereka tentang apa yang mereka ingin lakukan . Ini adalah masalah umum dalam pengembangan perangkat lunak di-rumah , tetapi dalam huruf konsekuensi , meskipun mahal , dapat diatasi dengan revisi dengan spesifikasi perangkat lunak . Upaya untuk mengubah paket off - the-shelf cenderung lebih mahal , selain merusak sebagian besar keuntungan yang akan telah digunakan untuk membenarkan mengambil rute paket di tempat pertama . Contohnya adalah proyek TAURUS naas , yang dimulai pada tahun 1988 dengan tujuan computerising London Stock Exchange. Setelah memutuskan untuk mendasarkan sistem pada paket dari Vista Corporation, tim proyek mulai menyadari bahwa perubahan substansial akan diperlukan untuk beradaptasi untuk mencerminkan Inggris daripada praktek perdagangan AS. Drummond (1996 : 102 ) menjelaskan masalah demikian : Perubahannya adalah masalah . The Vista Corporation tidak rumah perangkat lunak namun suatu perusahaan dengan satu produk siap pakai .Terbiasa membuat perubahan kecil saja, mereka illequippeduntukmelakukan penulisan ulang besar-besaran sekarang dibutuhkan oleh Stock Exchange.Dari sudut pandang integritas dan keamanan , modifikasi
paket menimbulkan situasi yang tidak menguntungkan . Jika vendor yang beroperasi di ceruk pasar yang kecil , sumber daya untuk membuat perubahan besar tidak mungkin akan tersedia ( seperti dalam kasus Vista ) . Jika produk melayani banyak pasar yang lebih besar ( misalnya , akuntansi bisnis kecil atau pesan EDI ) harga jual akan telah berkurang jauh oleh negara-negara
skala , dan kesalahan dan kesalahan harus telah terguncang oleh awal
pengguna . Bahkan jika pemasok bersedia untuk menyediakan modifikasi , ini akan sekarang berada pada tingkat pengisian yang lebih tinggi biasanya terkait dengan dipesan lebih dahulu sistem , dan dengan setiap kemungkinan bahwa kesalahan baru akan diperkenalkan .

2. Kite tanda dan standar . Pemasok mungkin mengutip berbagai standar di
sehubungan dengan kualitas atau keamanan produk mereka . Sebuah contoh adalah ISO seri standar yang berhubungan dengan keamanan data 7498 . ( Rincian beberapa standar ini diberikan dalam bab 14 ) . Dua pertimbangan harus diingat sebelum menempatkan ketergantungan pada ini . Pertama , beberapa standar mungkin tidak relevan . Sebagai contoh, beberapa jenis fitur keamanan dapat dinilai pada skala dari A1 ( sangat baik ) melalui C2 ( minimal ) , seperti yang ditetapkan dalam 'Orange Book ' ( lihat bagian 14.3 ) . Namun ini adalah peringkat yang terutama relevan dengan perlindungan kerahasiaan dalam sistem terpusat . Mereka tidak memberikan jaminan apapun, untuk Misalnya , bahwa sistem akan mampu melawan serangan virus , memeriksa pesan untuk merusak , atau melaksanakan fungsi lain yang mungkin ingin dalam lingkungan komersial . Kedua , rating hanya dapat memberikan beberapa ide dari kemampuan potensi produk . Jika fitur keamanan tidak benar-benar dilaksanakan dengan cara yang kompeten , setiap peringkat kualitas produk mungkin akan cepat terbukti tidak relevan .

3. Fasilitas untuk administrasi keamanan. Setelah terinstal , administrator keamanan akan perlu memperbarui otorisasi pengguna dari waktu ke waktu , dan auditor komputer akan ingin berkonsultasi informasi audit trail . Jika interaksi dengan sistem terbukti canggung , atau dokumentasi adalah
jelas , penggunaan fasilitas ini akan terhambat. Ini juga mungkin menunjukkan kelemahan dalam desain keseluruhan . Dengan paket , seharusnya
setidaknya mungkin untuk melihat demonstrasi dari fasilitas yang bersangkutan pada sistem hidup , dan meminta situs lain apakah masalah telah ditemukan . Dengan komputasi end-user , tidak mungkin bahwa penulis
akan memberikan banyak pemikiran untuk implikasi keamanan atau audit
upaya program mereka , yang bahkan mungkin ternyata melemahkan kontrol
sebelumnya di tempat .

4. Integrasi dengan perangkat lunak yang ada . Ini adalah masalah yang akan menjadi perhatian mereka yang akan harus menginstal perangkat lunak , tetapi juga memiliki implikasi internal . Paket akan memiliki konvensi sendiri dalam halfitur seperti maksimum yang diijinkan panjang password , waktunyadari pengguna aktif , atau pengambilan incremental back - up . Akhir - pengguna
program mungkin tidak memiliki konvensi-konvensi tersebut , atau bergantung pada orang-orang dari standar produk . Ini adalah masalah tertentu jika pengguna terbiasa tinggi tingkat integrasi , misalnya karena sistem menyediakan tunggal sign- on , atau pendekatan terpadu untuk mengambil salinan data cadangan .

11.4 SISTEM PENGUJIAN DAN IMPLEMENTASI AUDIT

Ada banyak kasus didokumentasikan proyek IT yang telah
benar-benar terbukti dan ada literatur yang memeriksa. Faktor-faktor yang menyebabkan proyek semacam ini eskalasi ( Beynon - Davies tahun 1995, Drummond 1996 , Keil 1995 , Margetts dan Willcocks 1993) . Jika sistem lama terus beroperasi seluruh bencana , namun, ada tidak akan selalu menjadi salah eksposur keamanan .

Sebuah tanda yang jelas dari bahaya adalah proyek menjadi dilanda dengan masalah saat sistem lama digantikan oleh yang baru , dan itu menjadi jelas
sistem baru akan gagal untuk memenuhi harapan . Sebuah contoh dari apa
bisa terjadi disediakan oleh pengalaman Commonwealth Foreign dan
Office ( FCO ) di London pada tahun 1990 .

The FCO telah merencanakan penerapan sistem baru sesuai
prinsip yang benar . Ada ketentuan untuk menguji sistem baru, menggunakan informasi akuntansi tiruan. Namun, begitu menghebohkan adalah masalah dengan sistem baru yang selama periode diperbolehkan untuk berjalan paralel , staf mencoba untuk mengkompensasi kesalahan dikenal di perangkat lunak dengan memindahkan entri ke ' rekening tiruan'. Isi dari rekening sampah tidak pernah terurai dengan baik . (UK Account 1991) .

Kekacauan dalam sebuah proyek bisa saja timbul karena setiap usaha telah dibuat untuk mengecualikan perhatian auditor dari awal . Pada tahun 1993, Departemen Kendaraan Bermotor di California akhirnya wajib membatalkan proyek untuk meng-upgrade database induk rincian lisensi mengemudi . Collins (1997 : 228 ) mencatat bahwa : " penipuan selama tes akan terdeteksi jika ada verifikasi independen secara teratur atau audit, dimana auditor akan melaporkan tidak ke komputer departemen tetapi untuk kepala eksekutif atau setara ' . Kasus ini memberikan gambaran yang baik tentang perlunya audit yang akan diarahkan oleh internal mengaudit fungsi , dengan jalur komunikasi langsung kepada kepala organisasi .

Prospek harus jelas tentang kelayakan teknis proyek menempatkan auditor komputer dalam posisi yang tidak diragukan lagi. Ini memberikan ujian akhir apakah dia loyalitas kepada tim pengembangan aplikasi , atau organisasi di besar . Namun, jika auditor tidak bersedia untuk mengambil tindakan tersebut , ada gunanya menciptakan peran pemeriksaan di tempat pertama .

Kesimpulannya, tujuan dari auditor komputer yaitu :

· Untuk memverifikasi bahwa kontrol preventif dan umpan balik yang ditetapkan dalam desain adalah operasional dan efektif . Ini mungkin berarti menekan kasus untuk menjadi diprioritaskan , ketika penekanannya pada mendapatkan fitur yang lebih produktif dari perangkat lunak.

· Untuk memastikan bahwa setiap kontrol yang bersamaan diperlukan di tempat.Memungkinkan auditor komputer untuk memeriksa proses dalam software ketika sedang digunakan sehari-hari . Mereka dibahas lebih lanjut dalam Bagian 12.3 .

· Untuk memastikan bahwa kontrol sepenuhnya didokumentasikan . Seharusnya tidak ada misteri tentang tujuan kontrol , di mana mereka dibangun ke dalam perangkat lunak , atau bagaimana mereka seharusnya digunakan .

· Untuk memeriksa ketentuan yang telah dibuat untuk manajemen perubahan . Beberapa perubahan ini akan memiliki implikasi keamanan . Sistem manajemen perubahan harus memastikan bahwa auditor komputer diberitahu jika perubahan tersebut sedang dipertimbangkan .

Subscribe to Posts | Subscribe to Comments

Ulul Azmi

Resume Sistem Informasi Akuntansi dari buku Andrew Hawker

Ditulis Oleh : Unknown ~ Doraemon template

Leave a Reply

Arsip Blog

Pengikut

Mengenai Saya