BAB 13 Kontrol Integritas dan Ketersediaan Pemrosesan

pengantar

Dua bab sebelumnya membahas tiga prinsip pertama keandalan sistem yang diidentifikasi dalam
Kerangka Layanan Kepercayaan: keamanan, kerahasiaan, dan privasi. Bab ini membahas dua prinsip
Kerangka Layanan Kepercayaan yang tersisa: integritas pemrosesan dan ketersediaan

Integritas Pemrosesan

Prinsip integritas pemrosesan Trust Services Framework menyatakan bahwa sistem yang andal
menghasilkan informasi yang akurat, lengkap, tepat waktu, dan valid. Tabel 13-1 mencantumkan
kontrol dasar atas input, pemrosesan, dan output data yang diidentifikasi oleh proses COBIT 2019
DSS06 sebagai penting untuk integritas pemrosesan.

KONTROL MASUKAN

Ungkapan "sampah masuk, sampah keluar" menyoroti pentingnya kontrol input. Jika data yang
dimasukkan ke dalam sistem tidak akurat, tidak lengkap, atau tidak valid, outputnya juga akan sama.
Akibatnya, hanya personel yang berwenang yang bertindak dalam kewenangan mereka yang harus
menyiapkan dokumen sumber. Selain itu, desain formulir, pembatalan dan penyimpanan dokumen
sumber, dan kontrol entri data otomatis diperlukan untuk memverifikasi validitas data masukan.

DESAIN FORMULIR

Dokumen sumber dan formulir lainnya harus dirancang untuk meminimalkan kemungkinan
kesalahan dan kelalaian. Dua kontrol desain formulir yang sangat penting melibatkan penomoran
dokumen sumber secara berurutan dan menggunakan dokumen turnaround.

1. Semua dokumen sumber harus diberi nomor secara berurutan. Prenumbering meningkatkan
kontrol dengan memungkinkan untuk memverifikasi bahwa tidak ada dokumen yang hilang.
(Untuk memahami hal ini, pertimbangkan kesulitan yang akan Anda hadapi dalam
menyeimbangkan rekening giro Anda jika tidak ada cek Anda yang diberi nomor.) Ketika
dokumen sumber data bernomor berurutan digunakan, sistem harus diprogram untuk
mengidentifikasi dan melaporkan dokumen sumber yang hilang atau duplikat.
2. Sebagaimana dijelaskan dalam Bab 2, perusahaan menggunakan dokumen turnaround untuk
menghilangkan kebutuhan pihak eksternal untuk mengirimkan informasi yang sudah dimiliki
organisasi, seperti nomor rekening pelanggan. Sebagai gantinya, data tersebut dicetak
sebelumnya dalam format yang dapat dibaca mesin pada dokumen turnaround. Contohnya
adalah tagihan utilitas yang dibaca oleh perangkat pemindai khusus saat tagihan
dikembalikan dengan pembayaran. Dokumen turnaround meningkatkan akurasi dengan
menghilangkan potensi kesalahan input saat memasukkan data secara manual.

PEMBATALAN DAN PENYIMPANAN DOKUMEN SUMBER

Dokumen sumber yang telah dimasukkan ke dalam sistem harus dibatalkan sehingga tidak dapat
secara tidak sengaja atau curang dimasukkan kembali ke dalam sistem. Dokumen kertas harus
dirusak, misalnya, dengan memberi cap “dibayar”. Dokumen elektronik juga dapat "dibatalkan"
dengan menetapkan bidang bendera untuk menunjukkan bahwa dokumen tersebut telah diproses.
Catatan: Pembatalan tidak berarti pembuangan. Dokumen sumber asli (atau gambar elektroniknya)
harus disimpan selama diperlukan untuk memenuhi persyaratan hukum dan peraturan dan
memberikan jejak audit.

KONTROL ENTRI DATA

Dokumen sumber harus dipindai untuk kewajaran dan kepatutan sebelum dimasukkan ke dalam
sistem. Namun, kontrol manual ini harus dilengkapi dengan kontrol entri data otomatis, seperti
berikut ini:

 Pemeriksaan bidang menentukan apakah karakter dalam bidang memiliki tipe yang tepat.
Misalnya, centang pada bidang yang seharusnya hanya berisi nilai numerik, seperti kode pos
AS, akan menunjukkan kesalahan jika berisi karakter alfabet.
 Pemeriksaan tanda menentukan apakah data dalam suatu bidang memiliki tanda aritmatika
yang sesuai. Misalnya, bidang jumlah yang dipesan tidak boleh negatif.
 Pemeriksaan batas menguji jumlah numerik terhadap nilai tetap. Misalnya, bidang jam kerja
reguler dalam input penggajian mingguan harus kurang dari atau sama dengan 40 jam.
Demikian pula, bidang upah per jam harus lebih besar atau sama dengan upah minimum.
 Pemeriksaan rentang menguji apakah jumlah numerik berada di antara batas bawah dan
atas yang telah ditentukan sebelumnya. Misalnya, promosi pemasaran mungkin hanya
ditujukan kepada prospek dengan pendapatan antara $50.000 dan $99.999.
 Pemeriksaan ukuran memastikan bahwa data masukan akan sesuai dengan bidang yang
ditetapkan. Misalnya, nilai 458.976.253 tidak akan muat dalam bidang delapan digit. Seperti
yang dibahas dalam Bab 11, pemeriksaan ukuran sangat penting untuk aplikasi yang secara
langsung menerima input pengguna akhir, menyediakan cara untuk mencegah kerentanan
buffer overflow.
 Pemeriksaan kelengkapan (atau tes) memverifikasi bahwa semua item data yang diperlukan
telah dimasukkan. Misalnya, catatan transaksi penjualan tidak boleh diterima untuk diproses
kecuali jika menyertakan alamat pengiriman dan penagihan pelanggan.
 Pemeriksaan validitas membandingkan kode ID atau nomor rekening dalam data transaksi
dengan data serupa di file induk untuk memverifikasi bahwa rekening tersebut ada.
 Misalnya, jika nomor produk 65432 dimasukkan pada pesanan penjualan, komputer harus
memverifikasi bahwa memang ada produk 65432 dalam database inventaris.
 Uji kewajaran menentukan kebenaran hubungan logis antara dua item data. Misalnya, jam
lembur harus nol untuk seseorang yang belum bekerja maksimal jumlah jam reguler dalam
periode pembayaran.
 Kode ID (seperti nomor bagian) dapat berisi digit cek yang dihitung dari digit lainnya.
