SISTEM INFORMASI AKUNTANSI

PENGENDALIAN SISTEM INFORMASI UNTUK SISTEM KEANDALAN BAGIAN 3: PROSES INTEGRITAS DAN KETERSEDIAAN

Disusun OlehKelompok II :

1. Amir Hasan2. Doni Kasmon3. Hikalmi4. Liza Aulia Rizki

ANGKATAN XXPROGRAM MAGISTER AKUNTANSI

PASCA SARJANA UNIVERSITAS SYIAH KUALADARUSSALAM, BANDA ACEH

2012

BAB 10

PENGENDALIAN SISTEM INFORMASI UNTUK SISTEM KEANDALAN BAGIAN 3: PROSES INTEGRITAS DAN KETERSEDIAAN

PROSES INTEGRITAS

Prinsip Proses Integritas dari Kerangka kerja Pelayanan keyakinan

(trust service) menyatakan bahwa sistem yang andal adalah salah satunya

menghasilkan informasi yang akurat, komplit, tepat waktu, dan valid. Seperti

yang dibahas dalam tujuan pengendalian COBIT DS 11.1, hal ini

membutuhkan pengendalian atas input, proses, dan output data. Tabel 10-1

menyajikan 6 katagori dasar penerapan pengendalian yang dibahas dalam

COBIT framework untuk memastikan proses integritas.

Tabel 10-1 Penerapan Pengendalian yang Dibahas dalam COBIT untuk memastikan Proses Integritas

Tahapan Proses dan Katagori COBIT Ancaman/Resiko PengendalianInput: AC1 –persiapan dan otoriasasi sumber data

AC2 – mengumpulkan dan memasukkan sumber data

AC3 – mengecek ketepatan (akurasi), kelengkapan dan kebenaran

Datanya : Tidak valid Tidak diotorisasi Tidak lengkap Tidak Akurat

Bentuk desain, pembatalan dan penyimpanan dokumen, otorisasi dan pemisahan tugas pengendalian, visual scanning, pengendalian data masukan.

Proses: AC4 – Proses Integritas dan Validitas

Kesalahan (eror) pada output dan data yang tersimpan.

Pencocokan data, label berkas (file), jumlah kumpulan (batch), menguji penjumlahan mendatar (cross footing), zero balance (saldo nol), menulis mekanisme perlindungan, pengendalian database proses integritas.

2

Output: AC5 – output review, rekonsiliasi dan kesalahan penanganan

AC6 – Kebenaran dan Integritas Transaksi

Menggunakan laporan yang tidak akurat atau tidak komplit

Pengungkapan tidak sah dari informasi sensitif (peka)

Kerugian, perubahan atau pengungkapan informasi dalam perjalanan

Meninjau kembali dan merekonsiliasi, enkripsi dan pengendalian akses, memeriksa kesamaan (parity), teknik pesan pengakuan.

Pengendalian Input (Input Control)

Frase sampah masuk, sampah keluar menyoroti pentingnya

pengendalian input. Jika data yang masuk ke dalam sistem tidak akurat,

tidak komplit, atau tidak valid, output yang dihasilkan juga demikian.

Karenanya, dokumen-dokumen sumber seharusnya dipersiapkan hanya oleh

personil yang berwenang dalam mengotorisasinya. Di samping itu, bentuk

desain, pembatalan dan penyimpanan sumber-sumber data, dan

pengendalian data masukan otomastis dibutuhkan untuk memverifikasi

validitas data input.

BENTUK DESAIN. Dokumen-dokumen sumber dan bentuk lainnya didesain

untuk meminimalisasi peluang bagi kesalahan dan kelalaian. Dua bentuk

pengendalian desain yang sangat penting yaitu urutan pra-penomoran

dokumen-dokumen sumber dan menggunakan dokumen turnaround.

1. Setiap dokumen sumber seharusnya diberikan nomor secara berurutan.

Pra-penomoran meningkatkan pengendalian dengan memungkinkannya

untuk memverifikasi bahwa tidak ada dokumen-dokumen yang hilang.

(untuk memahami ini, pertimbangkanlah kesulitan yang akan anda

dapatkan dalam menyeimbangkan akun yang diperiksa jika tidak satupun

akun yang diperiksa diberi nomor.) Ketika urutan pra-penomoran sumber

3

data dokumen digunakan, sistem harus diprogram untuk mengidentifikasi

dan melaporkan kehilangan atau menduplikat dokumen sumber.

2. Dokumen Turnaround adalah record (catatan) data perusahaan yang

dikirim ke pihak eksternal dan kemudian dikembalikan oleh pihak

eksternal ke sistem sebagai masukan (input). Dokumen turnaround

disiapkan dalam mesin pembaca bentuk untuk memfasilitasi proses

berikutnya sebagai record input. Sebagai contoh Utility Bill yang dapat

dibaca dengan perangkat scanning khusus ketika bill terebut dikembalikan

dengan pembayaran. Dokumen turnaround memastikan ketelitian dengan

mengeliminasi potensi kesalahan input ketika memasukkan data secara

manual.

PEMBATALAN DAN PENYIMPANAN DOKUMEN SUMBER. Dokumen sumber

yang sudah dimasukkan ke dalam sistem harus dapat dibatalkan sehingga

dokumen tersebut tidak dapat secara tidak sengaja atau menipu (fraud)

masuk kembali ke dalam sistem. Contohnya dokumen kertas dapat

dihancurkan, atau dicap “lunas”. Dokumen elektronik dapat juga dibatalkan

dengan pengaturan flag field yang mengindikasikan bahwa dokumen sudah

siap untuk diproses. Catatan: pembatalan tidak diartikan sebagai

pembuangan. Dokumen sumber yang asli (atau gambar elektronik) harus

ditahan sampai dengan dibutuhkan untuk memenuhi syarat hukum dan

regulasi dan menyiapkan audit trial.

PENGENDALIAN DATA ENTRY. Dokumen-dokumen sumber harus di scan

untuk menjamin kewajaran dan kebenaran sebelum dimasukkan ke dalam

sistem. Bagaimanapun, pengendalian manual ini harus dilengkapi dengan

pengendalian data entry otomatis, seperti hal berikut:

Field Check (cek filed) menentukan apakah karakter dalam field dari jenis

yang tepat. Sebagai contoh, mengecek pada field yang seharusnya berisi

hanya nilai angka, seperti pada US zip code, yang menunjukkan suatu

kesalahan jika itu berisi karakter huruf abjad.

4

Sign check (cek sign) menentukan apakah data dalam field memiliki tanda

sesuai aritmatika. Sebagai contoh, field pesanan kuantitas agar tidak

boleh negatif.

Limit check (cek batasan) menguji jumlah angka terhadap nilai tetap.

Sebagai contoh, field jam bekerja regular dalam input pembayaran upah

mingguan harus kurang dari atau sama dengan 40 jam. Sama halnya

dengan field upah harian harus lebih besar dari atau sama dengan upah

minimum.

Range check (cek ring) menguji apakah jumlah angka jatuh diantara batas

bawah dan atas dari yang ditetapkan. Sebagai contoh, promosi pemasaran

mungkin diarahkan hanya untuk prospek dengan laba $ 50.000 dan $

99.999.

Size check (cek ukuran) memastikan bahwa data input akan cocok ke

dalam filed tugas. Sebagai contoh nilai 458.976.253 akan tidak cocok

dengan field digit delapan.

Completeness check (cek kelengkapan) pada setiap input yang direkam

menentukan apakah semua item data yang dibutuhkan sudah

dimasukkan. Sebagai contoh, catatan (rekaman) transaksi penjualan tidak

harus diterima untuk diproses kecuali melengkapinya dengan alamat

pengiriman dan penagihan pelanggan.

Validity check (cek validitas) membandingkan kode ID atau nomor

rekening (akun) pada transaksi data dengan data yang sama dalam file

