drp template - iso 22301

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

Manajemen

Risiko

Teknologi

Informasi

2014Disaster Recovery Template (DRP) Template

Muh. Idil Haq Amir 5211100704

Sistem Informasi

Institut Teknologi Sepuluh Nopember

(ITS)

Surabaya


Daftar Isi

Daftar Isi ................................................................................................................................................. 1

Studi Literatur ......................................................................................................................................... 3

A. Bencana......................................................................................................................................... 3

B. Risiko ............................................................................................................................................ 3

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

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

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

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

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

I. Project Planning .......................................................................................................................... 11

1.1. Deskripsi Organisasi ............................................................................................................ 11

1.2. Kondisi Lingkungan IT Organisasi ....................................................................................... 11

1.3. Menentukan Scope Project ................................................................................................... 12

1.4. Membuat Project Schedule ................................................................................................... 12

1.5. Mengidentifikasi Risiko Project............................................................................................ 12

1.6. Menentukan Tim Proyek serta Project Sponsor ..................................................................... 13

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

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

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

V. Plan Development ....................................................................................................................... 19

5.1 Objective ............................................................................................................................. 19

5.2 Plan Assumptions ................................................................................................................. 19

5.3 Criteria for Invoking The Plan .............................................................................................. 19

5.4 Roles Responsibility and Authority ...................................................................................... 20

5.5 Procedures for Operating in Contingency Mode ................................................................... 21

5.6 Resource plan for operating in contingency mode ................................................................. 24

5.7 Criteria for Returning to Normal Operating Mode ................................................................ 24

VI. Implementation............................................................................................................................ 24

6.1 Procedures for Returning to Normal Operating Mode ........................................................... 24

6.2 Procedures for Recovering Lost or Damaged Data ................................................................ 25


6.3 Testing and Training ............................................................................................................ 25

6.4 Plan Maintenance ................................................................................................................. 25

6.5 Appendices for Inclusion ...................................................................................................... 25

VII. Testing and Exercising ................................................................................................................ 26

VIII. 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.”

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

“Bencana nonalam adalah bencana yang diakibatkan oleh peristiwa atau rangkaian

peristiwa nonalam yang antara lain berupa gagal teknologi, gagal modernisasi, epidemi, dan

wabah 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.”

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 kategori tersebut:

a. Risiko Murni, yaitu risiko yang tidak disengaja dan menimbulkan banyak kerugian bagi

organisasi, misalnya bencana alam, kebakaran, pencurian dan pencurian.


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, 2009).

Adapun Strategi dalam pengendalian risiko dapat dilakukan dengan menggunakan

pendekatan 4T (Siahaan, 2007), 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.


c. Transfer a risk, yaitu mengalihkan risiko kepada pihak lain misalnya melalui asuransi

atau hedging.

d. Tolerate a risk, yaitu risiko yang dapat diterima oleh bank.

Diversifikasi dan keterkaitan antar risiko sudah diperhitungkan pada strategi 4T ini. Metode

pengendalian risiko menggunakan pendekatan 4Ts dapat digambarkan sebagai berikut:

Gambar 1. Strategi Pengendalian - 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.


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 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 Disaster 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 dilakukan 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 Business Continuity Management. Standar ini dapat diterapkan baik oleh organisasi


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 (PECB, 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. Secara garis besar proses implementasi BCMS digambarkan dalam diagram

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.


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.


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 Phone Email Role Responsibility

II. 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) – 5 (Low Impact).

Lalu pada Resources (Internal Resources dan External Resources) digunakan skala 1

(Strong) – 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 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

Dependency

High Medium Low


Kemudian dari analisa yang telah dilakukan, maka dilakukan ranking berdasarkan

tingkat kepentingannya dengan menggunakan kriteria berikut:

Kriteria Rank

Critical 1

Essential 2

Necessary 3

Desirable 4

Lalu dimasukkan ke dalam tabel berikut:

System/Function/Process Rank

IV. 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 Risk.

Tahap pertama yang dilakukan adalah menentukan tim-tim yang akan bertanggung

jawab terhadap sistem/fungsi critical yang telah diidentifikasi pada tahap Business Impact

Analysis. Berikut adalah form yang dapat digunakan untuk tahap ini.

(Fungsi/Sistem Critical)

Contact Name Responsibility Work

Phone Email

Cell

Phone Pager



Phone Email

Cell

Phone Pager


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 Thursday Friday Saturday Sunday

Light, Normal, or Heavy

Processing Day

Transaction Volume

Dollar volume (if any)

Estimated processing time

Allowable delay (days,

hours, minutes, etc.)

Systems and Applications Used by this Critical System/Function

System/Application Component

Name

Tech ID (if

any)

Type

(online, batch

process,

script)

Frequency 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, 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 Secondary Contact

Name Name

Phone Phone


Alternate Phone Alternate Phone

Pager Pager

Title 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 Offsite Backup

(procedure policy) (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 –

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

a. Dokumen Emergency Response 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 dan contact info-nya.

Name Phone Email Role Responsibility

Kemudian memastikan bahwa setiap fungsi/sistem critical telah diberikan tanggung

jawab terhadap anggota proyek.



Phone Email

Cell

Phone Pager



Phone Email

Cell

Phone Pager

Project Management kemudian menghubungi anggota proyek menggunakan contact

yang telah didefinisikan pada Step IV.

Primary Contact Secondary Contact

Name Name

Phone Phone

Alternate Phone Alternate Phone

Pager Pager

Title Title

Begitu pula untuk para anggota support akan dihubungi menggunakan contact

support yang telah didefinisikan sebelumnya.

Support Personnel

Name

Phone

Alternate Phone

Pager

Title


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 Thursday Friday Saturday Sunday

Light, Normal, or Heavy

Processing Day

Transaction Volume

Dollar volume (if any)

Estimated processing time

Allowable delay (days,

hours, minutes, etc.)

Systems and Applications Used by this Critical System/Function

System/Application Component

Name

Tech ID (if

any)

Type

(online, batch

process,

script)

Frequency Runtime Allowable Delay (Days,

Hours, Minutes, etc.)


Vital Records

Vital Record

Type (e.g., backup, original, 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 Offsite Backup

(procedure policy) (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 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


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

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


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 the detailed plan for the test (if necessary) :

---Supervising the execution of the test :

---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 Recovery Planning. Retrieved January Thursday, 2014, from

Michigan State University: http://drp.msu.edu

MTI. (2009). Pengantar Risiko TI.

Nickolet, C. (2001). Disaster Recovery Planning - Process and Options. White Paper.

PECB. (2013). Business Continuity Management System. ISO 22301.

Safitri, E. (2009). Manajemen Resiko.

Siahaan, H. (2007). Manajemen Resiko, Konsep, dan Kasus Implementasi. Jakarta: Elexmedia.

drp template - iso 22301

Documents