Misalnya, sistem dapat menetapkan setiap item inventaris baru nomor sembilan digit,
kemudian menghitung digit kesepuluh dari sembilan asli dan menambahkan nomor yang
dihitung ke sembilan asli untuk membentuk 10 digit nomor bagian. Perangkat entri data
kemudian dapat diprogram untuk melakukan verifikasi digit cek, yang melibatkan
penghitungan ulang digit cek untuk mengidentifikasi kesalahan entri data. Melanjutkan
contoh kita, verifikasi digit cek dapat digunakan untuk memverifikasi keakuratan nomor item
inventaris dengan menggunakan sembilan digit pertama untuk menghitung berapa digit
kesepuluh yang seharusnya. Jika terjadi kesalahan dalam memasukkan salah satu dari
sepuluh digit, perhitungan yang dilakukan pada sembilan digit pertama tidak akan cocok
dengan kesepuluh, atau digit cek. Perhatikan bahwa verifikasi digit pemeriksaan hanya
menguji apakah kode ID dalam catatan transaksi mungkin ada dan dirancang untuk
menangkap kesalahan transposisi (misalnya, memasukkan 35689 alih-alih 35869 sebagai
nomor bagian). Pemeriksaan validitas adalah satu-satunya cara untuk memverifikasi bahwa
kode ID benar-benar ada.

Tes entri data sebelumnya digunakan untuk pemrosesan batch dan pemrosesan waktu nyata online.
Kontrol input data tambahan berbeda untuk kedua metode pemrosesan.

KONTROL ENTRY DATA PEMROSESAN BATCH TAMBAHAN

 Pemrosesan batch bekerja lebih efisien jika transaksi diurutkan sehingga akun yang
terpengaruh berada dalam urutan yang sama dengan catatan yang disimpan dalam file
induk. Misalnya, pemrosesan batch transaksi penjualan yang akurat untuk memperbarui
saldo akun pelanggan mengharuskan file transaksi penjualan terlebih dahulu diurutkan
berdasarkan nomor akun pelanggan. Pemeriksaan urutan menguji apakah file transaksi
berada dalam urutan numerik atau abjad yang tepat.
 Log kesalahan yang mengidentifikasi kesalahan input data (tanggal, penyebab, masalah)
memfasilitasi peninjauan dan pengiriman ulang transaksi yang tidak dapat diproses secara
tepat waktu.
 Total batch menghitung nilai numerik untuk batch record input. Total batch digunakan untuk
memastikan bahwa semua record dalam batch diproses dengan benar. Berikut ini adalah
tiga total batch yang umum digunakan:
1. Total keuangan menjumlahkan bidang yang berisi nilai moneter, seperti jumlah total
dolar dari semua penjualan untuk kumpulan transaksi penjualan.
2. Total hash menjumlahkan bidang numerik nonfinansial, seperti total bidang jumlah yang
dipesan dalam kumpulan transaksi penjualan. Tidak seperti total keuangan, total hash
tidak memiliki arti yang melekat. Misalnya, dimungkinkan untuk menjumlahkan nomor
faktur dalam satu batch transaksi penjualan tetapi hasilnya tidak ada artinya; satu-
satunya tujuannya adalah untuk berfungsi sebagai kontrol input.
3. Hitungan record adalah jumlah record dalam satu batch.
KONTROL ENTRI DATA ONLINE TAMBAHAN

 Dorongan, di mana sistem meminta setiap item data input dan menunggu respons yang
dapat diterima, memastikan bahwa semua data yang diperlukan telah dimasukkan (yaitu,
konfirmasi adalah pemeriksaan kelengkapan online).
 Loop tertutupverifikasi memeriksa keakuratan data input dengan menggunakannya untuk
mengambil dan menampilkan informasi terkait lainnya. Misalnya, jika petugas memasukkan
nomor rekening, sistem dapat mengambil dan menampilkan nama rekening sehingga
petugas dapat memverifikasi bahwa nomor rekening yang benar telah dimasukkan.
 Log transaksi mencakup catatan terperinci dari semua transaksi, termasuk pengidentifikasi
transaksi unik, tanggal dan waktu masuk, dan siapa yang memasukkan transaksi. Jika file
online rusak, log transaksi dapat digunakan untuk merekonstruksi file. Jika malfungsi
mematikan sistem untuk sementara, log transaksi dapat digunakan untuk memastikan
bahwa transaksi tidak hilang atau dimasukkan dua kali.

KONTROL PEMROSESAN

Kontrol juga diperlukan untuk memastikan data diproses dengan benar. Kontrol pemrosesan penting
mencakup hal-hal berikut:

 Pencocokan data. Dalam kasus tertentu, dua atau lebih item data harus dicocokkan sebelum
tindakan dapat dilakukan. Misalnya, sebelum membayar vendor, sistem harus memverifikasi
bahwa informasi pada faktur vendor cocok dengan informasi pada pesanan pembelian dan
laporan penerimaan.
 Label berkas. Label file perlu diperiksa untuk memastikan bahwa file yang benar dan terbaru
sedang diperbarui. Baik label eksternal yang dapat dibaca oleh manusia maupun label
internal yang ditulis dalam bentuk yang dapat dibaca mesin pada media perekaman data
harus digunakan. Dua jenis label internal yang penting adalah catatan header dan trailer.
Catatan header terletak di awal setiap file dan berisi nama file, tanggal kedaluwarsa, dan
data identifikasi lainnya. Catatan trailer terletak di akhir file; dalam file transaksi berisi total
batch yang dihitung selama input. Program harus dirancang untuk membaca catatan header
sebelum diproses, untuk memastikan bahwa file yang benar sedang diperbarui. Program
juga harus dirancang untuk membaca informasi dalam rekaman trailer setelah diproses,
 Perhitungan ulang total batch. Total batch harus dihitung ulang saat setiap catatan transaksi
diproses, dengan membandingkan total berjalan yang dihitung selama pemrosesan dengan
total batch yang sesuai yang dihitung selama input dan disimpan dalam catatan trailer.
Setiap perbedaan menunjukkan kesalahan pemrosesan. Seringkali, sifat ketidaksesuaian
memberikan petunjuk tentang jenis kesalahan yang terjadi. Misalnya, jika jumlah catatan
yang dihitung ulang lebih kecil dari aslinya, satu atau lebih catatan transaksi tidak diproses.
Sebaliknya, jika jumlah catatan yang dihitung ulang lebih besar dari aslinya, baik transaksi
tambahan yang tidak sah diproses, atau beberapa catatan transaksi diproses dua kali. Jika
perbedaan total keuangan atau hash habis dibagi 9, kemungkinan penyebabnya adalah
kesalahan transposisi, di mana dua digit yang berdekatan secara tidak sengaja terbalik
(misalnya, 46 bukannya 64). Kesalahan transposisi mungkin tampak sepele tetapi dapat
memiliki konsekuensi keuangan yang sangat besar. Misalnya, pertimbangkan efek kesalahan
pencatatan tingkat bunga pinjaman sebagai 6,4%, bukan 4,6%.
  Uji cross-footing dan zero-balance. Seringkali total dapat dihitung dengan berbagai cara.