master untuk memverifikasi bahwa akun ada. Sebagai contoh, jika nomor

produk 65432 dimasukkan pada pesanan penjualan, komputer harus

memverifikasinya bahwa produk tersebut benar bernomor 65432 dalam

database inventory.

Reasonableness check (cek kewajaran) menentukan kebenaran dari

hubungan logis antara dua item. Sebagai contoh, jam lembur harus dibuat

nol untuk seseorang yang tidak bekerja maksimum pada jam kerja regular

dalam periode pembayaran.

5

Nomor ID resmi (seperti nomor pekerja) dapat berisi suatu cek digit yang

dihitung dari digit lainnya. Sebagai contoh, sistem dapat menetapkan

setiap karyawan baru dengan nomor Sembilan digit, lalu menghitung digit

sepuluh dari Sembilan digit aslinya dan menambahkannya dengan jumlah

yang dihitung dengan Sembilan digit aslinya untuk membentuk nomor ID

sepuluh digit. Perangkat data entry kemudian dapat diprogram untuk

melakukan verifikasi cek digit dengan menggunakan digit Sembilan

pertama untuk menghitung digit kesepuluh setiap kali nomor ID tersebut

dimasukkan. Jika kesalahan dibuat dalam memasukkan salah satu dari

sepuluh digit, perhitungan dilakukan pada Sembilan digit pertama tidak

akan cocok dengan yang kesepuluh atau cek digit.

Pengujian data entry terdahulu (preceding) digunakan dua metode yaitu

batch processing dan online real-time processing. Pengendalian data input

tambahan berbeda dengan kedua metode proses tersebut.

PENGENDALIAN BATCH PROCESSING DATA ENTRY TAMBAHAN

Batch processing bekerja lebih efisien jika transaksi disortir (diurutkan)

sehingga akun-akun yang terpengaruh berada pada urutan yang sama

seperti rekaman dalam master file. Sebagai contoh, keakuratan batch

processing transaksi penjualan untuk memperbarui saldo rekening

pelanggan terlebih dahulu dilakukan dengan mengurutkan nomor rekening

pelanggan. Menguji sequent check (cek urutan) apakah batch data input

berada dalam angka atau huruf yang berurut.

Error log menunjukkan review terhadap kesalahan data input (tanggal,

sebab, masalah) yang tepat waktu dan pengajuan transaksi yang tidak

dapat diproses.

Batch total meringkas nilai penting untuk rekaman batch input. Berikut ini

adalah tiga batch total yang umumnya digunakan:

6

1. Total jumlah keuangan adalah field yang berisikan nilai-nilai moneter,

seperti jumlah total seluruh penjualan dalam dolar untuk sebuah batch

transaksi penjualan.

2. Total jumlah Hash adalah field angka non keuangan, seperti filed total

kuantitas yang dipesan pada batch transaksi penjualan.

3. Record count adalah jumlah rekaman dalam batch.

Batch total ini dihitung dan disimpan oleh sistem ketika data awalnya

dimasukkan. Data tersebut kemudian akan di kalkulasi ulang untuk

memverifikasi apakah seluruh input diproses dengan benar.

PENGENDALIAN DATA ENTRY ONLINE TAMBAHAN

Prompting, dimana sistem meminta setiap item data input dan menunggu

respon yang diterima, memastikan bahwa semua data yang diperlukan

dimasukkan (dengan kata lain, prompting adalah cek kelengkapan online).

Verifikasi closed-loop memeriksa akurasi data input dengan

menggunakannya untuk mengambil dan menampilkan nama akun

sehingga pengguna dapat membuktikan bahwa nomor akun yang benar

sudah dimasukkan.

Log transaksi meliputi rician rekaman seluruh transaksi, termasuk

mengidentifikasi transaksi unik, tanggal dan waktu entry, dan siapa yang

memasukkan transaksi. Jika sebuah file online rusak log transaksi dapat

digunakan untuk memastikan bahwa transaksi tersebut tidak hilang atau

dimasukkan dua kali.

Pengendalian Proses (Processing Control)

Pengendalian juga dibutuhkan untuk memastikan bahwa data diproses

dengan benar. Pengendalian proses yang penting sebagai berikut:

Data Matching. Pada kasus tertentu, dua atau lebih item data harus

dicocokkan terlebih dahulu sebelum terjadinya suatu tindakan. Sebagai

contoh, sebelum membayar penyedia (vendor), sistem harus

7

memverifikasi informasi bahwa faktur vendor cocok dengan informasi

pesanan pembelian dan laporan penerimaan.

File Labels. File label membutuhkan pemeriksaan untuk memastikan

bahwa file-file yang benar di perbaharui (update). Eksternal label yang

dapat dibaca oleh manusia dan internal label yang ditulis dalam bentuk

yang dapat dibaca oleh mesin pada media data record keduanya harus

digunakan. Dua tipe penting dari internal label adalah header dan trailer

record. Header record terletak pada awal setiap file dan berisikan nama

file, tanggal kadaluarsa dan identitas data lainnya. Trailer record terletak

pada akhir file dan berisikan total batch yang dihitung selama input.

Program-Program harus didesain untuk membaca header record sebelum

diproses, untuk memastikan file yang benar sedang diperbaharui.

Program-program tersebut juga harus didesain untuk membaca informasi

dalam trailer record setelah diproses, untuk memastikan bahwa semua

rekaman input sudah diproses dengan benar.

Perhitungan ulang dari batch total. Batch total harus dihitung kembali

sebagai setiap transaksi yang diproses, dan total untuk batch kemudian

harus dibandingkan dengan niali dalam trailer record. Setiap perbedaan

mengindikasikan suatu kesalahan proses. Seringkali. Sifat perbedaan

tersebut memberikan petunjuk tentang jenis kesalahan yang terjadi.

Sebagai contoh, jika saat dihitung ulang jumlah record nya lebih kecil dari

yang aslinya, satu atau lebih transaksi record tidak diproses. Sebaliknya,

jika saat dihitung ulang jumlah recordnya lebih besar dari yang aslinya,

ada tambahan transaksi yang tidak sah diproses, atau beberapa transaksi

record diproses dua kali. Jika perbedaan total keuangan atau hash dibagi

merata dengan 9, kemungkinan penyebabnya adalah kesalahan

transposisi (perubahan), dimana dua digit yang berdekatan secara tidak

sengaja terbalik (seperti 46 menjadi 64). Kesalahan transposisi mungkin

muncul karena dianggap sepele tapi bias memiliki konsekuensi keuangan

yang sangat besar. Sebagai contoh, efek dari salah mencatat tingkat

bunga pinjaman sebesar 6.4% menjadi 4.6%.

8

Cross footing dan zero balance test. Jumlah total dapat dihitung dalam

berbagai cara. Sebagai contoh, di dalam kertas kerja, grand total dapat

dihitung salah satunya dengan menjumlah total kolom atau baris atau

dengan menjumlahkan baris dari total kolom. Kedua metode ini harus

menghasilkan hasil yang sama. Cross footing balance test

membandingkan hasil yang diproduksi oleh setiap metode untuk

memverifikasi keakuratan. Zero balance test menerapkan logika yang

sama untuk mengendalikan akun. Sebagai contoh, akun kliring upah di

debit untuk pembayaran bruto semua pekerja dalam periode waktu

tertentu. Kemudian meng-kredit jumlah alokasi biaya seluruh pekerja

untuk berbagai katagori beban. Akun kliring upah harus memiliki saldo nol

setelah keduanya di jurnal (di entri); apabila tidak bersaldo nol

mengindikasikan kesalahan proses.

Write-protection mechanisms. Pengendalian ini untuk melindungi terhadap

tertimpanya atau terhapusnya data file yang tersimpan pada media

magnetic. Write-protection mechanisms telah lama digunakan untuk

