MAKALAH

SISTEM INFORMASI AKUNTANSI II

Tentang : Pengendalian Integritas
Pemrosesan dan Ketersediaan

NAMA KELOMPOK 2 :
1. RAHMAWATI – 217 200 38
2. AWON FRITS OPO – 217 200 42
 KATA PENGANTAR

Puji syukur kami aturkan atas kehadirat Tuhan Yang Maha Esa,
karena atas berkat, rahmat dan hidayah-Nya sehingga kami selaku penyusun
dapat menyelesaikan makalah ini, yang baik bentuk maupun isinya kami akui
masih banyak kekurangan. Kami juga mengucapkan banyak terima kasih
kepada ibu Fitriana A. Mado, SE., MM selaku Dosen mata kuliah Sistem
Informasi Akuntansi II yang telah memberikan kami tugas makalah ini serta
membimbing kami. Mohon maaf jika dalam makalah ini terdapat kesalahan
dikarenakan keterbatasan pengetahuan yang kami miliki. Kami mengharapkan
kritik dan saran yang membangun dari semua pihak untuk perbaikan makalah
ini.

Palu, 15 April 2019

Penyusun
 DAFTAR ISI
Sampul : .......................................................................... i

Kata Pengantar : .......................................................................... ii

Daftar Isi : .......................................................................... iii

BAB I Pendahuluan :

A. Latar Belakang : .......................................................................... 1

B. Rumusan Masalah : .......................................................................... 1
C. Tujuan : .......................................................................... 1

BAB II Pembahasan/Isi :

A. Integritas Pemrosesan : .......................................................................... 2

B. Ketersediaan : .......................................................................... 12

BAB II Penutup :

A. Kesimpulan : .......................................................................... 19
B. Kritik dan Saran : .......................................................................... 19

Daftar Pustaka : .......................................................................... 20

 BAB I

PENDAHULUAN

A. Latar Belakang
Dewasa ini, perkembangan dunia bisnis sangat luar biasa. Sistem yang
ada dalam perusahaan pun sangat berkembang pesat. Mulai dari sistem input,
proses maupun output di desain sedemikian rupa agar perusahaan dapat
menjalankan fungsinya dengan baik. Perusahaan terus berupaya
mengembangkan sistemnya agar mereka dapat beraktivitas lebih baik lagi.
Namun, adanya sistem yang baik bukan berarti menjamin perusahaan untuk
dapat beraktivitas dengan baik. Perusahaan juga memiliki tantangan seperti
adanya kesalahan dalam input entri data, kesalahan dalam pemrosesan ,
penggunaan laporan yang tidak benar serta rusaknya sistem itu sendiri
terutama dalam pemrosesan dan ketersediaan. Untuk itu, perusahaan perlu
untuk melakukan pengendalian pemrosesan dan ketersediaan untuk mencegah
adanya hal-hal yang tidak diinginkan

B. Rumusan Masalah
1. Bagaiman pengendalian yang didesain untuk memastikan integritas
pemrosesan?
2. Bagaimana pengendalian yang didesain untuk memastikan ketersediaan
sistem?
C. Tujuan Penulisan
1. Untuk menyelesaikan tugas Sitem Informasi Akuntansi II yang
diberikan;
2. Untuk memahami tentang pengendalian yang didesain untuk memastikan
integritas pemrosesan; dan
3. Untuk memahami pengendalian yang didesain untuk memastikan
ketersediaan sistem.
 BAB II

PEMBAHASAN

A. Integritas Pemrosesan
Prinsip integritas pemrosesan dari Trust Service Framework
menyatakan bahwa sebuah sistem yag dapat diandalkan adalah sistem yang
menghasilkan informasi akurat, lengkap, tepat waktu dan valid.
a. Pengendalian Input
Frasa “sampah masuk, sampah keluar” menunjukkan pentingnya
pengendalian input. Jika data yang dimasukkan kedalam sebuah sistem
tidak akurat, tidak lengkap, atau tidak valid, maka output-nya juga akan
demikian. Akibatnya, hanya personel yang berwenang untuk bertindak
didalam otoritasnya yang harus mempersiapkan dokumen sumber. Selain
itu, bentuk desain, pembatalan dan penyimpanan dokumen sumber, serta
pengendalian entri data secara otomatis diperlukan untuk memberifikasi
validitas data input.
 Bentuk desain
Dokumen sumber dan bentuk lainnya harus didesain untuk
meminimalkan kemungkinan kesalahan dan kelalaian. Dua bentuk
utama desain pengendalian yang penting melibatkan dokumen sumber
sebelum penomoran (prenumbering) secara berurutan dan
menggunakan dokumen turnaround.
1. Seluruh dokumen sumber harus dinomori sebelumnya secara
berurutan, prenumbering tersebut meningaktakan pengendalian
dengan memperbolehkannya untuk memverifikasi bahwa tidak ada
dokumen yang hilang. Ketika dokumen data sumber secara
berurutan yang sebelumnya telah dinomori digunakan, sistem harus
deprogram untuk mengidentifikasi dan melaporkan dokumen
sumber yang hilang atau duplikatnya.
 2. Sebuah dokumen turnaround (turnaround document) adalah
