DRP Template - ISO 22301

Manajemen Risiko Teknologi Informasi

2014

Disaster Recovery Template (DRP) (DRP) Template Template Muh. Idil Haq Amir 5211100704

0|Disaster Recovery Planning

Sistem Informasi Institut Teknologi Sepuluh Nopember (DRP) Template (ITS)

Daftar Isi

Daftar Isi ................................................................................................................................................. 1 Studi Literatur ......................................................................................................................................... 3 A.

Bencana.................. Bencana.................. ......................... .......................... ........................... .......................... ............... 3

B.

Risiko......................... ........................... ......................... .......................... ......................... ............ 3

C.

Manajemen Manajemen Risiko ........................ .......................... ......................... .......................... .................... 4

D.

Disaster Disaster Recovery Recovery Planning (DRP) ......................... .......................... ......................... .................... 5

E.

ISO 24762 ....................... ......................... .......................... ......................... ........................... ....... 7

F.

ISO 22301 ....................... ......................... .......................... ......................... ........................... ....... 8

Disaster Disaster Recovery Recovery Planning (DRP) Template........................ .......................... ......................... .............. 11 I.

Project Project Planning ........................... .......................... ......................... .......................... .................. 11 1.1. Deskripsi Deskripsi Organisasi Organisasi .......................... ......................... .......................... .......................... ..... 11 1.2. Kondisi Lingkungan Lingkungan IT Organisasi .......................... .......................... .......................... ......... 11 1.3. Menentukan Menentukan Scope Scope Project Project ......................... .......................... ......................... ....................... 12 1.4. Membuat Projec Projectt Schedule ......................... .......................... ......................... ....................... 12 1.5. Mengidentifikasi Mengidentifikasi Risiko Risiko Project................................... Project................................... ........................... ......................... ..... 12 1.6. Menentukan Menentukan Tim Proyek serta Project Sponsor .......................... ......................... .................. 13

II.

Risk Analysis Analysis .......................... .......................... .......................... ......................... ....................... 13

III.

Business Business Impact Analysis .......................... ......................... .......................... .......................... ..... 14

IV.

Recovery Recovery Strategy ........................ .......................... ......................... .......................... .................. 15

V.

Plan Development Development ........................ .......................... ......................... .......................... .................. 19 5.1 Objective Objective ......................... .......................... .......................... ......................... ....................... 19 5.2 Plan Assumptions Assumptions........................... ......................... .......................... .......................... ......... 19 5.3 Criteria for Invoking Invoking The The Plan Plan ......................... .......................... ......................... .................. 19 5.4 Roles Roles Responsibility Responsibility and Authority Authority ......................... .......................... .......................... ......... 20 5.5 Procedures Procedures for Operating Operating in Contingency Mode ........................................ .......................... . 21 5.6 Resource plan for operating operating in contingency contingency mode.......................... ......................... .............. 24 5.7 Criteria for for Returning to Normal Operating Mode Mode ..................................... ........................... 24

VI.

Implementation..................................... Implementation..................................... .......................... ........................... ......................... ......... 24 6.1 Procedures Procedures for Returning to Normal Operating Operating Mode ........................ .......................... ......... 24 6.2 Procedures Procedures for Recovering Recovering Lost or Damaged Damaged Data......................... ......................... .............. 25

1|Disaster Recovery Planning (DRP) Template

6.3 Testing and Training .......................... ......................... .......................... .......................... ..... 25 6.4 Plan Maintenance Maintenance ........................... ......................... .......................... .......................... ......... 25 6.5 Appendices Appendices for Inclusion Inclusion ........................ .......................... .......................... ......................... . 25 VII. Testing and Exercising .......................... ......................... .......................... .......................... ......... 26 VIII. Maintenance Maintenance ........................ .......................... .......................... ......................... ........................... 28 Daftar Pustaka ....................................................................................................................................... 29


Studi Literatur A. Bencana

Berdasarkan peraturan Undang-undang Nomor 24 Tahun 2007 tentang Penganggulangan Bencana, disebutkan bahwa definisi bencana adalah sebagai berikut: “Bencana adalah peristiwa atau rangkaian peristiwa yang mengancam dan mengganggu kehidupan dan penghidupan masyarakat yang disebabkan, baik oleh faktor alam dan/atau faktor nonalam maupun faktor manusia sehingga mengakibatkan timbulnya korban jiwa manusia, kerusakan lingkungan, kerugian harta benda, dan dampak psikologis.” psikologis.” Pada undang-undang tersebut dijelaskan bahwa bencana itu disebabkan oleh beberapa hal. Sehingga, pada undang-undang ini juga dijelaskan bahwa Bencana yang disebabkan oleh alam, nonalam serta sosial. Berikut adalah definisinya berdasarkan peraturan Undang-undang Nomor 24 Tahun 2007 tentang Penganggulangan Bencana. Bencana alam adalah bencana yang diakibatkan oleh peristiwa atau serangkaian peristiwa

“

yang disebabkan oleh alam antara lain berupa gempa bumi, tsunami, gunung meletus, banjir, kekeringan, angin topan, dan tanah longsor.” longsor.” be ncana yang diakibatkan o leh peristiwa atau at au rangkaian rangka ian Bencana nonalam adalah bencana

“

peristiwa nonalam yang antara lain berupa gagal teknologi, gagal modernisasi, epidemi, dan wabah penyakit.” penyakit.” Bencana sosial adalah bencana yang diakibatkan oleh peristiwa atau serangkaian peristiwa

“