melindungi master file dari kerusakan yang tidak disengaja. Invoasi

teknologi juga mengharuskan penggunaan Write-protection mechanisms

untuk melindungi integritas data transaksi. Sebagai contoh, tag identifikasi

frekuensi radio (RFID) digunakan untuk melacak kebutuhan persediaan

dengan perlindungan catatan (jumlah harga) agar pelanggan tidak dapat

merubah harga barang.

Pengendalian update bersamaan (Concurrent update control). Kesalahan

dapat terjadi ketika dua atau lebih pengguna berusaha untuk

memperbaharui record yang sama secara bersamaan. Pengendalian

update bersamaan mencegah kesalahan tersebut dengan mengunci satu

pengguna sampai sistem telah selesai memproses transaksi yang

dimasukkan oleh pengguna yang lain.

Pengendalian Output (Output Control)

9

Pemeriksaan output sistem memberikan tambahan pengendalian atas

proses integritas. Berikut merupakan Pengendalian output yang penting :

Pengguna mereview output. Pengguna harus secara hati-hati memeriksa

output sistem untuk memverifikasi bahwa output tersebut layak, lengkap,

dan bahwa mereka adalah penerima yang dimaksud.

Prosedur rekonsiliasi. Secara periodik, seluruh transaksi dan update sistem

lainnya harus direkonsiliasi (dicocokan) dengan laporan pengendalian,

status file/laporan update, atau mekanisme pengendalian lainnya.

Tambahan, akun buku besar harus direkonsiliasi dengan total akun buku

pembantu secara teratur (regular). Sebagai contoh, saldo pengendalian

akun persediaan pada buku besar harus sama dengan jumlah saldo item

pada database persediaan. Hal yang sama berlaku pada pengendalian

akun piutang, modal aset dan utang.

Rekonsiliasi data eksternal. Total database secara periodik harus

direkonsiliasi (dicocokan) dengan data yang dikelola di luar sistem.

Sebagai contoh, jumlah pekerja yang direcord pada file upah dapat

dibandingkan dengan total jumlah pekerja pada database sumber daya

manusia untuk mendeteksi upaya untuk menambah karyawan fiktif pada

database upah. Demikian pula, persediaan di tangan harus dihitung secara

fisik dan membandingkannya dengan kuantiti yang direcord di tangan

dalam database.

Pengendalian transmisi data. Organisasi juga butuh untuk menerapkan

desain pengendalian agar memperkecil resiko kesalahan transmisi

(pengiriman) data. Setiap kali perangkat penerima mendeteksi kesalahan

transmisi data, perangkat pengirim meminta untuk mengirim kembali data

tersebut. Umumnya, hal ini terjadi secara otomatis dan pengguna baru

menyadarinya setelah terjadi. Sebagai contoh, Transmission Control

Protocol (TCP) yang dibahas pada Bab 8 memberikan nomor urut untuk

setiap paket dan menggunakan informasi tersebut untuk memverifikasi

bahwa seluruh paket sudah diterima dan memasang kembali dalam

10

urutan yang benar. Ada dua pengendalian lain yang umumnya digunakan

dalam transmisi data yaitu checksums dan parity bits.

1. Checksums. Ketika data ditransmisikan (dikirim), perangkat pengirim

dapat menghitung file hash, yang disebut checksums. Perangkat

penerima melakukan perhitungan yang sama dan mengirim hasilnya ke

perangkat pengirim. Jika dua hash setuju, transmisi dianggap akurat.

Jika tidak file dikirim ulang.

2. Parity bits. Komputer merepresentasikan karakter sebagai kumpulan

digit berpasangan yang disebut bit. Setiap bit memiliki dua

kemungkinan nilai: 0 atau 1. Banyak komputer menggunakan skema

pengkodean tujuh digit, yang mewakili lebih dari 26 huruf dalam abjad

inggris (huruf besar dan kecil), nomor 0 sampai 9 dan variasi symbol

khusus ($, % dan sebagainya). Parity bit adalah suatu tambahan ekstra

digit untuk setiap karakter awal yang dapat digunakan untuk

memeriksa akurasi transmisi. Dua skema dasarnya yang disebut

sebagai even parity (parity genap) dan odd parity (parity ganjil). Pada

parity genap (Even Parity), parity bit diset agar masing-masing karakter

memiliki bit angka genap dengan nilai 1; pada parity ganil (Odd Parity)

parity bit diset agar jumlah ganjil bit dalam karakter memiliki nilai 1.

Untuk contoh, digit 5 dan 7 dapat direpresentasikan dengan pola tujuh

digit masing-masing 0000101 dan 0000111. Sistem Parity genap (even

parity) akan mengeset parity bit dari 5 sampai 0, sehingga akan

ditransmisikan sebagai 00000101 (karena kode binary dari 5 sudah

memiliki dua bit dengan nilai 1). Parity bit untuk 7 akan diatur ke 1,

sehingga akan ditransmisikan sebagai 10000111 (karena kode binary

untuk 7 memiliki 3 bit dengan nilai 1). Perangkat penerima melakukan

pemeriksaan pairy (parity checking), mencakup verifikasi bahwa jumlah

yang tepat dari bit diatur ke angka 1 pada masing-masing karakter

yang diterima

Contoh Ilustrasi : Proses Penjualan Kredit

11

Kita sekarang menggunakan penjualan kredit untuk menjelaskan berapa

banyak pengendalian aplikasi yang telah dibahas berdasarkan fungsinya.

Data transaksi berikut yang digunakan yaitu: nomor pesanan penjualan,

nomor rekening pelanggan, nomor item persediaan, kuantitas yang terjual,

harga jual, dan tanggal pengiriman. Jika pembelian pelanggan lebih dari satu

produk, akan ada item persediaan dengan nomor ganda, kuantitas yang

terjual dan harga terkait dengan setiap transaksi penjualan. Proses transaksi

ini meliputi langkah-langkah berikut: (1) memasukkan dan mengedit data

transaksi; (2) mengupdate record (catatan) pelanggan dan persediaan

(jumlah pembelian kredit ditambahkan pada saldo pelanggan; untuk setiap

item persediaan, kuantitas terjual dikurangi dari kuantitas di tangan); dan

(3) mempersiapkan dan mendistribusikan pengiriman dan/atau dokumen

penagihan. Contohnya untuk batch dan proses online disajikan.

PENGENDALIAN BATCH PROCESSING INTEGRITY. Gambar 10-1 menunjukkan

pengendalian aplikasi yang seharusnya diterapkan pada setiap langkah

proses batch transaksi penjualan kredit:

1. Menyiapkan batch total. Jumlah dari seluruh penjualan dihitung

sebagai total keuangan dan dicatat (direcord) pada batch form yang

menyertai setiap kelompok dokumen penjualan.

2. Memberikan transaksi ke departemen operasi komputer untuk

proses. Setiap batch diperiksa untuk otorisasi yang tepat dan direcord

dalam control log.

3. Masukkan data transaksi kedalam sistem. Sebagai data yang

dimasukkan, sistem melakukan beberapa pengujian validitas awal. Check

digit memverifikasi identifikasi transaksi-transaksi dengan nomor-nomor

akun yang tidak sah (invalid) atau nomor item persediaan yang tidak sah.

Field check memverifikasi bahwa kuantitas yang dipesan dan price field

(field harga) mengandung angka dan tanggal field mengikuti yang format

benar MM/DD/YYYY. Sequent check (cek urutan) pada nomor urut order

12

penjualan dan rekonsiliasi total batch dihitung dalam langkah 1

memverifikasi bahwa tidak ada transaksi yang hilang.

4. Laporan pengendalian menggambarkan seluruh kesalahan entri data. Kesalahan entri data terjadi karena operator membaca sumber