catatan atas data perusahaan yang dikirimkan ke pihak eksternal
dan kemudian dikembalikan oleh pihak eksternal tersebut untuk
selanjutnya di input ke sistem. Contohnya adalah utility bill
(tagihan keperluan listrik, telepon, sewa, dan sebagainya) yang
dapat dibaca alat pemindaian khusus ketika tagihan dikembalikan
dengan pembayaran.
 Pembatalan dan Penyimpanan Dokumen Sumber
Dokumen-dokumen sumber yang telah dimasukkan kedalam
sistem harus dibatalkan sehingga mereka tidak dapat dengan sengaja
atau secara tidak jujur dimasukkan ulang kedalam sistem. Dokumen
kertas harus ditandai, contohnya, dengan memberi stempel “dibayar”.
Dokumen elektronik dengan cara yang sama dapat “dibatalkan”
dengan mengatur sebuah field tanda untuk mengindikasikan bahwa
dokumen tersebut telah diproses.
 Pengendalian entri data
Dokumen-dokumen sumber harus dipindai untuk kewajaran dan
kebenaran sebelum dimasukkan kedalam sistem. Meskipun demikian,
pengendalian manual ini harus dilengkapi dengan pengendalian entri
data otomatis, seperti berikut ini.
 Pengecekan field (field check) menentukan apakah karakter pada
sebuah field adalah dari jenis yang tepat. Sebagai contoh,
pengecekan pada field yang semestinya hanya berisi nilai numerik,
seperti kode pos Amerika Serikat, akan mengidentifikasikan
sebuah kesalahan jika kode pos tersebut berisi karakter alfabetis.
 Pengecekan tanda (sign check) menetukan apakah data pada
sebuah field memiliki tanda aritmatika yang sesuai. Sebagai
contoh, field kuantitas yang dipesan seharusnya tidak pernah
negatif.
 Pengecekan batas (limit check) menguji sejumlah numerik
terhadap nilai tetap. Sebagai contoh, field jam regular yang
 dikerjakan dalam input penggajian mingguan harus kurang dari
atau sama dengan 40 jam. Sama halnya, field upah per jam harus
lebih besar dari atau sama dengan upah minimum.
 Pengecekan jangkauan (range check) menguji apakah sejumlah
numerik berada pada batas terendah dan tertinggi yang telah
ditentukan sebelumnya. Sebagai contoh, sebuah promosi
pemasaran mungkin dilakukan hanya untuk prospek dengan
pendapatan antara $50.000 dan $99.999.
 Pengecekan ukuran (size check) memastikan bahwa data input
akan sesuai pada dalam field yang ditentukan. Sebagai contoh,
nilai 458.976.253 tidak akan cukup dalam field delapan digit.
Pengecekan ukuran terutama penting untuk aplikasi yang menerima
input pengguna akhir, menyediakan cara untuk mencegah
kerentanan limpahan buffer (buffer overflow).
 Pengecekan validitas (validity check) membandingkan kode ID
atau nomor rekening dalam data transaksi dengan data serupa
didalam file induk untuk memverifikasi bahwa rekening tersebut
ada. Sebagai contoh, jika nomr produk 65432 dimasukkan ke
dalam sebuah pesanan penjualan, komputer harus memverifikasi
bahwa memang benar ada produk 65432 didalam database
persediaan.
 Tes kewajaran (resonablenese test) menentukan kebenaran dari
hubungan logis antara dua item-item data. Contohnya, jam lembur
seharusnya nol bagi seseorang yang belum menghitung jumlah
maksimum jam regular dalam sebuah periode pembayaran.
 Nomor ID resmi (seperti nomor pegawai) dapat berisi cek digit
(check digit) yang dihitung dari digit lain. Contohnya, sistem dapat
menetapkan setiap pegawai baru nomor digitnya Sembilan,
kemudian menghitung digit kesepuluh dari Sembilan yang asli dan
menambahkan catatan nomor yang dihitung tersebut kesembilan
digit nomor yang asli untuk membentuk sebuah nomor ID 10 digit.
 Perangkat entri data kemudian dapat deprogram untuk menjalankan
verifikasi cek digit (check digit verification), yang melibatkan
penghitungan ulang cek digit untuk mengidentifikasi kesalahan
entri data.

b. Pengendalian Tambahan Entri Data Pemrosesan Batch

 Pemrosesan batch bekerja lebih efisien jika transaksi-transaksi disortir,
sehingga rekening-rekening yang terkena dampak berada dalam urutan
yang sama dengan catatan di dalam file induk. Sebagai contoh,
pemrosesan batch yang akurat pada transaksi penjualan untuk
memperbarui saldo rekening pelanggan mensyaratkan transaksi disortir
terlebih dahulu berdasarkan nomor rekening pelanggan. Sebuah
pengecekan berurutan (sequence check) menguji apakah batch atas
input data berada dalam urutan numerik atau alfabetis yang tepat.
 Sebuah log kesalahan yang mengidentifikasikan kesalahan input data