Misalnya, dalam spreadsheet, total keseluruhan dapat dihitung dengan menjumlahkan
kolom dari total baris atau dengan menjumlahkan satu baris dari total kolom. Kedua metode
ini harus menghasilkan hasil yang sama. Sebuah tes keseimbangan cross-footing
membandingkan hasil yang dihasilkan oleh masing-masing metode untuk memverifikasi
akurasi. Tes keseimbangan nol menerapkan logika yang sama untuk memverifikasi
keakuratan pemrosesan yang melibatkan akun kontrol. Misalnya, rekening kliring penggajian
didebet untuk total gaji kotor semua karyawan dalam periode waktu tertentu. Kemudian
dikreditkan untuk jumlah semua biaya tenaga kerja yang dialokasikan ke berbagai kategori
pengeluaran. Rekening kliring penggajian harus memiliki saldo nol setelah kedua set entri
dibuat; saldo bukan nol menunjukkan kesalahan pemrosesan.
 Mekanisme perlindungan tulis. Ini melindungi terhadap penimpaan atau penghapusan file
data yang disimpan di media magnetik. Mekanisme perlindungan tulis telah lama digunakan
untuk melindungi file master agar tidak rusak secara tidak sengaja. Inovasi teknologi juga
mengharuskan penggunaan mekanisme perlindungan tulis untuk melindungi integritas data
transaksi. Misalnya, tag identifikasi frekuensi radio (RFID) yang digunakan untuk melacak
inventaris perlu dilindungi dari penulisan sehingga pelanggan yang tidak bermoral tidak
dapat mengubah harga barang dagangan.
 Kontrol pembaruan bersamaan. Kesalahan dapat terjadi ketika dua atau lebih pengguna
mencoba memperbarui catatan yang sama secara bersamaan. Kontrol pembaruan serentak
mencegah kesalahan tersebut dengan mengunci satu pengguna hingga sistem selesai
memproses transaksi yang dimasukkan oleh pengguna lain.

KONTROL KELUARAN

Pemeriksaan yang cermat terhadap keluaran sistem memberikan kontrol tambahan atas integritas
pemrosesan. Kontrol keluaran yang penting mencakup hal berikut:

 Ulasan pengguna tentang keluaran. Pengguna harus hati-hati memeriksa keluaran sistem
untuk memverifikasi bahwa itu masuk akal dan lengkap, dan bahwa mereka adalah
penerima yang dituju.
 Prosedur rekonsiliasi. Secara berkala, semua transaksi dan pembaruan sistem lainnya harus
direkonsiliasi dengan laporan kontrol, laporan status/pembaruan file, atau mekanisme
kontrol lainnya. Selain itu, akun buku besar harus direkonsiliasi dengan total akun pembantu
secara teratur. Misalnya, saldo akun pengendalian persediaan di buku besar harus sama
dengan jumlah saldo item dalam database persediaan. Hal yang sama berlaku untuk akun
piutang, aset modal, dan akun kontrol hutang.
 Rekonsiliasi data eksternal. Total basis data secara berkala harus direkonsiliasi dengan data
yang dipelihara di luar sistem. Misalnya, jumlah catatan karyawan dalam file penggajian
dapat dibandingkan dengan jumlah total karyawan dalam database sumber daya manusia
untuk mendeteksi upaya untuk menambahkan karyawan fiktif ke database penggajian.
Demikian pula, persediaan yang ada harus dihitung secara fisik dan dibandingkan dengan
jumlah yang ada di tangan yang tercatat dalam database. Hasil penghitungan fisik harus
digunakan untuk memperbarui jumlah yang tercatat dan perbedaan yang signifikan harus
diselidiki.
  Kontrol transmisi data. Organisasi juga perlu menerapkan kontrol yang dirancang untuk
meminimalkan risiko kesalahan transmisi data. Setiap kali perangkat penerima mendeteksi
kesalahan transmisi data, ia meminta perangkat pengirim untuk mengirim ulang data
tersebut. Umumnya, ini terjadi secara otomatis, dan pengguna tidak menyadari bahwa itu
telah terjadi. Sebagai contoh, Transmission Control Protocol (TCP) yang dibahas dalam Bab
11 memberikan nomor urut untuk setiap paket dan menggunakan informasi tersebut untuk
memverifikasi bahwa semua paket telah diterima dan untuk memasangnya kembali dalam
urutan yang benar. Dua kontrol transmisi data umum lainnya adalah checksum dan bit
paritas.
1. Checksum.Saat data ditransmisikan, perangkat pengirim dapat menghitung hash file,
yang disebut checksum. Perangkat penerima melakukan perhitungan yang sama dan
mengirimkan hasilnya ke perangkat pengirim. Jika kedua hash setuju, transmisi dianggap
akurat. Jika tidak, file akan dikirim ulang.
2. Bit paritas. Komputer mewakili karakter sebagai satu set digit biner yang disebut bit.
Setiap bit memiliki dua kemungkinan nilai: 0 atau 1. Banyak komputer menggunakan
skema pengkodean tujuh bit, yang lebih dari cukup untuk mewakili 26 huruf dalam
alfabet Inggris (baik huruf besar maupun kecil), angka 0 hingga 9, dan berbagai simbol
khusus ($,%, &, dll.). Bit paritas adalah digit tambahan yang ditambahkan ke awal setiap
karakter yang dapat digunakan untuk memeriksa akurasi transmisi. Dua skema dasar
disebut sebagai paritas genap dan paritas ganjil. Pada paritas genap, bit paritas diatur
sehingga setiap karakter memiliki jumlah bit genap dengan nilai 1; dalam paritas ganjil,
bit paritas diatur sehingga jumlah bit ganjil dalam karakter memiliki nilai 1. Misalnya,
angka 5 dan 7 dapat diwakili oleh pola tujuh bit 0000101 dan 0000111, masing-masing.
Sistem paritas genap akan mengatur bit paritas 5 menjadi 0, sehingga akan
ditransmisikan sebagai 00000101 (karena kode biner untuk 5 sudah memiliki dua bit
dengan nilai 1). Bit paritas untuk 7 akan diatur ke 1 sehingga akan ditransmisikan sebagai
10000111 (karena kode biner untuk 7 memiliki 3 bit dengan nilai 1). Perangkat penerima
melakukan pemeriksaan paritas, yang memerlukan verifikasi bahwa jumlah bit yang
tepat diatur ke nilai 1 di setiap karakter yang diterima.
3. Blockchain.Seperti yang dijelaskan di Bab 12, blockchain menyediakan cara untuk
memastikan bahwa transaksi dan dokumen yang divalidasi tidak diubah. Integritas
dijamin dengan hashing konten setiap blok dan kemudian menyimpan banyak salinan
dari seluruh rantai pada perangkat yang berbeda.

CONTOH ILUSTRASI: PEMROSESAN PENJUALAN KREDIT

Kami sekarang menggunakan pemrosesan penjualan kredit untuk menggambarkan berapa banyak
kontrol aplikasi yang telah dibahas benar-benar berfungsi. Setiap catatan transaksi mencakup data
berikut: nomor faktur penjualan, nomor rekening pelanggan, nomor item persediaan, jumlah yang
terjual, harga jual, dan tanggal pengiriman. Jika pelanggan membeli lebih dari satu produk, akan ada
beberapa nomor item inventaris, jumlah yang terjual, dan harga yang terkait dengan setiap transaksi
penjualan. Pemrosesan transaksi ini meliputi langkah-langkah berikut: (1) memasukkan dan
mengedit data transaksi; (2) memperbarui catatan pelanggan dan inventaris (jumlah pembelian
kredit ditambahkan ke saldo pelanggan; untuk setiap item inventaris, jumlah yang terjual dikurangi
dari jumlah yang ada); dan (3) menyiapkan dan mendistribusikan dokumen pengiriman dan/atau
penagihan.