dokumen yang tidak benar atau secara tidak sengaja menekan tombol yang salah, biasanya dapat diperbaiki segera setelah terdeteksi. Sumber data yang tidak benar, seperti transaksi penjualan yang

diotorisasi atau nomor akun yang tidak valid, seluruh masalah dan harus dikembalikan ke departemen penjualan untuk koreksi.

4. Menyortir dan mengedit file transaksi. File transaksi disortir

(diurutkan) dengan nomor rekening pelanggan. Pemeriksaan validasi

tambahan dilakukan, termasuk melakukan sign check terhadap kuantitas

pesanan dan field harga memuat nomor positif, dan range check pada

tanggal pengiriman yang dijanjikan untuk memverifikasi bahwa tidak

lebih awal dari tanggal pemesanan atau selambat-lambatnya dari

kebijakan perusahaan untuk mengiklankan. Transaksi-transaksi yang

ditolak terdaftar pada laporan pengendalian bersama dengan total batch

yang dihitung. Data control menyesuaikan dengan total batch,

menyelidiki dan mengoreksi seluruh kesalahan, dan menyampaikan

transaksi yang dikoreksi untuk diproses.

5. Memperbaharui master file. File transaksi penjualan diproses

terhadap database pelanggan (akun piutang) dan persediaan atau

master file. Operator membaca label eksternal dan program membaca

record internal header untuk memastikan bahwa master file yang benar

sedang di perbaharui (update). Transaksi penjualan dengan nomor

pelanggan atau nomor-nomor item yang tidak ada dalam master file

yang sesuai tidak diproses; sebagai gantinya, nomor-nomor tersebut

dimasukkan pada laporan kesalahan (error). Setelah transaksi penjualan

diproses, sign check bekerja untuk memastikan field kuantitas di tangan

pada master record tidak negatif. Pengujian juga dilakukan untuk

memastikan bahwa harga jual jatuh dalam batas normal, pesanan

tersebut tidak melebihi batas kredit pelanggan dan kuantitas yang

dipesan wajar mengingat dan riwayat pesanan pelanggan. Memeriksa

13

data yang berlebihan – untuk contoh, perbandingan jumlah item

persediaan dan deskripsi – digunakan untuk memastikan bahwa master

file record yang benar diperbaharui (update). Perubahan total dalam

saldo pelanggan dihitung; total keuangan ini dibandingkan dengan total

jumlah penjualan seluruh transaksi yang sedang diproses.

6. Mempersiapkan dan mendistribusikan output. Output termasuk

penagihan dan/atau dokumen-dokumen pengiriman dan laporan

pengendalian. Laporan pengendalian berisikan akumulasi total batch

selama file update run dan daftar transaksi yang ditolak oleh program

update.

7. Review Pengguna. Pengguna pada departemen pengiriman dan

penagihan melakukan review terbatas terhadap dokumen-dokumen yang

datanya tidak lengkap atau kekurangan. Mereka juga membandingkan

sistem yang dihasilkan total batch dengan yang dihitung pada langkah 1

untuk memverifikasi seluruh transaksi yang diproses.

PENGENDALIAN ONLINE PROCESSING INTEGRITY. Online real-time processing

merekord setiap transaksi penjualan kredit secara sendiri-sendiri. Hal ini

memungkinkan untuk mendeteksi ketepatan waktu dan mengoreksi

kesalahan. Berbagai pengendalian aplikasi yang dibahas pada bab ini

diterapkan pada setiap tahapan (input, proses, output) proses transaksi

online, sebagai berikut.

Pengendalian Data Entry Online

Ketika seseorang mengakses sistem online, logical access controls

mengkonfirmasi identitas dari perangkat data entry (personal computer,

terminal) dan validitas karyawan pengguna nomor ID dan password.

Uji Kompatabilitas memastikan bahwa karyawan berwenang untuk

melakukan tugas itu.

14

Sistem secara otomatis memberikan nomor transaksi yang telah

dirancang secara otomatis, sesuai dengan nomor urut dan tanggal

pembuatan faktur.

Sistem mengharuskan untuk mengisi data yang harus dimasukkan, dan

setelah itu sistem akan memberikan konfirmasi.

Setiap respon diuji menggunakan satu atau lebih dengan cara: cheks

validitas (validitas pelanggan dan nomor barang), daftar isian pada kolom

dan tanda ceklis yang sudah diberikan (hanya possitive, karakter numerik

dalam jumlah, tanggal, dan bidang harga), dan batas pengisian limit

yang sudah diisikan (tanggal pengiriman dibandingkan tanggal

sekarang).

Bila memasukkan nomor pelanggan, sistem mengambil nama pelanggan

yang sesuai dari database dan menampilkannya di layar. Operator visual

memeriksa nama pelanggan. Jika sesuai dengan nama dalam dokumen

pesanan penjualan, operator sistem, transaksi dapat dilanjutkan, jika

tidak maka sistem meminta untuk dilakukan data yang benar.

Bila jumlah item persediaan yang dimasukkan, sistem akan melakukan

hal yang sama seperti ketika memasukkan data nomor pelanggan.

Pengendalian Proses Online

Karena pengupdetan file akan mengakses pelanggan dan barang yang

dimasukkan, hal ini memerlukan penginputan data dengan melakukan uji

validasi tambahan dengan membandingkan data dalam setiap record

transaksi dengan data dalam catatan database yang sesuai. Yang termasuk

dalam tes ini adalah :

Mengecek kevalidan pada pelanggan dan nomor persediaan barang.

Memastikan bahwa saldo persediian di gudang telah sesuai (setelah

dikurangi jumlah dijual).

Beri batasan kredit dan kelompokkan pelanggan sesuai dengan batas

kredit yang diberikan.

Beri batasan harga disesuaikan dengan batas yang dibolehkan.

15

Lakukan tes kenormalan yang berhubungan dengan jumlah barang yang

terjual, dan jenis barang yang dikeluarkan secara online.

Pengendalian Output Online

Output (keluaran) dari proses ini termasuk di dalamnya dokumen tagihan

dan dokumen pengiriman. Kontrol Output berikut digunakan untuk:

• Penagihan dan pengiriman akan diporses secara elektronik hanya untuk

pengguna yang sudah dioutorisasi.

• Pengguna di département pengiriman dan penagihan melakukan

penelaahan terbatas dari dokumen dengan melakukan pemeriksaan data

yang belum lengkap, atau kesalahan lainnya.

• Laporan pengecekan ini dikirim ke penerima secara otomatis, jika sistem

meragukan keabsahan, maka akan mengkonfirmasi identitas yang

meminta data dengan memvalidasi terlebih dahulu nomor identitas dan

password pengguna.

Contoh berikut menggambarkan penggunaan kontrol aplikasi untuk

Memastikan integritas pemrosesan sebuah transaksi di sebuah Universitas di

Belanda.

Saat ini banyak organisasi menerapkan dan merasakan manfaat dari sistem

pengadaan secara elektronik. Di antara penghematan tersebut adalah

penghematan biaya yang begitu besar. Sebuah studi oleh Komisi Eropa

menunjukkan penghematan sekitar 40% sampai dengan 75%.

Untuk meningkatkan efisiensi dan keandalan dari proses pengadaan,

Universitas di Belanda ini mengaplikasikan sistemBasWare Enterpiseuntuk

melakukan pengadaan dan untuk pembayaran sebagai solusi manajemen

keuangan. Universitas memproses sekitar 10.000 faktur per bulan. Namun,

faktur kebanyakan berbentuk surat, Faktur tersebut di-scan dan kemudian

baru diproses dengan karakter optik, kemudian secara otomatis tersambung

ke pesanan pembelian atau kontrak dalam modul Contolling. Setelah

memverifikasi bahwa penerima menerima barang jasabagian anggaran

16

menerima e-mail yang meminta dia untuk memverifikasi faktur dalam waktu

lima hari kerja. Bagian anggaran memiliki kemampuan untuk melihat faktur

