Service continuity management

Floods, earthquakes, fires, ransomware or a major cloud outage are rare, but when they happen they can stop a business for days. Service continuity management prepares for these disasters, so that the most critical services keep running or come back within a time the business can survive.

Banjir, gempa bumi, kebakaran, ransomware, atau gangguan cloud besar memang jarang terjadi, tetapi saat terjadi bisa menghentikan bisnis berhari-hari. Service continuity management mempersiapkan diri menghadapi bencana tersebut, agar layanan paling kritis tetap berjalan atau pulih dalam waktu yang masih bisa ditoleransi bisnis.

Key ideasKonsep kunci

• Start with a business impact analysis. Which services matter most, and how long can the business survive without each one?
• Two key numbers. RTO: how fast it must be back. RPO: how much data you can afford to lose.
• Choose recovery options. Backups, a second site, another cloud region, or a manual workaround on paper.
• Ransomware changes the plan. Keep backups that attackers can’t reach or change, such as offline or immutable copies.
• An untested plan is a wish. People must know their roles, and recovery must be practiced.

• Mulai dengan business impact analysis. Layanan mana yang paling penting, dan berapa lama bisnis bisa bertahan tanpa masing-masing layanan?
• Dua angka kunci. RTO: seberapa cepat harus pulih. RPO: berapa banyak data yang boleh hilang.
• Pilih opsi pemulihan. Backup, lokasi kedua, region cloud lain, atau prosedur manual di atas kertas.
• Ransomware mengubah rencana. Simpan backup yang tidak bisa dijangkau atau diubah penyerang, seperti salinan offline atau immutable.
• Rencana yang belum diuji hanyalah harapan. Orang harus tahu perannya, dan pemulihan harus dilatih.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

1. Analyze impactRank services by business impact over time.
2. Assess risksWhich disasters are likely here?
3. Set strategyRTO and RPO per service, and recovery options.
4. Write plansClear steps, roles and contact lists.
5. TestTabletop exercises and real recovery tests.
6. Review and updateAfter every test and every major change.

1. Menganalisis dampakUrutkan layanan berdasarkan dampak bisnis dari waktu ke waktu.
2. Menilai risikoBencana apa yang mungkin terjadi di sini?
3. Menetapkan strategiRTO dan RPO per layanan, beserta opsi pemulihannya.
4. Menyusun rencanaLangkah, peran, dan daftar kontak yang jelas.
5. MengujiLatihan tabletop dan uji pemulihan nyata.
6. Meninjau dan memperbaruiSetelah setiap pengujian dan setiap perubahan besar.

How to measure itCara mengukurnya

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

1. L1InitialNo plan. The organization hopes a disaster won’t happen.
2. L2RepeatableBackups exist but are rarely tested, and the plan lives in someone’s head.
3. L3DefinedA business impact analysis is done, RTO and RPO are set, and critical services have documented plans tested every year.
4. L4MeasuredRegular tests show targets are met, gaps are fixed, and plans are updated after changes.
5. L5OptimizedContinuity is built into design, recovery is tested often and partly automated, and it links to business continuity and cyber resilience.

1. L1InitialTidak ada rencana. Organisasi berharap bencana tidak terjadi.
2. L2RepeatableBackup ada tetapi jarang diuji, dan rencananya hanya ada di kepala seseorang.
3. L3DefinedBusiness impact analysis sudah dilakukan, RTO dan RPO ditetapkan, dan layanan kritis punya rencana terdokumentasi yang diuji setiap tahun.
4. L4MeasuredPengujian rutin menunjukkan target tercapai, celah diperbaiki, dan rencana diperbarui setelah perubahan.
5. L5OptimizedKontinuitas sudah menjadi bagian dari desain, pemulihan sering diuji dan sebagian terotomasi, serta terhubung dengan business continuity dan ketahanan siber.

Assess service continuity management in the wizardNilai service continuity management di wizard →

Using AIMemanfaatkan AI

• Plan drafting and updates from configuration and dependency data.
• Scenario generation for realistic tabletop exercises.
• Early ransomware detection from unusual file activity.
• Backup integrity checks that flag unusual changes in backup size or content.

• Penyusunan dan pembaruan rencana dari data konfigurasi dan ketergantungan.
• Pembuatan skenario untuk latihan tabletop yang realistis.
• Deteksi dini ransomware dari aktivitas file yang tidak wajar.
• Pemeriksaan integritas backup yang menandai perubahan tidak wajar pada ukuran atau isi backup.

Real-world example: a disaster recovery test that took 11 hoursContoh kasus: uji pemulihan bencana yang memakan 11 jam3 min3 menit

A bank’s continuity plan says its main data center can fail over to the backup site in four hours, an important assumption for flood season. The first real test takes eleven hours, because one network change needs a supplier engineer who can’t be reached on a weekend.

Rencana kontinuitas sebuah bank menyatakan data center utamanya bisa dialihkan ke lokasi cadangan dalam empat jam, asumsi penting menjelang musim banjir. Pengujian nyata pertama memakan sebelas jam, karena satu perubahan jaringan membutuhkan engineer supplier yang tidak bisa dihubungi di akhir pekan.

They add a 24/7 contact clause to the supplier contract and automate the network switch. The next test takes three and a half hours, within target.

Mereka menambahkan klausul kontak 24/7 di kontrak supplier dan mengotomasi pengalihan jaringan. Pengujian berikutnya memakan tiga setengah jam, sesuai target.

Common pitfallsJebakan umum

• Checking that backups ran, but never restoring one.
• Storing the plan only on the systems that might fail.
• IT setting RTOs without asking the business.
• Forgetting suppliers, people and communication in the plan.

• Memeriksa bahwa backup berjalan, tetapi tidak pernah mencoba memulihkannya.
• Menyimpan rencana hanya di sistem yang justru bisa gagal.
• TI menetapkan RTO tanpa bertanya kepada bisnis.
• Melupakan supplier, orang, dan komunikasi dalam rencana.

Related practicesPractice terkait