KONTROL MASUKAN. Saat transaksi penjualan dimasukkan, sistem melakukan beberapa tes validasi
awal. Pemeriksaan validitas mengidentifikasi transaksi dengan nomor rekening yang tidak valid atau
nomor item inventaris yang tidak valid. Pemeriksaan lapangan memverifikasi bahwa jumlah yang
dipesan dan bidang harga hanya berisi angka dan bahwa bidang tanggal mengikuti format
MM/DD/YYYY yang benar. Tanda cek memverifikasi bahwa jumlah yang terjual dan bidang harga jual
berisi angka positif. Pemeriksaan rentang memverifikasi bahwa tanggal pengiriman tidak lebih awal
dari tanggal saat ini atau lebih lambat dari kebijakan pengiriman yang diiklankan perusahaan.
Pemeriksaan kelengkapan menguji apakah bidang yang diperlukan (misalnya, alamat pengiriman)
kosong. Jika pemrosesan batch digunakan, penjualan dikelompokkan ke dalam batch (ukuran tipikal
5 50) dan salah satu dari total batch berikut dihitung dan disimpan dengan batch:

KONTROL PEMROSESAN. Sistem membaca catatan header untuk file induk pelanggan dan inventaris
dan memverifikasi bahwa versi terbaru sedang digunakan. Karena setiap faktur penjualan diproses,
pemeriksaan batas digunakan untuk memverifikasi bahwa penjualan baru tidak meningkatkan saldo
akun pelanggan melebihi batas kredit yang telah ditentukan sebelumnya. Jika ya, transaksi akan
disingkirkan sementara dan pemberitahuan dikirim ke manajer kredit. Jika penjualan diproses, tanda
cek memverifikasi bahwa jumlah baru di tangan untuk setiap item persediaan lebih besar dari atau
sama dengan nol. Pemeriksaan rentang memverifikasi bahwa harga jual setiap item berada dalam
batas yang telah ditentukan. Pemeriksaan kewajaran membandingkan kuantitas yang dijual dengan
nomor item dan membandingkan keduanya dengan rata-rata historis. Jika pemrosesan batch
digunakan, sistem menghitung total batch yang sesuai dan membandingkannya dengan total batch
yang dibuat selama input; jika dua total batch tidak setuju, laporan kesalahan dibuat dan seseorang
menyelidiki penyebab perbedaan tersebut.

KONTROL KELUARAN. Dokumen penagihan dan pengiriman dirutekan hanya ke karyawan yang
berwenang di departemen akuntansi dan pengiriman, yang secara visual memeriksanya untuk
mencari kesalahan yang nyata. Laporan kontrol yang merangkum transaksi yang diproses dikirim ke
manajer penjualan, akuntansi, dan kontrol inventaris untuk ditinjau. Setiap persediaan kuartal di
gudang dihitung secara fisik dan hasilnya dibandingkan dengan jumlah tercatat di tangan untuk
setiap item. Penyebab perbedaan diselidiki dan jurnal penyesuaian dibuat untuk mengoreksi jumlah
yang tercatat. Contoh sebelumnya mengilustrasikan penggunaan kontrol aplikasi untuk memastikan
integritas pemrosesan transaksi bisnis. Fokus 13-1 menjelaskan pentingnya pemrosesan kontrol
integritas dalam pengaturan nonbisnis juga.

MEMPROSES KONTROL INTEGRITAS DI SPREADSHEET

Sebagian besar organisasi memiliki ribuan spreadsheet yang digunakan untuk mendukung
pengambilan keputusan. Namun, karena pengguna akhir hampir selalu mengembangkan
spreadsheet, mereka jarang berisi kontrol aplikasi yang memadai. Oleh karena itu, tidak
mengherankan jika banyak organisasi mengalami masalah serius yang disebabkan oleh kesalahan
spreadsheet. Misalnya, artikel 17 Agustus 2007, di Majalah CIO1 menjelaskan bagaimana kesalahan
spreadsheet menyebabkan perusahaan merugi, menerbitkan pengumuman pembayaran dividen
yang salah, dan melaporkan hasil keuangan yang salah.
 Pengujian spreadsheet yang cermat sebelum digunakan dapat mencegah kesalahan mahal
semacam ini. Meskipun sebagian besar perangkat lunak spreadsheet berisi fitur "audit" bawaan yang
dapat dengan mudah mendeteksi kesalahan umum, spreadsheet yang dimaksudkan untuk
mendukung keputusan penting memerlukan pengujian yang lebih menyeluruh untuk mendeteksi
kesalahan kecil. Sangat penting untuk memeriksa pengkabelan, di mana formula berisi nilai numerik
tertentu (misalnya, pajak penjualan 5 8,5% 3 A33). Praktik terbaik adalah menggunakan sel referensi
(misalnya, menyimpan tarif pajak penjualan di sel A8) dan kemudian menulis rumus yang
menyertakan sel referensi (misalnya, mengubah contoh sebelumnya menjadi pajak penjualan 5 A8 3
A33). Masalah dengan pengkabelan adalah bahwa spreadsheet awalnya menghasilkan jawaban yang
benar, tetapi ketika variabel bawaan (misalnya, tarif pajak penjualan dalam contoh sebelumnya)
berubah, rumus mungkin tidak dikoreksi di setiap sel yang menyertakan nilai bawaan itu. Sebaliknya,
mengikuti praktik terbaik yang direkomendasikan dan menyimpan nilai pajak penjualan dalam sel
berlabel jelas berarti bahwa ketika tarif pajak penjualan berubah, hanya satu sel yang perlu
diperbarui. Praktik terbaik ini juga memastikan bahwa tarif pajak penjualan yang diperbarui
digunakan di setiap formula yang melibatkan penghitungan pajak penjualan.

Ketersediaan

Gangguan pada proses bisnis karena tidak tersedianya sistem atau informasi dapat menyebabkan
kerugian finansial yang signifikan. Akibatnya, proses kontrol COBIT 2019 DSS01 dan DSS04
membahas pentingnya memastikan bahwa sistem dan informasi tersedia untuk digunakan kapan
pun dibutuhkan. Tujuan utama adalah untuk meminimalkan risiko sistem downtime. Namun, tidak
mungkin untuk sepenuhnya menghilangkan risiko downtime. Oleh karena itu, organisasi juga
memerlukan kontrol yang dirancang untuk memungkinkan dimulainya kembali operasi normal
dengan cepat setelah suatu peristiwa mengganggu ketersediaan sistem. Tabel 13-2 merangkum
kontrol utama yang terkait dengan dua tujuan ini.