asli dan dengan mudah dapat mengotorisasi. Oleh karena itu,jika bagian

anggaran belum menyetujui faktur dalam sistem BasWare,maka pada hari

itu juga mengirim faktur pengganti setelah tujuh hari. Setelah faktur

menyetujui harga pada sistem BasWare, maka akan menghasilkan jurnal,

dan secaraotomatis masuk dalam sistem yang pada gilirannya, SAP FI / Co

membuat file berkelompok, misal secara mingguan. File ini kemudian

diimpor oleh sebuah aplikasi keuangan online banking, kemudian manajer

keuangan dan / atau direktur dapat mengotorisasi pembayaran.

Universitas menerapkan sejumlah kontrol dalam proses untuk menjamin

integritas faktur pengolahan mereka. Legalitas dari pembayaran, dan

pengarsipan dengan software elemen dalam faktur penting dalam

kelengkapan kontrol, dengan persyaratan dari Komisi Eropa dan otoritas

pajak setempat. Pengontrolan ini meliputi :

• pemisahan tugas (Otorisasi);

• membuat otomasi kepada pihak yang berkepentingan;

• membuat otomasi akun dalam buku besar dan pusat-pusat biaya;

• mengontrol transmisi data antara sistem IT yang berbeda;

• memeberi tanda data yang sudah discan dan file pembayaran.

Pengolahan yang Terintegrasi pada Pengolah Data

Pentingnya spreadsheet pelaporan keuangan tercermin dalam

kenyataan bahwa ISACA (Information Systems Audit and Control

Association)– asosiasi di bidang audit sistem informas, dokumen IT

pengontrolan secara objektif untuk Sarbanes-Oxley berisi lampiran terpisah

yang khusus membahas kontrol integritas pengolahan yang harus digunakan

dalam spreadsheet. Namun, karena spreadsheet hampir selalu

dikembangkan oleh pengguna akhir, mereka jarang mengandung contols

aplikasi yang memadai. Oleh karena itu, tidak mengherankan bahwa banyak

organisasi mengalami masalah serius disebabkan oleh kesalahan

17

spreadsheet. Sebagai contoh, pada tanggal 17 Agustus 2007, artikel di

majalah CIO mengambarkan bagaimana kesalahan spreadsheet

menyebabkan perusahaan kehilangan uang, mengeluarkan pengumuman

pembagian dividen yang keliru, dan kesalahan melaporkan hasil keuangan.

Hal ini merupakan kesalahan yang fatal yang bisa dicegah dengan pengujian

cermat spreadsheet sebelum digunakan. Walaupun software spreadsheet

mengandung fitur "audit" yang dapat dengan mudah mendeteksi kesalahan

umum, spreadsheet dimaksudkan untuk mendukung keputusan untuk

mendeteksi kesalahan-kesalahan kecil. Namun demikian, survei profesional

di bidang keuangan menunjukkan bahwa hanya 2% perusahaan

menggunakan beberapa orang untuk memeriksa setiap sel spreadsheet,

yang merupakan satu-satunya cara yang dapat diandalkan untuk

mendeteksi kesalahan Efektif spreadsheet.

Ketersediaan (Availability)

Interupsi proses bisnis karena tidak tersedianya atau jika sistem

informasi dapat menyebabkan kerugian keuangan secara signifikan.

Akibatnya, COBIT bagian DS 4 membahas pentingnya memastikan bahwa

sistem dan informasi yang tersedia bisa digunakan. Tujuan utama adalah

untuk meminimalkan resiko tidak bekerjanya sistem. Hal ini tidak mungkin,

namun demikian, untuk benar-benar risiko tidak bekerjanya sistem. Oleh

karena itu, organisasi juga perlu kontrol yang dirancang untuk

memungkinkan dimulainya kembali operasi normal secara cepat setelah

terjadinya permasalahan pada sistem. Tabel 10-2 merangkumcara

mengontrol tujuan dengan dua cara.

Tabel 10-2Tujuan dan Kontrol Kunci

Objective Key Controls

1. meminimalisir risiko kegagalan tindakan pencegahan dengan

18

sistem melakukan perawatan

toleransi kesalahan

pusat data, dan desain

pelatihan

software antivirus

2. Memulihkan dan membuat

asumsi atas kegiatan normal

Prosedur membackup

Disaster recovery plan (DRP)

Business continuity plan (BCP)

Meminimalkan Risiko Kegagalan Sistem

Organisasi dapat memahami mengambil berbagai tindakan untuk

meminimalkan risiko COBIT dalam objektif DS 13.5 mengidentifikasihal yang

perlu dilakukan dengan melakukan tindakan pencegahan, kontrol dan benar

menyimpan media yang magnetic dan optik, untuk mengurangi risiko

kegagalan hardware dan software. Sebagai contoh, banyak organisasi

menggunakan redundant arrays if independent drives (RAID) bukan hanya

satu disk drive. Dengan RAID, data ditulis ke dirives beberapa disk hampir

bersamaan. Jadi, jika salah satu disk drive gagal, data dapat dengan mudah

diakses dari yang lain.

COBIT bagian DS 12 membahas pentingnya menemukan dan merancang

pusat data untuk meminimalkan risiko yang terkait dengan bencana alam

dan kesalahan manusia. Fitur desain secara umum adalah sebagai berikut:

• memperluas lantai penyimpanan, sebagai bentuk perlindungan kalau

terjadi banjir.

• Deteksi kebakaran dengan pendeteksi kebakaran untuk mengurangi

kemungkinan kerusakan akibat kebakaran.

19

• Sistem pendingin udara yang memadai untuk mengurangi kemungkinan

overheating peralatan komputer.

• Kabel dengan rancangan khusus yang tidak dapat dengan mudah

dicabut, mengurangi risiko mencabut sistem karena kerusakan yang

disengaja.

• Perlindungan untuk arus yang tidak stabil.

• Uninterruptible Power Supply (UPS) sistem menyediakan perlindungan

dalam hal terjadi pemadaman listrik berkepanjangan, menggunakan

daya baterai untuk memungkinkan sistem untuk beroperasi secara

fukup dalam proses untuk membuat cadangan data penting dan aman.

(Namun, penting untuk secara teratur memeriksa dan menguji baterai

dalam UPS Untuk memastikan bahwa hal itu akan berfungsi bila

diperlukan).

• Kontrol akses fisik mengurangi risiko pencurian atau kesalahan.

Dengan melakukan pelatihan dapat mengurangi resiko kegagalan

sistem. Melatih operator dengan membuat simulasi seolah-olah terjadi

kegagalan sistem, kemudian melakuan bagaimana memulihkan, dengan

kerusakan minimal. Itulah sebabnya COBIT mengontrol objektif DS 13.1

menekankan pentingnya mendefinisikan dan prosedur untuk memastikan

bahwa staf TI memahami tanggung jawab mereka.

Kegagalan sistem dapat disebabkan oleh adanya malware komputer (virus

dan worm). Oleh karena itu, penting untuk menginstal, menjalankan, dan

menjaga antivirus saat ini dan anti-spyware program. Program ini harus

secara otomatis dipakai tidak hanya untuk memindai e-mail, tetapi juga

semua media penyimpanan (CD, DVD, USB perangkat, dll) yang ada dalam

perusahaan.

Pemulihan dan Permulaan Awal Operasional Normal

20

Pencegahan kontrol yang didiskusikan pada bagian proses dapat

diminimalisir,tidak seluruhnya dieliminasi, pada resiko sistem downtime.

Kesalahan penggunaan hardware,masalah software atau kesalahan manusia

dapat menyebabakan data menjadi tidak dapat diakses. Oleh karena itu

mengapa back up prosedur dibutuhkan. Sebuah back up adalah salinan yg

jelas dari versi terbaru dari sebuah database,file, atau program software