yang diakibatkan oleh manusia yang meliputi konflik sosial antarkelompok atau antarkomunitas masyarakat, dan teror.” teror.” B. Risiko

Dalam dunia bisnis maupun IT, setiap proses dan aktifitas akan selalu menghadapi yang namanya ketidakpastian yang menimbulkan risiko bagi organisasi. Dan dari risiko tersebut akan menimbulkan berbagai dampak bagi organisasi, baik dari segi biata, sumber daya manusia, maupun aspek-aspek yang lain. Resiko adalah suatu hal yang kemungkinan terjadinya dapat diperhitungkan di awal serta memiliki dampak (Safitri, 2009). Menurut sifatnya, risiko dapat dibedakan menjadi lima kategori. Berikut adalah k ategori tersebut: a. Risiko Murni, yaitu risiko yang tidak disengaja dan menimbulkan banyak kerugian bagi organisasi, misalnya bencana alam, kebakaran, pencurian dan pencurian. 3|Disaster Recovery Planning (DRP) Template

b. Risiko Spekulatif, yaitu risiko yang sengaja ditimbulkan, maksudnya adalah organisasi sudah mengetahui tindakan yang diambil akan menimbulkan risiko bagi organisasi, misalnya hutang-piutang dan kontrak kerja. c. Risiko Fundamental, yaitu risiko yang terjadi tanpa diketahui penyebab utama. Artinya bahwa organisasi tidak dapat menjadikan seseorang/kelompok sebagai penyebab risiko terjadi dan menyebabkan banyak orang merasakan risiko tersebut. Misalnya banjir, angina topan dan sejenisnya. d. Risiko Khusus, yaitu risiko yang pada umumnya diketahui penyebabnya oleh organisasi. Misalnya kecelakaan mobil, pesawat jatuh dan tabrakan. e. Risiko Dinamis, yaitu risiko yang muncul dikarenakan perkembangan zaman dari waktu ke waktu dalam bidang ekonomi dan teknologi misalnya risiko penurunan harga karena sudah menjadi barang yang usang. Sedangkan menurut sumber atau penyebab timbulnya risiko, dapat dibedakan menjadi dua kategori yaitu (MTI, 2009) : a. Risiko Internal, yaitu risiko yang timbul akibat aktifitas organisasi itu sendiri dan dari pihak internal sendiri. Misalnya kecelakaan kerja, kerusakan mesin dan kekurangan karyawan. b. Risiko Eksternal, yaitu risiko yang timbul dari luar organisasi yang merugikan organisasi. Misalnya persaingan dengan organisasi lain, naik turunnya harga dan kondisi lingkungan. C. Manajemen Risiko

