BAB I

PENDAHULUAN

1.1 Latar Belakang

1.2 Rumusan Masalah

1.3 Tujuan Penulisan

 BAB II

PEMBAHASAN

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 Pengendalian
Input: Datanya : Bentuk desain,
 AC1 –persiapan dan  Tidak valid pembatalan dan
otoriasasi sumber data  Tidak diotorisasi penyimpanan dokumen,
 AC2 – mengumpulkan dan  Tidak lengkap otorisasi dan pemisahan
memasukkan sumber data  Tidak Akurat tugas pengendalian,
 AC3 – mengecek visual scanning,
ketepatan (akurasi), pengendalian data
kelengkapan dan masukan.
kebenaran
Proses: Kesalahan (eror) pada Pencocokan data, label
 AC4 – Proses Integritas output dan data yang berkas (file), jumlah
dan Validitas tersimpan. kumpulan (batch),
menguji penjumlahan
mendatar (cross
footing), zero balance
 (saldo nol), menulis
mekanisme
perlindungan,
pengendalian database
proses integritas.
Output:  Menggunakan Meninjau kembali dan
 AC5 – output review, laporan yang tidak merekonsiliasi, enkripsi
rekonsiliasi dan kesalahan akurat atau tidak dan pengendalian akses,
penanganan komplit memeriksa kesamaan
 AC6 – Kebenaran dan  Pengungkapan tidak (parity), teknik pesan
Integritas Transaksi sah dari informasi pengakuan.
sensitif (peka)
 Kerugian, perubahan
atau pengungkapan
informasi dalam
perjalanan

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 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.
 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.
 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:
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 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%.
 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)

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 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

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
penjualan dan rekonsiliasi total batch dihitung dalam langkah 1
memverifikasi bahwa tidak ada transaksi yang hilang.
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 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.
 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.
 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 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
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-2
Tujuan dan Kontrol Kunci

Objective Key Controls

1. meminimalisir risiko kegagalan  tindakan pencegahan dengan
sistem melakukan perawatan
 toleransi kesalahan
 pusat data, dan desain
 pelatihan
 software antivirus

2. Memulihkan dan membuat  Prosedur membackup

 asumsi atas kegiatan normal  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.
• 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

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.

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 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 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 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 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 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. 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 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.
 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.
 BAB III

PENUTUP

3.1 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-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 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.
 DAFTAR PUSTAKA

Romney, Marshall B., 2014, Sistem Informasi Akuntansi, Edisi 13, Salemba
Empat, Jakarta