yang dapat digunakan pada sebuah kejadian, originalnya tidak lama lagi

tersedia. Kejadian bencana alam dan terorisme dapat menghancurkan tidak

hanya data tapi juga keseluruhan informasi sistem. Oleh karena itu mengapa

organisasi juga membutuhkan pemulihan bencana dan perencanaan bisnis

secara berkelanjutan.

Prosedur back up suatu organisasi dan pemulihan bencana serta

perencanaan bisnis secara berkelanjutan mencerminkan jawaban

manajemen terhadap dua pertanyaan fundamental:

1. Seberapa banyak data yang sedang akan diciptakan kembali dari sumber

dokumen (jika tersedia) atau berpotensi hilang (jika tidak ada sumber

dokumen yang tersedia)?

2. Seberapa lama organisasi dapat berfungsi tanpa informasi sistemnya?

Gambar 10-3 menunjukkan hubungan antara dua pertanyaan

tersebut.ketika masalah terjadi, data tentang semua kejadian yang telah

terjadi sejak back up terakhir dihilangkan kecuali data tersebut dapat

dienter kembali kedalam sistem. Jadi, jawaban manajemen untuk pertanyaan

pertama menentukan recovery point obejective (RPO) atau sasaran poin

pemulihan sebuah organisasi yang mewakili jumlah maksimal data yang

berpotensi hilang. Jawaban atas pertanyaan kedua menentukan recovery

time objective (RTO) atau sasaran waktu pemulihan organisasi yang

mewakili jangka waktu yang berusaha untuk berfungsi tanpa sistem

informasinya.

21

Bagi beberapa organisasi,jawaban atas kedua pertanyaan tersebut

mendekati nol. Contohnya Penerbangan dan institusi finansial tidak dapat

beroperasi tanpa sistem informasi mereka,mereka juga dapat kehilangan

informasi tentang transaksi. pada organisasi seperti itu, tujuannya tidak

pada pemulihan cepat atas masalah,tapi resiliency. Solusinya adalah dengan

memperkerjakan real-time mirroring. Real-time mirroring termasuk

maintaining dua salinan dari dua database pada dua pust data yg terpisah

pada semua waktu dan mengaupdate setiap salinan dalam real-time seperti

setiap transaksi yang terjadi.jika suatu saat terjadi sesuatu pada satu pusat

data,organisasi dapat secara cepat mengganti semua kegiatan sehari2

dengan yang lainnya.

Walaubagaimanapun, Bagi organisasi lainnya penerimaan RPO dan

RTO mungkin dapat diukur dalam ukuran jam atau bahkan berhari-

hari.penerimaan tujuan-tujuan tersebut memerlukan prosedur back up data

ditambah pemulihan bencana dan kelancaran perencanaan bisnis.

Prosedur Backup Data

Prosedur data backup dirancang untuk sesuai dengan situasi dimana

informasi tidak selalu dapat diakses karena file-file yang relevan atau

database telah menjadi corrupted sebagai hasil dari kegagalan

hardware,masalah software,atau human eror, tapi sistem informasi itu

sendiri masih berfungsi. Beberapa perbedaan prosedur backup tersedia. A

full backup atau backup penuh adalah salinan nyata dari keseluruhan

database. Full backup adalah time-consuming,jadi kebanyakan organisasi

hanya melakukan full backup perminggu dan mensupplai mereka dengan

backup partial harian. Gambar 10-4 membandingkan dua tipe dari backup

partial harian.

1. Incremental backup termasuk hanya salinan data item yang telah

berubah sejak backup partial terakhir. Hal tersebut menghasilkan

seperangkat incremental backup file,yang setiap file terdiri dari setiap

22

file terdiri dari hasil transaksi satu hari. Restoration atau Perbaikan

termasuk loading pertama dan full backup terakhri dan kemudian diinstal

tiap kelanjutan incremental backup dari rangkaian yang cocok.

2. Differential backup. Semua Salinan differential backup atau backup

berbeda berubah dibuat sejak full backup atau backup penuh terakhir.

Jadi setiap file differential backup yang baru terdiri dari pengaruh

kumulatif dari semua aktivitas sejak full backup terakhir. Dengan

demikian, kecuali dari hari pertama mengikuti full backup, diffrential

backup harian memiliki waktu yang lebih lama daripada incremental

backup. Akan tetapi, restolution atau Perbaikan lebih simpel, karena full

backup terakhir membutuhkan untuk disuplemen dengan hanya

differential backup terbaru,daripada seperangkat file incremental backup

harian.

Tidak masalah prosedure backup mana yang digunakan, salinan

berlipat ganda seharusnya diciptakan. Satu salinan dapat disimpan pada on-

site, untuk penggunaan suatu kejadian dari masalah minor yang relativ

terjadi, seperti kerusakan hard drive. Pada kejadian dari masalah yang lebih

serius lagi, seperti kebakaran atau banjir, setiap salinan backup disimpan on-

site akan lebih mudah hancur atau tidak dapat diakses. Oleh karena itu,

salinan backup kedua perlu untuk disimpan off-site. File-file backup tersebut

dapat dipindahkan pada site penyimpanan yang jauh baik secara fisik

ataupun elektronik. pada kasus yang lain, kontrol keamanan yang sama

perlu untuk diaplikasikan untuk backup file yang digunakan untuk

23

melindungi salinan asli dari informasi. Hal itu berarti salinan backup dari data

sensitif harus dienkripsikan diantara tempat penyimpanan dan selama

transmisi elektronik. Akses ke backup file juga perlu dikontrol dan dimonitori

secara hati-hati.

Penting juga untuk melatih sistem penyimpanan secara periode dari

backupnya. hal tersebut berverifikasi bahwa prosedur backup bekerja

dengan benar dan bahwa media backup (tape atau disk) dapat dibaca

dengan sukses oleh hardware yang digunakan.

Backup dipakai hanya selama periode waktu yang relativ singkat.

Sebagai contoh,banyak organisasi bertahan hanya beberapa bulan dari

backup. Bagaimanapun, beberapa informasi harus disimpan lebih lama.

sebuah arsip adalah salinan dari database, master file, atau software yang

dipakai secara tidak langsung sebagai catatan historis, yang biasanya legal

dan memerlukan pengaturan. Sebagai backup, salinan arsip yang berlipat

ganda seharusnya dibuat dan disimpan pada lokasi yang berbeda. Tidak

seperti halnya backup, arsip jarang dienkripsikan karena mereka memiliki

rentetan waktu yang lama yang meningkatkan resiko kehilangan kunci

decryption. Akibatnya, kontrol akses secara fisik dan logis adalah alat pokok

untuk melindungi arsip file.

Media apa yang seharusnya digunakan untuk backup dan arsip-arsip,

tape atau disk? Disk backup lebih cepat dan disk mudah hilang. Tape lebih

murah, lebih mudah untuk dibawa, dan lebih berdurasi lama. Dengan

demikan, banyak organisasi menggunakan kedua media tersebut. Pertama

data diback up ke disk, untuk cepat, kemudian ditransfer ke tape.

Perhatian spesial perlu dibayar untuk backup dan pengarsipan e-mail,

karena telah menjadi repositori penting dari tingkah laku organisasi dan

informasi. Alih-alih, e-mail sering terdiri dari solusi-solusi untuk masalah

yang spesifik. E-mail juga biasanya terdiri dari informasi yang relevan

terhadap lowsnit. seharusnya menarik untuk sebuah organisasi untuk

menyadari suatu polis dari penghapusan semua e-mail secara periode, untuk

mencegah gugatan pengacara dari penemuan suatu "smoking gun" dan

24

untuk mencegah biaya penemuan e-mail yang diminta oleh partai lainnya.

Kebanyakan para ahli, menyarankan melawan seperti politisi-politisi, karena

ada beberapa hampir menjadi salinan-salinan dari e-mail yang disimpan di