MEMINIMALKAN RISIKO DOWNTIME SISTEM

Organisasi dapat melakukan berbagai tindakan untuk meminimalkan risiko waktu henti sistem.
Praktik manajemen COBIT 2019 DSS01.05 mengidentifikasi perlunya pemeliharaan preventif, seperti
membersihkan disk drive dan menyimpan media magnetik dan optik dengan benar, untuk
mengurangi risiko kegagalan perangkat keras dan perangkat lunak. Penggunaan komponen
redundan memberikan toleransi kesalahan, yang merupakan kemampuan sistem untuk terus
berfungsi jika komponen tertentu gagal. Misalnya, banyak organisasi menggunakan array drive
independen (RAID) yang berlebihan, bukan hanya satu drive disk. Dengan RAID, data ditulis ke
beberapa drive disk secara bersamaan. Jadi, jika satu disk drive gagal, data dapat dengan mudah
diakses dari yang lain.

Praktik manajemen COBIT 2019 DSS01.04 dan DSS01.05 membahas pentingnya menemukan
dan merancang pusat data yang menampung server dan basis data misi-kritis untuk meminimalkan
risiko yang terkait dengan bencana alam dan yang disebabkan manusia. Fitur desain umum meliputi:

 Lantai yang ditinggikan memberikan perlindungan dari kerusakan yang disebabkan oleh
banjir.
 Deteksi kebakaran dan perangkat pencegah kebakaran mengurangi kemungkinan kerusakan
akibat kebakaran.
 Sistem pendingin udara yang memadai mengurangi kemungkinan kerusakan pada peralatan
komputer karena panas berlebih atau kelembapan.
 Kabel dengan colokan khusus yang tidak dapat dengan mudah dilepas mengurangi risiko
kerusakan sistem karena mencabut perangkat secara tidak sengaja.
 Perangkat pelindung lonjakan arus memberikan perlindungan terhadap fluktuasi daya
sementara yang dapat menyebabkan komputer dan peralatan jaringan lainnya mogok.
 Sistem catu daya tak terputus (UPS) memberikan perlindungan jika terjadi pemadaman
listrik berkepanjangan, menggunakan daya baterai untuk memungkinkan sistem beroperasi
cukup lama untuk mencadangkan data penting dan dimatikan dengan aman. (Namun,
penting untuk secara teratur memeriksa dan menguji baterai di UPS untuk memastikan
baterai akan berfungsi saat dibutuhkan.)
 Kontrol akses fisik mengurangi risiko pencurian atau kerusakan.

Pelatihan juga dapat mengurangi risiko waktu henti sistem. Operator yang terlatih dengan baik
cenderung tidak membuat kesalahan dan akan tahu bagaimana memulihkan, dengan kerusakan
minimal, dari kesalahan yang mereka lakukan. Itulah sebabnya praktik manajemen COBIT 2019
DSS01 menekankan pentingnya mendefinisikan dan mendokumentasikan prosedur operasional dan
memastikan bahwa staf TI memahami tanggung jawab mereka.

Sistem downtime juga dapat terjadi karena malware komputer (misalnya, ransomware dapat
membuat aplikasi dan data tidak dapat diakses). Oleh karena itu, penting untuk menginstal,
menjalankan, dan menyimpan program antivirus dan anti-spyware terkini. Program-program ini
harus secara otomatis dipanggil tidak hanya untuk memindai e-mail, tetapi juga semua media
komputer yang dapat dipindahkan (CD, DVD, drive USB, dll.) yang dibawa ke dalam organisasi.
Sistem manajemen tambalan memberikan perlindungan tambahan dengan memastikan bahwa
kerentanan yang dapat dieksploitasi oleh malware diperbaiki tepat waktu.

PEMULIHAN DAN KEMBALI OPERASI NORMAL

Kontrol pencegahan yang dibahas di bagian sebelumnya dapat meminimalkan, tetapi tidak
sepenuhnya menghilangkan, risiko waktu henti sistem. Malfungsi perangkat keras, masalah
perangkat lunak, atau kesalahan manusia dapat menyebabkan data menjadi tidak dapat diakses.
Misalnya, perangkat RAID dapat mengalami kegagalan bencana, membuat semua drive tidak
berguna. Itu sebabnya manajemen senior perlu menjawab dua pertanyaan mendasar:
 1. Berapa banyak data yang ingin kita buat ulang dari dokumen sumber (jika ada) atau
berpotensi hilang (jika tidak ada dokumen sumber)? 2
2. Berapa lama kita bisa berfungsi tanpa sistem informasi kita?

Gambar 13-1 menunjukkan hubungan antara dua pertanyaan ini. Ketika terjadi masalah, data
tentang segala sesuatu yang telah terjadi sejak pencadangan terakhir akan hilang kecuali dapat
dimasukkan kembali ke dalam sistem. Dengan demikian, jawaban manajemen atas pertanyaan
pertama menentukan tujuan titik pemulihan organisasi (RPO), yang mewakili jumlah maksimum data
yang bersedia dimasukkan kembali atau berpotensi hilang oleh organisasi. RPO berbanding terbalik
dengan frekuensi pencadangan: semakin kecil RPO yang diinginkan, semakin sering pencadangan
perlu dilakukan. Jawaban atas pertanyaan kedua menentukan tujuan waktu pemulihan organisasi
(RTO), yang merupakan waktu maksimum yang dapat ditoleransi untuk memulihkan sistem
informasi setelah bencana. Jadi,

PROSEDUR CADANGAN DATA.Prosedur pencadangan data dirancang untuk menangani situasi di

mana informasi tidak dapat diakses karena file atau basis data yang relevan telah rusak akibat
kegagalan perangkat keras, masalah perangkat lunak, atau kesalahan manusia, tetapi sistem
informasi itu sendiri masih berfungsi. Ada beberapa prosedur pencadangan yang berbeda. Cadangan
lengkap adalah salinan persis dari seluruh basis data. Pencadangan penuh memakan waktu, sehingga
sebagian besar organisasi hanya melakukan pencadangan penuh setiap minggu dan melengkapinya
dengan pencadangan parsial harian. Gambar 13-2 membandingkan dua jenis pencadangan parsial
harian:

1. Pencadangan tambahan melibatkan penyalinan hanya item data yang telah berubah sejak
pencadangan parsial terakhir. Ini menghasilkan satu set file cadangan tambahan, masing-
masing berisi hasil transaksi satu hari. Pemulihan melibatkan pemuatan pertama cadangan
penuh terakhir dan kemudian menginstal setiap cadangan tambahan berikutnya dalam
urutan yang benar.
2. Cadangan diferensial menyalin semua perubahan yang dibuat sejak pencadangan penuh
terakhir. Jadi, setiap file cadangan diferensial baru berisi efek kumulatif dari semua aktivitas
sejak pencadangan penuh terakhir. Akibatnya, kecuali untuk hari pertama setelah
pencadangan penuh, pencadangan diferensial harian membutuhkan waktu lebih lama
daripada pencadangan inkremental. Pemulihan lebih sederhana, karena cadangan lengkap
terakhir hanya perlu dilengkapi dengan cadangan diferensial terbaru, bukan satu set file
cadangan inkremental harian.