Setiap risiko yang muncul dari aktivitas/proses bisnis organisasi perlu adanya manajemen untuk mnegantisipasi maupun mitigasi risiko tersebut. Secara umum, manajemen risiko adalah serangkaian kegiatan yang dilakukan untuk mengelola risiko yang mungkin akan terjadi dengan cara melakukan identifikasi dan mitigasi. “Manajemen risiko juga dapat diartikan sebagai suatu sistem pengawasan risiko dan perlindungan harta benda, hak milik dan keuntungan badan usaha atau perorangan atas kemungkinan timbulnya kerugian karena adanya suatu risiko” (MTI, risiko” (MTI, 2009). Adapun Strategi dalam pengendalian risiko dapat dilakukan dengan menggunakan pendekatan 4T (Siahaan, 2007), yaitu yaitu : a. Treating a risk, yaitu mengambil langkah langsung untuk mengurangi dampak ataupun frekuensi risiko. b. Terminate a risk, yaitu menghentikan aktivitas yang menimbulkan eksposur risiko. 4|Disaster Recovery Planning (DRP) Template

c. Transfer a risk, yaitu mengalihkan risiko kepada pihak lain misalnya melalui asuransi atau hedging. d. Tolerate a risk, yaitu risiko yang dapat diterima diterima oleh o leh bank. Diversifikasi dan keterkaitan antar risiko sudah diperhitungkan pada strategi 4T ini. Metode pengendalian risiko menggunakan pendekatan 4Ts dapat d igambarkan sebagai berikut:

Gambar 1. Strategi Pengendali Pengendali an - 4Ts

Keempat pendekatan 4Ts tersebut ditinjau berdasarkan kemungkinan terjadinya dan dampak/kerugiannya terhadap organisasi. Penerapan keempat pendekatan dalam pengendalian risiko tersebut dapat diterapkan sesuai dengan aktivitas atau bisnis proses serta ruang lingkup dan tanggung jawab unit kerja atau bank. Secara umum, manajemen risiko juga memiliki manfaat tertentu bagi organisasi, berikut ini adalah manfaatnya: a. Membantu organisasi menghindari semaksimal mungkin biaya-biaya yang terpaksa harus dikeluarkan. b. Membantu pihak manajemen untuk memutuskan apakah risiko yang dihadapi organisasi akan dihindari atau diambil. D. Disaster Recovery Planning (DRP)

Disaster

Recovery

Planning

(DRP)

merupakan

rangkaian

proses-proses

yang

didokumentasikan untuk melakukan prosedur recovery dan perlindungan terhadap infrastruktur bisnis IT sebelum terjadinya bencana, pada saat bencana maupun setelah terjadinya bencana. Perencaan ini biasanya tertulis pada sebuah dokumen tertulis yang berisi prosedur-prosedur yang harus dilakukan dalam menghadapi bencana yang akan terjadi. 5|Disaster Recovery Planning (DRP) Template

Disaster Recovery Planning (DRP) bertujuan untuk mengurangi risiko yang dapat terjadi dari adanya bencana dan mempertahankan agar setiap komponen/bagian dalam sistem tetap terhubung satu sama lain dalam menghadapi berbagai risiko dan bencana yang dapat terjadi. Dalam menyusun dokumen DRP ini, terdapat langkah-langkah yang harus dilakukan. Berikut adalah langkah-langkah penyusunan dokumen DRP ini. Step I

Project Initiation

Membuat perancangan awal dan penggalian informasi untuk menyusun dokumen DRP. Tujuan dari tahap awal ini adalah: 1. Memahami kondisi lingkungan IT organisasi saat ini dan di masa depan. 2. Menentukan Scope Project 3. Membuat Project Schedule 4. Mengidentifikasi risiko project 5. Menentukan tim proyek serta Project Sponsor Step II

Assessment of Disaster Risk

Mengetahui kemungkinan risiko yang terjadi berdasarkan kondisi geografis organisasi. Hal ini dapat diketahui dengan mempertimbangkan lokasi geografis organisasi, susunan/ komposisi bangungan, keamanan lingkungan/fisik operasional, alat-alat keamanan yang telah diterapkan, sistem control akses untuk lingkungan, prosedur operasional serta praktik back up yang dilakukan organisasi. Step III

Business Impact Analysis

Pada tahap ini, proses bisnis organisasi harus dianalisa dan diklasifikasikan aktifitas/sistem mana saja yang hanya dapat dijalankan dengan dukungan IT dan termasuk critical. Hal ini dilakukan untuk mempermudah proses recovery sehingga oprganisasi dapat kembali berjalan meskipun belum pulih seutuhnya. Pada bagian ini


juga dianalisa rentang waktu yang dibutuhkan agar sistem tetap tet ap dapat berjalan meskipun sistem lain tidak dapat dijalankan. Step IV

Definition of Requirements

Tahap ini merupakan tahap yang cukup sulit dan memakan banyak waktu. Setiap kebutuhan organisasi yang terkait dan dibutuhkan untuk perencanaan harus dijelaskan dengan detail. Pada bagian ini juga termasuk recovery requirement untuk proses bisnis dan IT, kemudian kebutuhan yang dihasilkan dari Businee Impact Analysis, Assessment of Disaster Risk and Mitigation of D isaster Risk. Step V

Project Planning

Menentukan proyek yang sedang dijalankan dan salah satu tujuan dari tahap ini adalah mengembangkan Disaster Recovery Plan dengan melakukan mitigasi terhadap risiko bencana sebanyak mungkin. Step VI

Project Execution

Proyek mulai dijalankan sesuai dengan standard operasional Project Management. Selama proses eksekusi ini, metode-metode mitigasi risiko mulai diterapkan dan Disaster Recovery Plan akan dibangun dan d ilakukan tahap testing. Step VII

BCP Integration

DRP yang telah dibuat pada tahap sebelumnya harus diintegrasikan kepada Business Continuity organisasi. Namun, ada pula organisasi yang membuat DRP terlebih dahulu kemudian membuat BCP dengan berdasarkan pada DRP sehingga keduanya saling terinterasi. Step VIII Ongoing Maintenance and Integration

Untuk memastikan Perencanaan yang telah dibuat tetap diperbarui sesuai perubahan lingkungan organisasi maupun factor yang lain, Perencanaan tersebut harus dilakukan Maintenance dan testing. Sehingga, ketika sewaktu-waktu terjadi sebuah bencana, maka organisasi tetap dapat menjalankan perencanaan sesuai dengan perubahan yang telah diperbarui perencanaannya. E. ISO 24762

ISO 24762 merupakan sebuah standar yang menyediakan panduan dalam menentukana layanan Information and Communication Technology Disaster Recovery (ICT DR) sebagai bagian dari dar i Business Continuity Management. Manage ment. Standar ini dapat diterapkan baik oleh organisasi 7|Disaster Recovery Planning (DRP) Template

yang menerapkan IT dan mengelolanya secara langsung ataupun organisasi yang menerapkan IT dengan bantuan dari pihak ketiga. Dalam penentuan layanan ini, ISO 24762 menetapkan beberapa hal berikut dalam standarnya: a. Kebutuhan yang harus dipenuhi dalam proses implementasi, monitoring dan memelihara layanan dan fasilitas ICT DR b. Kemampuan sebuah penyedia layanan ICT DR yang harus dimiliki dan praktik yang harus diikuti. c. Panduan dalam memilih Recovery Site d. Panduan untuk penyedia layanan ICT DR untuk mengembangkan layanan ICT DR secara berkala. Berikut adalah gambaran framework ISO 24762 untuk penyedia layanan ICT DR:

F.

ISO 22301

ISO 22301 merupakan sebuah Standar Internasional yang menetapkan prosedur yang harus dilakukan dalam proses merencanakan, menetapkan, mengoperasikan, memantau, mengkaji, memelihara dan mengembangkan Management System yang telah didokumentasikan untuk mempersiapakan organisasi dalam menghadapi bencana, menanggapinya serta melakukan recovery ketika bencana itu terjadi. Penerapan ISO 22301 ini tidak mengarah pada spesifikasi tertentu, tetapi bersifat umum dan dapat diterapkan oleh berbagai organisasi tanpa memperdulikan tipe organisasi, besar kecilnya, maupun sifat-sifat organisasi tersebut. Tingkat pengaplikasian ISO 22301 ini bergantung pada lingkungan pengoperasian dan kompleksitasnya.


Dalam pengembangannya, saat ini ISO 22301 memiliki struktur berikut sesuai dengan panduan ISO Guide 83 yang diatur ke dalam beberapa klausa utama berikut (PE CB, 2013): Clause 4: Context of the organization Pada bagian ini, ditentukan faktor-faktor apa saja yang relevan terhadap tujuan organisasi serta yang mempengaruhi kemampuan organisasi dalam mencapai hasil yang diinginkan. Misalnya, aktifitas yang terdapat dalam organisasi, fungsi-fungsi di dalamnya, layanan yang diberikan, produk yang dihasilkan, Rantai Pasok perusahaan, dan informasi umum lainnya. Clause 5: Leadership Pada bagian ini, Top Management perusahaan harus memastikan komitmen terhadap BCMS secara terus menerus. Hal ini dilakukan antara lain dengan memastikan bahwa BCMS telah sesuai dengan strategi perusahaan, mengintegrasikan kebutuhan BCMS dengan proses bisnis perusahaan dan memastikan bahwa target-target dan perencanaan dari BCMS telah ditetapkan sejak awal. Clause 6: Planning Bagian ini merupakan bagian yang sangat penting karena terkait dengan target-target strategi dan prinsip pelaksanaan BCMS secara keseluruhan. Target-target dari Business Continuity harus konsisten sesuai dengan Business Continuity Policy, terukur serta dapat dimonitoring dan diupdate secara tepat, Clause 7: Support Dalam menjalankan BCMS ini, setiap bagian haruslah menggunakan resources yang tepat. Resource ini termasuk staff bagian yang terlatih dan mampu memberikan pelayanan dan komunikasi dengan baik. Kemudian, baik pihak internal maupun eksternal organisasi juga harus dipertimbangkan dalam bagian ini. Clause 8: Operation Setelah melakukan perencanaan BCMS, maka perencanaan tersebut akan dilanjutkan pada bagian operasional. o perasional. Secara garis besar proses implementasi BCMS digambarkan d igambarkan dalam da lam diagram d iagram berikut.


Clause 9: Performance evaluation Ketika BCMS telah diterapkan, maka dalam proses ISO 22301 diperlukan proses monitoring secara berkala untuk mengembangkan pengoperasiannya. Clause 10: Improvement Continual Improvement pada bagian ini didefinisikan sebagai proses evaluasi dan monitoring secara keseluruhan terhadap organisasi untuk meningkatkan efektifitas dan efisiensi dalam proses keamanan dan control untuk meningkatkan keuntungan organisasi dan stakeholder. Hal ini dapat dilakukan dengan menyesuaikan pada Business Continuity Policy, Objectives, Hasil Audit, dan Management Review.

10 | D i s a s t e r R e c o v e r y P l a n n i n g ( D R P ) T e m p l a t e

Disaster Recovery Planning (DRP) Template Berikut adalah langkah-langkah pembuatan Dokumen Disaster Recovery Planning menggunakan ISO 22301.

I.

Project Planning 1.1. Deskripsi Organisasi

Menjelaskan informasi umum terkait organisasi untuk memahami bagaimana organisas menerapkan DRP pada tingkat tertentu sesua dengan kondisi organisasi dan tujuannya. Pada bagian ini dijelaskan: a. Nama organisasi b. Jenis organisasi c. Jumlah karyawan d. Struktur Organisasi e. Daftar Departemen f. Tujuan Organisasi 1.2. Kondisi Lingkungan IT Organisasi

Menentukan bagaimana tingkat penggunaan IT pada organisasi serta bagaimana IT berperan dalam menjalankan proses bisnis organisasi. Sehingga, nantinya dapat diklasifikasikan sistem yang sangat berpengaruh bagi organisasi dan proses bisnisnya. 11 | D i s a s t e r R e c o v e r y P l a n n i n g ( D R P ) T e m p l a t e

Serta memastikan bahwa ketika terjadi bencana, proses pemulihan dapat mengutamakan sistem yang sangat penting dalam organisasi. Pada bagian ini dijelaskan: a. Jenis infrastruktur IT organisasi b. Daftar infrastruktur ITS organisasi c. Spesifikasi infrastruktur IT 1.3. Menentukan Scope Project

Pendefinisian ruang lingkup project adalah sejauh mana organisasi akan dianalisa dalam pembuatan DRP dan pihak mana saja yang terkait dengan organisasi untuk pembuatan DRP ini. Pada bagian ini dijelaskan ruang lingkup proyek terkait: a. Organisasi yang akan diterapkan DRP b. Pihak internal dan eksternal organisasi 1.4. Membuat Project Schedule

Untuk memastikan proyek dapat selesai dengan tepat waktu dan terorganisir dengan baik, maka diperlukan penjadwalan untuk penyelesaian proyek. Pada bagian ini dibuat daftar aktifitas serta range waktu yang dibutuhkan untuk menyelesaikan suatu aktifitas. Project Milestone

Task

Duration

Start

Finish

Resource

1.5. Mengidentifikasi Risiko Project

Pendefinisian risiko untuk proyek sangat penting untuk mangantisipasi adanya risiko-risiko yang dapat menghambat jalannya proyek ke depan. Risk ID

Risk

Cause


Impact

1.6. Menentukan Tim Proyek serta Project Sponsor

Pembuatan struktur organisasi proyek yang bertujuan untuk mempermudah kordinasi tim dalam menyelesaikan proyek ini. Kemudian informasi terkait setiap anggota tim juga sangat diperlukan. Name

II.

Phone

Email

Role

Responsibility Responsibility

Risk Analysis

Mengetahui kemungkinan risiko yang terjadi berdasarkan kondisi geografis organisasi. Hal ini dapat diketahui dengan mempertimbangkan lokasi geografis organisasi, susunan/

komposisi

bangungan,

keamanan

lingkungan/fisik

operasional,

alat-alat

keamanan yang telah diterapkan, sistem control akses untuk lingkungan, prosedur operasional serta praktik back up yang dilakukan organisasi. Critical System/ Application/Function

Physical Security

Backup Systems

Data Security

Kemudian, dilakukan penilaian terhadap berbagai bencana yang mungkin muncul dengan menggunakan 5 faktor penilaian. Untuk penilaian pada Impact (Human Impact, Property Impact dan Business Impact) digunakan skala 1 (Hight Impact) – Impact) – 5 5 (Low Impact). Lalu pada Resources (Internal Resources dan External Resources) digunakan skala 1 (Strong) – (Strong) – 5 5 (Weak). Type of Disaster