arsip-arsip luar organisasi. Oleh karena itu, sebuah kewenangan menghapus

secara regular seluruh e-mail yang berarti bahwa organisasi tidak akan

dapat untk mengatakan bagian dalam cerita; pengadilan (dan hakim) hanya

akan membaca e-mail yang diciptakan oleh polis lainnya untuk

dipeselisihkan. Pernah juga ada kasus dimana pengadilan telah mendenda

organisasi jutaan dolar karena gagal memberikan e-mail yang diminta. Oleh

karena itu, organisasi perlu untuk mengbackup dan mengarsip e-mail

penting ketika purging secara periode sejumlah volume rutin, sisa-sisa e-

mail.

Pemulihan Bencana Alam dan Perencanaan Kelanjutan Bisnis

(Disaster Recovery and Business Continuity Planning)

Backup dirancang untuk masalah mitigasi ketika satu atau lebih file

atau database menjadi di karena hardware, software, atau human error.

Pemulihan Bencana Alam dan Perecanaan Kelanjutan Bisnis dirancang untuk

mitigasi masalah yang lebih serius.

Perencanaan pemulihan bencana atau Disaster Recovery Plan (DRP)

outline prosedur untuk menyimpan kembali fungsi organisasi IT pada suatu

kejadian yang pusat datanya terusak oleh bencana alam atau akibat dari

terorisme. Organisasi memiliki tiga pilihan dasar untuk menggantikan IT

infrastruktur mereka yang tidak hanya termasuk komputer,tapi juga jaringan

komponen seperti routers dan switches, software, data, akses internet,

printer, dan supplies. Pilihan pertama adalah untuk mengontrak untuk

kegunaan dari cold site. Yaitu sebuah gedung kosong diprewired untuk

keperluan akses telepon dan internet, ditambah sebuah kontrak dengan satu

atau lebih vendor untuk menyediakan semua perlengkapan yang perlu

dalam periode waktu yg spesifik. Cold site masih meninggalkan organisasi

tanpa penggunaan dari sistem informasi selama periode waktu,jadi sesuai

25

jika hanya ketika organisasi RTO pada satu hari atau lebih. Pilihan waktu

kedua adalah untuk mengontrak untuk penggunaan dari hot site, yaitu

sebuah fasilitas yang tidak hanya prewired untuk akses telepon dan internet

tapi juga tetdiri dari semua perlengkapan kantor dan komputer organisasi

yang perlu untuk menampilkan aktivitas esensi bisnis. Hot site secara tipikal

berhasil dalam RTO hitungan jam.

Masalah antara cold dan hot site adalah penyedia site secara tipikal

menjual berlebihan kapasitasnya, dibawah asumsi bahwa dalam sekali waktu

hanya sedikit klien yang akan perlu untuk menggunakan fasilitas. Asumsi

tersebut biasany dibenarkan. Pada kejadian bencana pada umumnya, seperti

badai katrina, mempengaruhi semua organisasi dalam area geografik,

bagaimanapun juga beberapa organisasi dapat menemukan bahwa mereka

tidak dapat meraih akses ke cold dan hot site mereka. Akibatnya, pilihan

ketiga pergantian infrastruktur bagi organisasi dengan jangka pendek RTO

adalah untuk membangun pusat data kedua sebagai back up dan

menggunakannya untuk implementasikan real-time mirroring.

Business continuity plan (BCP) atau kelanjutan perencanaan bisnis

menspesifikasikan bagaimana cara untuk meringkas tidak hanya operasional

IT tapi semua proses bisnis, termasuk pemindahan ke kantor baru dan

menyewa tempat sementara, jikambencana besar tidak hanya

menghancurkan pusat data organisasi tapi juga pusat kepala bagian.

Perencanaan seperti itu sangat penting karena lebih dari setengah

organisasi tanpa DRP dan BCP tidak pernah buka kembali setelah ditekan

untuk tutup lebih dari beberapa hari karena bencana. Maka, memiliki DRP

dan BCP dapat berarti perbedaan antara bertahan atas major catastrophe

seperti badai katrina atau 9/11 dan bangkrut.

Memiliki DRP dan BCP bagaimanapun juga tidaklah cukup. Kedua

perencanaan harus didokumentasikan dengan baik. Dokumentasi tersebut

seharusnta tidak hanya termasuk instruksi untuk notifikasi kesesuaian staf

dan langkah-langkah untuk mengambil ringkasan operasional, tapi juga

dokumentasu vendor dari semua hardware dan software. penting khususnya

26

untuk mendokumentasikan modifikasi numerous yang dibuat untuk

konfigurasi default, sehingga pergantian sistem memiliki fungsi yang sama

sebagai aslinya. Kegagalan melakukan hal tersebut dapat menciptakan biaya

substansial dan menunda implementasi proses pemulihan. Instruksi

operasional secara rinci juga dibutuhkan, khususnya jika pergantian

sementara telah disewa. Akhirnya, salinan dari seluruh dokumen perlu untuk

disimpan anatara on-site dan off-site sehingga dapat tersedia ketika

dibutuhkan.

Pengetesan secara periode dan revisi kemungkinan adalah komponen

yang paling penting dan efektif terhapa pemulihan bencana dan kelancaran

perencanaan bisnis. Kebanyakan perencanaan gagal meinisialkan tes

mereka karena tidak mungkin untuk memenuhi segala antisipasi yang bisa

saja salah. Waktu untuk menemukan masalah seperti itu tidak selama

emergenci aktual, tapi lebih pada pengaturan yang mana kelemahan dapat

dengan hati-hati dan melalui analisa dan perubahan yang sesuai pada

prosedur yang dibuat. Oleh karena itu pemulihan bencana dan kelancaran

perencanaan bisni perlu untuk dites pada akhir dasar annual untuk

meyakinkan bahwa mereka dengan akurat mencerminkan perubahan

terbaru pada perlengkapan dan prosedur. sangat penting khususnya untuk

mengetes prosedur termasuk dalam mentransfer operasi aktual pada cold

dan hot site. Akhirnya, dokumentasi DRP dan BCP Perlu untuk diperbaharui

untuk merefleksikan setiap perubahan dalam prosedur yang dibuat dalam

merespon untuk identifikasi masalah selama pengujian rencana-rencana

tersebut.

Pengaruh Virtualisasi dan Cloud Computing (Effects of Virtualization

and Cloud Computing)

Mesin virtual hanya koleksi dari file software. Oleh karena itu, jika

server fisik ditempatkan bahwa mesin gagal, file-file dapat diinstal pada host

mesin dalam hitungan menit. Maka, virtualisasi secara signifikan mengurangi

waktu yang diperlukan untuk memulihkan (RTO) dari masalah hardware.

27

Catat bahwa virtualisasi tidak mengeliminasi keperluan selama backup;

organisasi masih perlu untuk menciptakan periode "snapshots" dari dekstop

dan jaringan mesin virtual dan kemudian menyimpan snapshots pada

network drive sehingga mesin dapat diciptakan kembali. Virtualisasi dapat

juga digunakan untuk mendukung real-time mirroring yang mana dua

salinan dari setiap mesin virtual dijalankan berurutan di dua fisik host yang

terpisah. Setiap transaksi diproses disetiap mesin virtual. Jika satu gagal,

yang lainnya diambil tanpa jeda pada jaringan.

Cloud computing memiliki pengaruh positif dan negatif dalam

ketersediannya. Cloud computing secara tipikal memanfaatkan bank dari

jaringan yang redunda pada lokasi yang berlipatganda, dengan demikan

dapat mengurangi resiko bahwa bencana tunggal dapat membawa pada

sistem downtime dan kehilangan seluruh data. Walaubagaimanapun, jika

penyedia publik cloud bangkrut, akan sulit, jika tidak mungkin, untuk

menyelamatkan setiap data disimpan pada cloud. Oleh karena itu, sebuah

