Diantina Puspa Larasati (C1CO12001)
Akuntansi A 2012

Diantina Puspa Larasati (C1C012001)

Akuntansi A 2012

Buku : Andrew Hawker

Chapter 9 : BUSINESS CONTINUITY

9.1 Pengenalan

Melakukan Business Continuity Planing untuk setiap layanan Teknologi Informasi  tidaklah mudah, dan tidak dapat dilakukan tanpa dukungan dari manajemen. Jika  organisasi memiliki BCP baik, mungkin layak melihat sistem individu di kantor, dan mempertimbangkan apakah ada langkah-langkah lebih lanjut yang dapat diambil untuk meminimalkan gangguan yang mungkin timbul dari bencana yang lebih lokal.

9.2 Ancaman untuk Kontinuitas Bisnis

BCP memerlukan dua hal yang sangat berbeda dari persiapan. Pertama, ada identifikasi ancaman-ancaman yang dapat dihindari. Kedua, ada ancaman yang lebih keras  yang tidak pernah bisa sepenuhnya dihilangkan.

Business continuity and archiving/pengarsipan

Pada titik ini berguna untuk membuat beberapa keputusan awal tentang apa yang
bisa dilakukan tentang masing-masing dari ancaman. Sebagai contoh, jika ancaman
merupakan salah satu hilangnya daya listrik ke komputer, salah satu caranya yaitu Memiliki pengaturan dimana pekerjaan komputasi dapat dengan cepat ditransfer ke komputer lain di gedung yang berbeda.

9.3 Perlindungan Fisik Prosesor, Simpul dan Terminal

Perlindungan fisik berkaitan  dengan menghilangkan atau melindungi terhadap sumber kerusakan. Akses ke segala penjuru  teknologi informasi  atau telekomunikasi kompleks harus dikontrol oleh metode biasa, seperti kartu gesek, biometrik, atau kunci bantalan di samping semua pintu masuk. Kompromi kadang-kadang akan diperlukan, karena meskipun  sulit untuk masuk ke dalam, mereka harus mudah untuk melarikan diri dari dalam peristiwa kebakaran atau peringatan bom. Namun, jika semuanya gagal, organisasi harus menciptakan teknologi informasi  layanan, mungkin di lokasi yang sama sekali berbeda.

Akses ke beberapa item yang  tersebar di peralatan teknologi informasi dapat lebih sulit untuk dikontrol, dan mudah diabaikan. Hal ini dapat karena peralatan komputer telah ditambahkan, ditata untuk tujuan lain.

Peralatan juga perlu benar dilindungi terhadap bencana 'alam'. Dalam gedung kantor, ancaman yang paling umum adalah dari kebakaran dan banjir.  Contoh bencana alam lainnya adalah adanya gempa bumi  yang menghadirkan ancaman di banyak bagian dunia.

Pada akhirnya, perlindungan fisik terhadap peralatan teknologi informasi sedikit berbeda dari  kebanyakan jenis aset lainnya. Perencanaan di area ini harus selalu berada dalam kerjasama yang erat dengan mereka yang bertanggung jawab atas keamanan fisik dalam organisasi
secara keseluruhan.

9.4 Menyiasati Bencana

Baris kedua pertahanan untuk sistem teknologi informasi adalah untuk mempertimbangkan apakah  jika terjadi kerusakan terbatas, mungkin untuk terus menjalankan sistem
tanpa efek yang berat.

Penghapusan atau menghindari dampak kerusakan panggilan untuk beberapa bentuk 'jaring pengaman'. Peralatan dan kesalahan manajemen Ekstra perangkat lunak yang diinstal, yang dipotong pada saat kesulitan terjadi. Idealnya, ini akan terjadi lancar, sehingga pengguna bahkan tidak akan menyadari bahwa ada sesuatu yang salah. Dalam prakteknya, hal itu tidak selalu untuk mencapai pemulihan 'instan', atau mungkin ada degradasi nyata dalam kualitas layanan.