Human Impact

Property Impact

Business Impact

Internal Resources


External Resources

Total

III.

Business Impact Analysis

Pada tahap ini, proses bisnis organisasi harus dianalisa dan diklasifikasikan aktifitas/sistem mana saja yang hanya dapat dijalankan dengan dukungan IT dan termasuk critical. Hal ini dilakukan untuk mempermudah proses recovery sehingga oprganisasi dapat kembali berjalan meskipun belum pulih seutuhnya. Pada bagian ini juga dianalisa rentang waktu yang dibutuhkan agar sistem tetap dapat berjalan meskipun sistem lain tidak dapat dijalankan. Dalam menyelesaikan step ini, yang perlu dilakukan adalah: 1. Mengidentifikasi fungsi, proses dan sistem dalam organisasi 2. Melakukan interview terhadap karyawan IS Support organisasi 3. Melakukan interview terhadap karyawan Business Unit organisasi 4. Menganalisa hasil interview untuk menentukan sistem apa saja yang termasuk critical, aplikasi dan proses bisnis organisasi 5. Mempersiapkan analisa dampak terhadap adanya gangguan pada sistem yang critical Untuk mempermudah Business Impact Analysis ini, dapat dilakukan dengan menggunakan form berikut. Setiap fungsi/sistem yang ada pada organisasi wajib mengisi form berikut sesua dengan aplikasi yang digunakan. Pada form berikut diidentifikasi sejauh mana sebuah fungsi bergantung terhadap fungsi dari resource yang lain. Department Name : Application : Function : What is the purpose of this function or application system? Primary Contact Name for Function : Phone: : How would you classify this function? a. Critical b. Essential c. Necessary d. Desirable The categories detail the length of o f time that an activity can remain disrupted: Critical Less than one day Essential 2 - 4 days Necessary 5 -7 days Desirable More than 10 days Resource