(tanggal, penyebab, masalah) memudahkan pemeriksaan tepat waktu
dan pengumpulan ulang atas transaksi yang tidak dapat diproses.
 Total batch (batch total) merangkum nilai-nilai numerik bagi sebuah
batch atas catatan input. Berikut ini adalah tiga total batch yang sering
digunakan :
1. Total financial (financial total) menjumlahkan sebuah field
yang berisi nilai-nilai moneter; seperti total jumlah dolar dari
seluruh penjualan untuk sebuah batch transaksi penjualan.
2. Total hash (hash total) menjumlahkan sebuah field numerik
non-finansial, seperti field total kuantitas yang dipesan didalam
sebuah batch transaksi penjualan.
3. Jumlah catatan (record count) adalahnya banyaknya catatan
dalam sebuah batch.
c. Pengendalian tambahan Entri Data Online
 Prompting, dimana sistem meminta tiap-tiap item data input dan
menunggu respons yang dapat diterima, memastikan bahwa seluruh
data yang diperlukan telah dimasukkan (dengan kata lain, prompting
adalah sebuah pengecekan kelengkapan secara online).
 Verifikasi closed-loop (closed-loop verivication) mengecek ketepatan
dari data input dengan menggunakannya untuk mengambil dan
penampilkan informasi terakit lainnya. Sebagai contoh, jika seorang
petugas memasukkan nomor rekening, sistem dapat mengambil dan
menampilkan nama rekening sehingga petugas tersebut dapat
memverifikasi bahwa nomor rekening yang tepat telah dimasukkan.
 Sebuah log transaksi menyertakan sebuah catatan mendetail dari
seluruh transaksi termasuk pengidentifikasian transaksi khusus,
tanggal dan waktu entri, serta siapa yang memasukkan transaksi. Jika
sebuah file online dirusak, log transaksi dapat digunakan untuk
memulihkan file. Jika sebuah kegagalan fungsi (malfungsi) untuk
sementara menutup sistem, maka log transaksi dpat digunakan untuk
memastikan bahwa transaksi tidak hilang atau dimasukkan dua kali.

d. Pengendalian Pemrosesan
Pengendalian juga diperlukan untuk memastikan bahwa data diproses
debgan benar. Pengendalian pemrosesan yang penting mencakup kegiatan
sebagai berikut.
 Pencocokan data. Dalam kasus-kasus tertentu, dua atau lebih item
dari data harus dicocokkan sebelum sebuah tindakan dilakukan.
Sebagai contoh, sebelum membayar kepada seorang vendor, sistem
harus memverivikasi bahwa informasi pada faktur vendor sesuai
dengan informasi dalam pesanan pembelian dan laporan penerimaan.
 Label file. Label file perlu dicek untuk memastikan bahwa file yang
benar dan terkini sedang diperbarui. Baik label ekspternal yang dapat
dibaca oleh manusia maupun label internel yang tertulis dalam bentuk
 yang dapat terbaca mesin dalam media pencatatan data harus
digunakan. Dua jenis label internel yang penting adalah catatan kepala
dan trailer. Catatan kepala (header record) ditempatkan diawal setiap
file dan memuat nama file, tanggal kadaluwarsa, serta data identifikasi
lainnya. Catatan trailer (trailer record) diletakkan pada akhir file;
dalam file transaksi, catatan trailer memuat total batch yang dihitung
selama input.
 Perhitungan ulang total batch. Total batch harus dihitung ulang
setiap masing-masing catatan transaksi diproses, dan total dari batch
tersebut harus dibandingkan dengan nilai-nilai dalam catatan trailer.
Jika sebuah perbedaan total financial atau hash dapat dibagi dengan
angka 8 kemungkinan yang menyebabkan adalah kesalahan transposisi
(transposition error), dimana dua digit yang berdekatan secara tidak
sengaja terbalik (misalnya, 46 bukannya 64). Kesalahan transposisi
mungkin nampaknya sepele, tetapi dapat memiliki konsikuensi
financial yang sangat besar. Sebagai contoh, pertimbangkan efek dari
kesalahan pencatatan tingkat bunga pinjaman menjadi 6,4% bukannya
4,6%.
 Pengujian saldo cross-footing dan saldo nol. Biasanya total dapat
dihitung dengan berbagai cara. Sebagai contoh, dalam spreadsheet
sebuah grand total dapat dihitung dengan menjumlahkan sebuah
kolom dari total baris atau dengan menjuamlahkan sebuah baris dari
total kolom. Pengujian saldo nol (zero-balance test) menerapkan
logika yang sama untuk memverivikasi ketepatan pemrosesan yang
melibatkan rekening kontrol. Sebagai contoh, rekening kliring
penggajian diterbitkan sebesar total gaji kotor kepada seluruh pegawai
dalam satu periode waktu tertentu. Kemudian total gaji kotor tersebut
dikreditkan sebesar jumlah dari seluruh biaya tenaga kerja yang
dialokasikan ke berbagai kategori biaya. Rekening kliring penggajian
harus memiliki saldo nol setelah kedua set entri telah dibuat; sebuah
saldo bukan nol mengindikasikan kesalahan pemrosesan.
  Mekanisme write-protection. Mekanisme ini melindungi terhadap