Deduplikasi menyebabkan banyak organisasi menghilangkan pembuatan cadangan penuh dan

secara terus-menerus membuat cadangan parsial tambahan. Deduplikasi menggunakan hashing
untuk mengidentifikasi dan mencadangkan hanya bagian-bagian dari file atau database yang telah
diperbarui sejak pencadangan terakhir. Proses deduplikasi bekerja dengan membagi file atau
database menjadi potongan berukuran seragam. Setiap potongan di-hash, dan nilai hash potongan
dibandingkan dengan nilai hash dari semua potongan dalam file hash dari cadangan sebelumnya.
Ingatlah bahwa nilai hash yang identik berarti bahwa dua set data identik bit-untuk-bit. Dengan
demikian, setiap potongan data dengan file hash yang cocok dengan nilai dalam file hash dari
cadangan sebelumnya tidak diubah. Akibatnya, itu tidak perlu dicadangkan lagi. Sebagai gantinya,
hanya potongan data yang nilai hashnya saat ini tidak cocok dengan nilai apa pun dalam file hash
dari cadangan sebelumnya yang perlu dicadangkan kali ini. Biasanya, hanya sebagian kecil dari
database atau file yang telah diubah sejak pencadangan terakhir; oleh karena itu, deduplikasi
menghasilkan pencadangan cepat. Proses pemulihan kemudian melibatkan penggunaan file hash
potongan terbaru untuk mengidentifikasi file cadangan tambahan yang sesuai yang perlu
digabungkan untuk membuat ulang file atau database lengkap.

Apa pun prosedur pencadangan yang digunakan, banyak salinan cadangan harus dibuat. Satu
salinan dapat disimpan di tempat, untuk digunakan jika terjadi masalah yang relatif kecil, seperti
kegagalan hard drive. Jika terjadi masalah yang lebih serius, seperti kebakaran atau banjir, salinan
cadangan apa pun yang disimpan di tempat kemungkinan besar akan dihancurkan atau tidak dapat
diakses. Oleh karena itu, salinan cadangan kedua perlu disimpan di luar situs. File cadangan ini dapat
diangkut ke situs penyimpanan jarak jauh baik secara fisik (misalnya, melalui kurir) atau secara
elektronik. Dalam kedua kasus, kontrol keamanan yang sama perlu diterapkan ke file cadangan
seperti yang digunakan untuk melindungi salinan asli informasi. Ini berarti bahwa salinan cadangan
data sensitif harus dienkripsi baik dalam penyimpanan maupun selama transmisi elektronik. Akses ke
file cadangan juga perlu dikontrol dan dipantau secara hati-hati.

Penting juga untuk secara berkala berlatih memulihkan sistem dari cadangannya. Ini
memverifikasi bahwa prosedur pencadangan bekerja dengan benar dan media cadangan (pita atau
disk) dapat berhasil dibaca oleh perangkat keras yang digunakan.

Tujuan pencadangan adalah untuk memungkinkan pemulihan data jika salinan asli tidak dapat
diakses. Akibatnya, cadangan disimpan hanya untuk waktu yang relatif singkat. Misalnya, banyak
organisasi hanya mempertahankan cadangan selama beberapa bulan. Beberapa informasi,
bagaimanapun, harus disimpan lebih lama. Arsip adalah salinan database, file induk, atau perangkat
lunak yang disimpan tanpa batas waktu sebagai catatan sejarah, biasanya untuk memenuhi
persyaratan hukum dan peraturan. Arsip digunakan untuk mengambil data yang dipilih, bukan untuk
mengembalikan seluruh file atau database. Akibatnya, perangkat lunak arsip menyertakan fitur
pengindeksan untuk memfasilitasi pengambilan cepat, tetapi perangkat lunak cadangan tidak. Oleh
karena itu, menyimpan cadangan selama bertahun-tahun bukanlah alternatif yang layak untuk
membuat arsip yang sebenarnya. Seperti halnya backup, beberapa salinan arsip harus dibuat dan
disimpan di lokasi yang berbeda. Tidak seperti pencadangan, arsip jarang dienkripsi karena waktu
penyimpanannya yang lama meningkatkan risiko kehilangan kunci dekripsi. Akibatnya, kontrol akses
fisik dan logis adalah cara utama untuk melindungi file arsip.

Media apa yang harus digunakan untuk backup dan arsip, tape atau disk? Pencadangan disk
lebih cepat, begitu pula waktu yang dibutuhkan untuk mengambil data. Namun, pita lebih murah,
lebih mudah diangkut, dan lebih tahan lama. Selain itu, karena kaset biasanya disimpan secara
offline, kecil kemungkinannya untuk terinfeksi oleh ransomware. Akibatnya, banyak organisasi
menggunakan kedua media tersebut. Data pertama dicadangkan ke disk, untuk kecepatan, dan
kemudian ditransfer ke tape.

Perhatian khusus perlu diberikan pada pencadangan dan pengarsipan email karena telah
menjadi tempat penyimpanan informasi dan perilaku organisasi yang penting. Memang, email sering
kali berisi solusi untuk masalah tertentu. E-mail juga sering berisi informasi yang relevan dengan
tuntutan hukum. Organisasi mungkin tergoda untuk mempertimbangkan kebijakan penghapusan
semua email secara berkala, untuk mencegah pengacara penggugat menemukan "senjata api" dan
untuk menghindari biaya pencarian email yang diminta oleh pihak lain. Namun, sebagian besar pakar
menyarankan agar kebijakan tersebut tidak dilakukan karena pihak lain kemungkinan besar memiliki
salinan email tersebut. Oleh karena itu, kebijakan untuk menghapus semua email secara teratur
berarti bahwa organisasi tidak akan dapat menceritakan kisahnya; sebagai gantinya, pengadilan (dan
juri) hanya akan membaca email yang diberikan oleh pihak lain yang bersengketa. Ada juga kasus di
mana pengadilan telah mendenda organisasi jutaan dolar karena gagal menghasilkan e-mail yang
diminta pada waktu yang tepat. Oleh karena itu, organisasi perlu mencadangkan dan mengarsipkan
email penting sekaligus secara berkala membersihkan volume besar email rutin yang tidak penting.

PEMULIHAN BENCANA DAN PERENCANAAN KELANJUTAN USAHA.Cadangan dirancang untuk

mengurangi masalah ketika satu atau lebih file atau basis data menjadi rusak karena perangkat
keras, perangkat lunak, atau kesalahan manusia. Rencana pemulihan bencana dan rencana
kelangsungan bisnis dirancang untuk mengurangi masalah yang lebih serius.

Rencana pemulihan bencana(DRP) menguraikan prosedur untuk memulihkan fungsi TI