Model and/ or location

Major application

High


Dependency Medium

Low

Kemudian dari analisa yang telah dilakukan, maka dilakukan ranking berdasarkan tingkat kepentingannya dengan menggunakan kriteria berikut: Kriteria Critical Essential Necessary Desirable

Rank 1 2 3 4

Lalu dimasukkan ke dalam tabel berikut: System/Function/Process

IV.

Rank

Recovery Strategy

Tahap ini merupakan tahap yang cukup sulit dan memakan banyak waktu. Setiap kebutuhan organisasi yang terkait dan dibutuhkan untuk perencanaan harus dijelaskan dengan detail. Pada bagian ini juga termasuk recovery requirement untuk proses bisnis dan IT, kemudian kebutuhan yang dihasilkan dari Business Impact Analysis, Assessment of Disaster Risk and Mitigation of Disaster D isaster Risk. Tahap pertama yang dilakukan adalah menentukan tim-tim yang akan bertanggung jawab terhadap sistem/fungsi critical yang telah t elah diidentifikasi d iidentifikasi pada tahap Business Impact Analysis. Berikut adalah form yang dapat digunakan untuk tahap ini. (F un gsi/ gsi/ Sistem istem Cri tical)

Contact Name


Work Phone

Email

Cell Phone

Pager

Cell Phone

Pager

(F un gsi/ gsi/ Sistem istem Cri tical)

Contact Name


Work Phone

Email


Kemudian, dari hasil Business Impact Analysis diberikan penjelasan secara detail. Penjelasan setiap fungsi/sistem critical secara detail dapat dilakukan dengan form berikut. Critical System …(System’s Name) Steps for completing system process 1. … 2. … 3. … Processing Requirements Monday Tuesday Wednesday Light, Normal, or Heavy Processing Day Transaction Volume Dollar volume (if any) Estimated processing time Allowable delay (days, hours, minutes, etc.)

Thursday

Systems and Applications Used by this Critical System/Function Type Component Tech ID (if (online, batch System/Application Name any) process, script)

Frequency

Friday

Saturday

Sunday

Runtime

Allowable Delay (Days, Hours, Minutes, etc.)


Vital Records

Untuk setiap vital record yang teridentifikasi, akan dibuatkan sebuah form seperti berikut. Vital Record Type (e.g., backup, original, o riginal, master, history, etc.) Location Source of item or record Generation frequency Number of generations available off-site Media type Number in set (. e.g., number of tapes in a backup) Retention period Rotation cycle Who is authorized to retrieve the backups? Minimum Components Required for Processing

Vital Records