Untuk sistem yang lebih besar posisi mungkin sangat berbeda. Jika sistem ini
penting untuk perusahaan, error recovery dari apapun penyebabnya akan sangat serius. Untuk menurunkan layanan untuk semua ini akan mengakibatkan kerugian besar pendapatan , dan banyak pelanggan dan pengecer yang kecewa . Oleh karena itu lotere telah banyak berinvestasi dalam
peralatan tambahan untuk memungkinkan untuk bertahan hidup sebanyak mungkin dari kegagalan
yang mungkin mempengaruhi sistem , termasuk kerugian daya , crash prosesor
atau disk , dan kegagalan telekomunikasi ( Partridge 1994 ) .

Diyakinkan pemulihan instan umumnya membutuhkan tiga unsur utama:

ü  Sebuah duplikat fasilitas . Ini bisa menjadi prosesor , disk drive yang berisi salinan file yang terbaru , power supply , atau jalur komunikasi . Fasilitas ini sangat jarang , sehingga sangat penting untuk memastikan bahwa akan bekerja jika dan ketika diperlukan . Pemeriksaan dapat dilakukan melalui tes rutin dari peralatan, atau dapat dibangun dengan cara sistem yang bekerja.  Ada tujuan kecil
dalam memiliki dua prosesor jika mereka berbagi , misalnya , penggunaan penting
dan kesalahan - rawan komponen , seperti unit daya atau antarmuka jaringan kartu.

ü  Integritas setelah cut -over . Tidak ada prosedur yang benar-benar ' instan ' , dan sebagainya. selalu ada risiko bahwa ketika fasilitas duplikat mengambil alih , itu tidak akan berada  persis pada keadaan yang sama seperti aslinya . Hal ini dapat berarti bahwa beberapa data akan hilang ' jatuh melalui celah-celah ' , atau sistem yang tersisa dengan transaksi yang tidak dapat diselesaikan dengan baik.

ü  Kelayakan perbaikan. Jika sistem ini ditutup untuk pemeliharaan secara rutin, setiap item yang rusak dapat diperbaiki atau diganti saat ada
kesempatan yang tersedia. Untuk sistem yang beroperasi sepanjang waktu, yang situasinya tidak begitu sederhana. Pemulihan instan hanya masuk akal jika itu layak untuk membuat perbaikan 'on the fly'. Jika tidak, pengguna masih akan terganggu, meskipun mungkin ada beberapa pilihan tentang waktu dari gangguan, dan mereka dapat diberikan beberapa peringatan terlebih dahulu. Menjalankan perbaikan hanya akan mungkin jika hal ini telah diizinkan dalam desain peralatan. Sebagai contoh, teknisi harus mampu
mendapatkan akses yang aman ke seluruh bagian perakitan, tanpa mengganggu apapun peralatan yang tidak terpengaruh, atau harus mematikan
pasokan listrik secara umum.

·         9.4.1 Power persediaan

Pengaturan yang mungkin dilakukan oleh bisnis berusaha untuk menutupi
setiap kemungkinan yang ditunjukkan pada Gambar 9.2. Dalam operasi normal, melalui normal Power Supply (1). Jika hal ini gagal, tetapi utilitas listrik masih mengirim kekuasaan atas masyarakat grid, peralatan menarik daya dari Normal Power Supply (2).

Pemeriksaan rutin akan diperlukan pada setiap aspek daya stand-by sistem, misalnya, untuk memastikan bahwa baterai UPS memegang  biaya, dan bahwa generator mampu bekerja dengan baik dan memiliki bahan bakar di dalam tangki. Sistem UPS yang lebih besar menghasilkan banyak panas dari baterai, dan sehingga beberapa pengaturan pendingin khusus mungkin diperlukan. Kapasitas pasokan back-up juga harus dimasukkan di antara hal-hal jika ditinjau peralatan komputasi baru dipasang, untuk memastikan bahwa
akan mampu mengatasi dengan meningkatnya permintaan yang dapat ditempatkan di atasnya.

·         9.4.2 Disk: cermin dan bayangan