menimpa (overwriting) atau menghapus (erasing) file data yang
disimpan dalam media magnetic. Mekanisme write-protection telah
lama digunakan untuk melindungi file induk dari kerusakan yang tidak
disengaja. Sebagai contoh, label-label radio frequency identification
(RFID) digunakan dalam melacak kebutuhan persediaan untuk
melindungi penulisan (write-protected), sehingga pelanggan yang
curang tidak dapat mengubah harga barang dagang.
 Pengendalian pembaruan secara bersamaan. Kesalahan dapat
terjadi ketika dua pengguna lebih berupaya untuk memperbarui catatan
yang sama secara bersamaan. Pengendalian pembaruan secara
bersamaan (concurrent update controls) mencegah kesalahan tersebut
dengan mengunci satu pengguna sampai sistem telah selesai
memproses transaksi yang dimasukkan oleh yang lainnya.

e. Pengendalian Output
Pengecekan yang hati-hati terhadap output sistem memberikan
pengendalian tambahan atas integritas pemrosesan. Pengendalian output
yang penting meliputi:
 Pemeriksaan pengguna terhadap output. Para pengguna harus
dengan cermat memeriksa output sistem untuk memverifikasi bahwa
output-nya masuk akal, lengkap, dan pengguna adalah penerima yang
dituju.
 Prosedur rekonsiliasi. Secara periodik, seluruh transaksi dan
pembaruan sistem lainnya harus direkonsiliasi untuk laporan
pengendalian, laporan status/pembaruan file, atau mekanisme
pengendalian lainnya. Selain itu, rekening buku besar harus
direkonsiliasi dengan total rekening buku pembantu secara teratur.
Sebagai contoh, saldo dari rekening kontrol persediaan dalam buku
besar harus sama dengan jumlah dari saldo barang di dalam database
 persediaan. Hal yang sama berlaku untuk rekening kontrol pada
piutang, asset modal dan utang usaha.
 Rekonsiliasi data eksternal. Total database harus di rekonsiliasi
secara periodik dengan data yang dikelola diluar sistem. Sebagai
contoh, jumlah catatan pegawai di file penggajian dapat dibandingkan
dengan total jumlag pegawai di database sumber daya manusia untuk
mendeteksi upaya menambahkan pegawai-pegawai fiktif ke database
penggajian. Sama halnya, persediaan ditangan harus dihitung secara
fisik dan dibandingkan dengan kuantitas ditangan yang tercatat di
database.
 Pengendalian transmisi data. Organisasi juga perlu
mengimplementasikan pengendalian yang didesain untuk
meminimalkan resiko kesalahan transmisi data. Setiap kali perangkat
penerima mendeteksi sebuah kesalahan transmisi data, ia memita
perangkat pengirim untuk mentransmisikan ulang data tersebut. Secara
umum, ini terjadi secara otomatis, dan pengguna tidak sadar bahwa
pengendalian transmisi telah terjadi. Sebagai contoh, transmission
control protocol (TCP) menentukan urutan nomor untuk setiap paket
dan menggunakan informasi tersebut untuk memverifikasi bahwa
seluruh paket telah diterima dan menyusun kembali dalam urutan yang
benar. Dan pengendalian transmisi data yang umum lainnya adalah
checksum dan bit paritas.
1. Checksum. Ketika data ditransmisikan, perangkat pengirim
dapat menghitung sebuah hash dari file tersebut, yang disebut
chekcum.
2. Bit Paritas. Komputer merepresentasikan karakter sebagai
sebuah set digit biner yang disebut bit. Setiap bit memiliki 2
nilai yang mungkin: 0 atau 1. Kebanyakan komputer
menggunakan skema pengodean 7 bit, yang lebih dari cukup
untuk merepresentasikan 26 huruf dalam alphabet bahasa
inggris (baik huruf besar maupun kecil), angka 0 sampai 9, dan
 berbagai symbol khusus ($, %, &, dsb). Sebuah bit paritas
(parity bit) adalah digit ekstra yang ditambahkan awal pada tiap-
tiap karakter yang dapat digunakan untuk mengecek ketepatan
transmisi. Dua skema dasar disebut sebagai paritas genap dan
paritas ganjil.

f. Contoh Ilustratif : Pemrosesan Penjualan Kredit