organisasi jika pusat datanya dihancurkan. Organisasi memiliki tiga opsi dasar untuk mengganti
infrastruktur TI mereka, yang mencakup tidak hanya komputer, tetapi juga komponen jaringan
seperti router dan sakelar, perangkat lunak, data, akses Internet, printer, dan persediaan. Opsi
pertama adalah mengontrak untuk penggunaan situs dingin, yang merupakan bangunan kosong
yang disiapkan untuk akses telepon dan Internet yang diperlukan. Namun, situs dingin tidak berisi
peralatan komputasi apa pun; sebaliknya, organisasi memiliki kontrak dengan satu atau lebih vendor
untuk menyediakan semua peralatan yang diperlukan dalam jangka waktu tertentu.

Pilihan kedua adalah kontrak untuk penggunaan situs panas, yang merupakan fasilitas tidak
hanya untuk telepon dan akses Internet tetapi juga berisi semua komputasi dan peralatan kantor
yang dibutuhkan organisasi untuk melakukan kegiatan bisnis penting. Opsi ketiga adalah
pencerminan waktu nyata, yang melibatkan pemeliharaan dua salinan basis data di dua pusat data
terpisah setiap saat dan memperbarui kedua basis data secara waktu nyata saat setiap transaksi
terjadi.

Opsi DRP yang berbeda (situs dingin, situs panas, atau pencerminan waktu nyata) bervariasi
dalam biaya, dengan situs dingin menjadi yang paling murah dan pencerminan waktu nyata paling
mahal. Namun, pilihan tidak boleh didorong oleh biaya tetapi harus mencerminkan keputusan
manajemen tentang RPO dan RTO yang dapat ditoleransi. Untuk beberapa organisasi, baik RPO
maupun RTO harus sedekat mungkin dengan nol. Maskapai penerbangan dan lembaga keuangan,
misalnya, tidak dapat beroperasi tanpa sistem informasi mereka, juga tidak dapat kehilangan data
tentang transaksi karena mereka memiliki begitu banyak setiap menit. Untuk organisasi seperti itu,
tujuannya bukanlah pemulihan tetapi ketahanan (yaitu, mereka harus dapat terus berfungsi apa pun
yang terjadi). Pencerminan waktu nyata memberikan ketahanan maksimum karena RPO dan RTO
mendekati nol. Transaksi dicadangkan secara real time, dan jika terjadi sesuatu pada satu pusat data,
organisasi dapat segera mengalihkan semua pemrosesan ke pusat data lainnya. Jadi, pencerminan
waktu nyata adalah pilihan DRP yang tepat ketika RPO, RTO, atau keduanya harus mendekati nol.

Beberapa organisasi dapat mentolerir potensi kehilangan beberapa data dan memiliki
kemampuan untuk beroperasi untuk jangka waktu tertentu tanpa AIS mereka. Jika manajemen telah
memutuskan bahwa mereka dapat mentolerir RTO dan RPO mulai dari jam hingga sehari penuh,
pilihan situs panas sebagai strategi DRP diperlukan. Menggunakan situs dingin untuk DRP hanya
tepat jika manajemen dapat mentolerir memiliki RTO dan RPO lebih dari satu hari.

Organisasi dapat memilih untuk membangun situs panas atau situs dingin mereka sendiri,
atau mereka dapat membuat kontrak dengan pihak ketiga untuk penggunaan fasilitas tersebut.
Menggunakan situs pihak ketiga lebih murah, tetapi membawa risiko tidak tersedia saat dibutuhkan.
Sebagian besar penyedia situs panas dan dingin "menjual berlebihan" kapasitas mereka dengan
asumsi bahwa pada suatu saat hanya beberapa klien yang perlu menggunakan fasilitas tersebut.
Biasanya, itu adalah asumsi yang aman. Namun, jika terjadi bencana besar, seperti Badai Katrina dan
Sandy, yang mempengaruhi setiap organisasi di wilayah geografis, itu berarti bahwa beberapa
organisasi mungkin tidak dapat menggunakan layanan yang mereka kontrakkan. (Kemampuan untuk
menuntut kegagalan menyediakan layanan bukanlah kontrol kompensasi karena organisasi mungkin
gulung tikar pada saat gugatan diselesaikan.)

Sementara DRP berfokus pada cara melanjutkan operasi TI jika pusat data utama organisasi
tidak tersedia, rencana kelangsungan bisnis (BCP) menentukan cara melanjutkan semua proses
bisnis, termasuk relokasi ke kantor baru dan mempekerjakan pengganti sementara, jika dari sebuah
bencana besar. Perencanaan seperti itu penting karena lebih dari separuh organisasi tanpa DRP dan
BCP tidak pernah dibuka kembali setelah terpaksa ditutup selama lebih dari beberapa hari karena
bencana. Dengan demikian, memiliki DRP dan BCP dapat berarti perbedaan antara selamat dari
bencana besar seperti badai atau serangan teroris dan keluar dari bisnis. Focus 13-2 menjelaskan
bagaimana perencanaan membantu NASDAQ bertahan dari kehancuran total kantornya di World
Trade Center pada 11 September 2001.

Hanya memiliki DRP dan BCP, bagaimanapun, tidak cukup. Kedua rencana tersebut harus
didokumentasikan dengan baik. Dokumentasi harus mencakup tidak hanya instruksi untuk memberi
tahu staf yang tepat dan langkah-langkah yang harus diambil untuk melanjutkan operasi, tetapi juga
dokumentasi vendor dari semua perangkat keras dan perangkat lunak. Sangat penting untuk
mendokumentasikan berbagai modifikasi yang dibuat pada konfigurasi default, sehingga sistem
pengganti memiliki fungsi yang sama seperti aslinya. Kegagalan untuk melakukannya dapat
menimbulkan biaya yang besar dan penundaan dalam pelaksanaan proses pemulihan. Instruksi
pengoperasian yang terperinci juga diperlukan, terutama jika pengganti sementara harus
dipekerjakan. Terakhir, salinan semua dokumentasi perlu disimpan baik di dalam maupun di luar
lokasi sehingga tersedia saat dibutuhkan.