PC biasanya tergantung pada satu disk drive dengan kapasitas beberapa gigabyte .
Sistem yang lebih besar menggunakan beberapa drive , tidak semua yang mungkin
sama, misalnya , data yang yang sedang diarsipkan dapat ditulis lebih lambat
dan perangkat yang lebih murah , seperti WORM ( ' write -once , read- many ' optik
drive ) . Perlindungan terhadap kegagalan komponen hanya mungkin dipertimbangkan untuk data yang teratur dalam permintaan . Ada tiga cara yang berbeda mendekati ini , yang diilustrasikan pada Gambar 9.3 . Ini menunjukkan gambar disederhanakan , di mana prosesor dapat menyimpan data pada salah satu dari tiga disk . Ada dua file , A dan B , masing-masing diasumsikan , lagi untuk kesederhanaan , mengandung hanya dua catatan .
Metode paling sederhana untuk menduplikasi sebuah file akan menuliskannya dalam Surat
keseluruhan untuk kedua dari disk dalam unit yang sama. Atau , salinan mungkin dikirim ke disk yang sama sekali berbeda (dalam unit 1).
dalam unit 2 , yang bisa berada di lokasi yang sama sekali berbeda. Pilihan pertama  akan lebih mudah dan lebih murah untuk diterapkan, tetapi penggunaan yang terpisah, unit pilihan kedua membuat pengaturan jauh lebih tangguh .

Figure 9.3

Membuat salinan , terutama jika mereka disimpan di lokasi terpencil , dikenal sebagai
mirroring atau berbayang . Kemungkinan ketiganya  ditampilkan , penggunaan file B. Sekali lagi , file tersebut hanya memiliki dua catatan , tapi kali ini catatan yang dibagi di dua drive . Ini dikenal sebagai striping data . Striping masuk akal bila diterapkan untuk hanya dua catatan , tetapi merupakan suatu fitur integral dari sistem penyimpanan RAID , di mana RAID singkatan dari Redundant Array of Independent ( atau Inexpensive ) Disks .

Sistem RAID mengandung sejumlah besar disk drive , dengan data yang bergaris-garis dari mereka ( tidak selalu catatan sebagai individu, tetapi cara apa pun sistem kontrol unit RAID yang memilih ) . Pemasok RAID memiliki menciptakan cara-cara canggih untuk mengelola data , untuk membantu memastikan akses bahkan jika kegagalan terjadi pada drive individu . RAID telah menjadi populer tidak hanya untuk ketahanan , tetapi karena dapat memberikan waktu respon yang sangat baik untuk menulis dan mengambil catatan . Pemasok telah mengembangkan berbagai sistem. Banyak yang menggabungkan manfaat dari kedua striping dan membayangi ( Brackenridge 1993) .
Oleh karena itu mungkin untuk memiliki yang terbaik dari kedua dunia - kinerja dan
ketahanan - meskipun biasanya pada harga premium . Pengguna harus diingat bahwa dalam hal terjadi bencana serius , isi disk individual akan berarti sebagian besar , dan data hanya dapat disatukan lagi dengan bantuan perangkat lunak RAID proprietary , dan tabel yang
mempertahankan .

9.5 Menciptkan dan Melaksanakan Rencana Pemulihan Bencana

Ada sebagian  kecil, dan berkurang, sejumlah organisasi yang  melakukan Rencana Pemulihan Bencana yang  tidak perlu, para anggota ini menggunakan sedikit sistem informasi, dan bekerja pada penjualan yang panjang dan siklus produksi. Semua organisasi setidaknya harus meninjau apakah mereka membutuhkan sebuah Rencana Pemulihan Bencana. Setelah kasus untuk rencana telah dibuat, manajemen harus mengambil langkah awal dengan resourcing pekerjaan yang diperlukan untuk mengembangkan rencana tersebut, dan menyetujui definisi layanan-layanan yang dicakup oleh program tersebut, sebagai benar-benar penting untuk kelangsungan hidup organisasi.
Jika beberapa atau semua sistem teknologi informasi outsourcing, prosedur pemulihan harus tercakup dalam perjanjian outsourcing. Bahkan kemudian, sebenarnya proses pemulihan dari bencana akan membutuhkan kerjasama dari kedua pihak, dan Rencana Pemulihan Bencana harus ditetapkan mana tanggung jawab milik organisasi, dan yang melakukan  promosi.