Saat ini kita menggunakan pemrosesan penjualan kredit untuk
mengilustrasikan seberapa banyak pengendalian aplikasi yang telah
membahas fungsi sebenarnya. Setiap catatan stransaksi meliputi data
berikut: nomor faktur penjualan, nomor rekening pelanggan, nomor barang
persediaan, kuantitas terjual, harga penjualan dan tanggal pengiriman. Jika
pelanggan membeli lebih dari satu produk, maka akan ada beberapa nomor
barang persediaan, kuantitas terjual, dan harga yang terkait dengan setiap
transaski menjualan. Pemrosesan transaksi-transaksi ini mencakup
tahapan-tahapan berikut: (1) memasukkan dan mengedit data transaksi; (2)
memperbarui catatan pelanggan dan persediaan (jumlah dari pembelian
kredit ditambahkan ke saldo pelanggan; untuk setiap barang persediaan,
kuantitas terjual dikurangkan dari kuantitas ditangan); dan (3) menyiapkan
dan mendistribusikan dokumen pengiriman dan/atau penagihan.
 Pengendalian Input Setelah transaksi penjualan dimasukkan, sistem
menjalankan beberapa pengujian validasi pendahuluan. Pengecekan
validitas mengidentifikasi transaksi dengan jumlah rekening yang tidak
valid atau nomor barang persediaan yang tidak valid. Pengecekan field
memverifikasi bahwa field kuantitas yang dipesan dan harga hanya
memuat nomor dan pada field tanggal mengikuti format
MM/DD/YYYY. Pengecekan tanda memverifikasi bahwa field
kuantitas yang terjual dan harga penjualan memuat angka positif.
Sebuah pengecekan jangkauan memverfikasi bahwa tanggal
pengiriman tidak lebih cepat dari tanggal saat ini tidak pula lebih lama
dari kebijakan pengiriman yang diiklankan perusahaan. Sebuah
 pengecekan kelengkapan menguji apakah setiap field memerlukan
(misalnya, alamat pengiriman) yang kosong. Jika pemrosesan batch
yang digunakan, penjualan dikelompokkan kedalam batch (ukuran
yang umum = 50) dan salah satu dari total batch berikut dihitung dan
disimpan dengan batch: total financial dari total jumlah penjualan,
total hash dari nomor faktur, atau jumlag catatan.
 Pengendalian Pemrosesan Sistem membaca catatan kepala dari file
induk pelanggan dan persediaan serta memverifikasi bahwa versi
terbaru sedang digunakan. Sebagai mana setiap faktur penjualan yang
sedang diproses, pengecekan batas digunakan untuk memverifikasi
bahwa penjualan yang baru tidak meningkatkan saldo rekening
pelanggan melebihhi batas kredit yang telah ditetapkan sebelumnya.
Jika melebihi, transaksi sementara dikesampingkan dan sebuah
pemberitahuan dikirim ke manajer kredit. Jika penjualan diproses,
pengecekan tanda memverifikasi bahwa kuantitas ditangan yang baru
untuk setiap barang persediaan lebih besar atau sama dengan nol.
Sebuah pengecekan jangkauan memverifikasi bahwa setiap harga jual
barang berada dalam batas yang telah diatur sebelumnya.
 Pengendalian Output Dokumen penagihan dan pengiriman hanya
diarahkan kepada pegawai yang diotorisasi di departemen akuntansi
dan pengiriman, yang secara visual menginspeksi dokumen-dokumen
tersebut untuk kesalahan yang jelas. Sebuah laporan pengendalian
yang merangkum transaksi yang diproses dikirim ke manajer
pengendalian penjualan, akuntansi dan persediaan untuk ditinjau.
Setiap kuartal, persediaan di dalam gudang dihitung secara fisik dan
hasilnya dibandingkan dengan kuantitas yang tercatat ditangan untuk
setiap barang. Penyebab perbedaan diselidiki dan jurnal penyesuaian
dibuat untuk memperbaiki kuantitas yang tercatat.
g. Pengendalian Integritas Pemrosesan dalam Spreadsheet
Sebagaian besar organisasi memiliki ribuan spreadsheet yang
digunakan untuk mendukung pembuatan keputusan. Pentingnya
spreadsheet bagi pelaporan keuangan direfleksikan dalam fakta bahwa
ISACA mendokumentasikan IT Control Objectives for Sarbanes-Oxley
yang berisi lampiran terpisah yang secara spesifik menjelaskan
pengendalian integritas pemrosesan yang harus diterapkan dalam
spreadsheet. Meskipun demikian, pengguna akhir hampir selalu
megembangkan spreadsheet, mereka jarang penampung pengendalian
aplikasi yang memadai. Oleh karena itu, tidaklah mengejutkan bahwa
banyak organisasi telah mengalami masalah-masalah serius yang
disebabkan oleh kesalahan spreadsheet. Sebagai contoh, pada 17 agustus
2007, artikel dalam CIO Magazine menjelaskan bagaimana kesalahan
spreadsheet menyebabkan perusahaan kehilangan uang, menerbitkan
pengumuman pembayaran dividen yang besar, dan salah melaporkan hasil
keuangan.
B. Ketersediaan
Gangguan dalam proses bisnis yang dikarenakan tidak tersedianya
sistem atau informasi dapat menyebabkan kerugian keuangan yang signifikan.
Akibatnya, proses pengendalian DSS01 dan DSS 04 COBIT 5 menunjukkan
pentingnya memastikan bahwa sistem dan informasi tersedia setiap saat
dibutuhkan oleh pengguna. Tujuan utamanya adalah untuk meminimalkan
risiko penghentian sistem (system downtime). Meskipun demikian,
ketersediaan sistem dan informasi mustahil untuk sepenuhnya mengeliminasi
risiko penghentian. Oleh karena itu, oragnisasi juga perlu memiliki
pengendalian yang didesain untuk memungkinkan pelanjutan (resumption)
cepat dari operasi normal setelah ada kejadian yang mengganggu ketersediaan
sistem.