polis membuat backup regular dan menyimpan backup tersebut dimanapun

tempat lain daripada dengan penyedia cloud secara kritik. Sebagai

tambahan, akuntan perlu untuk menilai kelangsungan keuangan orang

banyak dalam jangka panjang dari penyedia cloud sebelum organisasi

menjalankan untuk sumber luar disetiap data atau aplikasinya untuk sebuah

cloud public.

Control perubahan

Alamat COBIT bagian AI 6, AI 7 , dan Ds 9 merupakan aspek yang

berbeda dari topik penting perubahan kontrol. Organisasi memodifikasi

sistem informasi untuk mencerminkan praktek-praktek bisnis baru dan

mengambil keuntungan dari kemajuan teknologi informasi. Perubahan

kontrol adalah proses formal yang digunakan untuk memastikan bahwa

modifikasi hardware, software, atau proses tidak mengurangi keandalan

sistem. Bahkan, perubahan kontrol yang baik sering menyebabkan kinerja

28

operasional secara keseluruhan menjadi lebih baik: pengujian dilakukan

secara hati-hati sebelum pelaksanaan untuk mengurangi kemungkinan

membuat perubahan yang menyebabkan sistem downtime, dokumentasi

yang menyeluruh akan cepat memfasilitasi "pemecahan masalah" dan

resolusi dari setiap masalah yang memang terjadi. Perusahaan dengan

proses kontrol yang baik juga kurang memungkinan untuk menderita

kerugian keuangan atau reputasi dari insiden keamanan.

Prosedur perubahan yang efektif memerlukan control teratur untuk

pemantauan perubahan yang tidak sah dan sanksi bagi siapa saja yang

sengaja memperkenalkan perubahan tersebut. Prinsip-prinsip lain dari

proses kontrol yang dirancang dengan perubahan yang baik meliputi:

Semua permintaan perubahan harus didokumentasikan dan mengikuti

format standar yang jelas dengan mengidentifikasi sifat perubahan,

alasan permintaan, tanggal permintaan, dan hasil dari permintaan.

Semua perubahan harus disetujui oleh tingkat manajemen yang tepat.

Persetujuan harus didokumentasikan secara jelas untuk memberikan

jejak audit. Manajer harus berkonsultasi dengan CISO atau manajer IT

tentang efek atau perubahan yang diajukan terhadap keandalan sistem.

Untuk menilai dampak dari perubahan yang diusulkan pada kelima

prinsip keandalan sistem, perubahan harus benar-benar diuji sebelum

pelaksanaan di lingkungan, Nonproduksi harus terpisah, sistem harus

benar-benar digunakan untuk proses bisnis sehari-hari. (teknologi

virtualisasi dapat digunakan untuk mengurangi biaya dalam membuat

pengujian terpisah dan pengembangan sistem). Data database dari file

lama dimasukkan ke dalam struktur data baru, kontrol percakapan

diperlukan untuk memastikan bahwa media penyimpanan data baru

bebas dari kesalahan. Sistem lama dan baru harus dijalankan secara

paralel setidaknya sekali dan hasilnya dibandingkan untuk

mengidentifikasi perbedaan. Auditor Internal harus meninjau proses

konversi data untuk akurasi.

29

Semua dokumentasi (Program petunjuk, deskripsi sistem, backup dan

rencana pemulihan bencana, dll) harus diperbarui untuk mencerminkan

perubahan berwenang untuk sistem.

Perubahan "darurat" atau penyimpangan dari kebijakan standar operasi

harus didokumentasikan dan dikenakan tinjauan formal serta proses

persetujuan sesaat setelah implementasi sebagai praktis. Semua

perubahan darurat perlu dicatat untuk menyediakan jejak audit.

rencana "backout" memerlukan pengembangan untuk kembali kepada

kasus konfigurasi sebelumnya dalam kasus. Perubahan tersebut

memerlukan persetujuan untuk terganggu atau ditinggalkan.

Pengguna hak dan keistimewaan harus dipantau dengan teliti pada

proses perubahan untuk memastikan bahwa pemisahan tugas yang tepat

bisa dipertahankan

Mungkin kontrol perubahan yang paling penting adalah pemantauan yang

memadai dan mereview atas tindakan manajemen untuk memastikan bahwa

perubahan yang diusulkan dan yang dilaksanakan berjalan konsisten dengan

rencana multiyear strategis organisasi. Tujuan dari pengawasan ini adalah

untuk memastikan bahwa sistem informasi organisasi terus efektif untuk

mendukung strategi. Banyak organisasi IT menciptakan komite kemudi untuk

melakukan pemantauan fungsi penting ini.

Ringkasan dan kesimpulan kasus

Laporan Jason dirancang untuk menilai efektivitas kontrol Northwest industri

dan memastikan integritas pengolahannya. Untuk meminimalkan entri data,

dan kesempatan dalam membuat kesalahan, Northwest industri

mengirimkan dokumen turnaround kepada pelanggan, yang kembali dengan

pembayaran mereka. Semua entri data dilakukan secara online, dengan

penggunaan luas dari rutinitas dan memasukkan validasi untuk memastikan

keakuratan dari komponen kunci laporan keuangan secara teratur lintas-

30

divalidasi dengan sumber independen. Misalnya, persediaan dihitung secara

triwulanan, dan hasil penghitungan fisik didamaikan dengan jumlah yang

disimpan didalam sistem.

Jason prihatin tentang efektivitas pengendalian yang dirancang untuk

memastikan ketersediaan sistem, namun. Dia mencatat bahwa meskipun

Northwest industri telah mengembangkan pemulihan bencana dan rencana

kelangsungan bisnis, rencana tersebut belum ditinjau atau diperbarui selama

tiga tahun. Perhatian yang lebih besar adalah fakta bahwa banyak bagian

dari rencana, termasuk pengaturan untuk situs dingin yang terletak di

California, belum pernah diuji. Keprihatinan Jason yang terbesar adalah

bagaimanapun itu berkaitan dengan prosedur cadangan. Semua file

mingguan pada hari Sabtu dimasukkan ke DVD, backup incremental tidak

dienkripsi, dan satu salinan tersebut disimpan di tempat ruang server utama.

Jason juga mendokumentasikan bukti kelemahan tersebut terkait dengan

perubahan kendali. Salah satu titik perhatian adalah temuan bahwa

perubahan "darurat" yang dibuat selama setahun terakhir tidak

didokumentasikan. Fakta Lainnya adalah fakta bahwa untuk menghemat

uang, Northwest industri memberikan programmer akses ke sistem

pemrosesan transaksi untuk membuat perubahan, daripada menggunakan

pengujian terpisah dan pengembangan sistem.

Jason menyimpulkan laporannya dengan laporan rekomendasi khusus untuk

mengatasi kelemahan yang telah ditemukan. Dia merekomendasikan bahwa

Northwest industri segera menguji cadangan prosedur restorasi dan

mengenkripsi file cadangan. Jason juga dianjurkan menguji rencana DRP dan

CBP. Rekomendasi lain adalah untuk membeli sebuah server yang akan

menggunakan perangkat lunak virtualisasi untuk membuat sebuah sistem

pengujian dan pengembangan serta membatasi akses programmer hanya

pada sistem virtual. Akhirnya, ia disarankan harus menetapkan seseorang

CIO untuk memperbarui dokumentasi untuk merekam efek "perubahan

31

darurat" yang dibuat selama tahun lalu dan menerapkan prosedur untuk

memastikan bahwa semua perubahan masa depan dapat didokumentasikan.

Jason merasa yakin sekali bahwa mereka dapat melaksanakan rekomendasi,

manajemen sangat yakin bahwa sistem informasi Northwest industri telah

memenuhi kriteria AICPA trust, kerangka layanan dan prinsip-prinsip

keandalan sistem.

32