Rencana Pemulihan Bencana perlu mengandung enam unsur utama yang ditunjukkan pada Gambar 9.4. yang pertama,  Dua catatan yang digarisbawahi karena mereka mengacu pada aset yang sekali hilang, mungkin mustahil untuk menggantikan. Segala sesuatu yang lain dalam daftar bisa dibeli, atau meminjam dari tempat lain. organisasi akan mengetahui kenapa dia tidak dapat membeli di pasar terbuka, melalui rincian penjualan bulan lalu, dan pengalaman dan keahlian dari para stafnya.

Rencana Pemulihan Bencana  adalah sebuah rencana aksi , dan karena itu harus berkonsentrasi pada  isu-isu seperti bagaimana orang-orang diharapkan untuk melakukan kontak , apa yang harus mereka lakukan , dan di mana mereka akan menemukan hal-hal lain . Pada puncak darurat , staf tidak akan tertarik untuk membaca poin-poin penting dari kebijakan . struktur
harus dimodelkan pada contoh terbaik dari panduan yang dikeluarkan untuk pemilik dari komputer , menyediakan semua bahan referensi penting dengan pengindeksan yang  baik , dan memberikan penjelasan sederhana dari prosedur yang harus diikuti .

Salinan rencana harus dikeluarkan untuk semua orang yang kemungkinan akan memainkan
peran penting dalam mengimplementasikannya . Staf harus didorong untuk mengambil salinan rumah , sehingga mereka akan bisa menyediakan  bahkan jika kantor mereka tidak diberikan diakses. Ini berarti mempertahankan daftar sirkulasi dan sistematis penerbitan setiap update.  Jika  tidak, kebingungan akan hasil dari orang yang mencoba untuk menerapkan versi yang berbeda dari rencana. Beberapa langkah perlu menempatkan secara berkelanjutan, Misalnya , salinan back- up secara teratur harus diambil , dan stand-by fasilitas akan perlu diuji .

Mari kita perhatikan masing-masing bahan dari rencana pada gilirannya:
1.  Manusia . Ada alasan kuat untuk bersikeras bahwa orang yang menarik rencana tidak harus menjadi orang yang mengambil alih jika dan ketika itu diberlakukan . Pertama , penulis rencana harus mengasumsikan bahwa hal itu akan diperlukan untuk menguraikan semua peran dan tanggung jawab staf , termasuk dari orang yang akan menjalankan pemulihan operasi . Hal ini memastikan bahwa tidak ada dalam rencana tergantung pada informasi hanya diketahui oleh penulis , sehingga menghindari masalah yang bisa muncul pada saat penting jika ternyata penulis telah meninggalkan
perusahaan, atau mengambil libur . Kedua , ada kemungkinan bahwa jika bencana mengancam
seluruh masa depan bisnis , kepala eksekutif akan ingin mengambil kendali langsung pula .
Demikian pula, prosedur yang ditetapkan dalam rencana tidak harus mengasumsikan bahwa
bernama individu akan tersedia . Dalam acara tersebut , mereka mungkin tidak dapat dihubungi , atau  bahkan kematian dari dampak dari bencana ini . Ini tidak berarti bahwa nama harus
dihindari dalam rencana,  memang, nama dan nomor telepon rumah akan
menjadi bagian penting dari itu , tetapi , sedapat mungkin harus dapat diidentifikasi .
2 . Data dan software . Ini harus diasumsikan bahwa bencana akan menghancurkan semua
salinan data dan perangkat lunak yang  ada pada organisasi. Hal ini menimbulkan banyak pertanyaan tentang di mana back- up salinan harus diadakan , dan bagaimana mereka harus terus up to date .
Pendekatan paling sederhana untuk menjaga back- up salinan data didasarkan pada
' Generasi ' , seperti digambarkan pada Gambar 9.5 . Pada tanggal 1 Januari , salinan back- up
data dibuat ke kaset A. Seminggu kemudian back- up dibuat pada tape B , dan seminggu kemudian pita C digunakan . Pada titik ini , instalasi memiliki tiga back- up . satu dari ketiga back- up tersebut adalah yang terbaru, tetapi dalam hal apapun harus terjadi untuk itu , dua lainnya yang tersedia akan lama tidak bekerja . Dalam prakteknya , data yang back- up strategi harus sedikit lebih canggih
dari ini , untuk sejumlah alasan seperti:

ü  Karena penuh back- up sering melibatkan data dalam jumlah besar , dapat
mudah untuk bekerja dengan incremental back - up . ini hanya mengandung
perubahan data yang telah dibuat sejak back- up sebelumnya . untuk menciptakan kembali data secara keseluruhan , perlu untuk memulai dengan satu penuh back- up , dan menambahkan kembali semua incremental back - up yang telah dilakukan .

ü  Prosedur menyalin lain mungkin di tempat untuk keperluan lain , karena
Misalnya , catatan dapat teratur dipisahkan dari file pada disk komputer utama , dan dimasukkan ke dalam beberapa bentuk arsip . Ini mungkin diasumsikan (mungkin cukup salah) bahwa pengarsipan memberikan perlindungan terhadap bencana . Jika arsip yang tidak dilindungi , mereka juga harus disertakan dalam rencana back- up , karena mereka mungkin diperlukan untuk alasan hukum , atau untuk membantu dengan audit, atau untuk analisis jangka panjang diperlukan untuk keputusan manajemen .

ü  Ketika data langsung pada sistem itu akan tunduk pada jenis
kontrol akses, Data harus terus dilindungi setelah berada di back- up tape ( yang biasanya akan berarti menempatkan pembatasan ketat pada situasi di mana rekaman itu dapat digunakan ) , dan itu harus mungkin untuk menciptakan kembali data dalam persis bentuk yang ekuivalen pada sistem lain , sehingga kontrol akses akanterus bekerja .

Dalam beberapa kasus, back up data tampaknya tak ada gunanya, misalnya, data referensi yang digunakan dalam perencanaan atau desain pekerjaan mungkin telah diperoleh dari sumber eksternal, sehingga mudah untuk menggantinya.

 Duplikat salinan beberapa dataset dapat diadakan pada sistem, untuk melayani berbagai kelompok pengguna, atau untuk meningkatkan kinerja sistem, dan membuat duplikat backup
ini tampak berlebihan. Perangkat lunak biasanya menyumbang ruang penyimpanan lebih sedikit , dan jadi ada seharusnya tidak ada masalah dalam dukungan itu secara keseluruhan . Perhatian khusus harus dibayar untuk perangkat lunak penting , yaitu bahwa yang unik untuk bisnis, dan yang menangani kegiatan inti seperti manajemen persediaan dan akuntansi . Namun demikian, membayar untuk membuat perangkat lunak sebagai back up komprehensif mungkin , untuk menghindari tertangkap oleh inter – dependensi antara program , yang tidak selalu jelas . Sebagai contoh, paket mungkin perlu menggunakan utilitas kompresi data , tanpa ada yang akan mampu membuka file-nya.
3.  Premises .  Untuk memastikan ketersediaan , alternatifnya, meningkatkan kemungkinan bahwa
mereka akan terpengaruh oleh bencana yang lebih luas yang mungkin telah ditelan situs asli . Namun, ini akan memperlambat pemulihan , karena akan memakan lebih lama untuk mentransfer staf , dan bahan-bahan yang telah diselamatkan .
4.  Prosesor . Keputusan tentang prosesor sangat erat kaitannya dengan keputusan tentang tempat . Umumnya , stand-by situs dapat dikelompokkan dalam tiga kategori, yaitu:
( a) Mutual . Tercapai kesepakatan dengan situs lain yang ruang dan komputasi daya akan disisihkan, dan akan selalu tersedia dalam terjadi bencana . Idenya adalah bahwa kedua belah pihak masing-masing beroperasi sistem serupa , tapi selalu memungkinkan untuk sejumlah kapasitas cadangan ,
sehingga mereka dapat , jika perlu , memberikan cadangan untuk satu sama lain . ini pilihan yang menarik bagi dua situs dalam organisasi yang sama , terutama jika mereka dijalankan sebagai bagian dari departemen TI tunggal . situasi dapat lebih rumit jika organisasi terpisah yang terlibat . masing-masing pihak memiliki , setelah semua , untuk mendanai kapasitas cadangan untuk kepentingan lain, dan itu mungkin sulit untuk setuju persis bagaimana ini harus dibayar . ketegangan juga dapat timbul karena instalasi , bahkan jika mereka sangat mirip awalnya , mungkin perlu untuk mengembangkan ke arah yang berbeda untuk peralatan atau perangkat lunak .