Untuk setiap vital record yang teridentifikasi, akan dibuatkan sebuah form seperti berikut. Vital Record Type (e.g., backup, original, o riginal, master, history, etc.) Location Source of item or record Generation frequency Number of generations available off-site Media type Number in set (. e.g., number of tapes in a backup) Retention period Rotation cycle Who is authorized to retrieve the backups? Minimum Components Required for Processing

Untuk setiap komponen yang teridentifikasi, akan dibuatkan sebuah form seperti berikut. Component Type (e.g., server, software, hardware, etc.) Item name and description Quantity required Location of inventory, alternative, or offsite storage Vendor/supplier

Kemudian, setelah itu akan dilakukan identifikasi metode alternative untuk proses, melakukan perhitungan jika memungkinkan, terhadap apa yang mempengaruhi proses. Identify person(s) who supports the system or application Support Personnel

Name Phone Alternate Phone Pager Title Identify primary and secondary person to contact if system or application cannot function as normal Primary Contact

Name Phone

Secondary Contact

Name Phone


Alternate Phone Pager Title

Alternate Phone Pager Title

Memperhitungkan jumlah resources yang dibutuhkan selama proses recovery dari waktu ke waktu. Misal, jumlah Orang, Computer, Server, dll.

Contoh: 2 pekerja setiap hari 1 Desktop Computer yang terhubung dengan internet 1 Printer Strategi dokumentasi per-unit selama proses recovery untuk sistem critical selama proses recovery:

Contoh: Selama terjadi bencana dan gangguan, proses pembayaran dapat ditangani secara manual: a. Siswa dapat mencatat kapan mereka melakukan sign in dan submit pada sistem b. Administrator dapat mengecek langsung melalui log file sistem untuk memastikan c. … Identify all vendors associated with the system or application System/ Application / Hardware

Component used in Normal or Alternative Process?

Vendor

Vendor Phone

Vendor Local Contact/ Rep

Contingency agreement in place with this vendor?

Review Onsite and Offsite Backup and Recovery Procedures



Onsite Backup (procedure policy)



Offsite Backup (procedure policy)

Dean/Director Approval Signature:


Date

V.

Plan Development

Menentukan proyek yang sedang dijalankan dan salah satu tujuan dari tahap ini adalah mengembangkan Disaster Recovery Plan dengan melakukan mitigasi terhadap risiko bencana sebanyak mungkin. Bagian ini merupakan penyempurnaan dari bagian I – I – VII dengan mengembangkan perencanaan dokumen secara detail pada seluruh bagian organisasi. Adapun langkah-langkah yang harus diterapkan untuk menyelesaikan tahap Plan Development ini adalah sebagai berikut: 5.1

Objective

Penentuan deskripsi, tujuan, scope dan informasi umum terkait project DRP ini. Bagian ini telah dideskripsikan pada bagian Step I. 5.2

Plan Assumptions Bagian ini berisi berbagai asumsi terkait penerapan DRP pada organisasi.

5.3

Criteria for Invoking The Plan Bagian ini merupakan penjelasan kapan perencanaan akan dilaksanakan/ diserukan untuk

mulai diterapkan. Pada bagian ini dijelaskan dokumen apa saja yang akan dibuat sesaat sebelum bencana bencana datang.

a. Dokumen Emergency Dokumen Emergency Response Respon se yang yang berisikan berbagai prosedur yang dilakukan selama keadaan darurat dan setelahnya. Misalnya, memastikan proses evakuasi dilakukan kepada setiap orang, memanggil pemadam kebakaran, setelah keadaan darurat melakukan pengecekan bangunan sebelum memperbolehkan setiap orang memasuki bangunan. b. Dokumen prosedur pengkajian dan pernyataan status keadaan darurat c. Dokumen prosedur pemberitahuan untuk memperingatkan setiap unit dan departemen. d. Dokumen prosedur pemberitahuan untuk memperingatkan vendor e. Dokumen prosedur pemberitahuan untuk memperingatkan staff unit dan beberapa cabang lain dengan lokasi yang berbeda.


5.4

Roles Responsibility and Authority

Pertama, memastikan bahwa Disaster Recovery Team telah terdefinisikan untuk role, responsibilities responsibilities dan contact co ntact info-nya. Name

Phone

Email

Role


Kemudian memastikan bahwa setiap fungsi/sistem critical telah diberikan tanggung jawab terhadap anggota proyek. (F un gsi/ gsi/ Sistem istem Cri tical)

Contact Name


Work Phone

Email

Cell Phone

Pager

Cell Phone

Pager

(F un gsi/ gsi/ Sistem istem Cri tical)

Contact Name


Work Phone

Email

Project Management kemudian menghubungi anggota proyek menggunakan contact yang telah didefinisikan pada Step IV. Primary Contact

Secondary Contact

Name Phone Alternate Phone Pager Title


Begitu pula untuk para anggota support akan dihubungi menggunakan contact support yang telah didefinisikan sebelumnya. Support Personnel



5.5

Procedures for Operating in Contingency Mode

Bagian ini merupakan hasil identifikasi yang telah dilakukan di bagian Step IV yang bertujuan untuk menentukan prosedur keadaan darurat pada sistem critical organisasi.


Critical System …(System’s Name) Steps for completing system process 4. … 5. … 6. … Processing Requirements Monday Tuesday Wednesday Light, Normal, or Heavy Processing Day Transaction Volume Dollar volume (if any) Estimated processing time Allowable delay (days, hours, minutes, etc.)

Thursday

Systems and Applications Used by this Critical System/Function Type Component Tech ID (if (online, batch System/Application Name any) process, script)