a. Meminimalkan Risiko Penghentian Sistem

Organisasi dapat melakukan berbagai tindakan untuk meminimalkan
resiko penghetian sistem. Praktek manajemen DSS01.5 COBIT 5
mengidentifikasikan kebutuhan akan pemeliharaan yang preventif, seperti
membersihkan disk drive dan menyimpan media magnetik dan obtik
dengan tepat, untuk mengurangi risiko kegagalan perangkat keras dan
lunak. Penggunaan komponen-komponen yang berulang menyediakan
toleransi kesalahan (fault tolerance), yang merupakan kemampuan
sebuah sistem untuk terus berfungsi dalam kejadian ketika sebuah
komponen tertentu gagal. Sebagai contoh, banyak perusahaan
menggunakan redundant arrays of independent drives (RAID) bukan
hanya satu disk drive. Dalam menggunakan RAID, data dituliskan ke
berbagai disk drive secara bersamaan. Dengan demikian, jika satu disk
drive gagal maka data dapat segera diakses dari yang lainnya.
Praktik manajemen DSS01.04 dan DSS01.05 COBIT 5 menunjukkan
pentingnya meletakkan dan mendesain pusat-pusat data yang menaungi
server tugas kritis dan database sehingga meminimalkan risiko yang
 terkait dengan bencana alam dan yang disebabkan manusia. Fitur-fitur
desain umumnya meliputi sebagai berikut.
 Lantai yang tinggikan memberikan perlindungan yang disebabkan oleh
banjir.
 Pendeteksi api dan perangkat penekanan mengurangi kemungkinan
kerusakan akibat kebakaran.
 Sistem pendingin udara yang memadai untuk mengurangi
kemungkinan kerusahan bagi peralatan komputer karena terlalu panas
atau lembab.
 Table dengan tancapan khusus yang tidak dapat diganti dengan mudah
menurunkan risiko kerusakan sistem karena mencabut tanpa sengaja
pada perangkat tersebut.
 Perangkat antipetir memberikan perlindungan terhadap fluktuasi daya
temporer yang mungkin menyebabkan kerusakan computer dan
peralatan jaringan lainnya.
 Sebuah sistem uninterruptible power supply (UPS) atau suplai daya
bebas gangguan memberikan perlindungan dari kejadian sebuah listrik
berkepanjangan dengan menggunakan tenaga baterai yang
memungkinkan sistem peroperasi cukup lama untuk menadangkan
data penting dan mematikan (shutdown) dengan aman. (meskipun
demikian, pentingnya untuk menginspeksi secara teratur dan menguji
baterai dalam sebuah UPS untuk memastikan bahwa UPS akan
berfungsi ketika diperlukan).
 Pengendalian akses fisik mengurangi risiko pencurian atau kerusakan.

b. Pemulihan dan Penerusan Operasi Normal

Pengendalian preventif yang didiskusikan pada bagian sebelumnya
dapat meminimalkan, tetapi tidak secara keseluruhan mengeliminasi,
risiko penghentian sistem. Kegagalan perangkat keras, masalah perangkat
lunak, atau kesalahan manusia dapat menyebabkan data tidak dapat
diakses. Itulah mengapa praktek manajemen DSS04.07 COBIT 5
mendiskusikan prosedur backup yang sesuai. Sebuah backup adalah
sebuah salinan yang sama persis atas versi terbaru dari database, file, atau
program perangkat luna yang dapat digunakan jika data aslinya tidak lagi
tersedia. Meskipun demikian, backup hanya memusatkan ketersediaan data
dan perangkat lunak. Bencana alam atau tindakan teroris tidak hanya dapat
menghancurkan data, tetapi juga seluruh sistem informasi. Itulah mengapa
organisasi juga memerlukan rencana pemulihan bencana dan rencana
kelangsungan bisnis (DRP-Disaster Recovery Plans dan BCP-Business
Continuity Plans).
 Prosedur Backup data