(b) warm or hot stand-by. Sebuah situs hot stand-by menawarkan fasilitas yang cocok dengan yang tersedia di instalasi yang ada pada organisasi. Ini termasuk semua kekuatan yang diperlukan, kabel, telekomunikasi,AC, dan satu set lengkap peralatan komputer.

(c) Cold stand-by. A cold stand-by situs (kadang-kadang disebut 'shell' situs) menawarkan tidak lebih dari ruang di mana layanan komputer dapat dibangun kembali dari awal. Ini akan memiliki pasokan listrik yang memadai dan beberapa Link telekomunikasi dasar, tetapi , Ini akan sampai kepada klien untuk meminjam atau membeli dalam prosesor, disk, dan printer, dan mengatur link telekomunikasi tambahan yang dibutuhkan.

5 . Telekomunikasi . Penyediaan perlu dibuat untuk saluran telepon biasa(termasuk yang diperlukan untuk digunakan dengan pesanan telepon berbasis entri atau pertanyaan layanan yang sedang direlokasi ) . Rencana Pemulihan Bencana tersebut harus juga menentukan jumlah dan jenis koneksi yang akan dibutuhkan untuk link data ke bagian lain dari organisasi , misalnya untuk suboffices atau gudang , serta untuk layanan eksternal , seperti link untuk EDI dan email via VAN atau Internet . Jika organisasi beroperasi nya situs web sendiri , mungkin menemukan solusi yang terbaik adalah dengan mengatur bahwa cermin copy dari situs cepat dapat diaktifkan menggunakan jasa komersial penyedia situs web internet .

6. Supplies . Kadang-kadang hal-hal sederhana yang paling mudah untuk mengabaikan .
Namun, tidak ada sistem komputer dapat berjalan tanpa perlengkapan dasar seperti kartrid tinta, kertas untuk printer terus menerus dan sheet -feed , dan banyak kaset kosong dan disket . Foresight di daerah ini dapat memainkan peran besar dalam mempertahankan kepercayaan pelanggan dan pemasok. misalnya , jika organisasi dapat terus mengirimkan surat-surat dan cek kepada alat cetakannya sendiri. Bentuk yang tepat, rencana mengambil akan tergantung pada faktor-faktor seperti ukuran organisasi , dan prioritasnya.

Jika kerusakan hanya parsial, tahap penilaian bencana mungkin lebih sulit. Jelas, tidak ada gunanya dalam mengarahkan energi setiap orang untuk beralih ke stand-by situs, jika ada kemungkinan wajar bahwa aslinya situs dapat dibawa kembali ke layanan. Namun, setelah itu telah
memutuskan untuk melaksanakan rencana tersebut, harus ada sedikit keraguan karena mungkin
untuk bagian yang setiap orang diharapkan untuk bermain. Satu-satunya cara untuk menjadi yakin bahwa rencana tersebut akan bekerja adalah untuk melakukan suatu pengujian.  Bila memungkinkan, peralatan dan perangkat lunak pemasok harus terlibat dalam pengujian, juga tanpa peringatan terlebih dahulu. Jika stand-by situs adalah untuk digunakan, hal itu mungkin tidak layak untuk memeriksa pembangunan yang sebenarnya layak dari sistem. Ini harus dimungkinkan untuk memeriksa apakah semua pemasok yang relevan yang dihubungi, dan apakah mereka memegang saham dari item yang akan diperlukan.

9.6 Implikasi Proliferasi nya

Prosedur yang ditetapkan dalam Rencana Pemulihan Bencana akan mencakup semua
program dan file yang disimpan di jantung organisasi. idealnya, ini akan memuat segala sesuatu signifikansi yang telah ditangkap atau dihasilkan dalam kantor remote. Dalam prakteknya, akan selalu ada beberapa lokal bahan diadakan yang belum diserap ke dalam pusat informasi
sistem dengan cara ini.