Pengujian dan revisi berkala mungkin merupakan komponen terpenting dari DRP dan BCP
yang efektif. Sebagian besar rencana gagal dalam tes awal mereka karena tidak mungkin untuk
sepenuhnya mengantisipasi segala sesuatu yang bisa salah. Pengujian juga dapat mengungkapkan
detail yang diabaikan. Misalnya, Badai Sandy memaksa banyak bisnis untuk menutup kantor pusat
mereka selama beberapa hari. Sayangnya, beberapa perusahaan menemukan bahwa meskipun
mereka dapat melanjutkan operasi TI di situs cadangan yang terletak di wilayah geografis lain,
mereka tidak dapat segera melanjutkan layanan pelanggan normal karena mereka tidak
menduplikasi kemampuan sistem telepon kantor pusat mereka untuk secara otomatis mengubah
rute dan meneruskan panggilan masuk ke karyawan. ' ponsel dan telepon rumah. Waktu untuk
menemukan masalah seperti itu bukanlah selama keadaan darurat yang sebenarnya, melainkan
dalam pengaturan di mana kelemahan dapat dianalisis secara hati-hati dan menyeluruh dan
perubahan yang tepat dalam prosedur dibuat. Oleh karena itu, DRP dan BCP perlu diuji setidaknya
setiap tahun untuk memastikan bahwa mereka secara akurat mencerminkan perubahan terbaru
dalam peralatan dan prosedur. Hal ini sangat penting untuk menguji prosedur yang terlibat dalam
transfer operasi yang sebenarnya ke situs dingin atau panas. Akhirnya, dokumentasi DRP dan BCP
perlu diperbarui untuk mencerminkan setiap perubahan dalam prosedur yang dibuat dalam
menanggapi masalah yang diidentifikasi selama pengujian rencana tersebut. Hal ini sangat penting
untuk menguji prosedur yang terlibat dalam transfer operasi yang sebenarnya ke situs dingin atau
panas. Akhirnya, dokumentasi DRP dan BCP perlu diperbarui untuk mencerminkan setiap perubahan
dalam prosedur yang dibuat dalam menanggapi masalah yang diidentifikasi selama pengujian
rencana tersebut. Hal ini sangat penting untuk menguji prosedur yang terlibat dalam transfer operasi
yang sebenarnya ke situs dingin atau panas. Akhirnya, dokumentasi DRP dan BCP perlu diperbarui
untuk mencerminkan setiap perubahan dalam prosedur yang dibuat dalam menanggapi masalah
yang diidentifikasi selama pengujian rencana tersebut.

EFEK VIRTUALISASI DAN KOMPUTASI CLOUD. Virtualisasi dapat secara signifikan meningkatkan
efisiensi dan efektivitas pemulihan bencana dan dimulainya kembali operasi normal. Mesin virtual
hanyalah kumpulan file perangkat lunak. Oleh karena itu, jika server fisik yang menghosting mesin
tersebut gagal, file dapat diinstal pada mesin host lain dalam beberapa menit. Dengan demikian,
virtualisasi secara signifikan mengurangi waktu yang dibutuhkan untuk memulihkan (RTO) dari
masalah perangkat keras. Perhatikan bahwa virtualisasi tidak menghilangkan kebutuhan akan
pencadangan; organisasi masih perlu membuat "snapshot" berkala dari mesin virtual desktop dan
server dan kemudian mereplikasi snapshot tersebut pada drive jaringan sehingga mesin dapat dibuat
ulang. Salinan kedua dari snapshot juga harus direplikasi ke cloud (atau disimpan di pusat data
terpisah) jika pusat data utama yang menampung mesin virtual dihancurkan. Virtualisasi juga dapat
digunakan untuk mendukung pencerminan waktu nyata di mana dua salinan dari setiap mesin virtual
dijalankan bersama-sama pada dua host fisik yang terpisah. Setiap transaksi diproses di kedua mesin
virtual. Jika salah satu gagal, yang lain mengambil tanpa istirahat dalam pelayanan.

Komputasi awan memiliki efek positif dan negatif pada ketersediaan. Penyedia komputasi
awan biasanya menggunakan bank server yang berlebihan di beberapa lokasi, sehingga mengurangi
risiko bahwa satu bencana dapat mengakibatkan waktu henti sistem dan hilangnya semua data.
Namun, jika penyedia cloud publik gulung tikar, mungkin sulit, jika bukan tidak mungkin, untuk
mengambil data apa pun yang tersimpan di cloud. Oleh karena itu, kebijakan membuat cadangan
reguler dan menyimpan cadangan tersebut di tempat lain selain dengan penyedia cloud utama
sangat penting.

Seperti yang dibahas dalam bab tentang keamanan, organisasi harus memeriksa laporan
SOC-2 Tipe 2 tentang kontrol TI penyedia cloud. Selain itu, akuntan perlu menilai kelayakan finansial
jangka panjang dari penyedia cloud sebelum organisasi mereka berkomitmen untuk
mengalihdayakan data atau aplikasinya ke cloud publik. Penggunaan cloud juga tidak menghilangkan
kebutuhan untuk mempertimbangkan RTO dan RPO karena tidak semuanya dapat dicadangkan atau
dipulihkan secara tepat waktu dari cloud. Misalnya, tidak praktis untuk mentransfer database yang
mencapai ratusan terabyte melalui Internet; sebaliknya, penyimpanan data yang besar seperti itu
harus direkam pada disk atau tape dan diangkut secara fisik. Selain itu, meskipun beberapa solusi
cloud menyertakan pencadangan, beberapa tidak dan secara khusus menyatakan dalam kontrak
bahwa pencadangan adalah tanggung jawab pelanggan. Akhirnya,
Ringkasan dan Kesimpulan Kasus

Laporan Jason menilai efektivitas kontrol Northwest Industries yang dirancang untuk memastikan
integritas pemrosesan. Untuk meminimalkan entri data, dan peluang kesalahan, Northwest
Industries mengirimkan dokumen turnaround kepada pelanggan, yang dikembalikan dengan
pembayaran mereka. Semua entri data dilakukan secara online, dengan penggunaan rutin validasi
input yang ekstensif untuk memastikan keakuratan informasi yang masuk ke sistem. Manajer
meninjau keluaran untuk kewajaran, dan keakuratan komponen kunci dari laporan keuangan secara
teratur divalidasi silang dengan sumber independen. Misalnya, persediaan dihitung setiap tiga bulan,
dan hasil penghitungan fisik dicocokkan dengan jumlah yang disimpan dalam sistem.

Namun, Jason prihatin tentang efektivitas kontrol yang dirancang untuk memastikan
ketersediaan sistem. Dia mencatat bahwa meskipun Northwest Industries telah mengembangkan
rencana pemulihan bencana dan kelangsungan bisnis, rencana tersebut belum ditinjau atau
diperbarui selama tiga tahun. Yang lebih memprihatinkan adalah kenyataan bahwa banyak bagian
dari rencana itu tidak pernah diuji. Kekhawatiran terbesar Jason, bagaimanapun, terkait dengan
prosedur pencadangan. Semua file dicadangkan setiap minggu, pada hari Sabtu, ke DVD, dan
pencadangan tambahan dibuat setiap malam, tetapi tidak ada yang pernah berlatih memulihkan
data. Selain itu, cadangan tidak dienkripsi, dan satu-satunya salinan disimpan di tempat di ruang
server utama di rak dekat pintu.

Jason menutup laporannya dengan rekomendasi khusus untuk mengatasi kelemahan yang
dia temukan. Dia merekomendasikan agar Northwest Industries segera menguji prosedur pemulihan
cadangannya, mengenkripsi file cadangannya, dan menyimpan salinan kedua dari semua cadangan
di luar lokasi. Jason juga merekomendasikan untuk menguji rencana DRP dan BCP. Jason merasa
yakin bahwa setelah rekomendasi tersebut diterapkan, manajemen dapat diyakinkan secara wajar
bahwa sistem informasi Northwest Industries telah memenuhi kriteria dan prinsip kerangka kerja
Trust Services AICPA untuk keandalan sistem.