Prosedur backup data didesain untuk menghadapi dimana
informasi tidak dapat diakses karena file atau database yang relevan
telah menjadi korup/rusak akibat kegagalan perangkat keras, masalah
perangkat lunak, atau kesalahan manusia, namun sistem informasinya
masih berfungsi. Ada beberapa prosedur backup yang berbeda.
Backup penuh (full backup) adalah sebuah salinan tepat dari
keseluruhan sebuah database. Tindakan tersebut membutuhkan banyak
waktu, hingga sebagian besar organisasi hanya melakukan backup
penuh secara mingguan dan melengkapinya dengan backup parsial
harian. Dua jenis backup parsial harian:
1. Sebuah backup inkremental (incremental backup) hanya
melibatkan penyalinan item-item data yang telah berubah sejak
backup parsial terakhir. Salinan ini menghasilkan sebuah set file
backup inkremental, masing-masing memuat hasil dari transaksi-
transaksi yang terjadi dalam satu hari. Pengembalian melibatkan
dari backup penuh terakhir dan kemudian memasangkan setiap
backup inkremental lanjutan dalam urutan yang sesuai.
2. Sebuah backup diferensial (differential backup) menyalin seluruh
perubahan yang dibuat sejak backup penuh terakhir. Jadi, tiap file
backup diferensial yang baru membuat efek kumulatif dari seluruh
aktivitas sejak backup penuh terakhir. Akibatnya, selain utnuk satu
 hari setelah backup penuh, backup diferensial harian membutuhkan
waktu yang lebih lama dibandingkan backup inkremental.
Pengembaliannya lebih sederhana, meski demikian, backup penuh
terakhir hanya perlu dilengkapi dengan backup diferensial yang
paling terkini saja, bukannya sebuah set file backup inkremental
harian.

Tidak peduli prosedur backup mana yang digunakan, barbagai

salinan backup harus dibuat. Satu salinan dapat disimpan ditempat,
untuk digunakan dalam kejadian atas masalah-masalah yang relative
minor, seperti kegagalan atas hard drive. dalam kejadian atas sebuah
masalah-masalah yang lebih serius, seperti kebakaran atau banjir,
semua salinan backup yang disimpan ditempat mungkin akan hancur
atau tidak dapat diakses. Oleh karena itu, sebuah salinan backup kedua
perlu disimpan diluar tempat. File backup ini dapat dikirimkan
ketempat situs penyimpanan jarak jauh baik secara fiisik (misalnya,
dengan kurir) atau secara elektronik dalam kasus lainnya, pengendalian
keamanan yang sama perlu diterapkan pada file backup yang
digunakan untuk melindungi salinan asli informasi tersebut. Ini berarti
bahwa salinan backup atas data sensitive harus dienkripsi baik dalam
penyimpanan maupun selama transimis elektronik. Akses terhadap file
backup juga perlu dikendalikan dan diawasi dengan cermat.

 Perencanaa pemulihan Bencana dan Kelangsungan Bisnis

Sejumlah backup didesain untuk mengatasi masalah-masalah
ketika satu atau lebih file atau database rusak karena kesalahan
perangkat keras, perangkat luna, dan manusia. DRP dan BCP didesain
utnuk mengatasi masalah-masala yang lebih serius.
Sebuah rencana pemulihan bencana (Disaster Recovery Plan –
DRP) menguraikan prosedur-prosedur untuk mengembalikan fungsi TI
sebuah organisasi akibat kejadian hancurnya pusat data karena bencana
alam atau tindakan terorisme. Organisasi memiliki tigas pilihan dasar
untuk mengganti infrastruktur TI-nya, termasuk tidak hanya computer,
tetapi juga komponen-komponen jaringan seperti router dan switch,
perangkat lunak, data, akses internet, printer, dan suplai. Pilihan
pertama adalah kontrak untuk menggunakan sebuah situs dingin (cold
site), yang merupakan sebuah bangunna kosong yang diberi kabel
sebelumnya untuk akses telepon dan internet yang memadai, ditambah
kontrak dengan satu vendor atau lebih untuk menyediakan seluruh
peralatan yang diperlukan dalam satu periode waktu tertentu. Sebuah
situs dingin masih meniggalkan organisasi tanpa penggunaan sistem
informasinya dalam satu periode waktu, sehingga situs dingin ini
hanya sesuai ketika RTO organisasi adalah satu hari atau lebih. Pilihan
kedua adalah kontrak untuk menggunakan sebuah situs panas (hot
site), yang merupakan sebuah fasilitas yang tidak hanya diberi kabel
sebelumnya untuk akses telepon dan internet, tetapi juga terdiri atas
seluruh peralatan komputasi dan peralatan kantor yang dibutuhkan
organisasi untuk menjalankan aktivitas bisnis pokoknya. Sebuah situs
panas biasanya hasil dari sebuah RTO selama berjam-jam.
Masalah dengan situs dingin maupun situs panas adalah bahwa
penyedia situs biasanya menjual melebihi kapasitas, dengan asumsi
bahwa dalam satu waktu hanya ada beberapa klien yang akan perlu
untuk menggunakan fasilitas tersebut. Asumsi ini biasanya dijamin.
Ketika terjadi sebuah kejadian atas bencana besar, seperti badai katrika
dan sandy yang memengaruhi seluurh organisasi dalam sebuah area
geografis, meski demikian, beberapa organisasi mungkin merasa
bahwa mereka tidak dapat memperoleh akses kesitus dingin dan panas
mereka. Akibatnya, sebuah opsi pengganti infrastruktur ketiga bagi
organisasi dengan RTO yang sangat singkat adalah menetapkan sebuah
pusat data kedua sebagai sebuah backup dan menggunakannya untuk
mengimplementasikan real-time mirroring.
Sebuah rencana kelangsungan bisnis (business continuity plan -
BCP) menspesifikasikan bagaimana untuk merangkum tidak hanya
 fungsi TI, tetapi seluruh proses bisnis, termasuk relokasi ke kantor