Dalam beberapa hal , keberadaan file lokal dalam bentuk elektronik adalah keuntungan . Sebelumnya, dokumen mungkin hilang melalui penghancuran lemari arsip dalam ledakan atau kebakaran , dan satu-satunya perlindungan yang mungkin akan melalui sejumlah besar pencegahan . elektronik catatan akan didukung dalam beberapa detik , dan disimpan pada disk tunggal . Sebuah kantor lokal tidak perlu menyusun Rencana Pemulihan Bencana penuh tetapi harus menempatkan beberapa langkah-langkah dasar di tempat , dengan menggunakan prinsip-prinsip berikut:

ü  Kemudahan kepatuhan . Pilihan yang paling sederhana adalah untuk mengambil seluruh salinan. Hal ini cukup layak untuk mengambil salinan lengkap dari setiap disk di setiap PC secara teratur , menggunakan pita kaset atau berkapasitas tinggi disket drive . Namun , seperti dalam kasus pemeriksaan virus , ini hanya akan efektif jika kepatuhan semua orang terjamin . Mungkin ada keengganan untuk repot-repot dengan back- up jika melibatkan prosedur seperti memasukkan peralatan ke dalam bagian belakang mesin , dan mencari ikon kanan layar untuk mengaktifkannya . Proses menyimpan file harus otomatis , sejauh bahwa hal itu dikurangi untuk memilih opsi menu sebelum mematikan mesin , atau bahkan dipicu secara otomatis setiap hari . Jika PC adalah melekat pada LAN , salinan back- up dapat dikirim ke server LAN ,
dan file server 'maka dapat didukung secara massal .

Jika PC adalah portabel , mungkin perlu memiliki perangkat penyimpanan back- up sendiri . back- up layanan untuk file PC menjadi tersedia di Internet , meskipun dalam hal ini perawatan kasus perlu diambil untuk memastikan bahwa setiap file sensitif dilindungi dengan benar .

ü  Teks dan pesan suara . Serta file yang langsung di bawah pengguna, kontrol dalam PC kantor , mungkin ada salinan masuk dan keluar pesan yang penting bagi pekerjaan departemen . ini dapat terdiri dari pesan EDI , surat elektronik dan pesan suara . Ini akan menjadi berguna untuk memeriksa , jika ada , ini benar-benar diadakan pada kantor Server . Jika mereka disimpan di tempat lain , itu akan menjadi layak bertanya apa ketentuan yang telah dibuat untuk ini harus dipulihkan jika terjadi bencana.

ü  Ketersediaan alat . Kadang-kadang karyawan mungkin diperlukan untuk bekerja
dengan informasi sensitif . Di kantor tradisional , mereka mungkin diperlukan untuk memastikan bahwa semua dokumen yang relevan disimpan dalam khusus mengamankan kabinet . Adalah penting bahwa fasilitas setara dengan mudah tersedia
kepada orang-orang melakukan pekerjaan tersebut secara elektronik . Sebagai contoh,
organisasi harus membuatnya mudah untuk mendapatkan dan menginstal kontrol akses tambahan dan fasilitas untuk PC individual back- up , terutama jika ini adalah
portabel .

9.7 Membenarkan Investasi di Tindakan untuk Kontinuitas Usaha Perlindungan

Pemilihan langkah-langkah untuk melindungi kelangsungan bisnis ( BCP ) harus
berdasarkan penilaian terhadap semua risiko , biaya dan manfaat. Metode ini tidak akan cukup diterapkan  dengan cara yang sama , namun, seperti yang  lainnya jenis risiko keamanan. Secara umum, risiko sedang dipertimbangkan di BCP memiliki keterkaitan  dengan teknologi , dan lebih berkaitan dengan isu-isu yang lebih luas . Beberapa Perbedaan yang mengatur BCP terpisah dari aspek-aspek lain dari keamanan informasi adalah sebagai berikut :

ü  Banyak ancaman yang dipertimbangkan tidak spesifik untuk IT . cara ini bahwa ada banyak pengalaman dari orang-orang yang bekerja di lain bidang, dan bahwa mungkin ada statistik yang relevan akan kembali jauh sebelum IT diciptakan . Contohnya adalah fenomena alam , seperti pola cuaca buruk dan efek yang dihasilkan dari itu .