Vital Records Vital Record Type (e.g., backup, o riginal, master, history, etc.) Location Source of item or record Generation frequency Number of generations available off-site Media type Number in set (. e.g., number of tapes in a backup) Retention period Rotation cycle Who is authorized to retrieve the backups? Minimum Components Required for Processing Component Type (e.g., server, software, hardware, etc.)

Frequency

Friday

Saturday

Sunday

Runtime

Allowable Delay (Days, Hours, Minutes, etc.)

Vital Records Vital Record Type (e.g., backup, o riginal, master, history, etc.) Location Source of item or record Generation frequency Number of generations available off-site Media type Number in set (. e.g., number of tapes in a backup) Retention period Rotation cycle Who is authorized to retrieve the backups? Minimum Components Required for Processing Component Type (e.g., server, software, hardware, etc.) Item name and description Quantity required Location of inventory, alternative, or offsite storage Vendor/supplier Identify all vendors associated with the system or application System/ Application / Hardware

Component used in Normal or Alternative Process?

Vendor

Vendor Phone

Vendor Local Contact/ Rep

Contingency agreement in place with this vendor?

Review Onsite and Offsite Backup and Recovery Procedures



Onsite Backup (procedure policy)



Offsite Backup (procedure policy)

Dean/Director Approval Signature:


Date

5.6

Resource plan for operating in contingency mode

Memperhitungkan jumlah resources yang dibutuhkan selama proses recovery dari waktu ke waktu. Misal, jumlah Orang, Computer, Server, dll. Contoh: 2 pekerja setiap hari 1 Desktop Computer yang terhubung dengan internet 1 Printer Strategi dokumentasi per-unit selama proses recovery untuk sistem critical selama proses recovery: Contoh: Selama terjadi bencana dan gangguan, proses pembayaran dapat ditangani secara manual: a. Siswa dapat mencatat kapan mereka melakukan sign in dan submit pada sistem b. Administrator dapat mengecek langsung melalui log file sistem untuk memastikan c. … 5.7

Criteria for Returning to Normal Operating Mode

Untuk mengembalikan keadaan darurat (Emergency) menjadi Normal kembali, maka perlu untuk dilakukan pendefinisian kriteria untuk setiap fungsi/ proses pro ses untuk dianggap normal kembali. Misalnya, fungsi dapat menjalankan operasi tertentu yang dapat memastikan bahwa organisasi dapat berjalan sebagaimana mestinya serta tidak ada lagi proses yang dapat menghambat fungsi yang lain. VI.

Implementation

Proyek mulai dijalankan sesuai dengan standard operasional Project Management. Selama proses eksekusi ini, metode-metode mitigasi risiko mulai diterapkan dan Disaster Recovery Plan akan dibangun dan dilakukan tahap testing. 6.1

Procedures for Returning to Normal Operating Mode

Mendefinisikan prosedur untuk mengembalikan organisasi pada mode Normal dalam menjalankan fungsi/proses. Berikut adalah beberapa hal yang harus dipenuhi pada bagian ini: a. Prosedur pengadaan perlengkapan dan peralatan yang dibutuhkan 24 | D i s a s t e r R e c o v e r y P l a n n i n g ( D R P ) T e m p l a t e

b. Prosedur pemulihan/restart sistem yang diperlukan c. Prosedur pengecekan fungsionalitas/ hasil sistem d. Prosedur pemberitahuan kepada seluruh personil untuk kembali ke mode normal 6.2

Procedures for Recovering Lost or Damaged Data

Pada bagian ini didefinisikan prosedur untuk melakukan perbaikan dan pemulihan data yang corrupt atau hilang. 6.3

Testing and Training

Membuat dokumen Test Strategy yang selanjutnya akan dijelaskan secara detail pada bagian VII Testing and Exercising. Test Strategy terdiri dari tanggal pelaksanaan, resources yang akan dikelola dan menjalankan proses testing, dan lampiran untuk scenario pengujian yang sebenarnya 6.4

Plan Maintenance

Pada tahap ini, dipastikan bahwa rencana mencerminkan perubahan terhadap Resources sangat penting. Bagian ini juga akan memperbarui Rencana dan merevisi untuk diperbarui, menguji rencana yang baru dan melatih para personil. Tugas ini sepenuhnya dipegang oleh kordinator tim sekaligus menjadi penanggung jawab. Rencana kemudian akan diulas secara formal untuk dijadikan pelaporan bagi organisasi. Setiap tahunnya, kordinator proyek DRP akan mereview dokumen-dokumen yang pernah dibuat sehingga akan menimbulkan berbagai revisi untuk dokumen yang terbaru. Revisi kemudian akan dibagikan kepada semua petugas yang berwenang untuk diterapkan. Kemudian akan diserahkan sebagai laporan tahunan DRP kepada pihak manajer organisasi. 6.5

Appendices for Inclusion

Tahap ini merupakan pelampiran data-data apa saja yang ada di laporan DRP. Untuk tahap ini, berikut adalah lampiran yang disertakan pada laporan perencanaan DRP: a. Laporan dan form persediaan b. Form pemeliharaan c. Daftar hardware dan nomor seri d. Daftar software dan nomor lisensi


e. Daftar kontak untuk vendor f. Daftar kontak untuk staf dengan nomor rumah dan pekerjaan g. Daftar kontak untuk departemen interfacing lainnya h. Skema jaringan diagram i. Diagram ruang peralatan j. Perjanjian kontrak dan pemeliharaan k. Instruksi cara pengoperasian khusus untuk peralatan yang sensitif l. Perjanjian dan persediaan telepon selular m. Dokumentasi lain yang diperlukan dalam hal gangguan yang besar n. Skenario pengujian VII. Testing and Exercising