baru dan menggunakan pengganti sementara, dalam kejadian ketika
sebuah kerusakan besar menghancurkan tidak hanya pusat data sebuah
organisasi, tetapi juga kantor utamanya. Prencanaan seperti itu penting,
karena lebih dari separuh organisasi tanpa DRP dan BCP tidak pernah
beroperasi kembali setelah dipaksa tutup selama beberapa hari karena
sebuah bencana. Jadi, dengan memiliki baik DRP dan BCP dapat
menunjukkan perbedaan antara bertahan dari sebuah kerusakan besar
seperti badai atau serangan teroris dengan menghentikan bisnis.

 Efek dari Virtualisasi dan Komputasi Cloud

Virtuaslisasi dapat secara signifikan meningkatkan efektifitas dan
efisiensi dari pemulihan bencana dan penerusan operasi normal.
Sebuah mesin virtual hanyalah sebuah kumpulan file perangkat lunak.
Oleh karena itu, jika server fisik yang menampung file tersebut gagal,
maka file dapat dipasang pada mesin penampung lainnya dalam
beberapa menit. Jadi, virtualisasi secara signifikan mengurangi waktu
yang diperlukan untuk memulihkan (RTO) dari masalah perangkat
keras. Ingat bahwa virtualisasi tidak mengeliminasi kebutuhan untuk
backup; organisasi masih perlu membuat “snapshoot” periodik dari
desktop dan mesin-mesin virtual server kemudian menyimpan
sejumlah snapshoot tersebut dalam sebuah penampung jaringan
sehingga mesin dapat dibuat ulang. Vortualisasi juga dapat digunakan
untuk mendukung real-time mirroring dimana dua salinan dari tiap-tiap
mesin virtual dijalankan dalam tandem pada dua penampung fisik
terpisah. Setiap transaksi diproses dalam kedua mesin virtual. Jika satu
gagal, yang lain menambil tanpa adanya jeda dalam layanan.
Komputasi cloud memiliki efek posotif dan negatif dalam
ketersediaan. Komputasi cloud biasanya memanfaatkan bank atas
server berlebih dalam berbagai lokasi, sehingga menurunkan risiko
bahwa sebuah kerusakan tunggal dapat mengakibatkan penghentian
sistem dan hilangnya semua data. Meski demikian, jika sebuah
penyedia cloud public keluar dari bisnis, ini mungkin sulit, jika
memungkinkan, untuk mendapatkan kembali semua data yang
disimpan dalam cloud tersebut. Oleh karenanya, sebuah kebijakan atas
pembuatan backup teratur dan menyimpannya pada tempat lain dari
penyedia cloud sangatlah penting. Sebagai tambahan, para akuntan
perlu menilai kelangsungan financial jangka panjang dari sebuah
penyedia cloud sebelum organisasi melakukan alih daya data atau
aplikasinya ke sebuah cloud publik.
 BAB III
PENUTUP

A. Kesimpulan
1. Prinsip integritas pemrosesan dari Trust Service Framework
menyatakan bahwa sebuah sistem yag dapat diandalkan adalah sistem
yang menghasilkan informasi akurat, lengkap, tepat waktu dan valid.
2. Gangguan dalam proses bisnis yang dikarenakan tidak tersedianya
sistem atau informasi dapat menyebabkan kerugian keuangan yang
signifikan. Akibatnya, proses pengendalian DSS01 dan DSS 04
COBIT 5 menunjukkan pentingnya memastikan bahwa sistem dan
informasi tersedia setiap saat dibutuhkan oleh pengguna. Tujuan
utamanya adalah untuk meminimalkan risiko penghentian sistem
(system downtime). Meskipun demikian, ketersediaan sistem dan
informasi mustahil untuk sepenuhnya mengeliminasi risiko
penghentian. Oleh karena itu, oragnisasi juga perlu memiliki
pengendalian yang didesain untuk memungkinkan pelanjutan
(resumption) cepat dari operasi normal setelah ada kejadian yang
mengganggu ketersediaan sistem.

B. Kritik dan Saran

Menyadari bahwa penulis masih jauh dari kata sempurna, kedepannya
penulis akan lebih fokus dan details dalam menjelaskan tentang makalah
ini dengan sumber - sumber yang lebih banyak yang tentunya dapat di
pertanggung jawabkan. Untuk saran bisa berisi kritik atau saran terhadap
penulisan juga bisa untuk menanggapi terhadap kesimpulan dari bahasan
makalah yang telah dijelaskan. Terima kasih.
 DAFTAR PUSTAKA

Romney B,Marshall. Steinbart,Paul John.Sistem Informasi Akuntansi, Edisi

13.2016.Jakarta Selatan: Salemba Empat.