ü  BCP meliputi seluruh perusahaan , bukan hanya IT . Ini berarti bahwa aset TI mungkin perlu dipertimbangkan bersama jenis yang sama sekali berbeda dari yang lain aset , dan bahwa metodologi yang digunakan untuk analisis harus sesuai dengan yang dipilih oleh tim proyek BCP .

ü  BCP akan mencari di luar organisasi . Jika bencana pemogokan keseluruhan daerah atau masyarakat , pemulihan akan terhambat oleh kurangnya pelayanan publik dan persaingan antara perusahaan untuk fasilitas yang berada di pasokan pendek . Mungkin sulit untuk memperoleh informasi yang dapat dipercaya tentang apa yang terjadi , atau untuk menetapkan siapa yang bertanggung jawab .

ü   Penanggulangan relevan dengan BCP sering dapat diuji . Seperti yang telah terlihat pada
bab-bab sebelumnya , hampir tidak mungkin untuk memverifikasi apakah  dalam event , dompet elektronik atau firewall Internet akan menjadi cukup tahan terhadap serangan . Namun, masalah BCP sering berpusat pada lebih pertanyaan biasa , seperti apakah dinding adalah api-bukti , atau atap adalah cukup kuat untuk mengambil beban yang diberikan . The Disaster Recovery Plan , juga, dapat diuji secara menyeluruh hanya dengan berpura-pura bahwa bangunan tidak dapat digunakan .
Hal ini bertentangan dengan ketidakpastian yang terkait dengan bentuk-bentuk lain
pengujian keamanan , di mana perlu untuk menebak bagaimana hacker berbakat
mungkin memulai serangan mereka : ini tergantung pada asumsi penduduk yang
ahli yang dapat mengidentifikasi semua kemungkinan ancaman .

ü  BCP prihatin dengan pelestarian aset , dan sehingga tidak terlalu sulit untuk mengurangi perkiraan kemungkinan kerusakan sosok tunai . Sebaliknya, dengan isu-isu seperti privasi atau integritas pesan , yang sama pentingnya , sulit untuk mengukur manfaat yang
yang disediakan oleh langkah-langkah keamanan . Sebagian besar dari faktor-faktor yang tercantum di atas memiliki efek membuat perhitungan untuk BCP merasa lebih ' utama ' dan akrab ( setidaknya untuk akuntan ) . Namun, skala yang sangat besar potensi kerugian , dan probabilitas yang sangat rendah yang ering dikaitkan dengan mereka, mengambil perhitungan ke daerah-daerah bermasalah yang telah dibahas sebelumnya (lihat bagian 2.4).

Dalam mempertimbangkan dampak dari kegagalan besar, konsekuensi yang mungkin
dapat diklasifikasikan dalam dua judul: kerugian langsung dan tidak langsung. Kerugian langsung biasanya diasuransikan. Pembayaran dari asuransi perusahaan pasti akan membantu untuk melunakkan dampak dari bencana, tetapi mereka tidak boleh dianggap sebagai pengganti perencanaan pemulihan. Penanggung dimengerti enggan untuk menanggung kerugian yang tidak dapat dijelaskan di muka. Mereka akan memberikan penutup untuk penggantian peralatan, atau kompensasi yang akan dibuat dalam keadaan pasti, namun di luar itu klausul pengecualian mulai menjadi sangat luas, atau secara dramatis premi yang lebih tinggi akan menuntut. Restitusi kerugian langsung tetap akan begitu penting, kecuali mungkin kepada kreditur perusahaan, jika hasil bersih dari bencana telah bahwa perusahaan tidak bisa melanjutkan trading dan telah dipaksa ke kurator.

Oleh karena itu, kerugian yang paling penting untuk dipertimbangkan adalah yang  tidak langsung.

Kerugian tidak langsung cenderung tidak berwujud dan sulit untuk diukur. mereka akan
sering melebihi kerugian langsung dengan margin lebar, dan akan terus menjadi
merasa untuk waktu yang lama setelah bencana selesai.