DRP yang telah dibuat pada tahap sebelumnya harus diintegrasikan kepada Business Continuity organisasi. Namun, ada pula organisasi yang membuat DRP terlebih dahulu kemudian membuat BCP dengan berdasarkan pada DRP sehingga keduanya saling terinterasi. Pada bagian ini, dokumen strategi harus berisi komponen-komponen berikut: a. Unit/ Departemen yang akan dibahas dalam pengujian. b. Fungsi/ proses/ sistem critical yang akan dibahas da lam pengujian. c. Tujuan yang ingin dicapai pada proses testing. d. Jenis testing skenario yang akan dilakukan dan deskripsinya. e. Personil/ tim yang terlibat dalam pengujian. f. Frekuensi dan jangka waktu untuk pengujian. g. Efek yang diinginkan dari hasil tes dalam mengevaluasi DRP. h. Rencana untuk mempertahankan rencana selanjutnya untuk pengujian. Setelah dilakukan Test Plan, hasil test terkait critical sisytem yang ada dan langkah pemulihannya dituliskan pada form berikut: Crutial Function/ Process Step Result Step Result … …

: : : : : : :


Step Result Test Evaluation Recommended Action (based on test evaluation) Action Taken

: : : : :

Rencana pengujian individu atau menggunakan skenario muncul dari keseluruhan strategi pengujian DRP untuk setiap unit. Ada lima jenis tes pengujian yang dapat dijalankan. Masing-masing sesuai dengan tujuan yang ingin dicapai dan jenis proses sedang diuji. a. Table Top Test : Prosedur pengujian pemulihan bencana yang paling informal. Setiap tim pemulihan bencana secara lisan meninjau proses untuk memulihkan data dan aplikasi. b. Walk-Through : Diskusi lebih mendalam tentang langkah-langkah yang sebenarnya dalam proses pemulihan. Setiap anggota tim menggunakan rencana pemulihan bencana untuk membahas proses backup dan bagaimana melaksanakan setiap langkah pemulihan itu. c. Simulation Exercise : Pengujian yang lebih maju. Sebuah simulasi yang menggunakan rencana pemulihan bencana yang ada untuk mengukur efektivitas terhadap serangkaian peristiwa bencana. Semua staf yang bertanggung jawab harus hadir pada simulasi, yang mana masing-masing biusiness atau IS unit mengirim tim pemulihan bencana mereka masingmasing untuk even tersebut. d. Alternative Site : Jika organisasi menggunakan fasilitas alternatif untuk hosting pusat data atau penyimpanan cadangan, organisasi harus melakukan tes ini untuk memastikan situs alternatif beroperasi dengan benar selama proses pemulihan. e. Automated Test : Memerlukan sangat sedikit interaksi dari tim dan anggota staf, dan dapat digunakan secara berkelanjutan untuk menguji operasi dari aplikasi. Tes ini melibatkan sistem pemantauan robot. Sistem ini melakukan query pada software dan aplikasi secara teratur untuk menentukan status operasionalnya. 27 | D i s a s t e r R e c o v e r y P l a n n i n g ( D R P ) T e m p l a t e

Kemudian, individual test akan dilakukan oleh masing-masing unit/departemen organisasi menggunakan form berikut: Unit/Department Name Critical Function/Process Objectives to Be Achieved by this Test Scenario(s) For Carrying Out The Objectives Of This Test Frequency & Dates for the Test Responsible Parties ---Writing ---Writing the detailed plan for the test (if necessary) ---Supervising the execution of the test ---Providing/securing ---Providing/securing resources for the test ---Documenting the results of the test ---Updating the plan as a result of the test

: : : : : : : : : :

VIII. Maintenance

Untuk memastikan Perencanaan yang telah dibuat tetap diperbarui sesuai perubahan lingkungan organisasi maupun factor yang lain, Perencanaan tersebut harus dilakukan Maintenance dan testing. Sehingga, ketika sewaktu-waktu terjadi sebuah bencana, maka organisasi tetap dapat menjalankan perencanaan sesuai dengan perubahan yang telah diperbarui perencanaannya. Dalam mengawasi proses ini, Direktur/Manajer yang akan bertanggung jawab. Berikut adalah proses yang akan dilakukan pada tahap ini: 1. Melakukan peninjauan ulang (review) terhadap perubahan lingkungan, teknologi dan prosedur. 2. Mengembangkan pemicu dan prosedur maintenance 3. Menyetor perubahan untuk pengembangan prosedur sistem 4. Melakukan modifikasi terhadap prosedur perubahan manajemen unit 5. Mengeluarkan dan mendistribusikan perencanaan yang telah diperbarui


Daftar Pustaka Michigan State University. (n.d.). Disaster (n.d.). Disaster Recovery Recovery Planning . Retrieved January Thursday, 2014, from Michigan State University: http://drp.msu.edu MTI. (2009). Penganta (2009). Pengantarr Risiko TI . Nickolet, Nickolet, C. (2001). Disaster Disaster Recovery Recovery Planning - Process Process and Options. Options. White Paper . PECB. (2013). Business Continuity Management System. ISO 22301. 22301. Safitri, E. (2009). Manajeme (2009). Manajemen n Resiko. Resiko. Siahaan, H. (2007). Manajeme (2007). Manajemen n Resiko, Resiko, Konsep, dan Kasus Implementasi Implementasi.. Jakarta: Elexmedia.


DRP Template - ISO 22301

Recommend Documents