Business Continuity & Disaster Recovery

9.1 Gambaran Umum & Tujuan

Bab ini mendefinisikan kewajiban kelangsungan bisnis dan pemulihan bencana (BCDR) yang mengatur penyediaan ProjectVIEW ERP Platform oleh Provider. Bab ini menetapkan strategi backup, arsitektur replikasi, prosedur failover, target waktu pemulihan, komitmen redundansi data, dan persyaratan perencanaan kelangsungan yang memastikan Data Customer tetap tersedia, tahan lama, dan dapat dipulihkan selama Masa Langganan.

Sistem Manajemen Kelangsungan Bisnis (BCMS) milik Provider selaras dengan ISO 22301:2019 (Security and Resilience — Business Continuity Management Systems) dan mengacu pada NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems) serta Microsoft Cloud Enterprise Business Continuity Management (EBCM) Programme. Bab ini melengkapi komitmen ketersediaan yang didefinisikan dalam Chapter 3 (Service Level Agreement), kontrol keamanan infrastruktur yang dijelaskan dalam Chapter 8 (Information Security & Confidentiality), dan ketentuan perlindungan data di Chapter 7 (Data Protection & Privacy).

Setiap lingkungan berdaulat privat khusus milik Customer disediakan dengan kontrol kelangsungan berlapis yang mencakup lapisan komputasi, basis data, penyimpanan, dan jaringan — memastikan bahwa tidak ada satu titik kegagalan yang dapat mengakibatkan kehilangan data atau gangguan layanan berkepanjangan melebihi Recovery Point Objective (RPO) dan Recovery Time Objective (RTO) yang dikontrakkan.

9.2 Ruang Lingkup

Bab ini mencakup:

• (a) Tujuan pemulihan: Komitmen RPO dan RTO yang mengikat secara kontraktual untuk seluruh lapisan Platform.
• (b) Manajemen backup: Jadwal backup, masa retensi, verifikasi integritas, dan prosedur pemulihan untuk virtual machine, basis data, dan artefak aplikasi.
• (c) Redundansi & replikasi data: Opsi replikasi Azure Storage (LRS, ZRS, GRS), read-replica basis data, dan arsitektur failover geo-redundan.
• (d) Pemulihan bencana: Prosedur failover, aktivasi wilayah sekunder, protokol komunikasi, dan alur kerja pemulihan layanan.
• (e) Perencanaan kelangsungan bisnis: Business Impact Analysis (BIA), pemeliharaan rencana kelangsungan, jadwal drill DR, dan prosedur tinjauan pasca insiden.
• (f) Kepemilikan & portabilitas data: Hak kepemilikan data Customer, mekanisme ekspor data, kewajiban manajemen records, dan dukungan e-discovery.
• (g) Peran & tanggung jawab: Alokasi RACI di seluruh organisasi Provider dan Customer untuk semua aktivitas BCDR. Bab ini tidak mencakup kontrol keamanan tingkat aplikasi (lihat Chapter 8), pemrosesan data pribadi (lihat Chapter 7), atau alur kerja dukungan operasional (lihat Chapter 4).

9.3 Kesesuaian Standar & Kerangka Kerja

Program BCDR Provider selaras dengan standar dan kerangka kerja yang diakui secara internasional berikut:

9.4 Tujuan Pemulihan

Tujuan pemulihan yang mengikat secara kontraktual berikut berlaku untuk setiap lingkungan berdaulat privat khusus milik Customer. Tujuan ini mendefinisikan maksimum kehilangan data yang dapat ditoleransi (RPO) dan maksimum waktu henti yang dapat ditoleransi (RTO) untuk setiap lapisan Platform:

Jika Customer memilih Enhanced DR Option (server sekunder dengan read-only database replica dan replikasi frekuensi tinggi hingga interval 15 menit), RTO lapisan basis data dikurangi menjadi 1 jam karena VM sekunder mengambil alih peran utama dengan kehilangan data dan waktu yang minimal. Enhanced DR Option dikenakan biaya langganan tambahan sebagaimana diatur dalam Kontrak Komersial yang berlaku.

Gambaran Umum Business Continuity Azure SQL Database

9.5 Manajemen Backup

Provider menerapkan rezim backup komprehensif yang mencakup seluruh komponen lingkungan berdaulat privat khusus milik setiap Customer. Operasi backup dilakukan menggunakan Azure Backup dan kemampuan backup native SQL Server.

9.5.1 Jadwal Backup & Retensi

Pencadangan dengan frekuensi lebih tinggi yang disesuaikan dapat disediakan atas permintaan Customer dengan tetap tunduk pada biaya langganan tambahan. Seluruh frekuensi pencadangan dan periode retensi didokumentasikan dalam Amandemen Jadwal Pencadangan yang berlaku dan dilampirkan pada Kontrak Komersial.

Gambaran Umum Azure Backup Pencadangan SQL Server ke Azure

9.5.2 Verifikasi Integritas Pencadangan

Provider wajib melaksanakan prosedur verifikasi integritas pencadangan berikut:

• (a) Validasi checksum otomatis: Setiap operasi pencadangan menghasilkan checksum kriptografis (SHA-256). Checksum diverifikasi secara otomatis setelah selesai dan dicatat dalam jejak audit pencadangan.
• (b) Uji pemulihan bulanan: Setidaknya sekali setiap bulan kalender, Provider wajib melakukan pemulihan uji atas backup database yang dipilih secara acak ke lingkungan terisolasi, dengan memverifikasi kelengkapan data, integritas referensial, dan fungsionalitas pada lapisan aplikasi.
• (c) Latihan pemulihan full-stack triwulanan: Setidaknya sekali setiap kuartal kalender, Provider wajib melakukan pemulihan platform secara lengkap (VM + database + aplikasi + konfigurasi) ke lingkungan terisolasi, mensimulasikan skenario pemulihan bencana penuh. Hasilnya didokumentasikan dalam Laporan Latihan DR.
• (d) Pemantauan & peringatan pencadangan: Peringatan Azure Monitor dikonfigurasi untuk memberi tahu tim Cloud Operations Provider dalam waktu 15 menit jika terjadi kegagalan backup, timeout, atau kegagalan pemeriksaan integritas. Backup yang gagal akan memicu percobaan ulang otomatis dalam waktu 1 jam.

9.6 Redundansi & Replikasi Data

Setiap lingkungan sovereign privat khusus milik Customer memanfaatkan arsitektur redundansi data berlapis milik Azure untuk melindungi dari kegagalan perangkat keras, kegagalan fasilitas, dan bencana regional:

Secara default, setiap akun Azure Storage milik Customer disediakan dengan Penyimpanan Geo-Redundan (GRS), yang mempertahankan enam salinan Data Customer, yaitu tiga di wilayah Azure utama dan tiga di wilayah sekunder pasangan geografis. Jika terjadi kegagalan di wilayah utama, Azure Storage secara otomatis melakukan failover ke wilayah sekunder, sehingga memastikan keandalan data tanpa intervensi manual.

Redundansi Azure Storage

9.6.1 Replikasi Basis Data

Basis data SQL Server 2022 dalam lingkungan masing-masing Customer mendukung konfigurasi replikasi berikut:

• (a) Konfigurasi standar: Backup penuh harian dengan retensi 7 hari, disimpan di GRS. Log transaksi dicadangkan sesuai jadwal yang dikonfigurasi (default: per jam; Enhanced DR: setiap 15 menit).
• (b) Konfigurasi Enhanced DR (opsional): Sebuah instans SQL Server sekunder disediakan dengan replika read-only dari seluruh basis data Customer. Pengiriman log berfrekuensi tinggi (hingga interval 15 menit) memastikan sinkronisasi data hampir real-time. Jika terjadi kegagalan server utama, server sekunder secara otomatis mengambil alih peran utama, memberikan kesinambungan dengan kehilangan data minimal (RPO ≤ 15 menit) dan pemulihan cepat (RTO ≤ 1 jam).
• (c) Kepatuhan residensi data: Replikasi data dibatasi pada wilayah geografis yang dipilih Customer kecuali Customer secara tegas memberikan otorisasi tertulis untuk replikasi lintas wilayah. Data tidak dapat dikirim ke luar wilayah geografis yang dipilih tanpa persetujuan Customer, sesuai dengan persyaratan transfer lintas batas GDPR Pasal 44 dan UAE PDPL Pasal 22 (lihat Bab 7, §7.14).

9.7 Prosedur Pemulihan Bencana

Provider memelihara prosedur pemulihan bencana yang terdokumentasi untuk setiap lapisan Platform. Prosedur ini diuji setidaknya setiap kuartal dan diperbarui setelah setiap perubahan material pada arsitektur Platform, kemampuan layanan Azure, atau konfigurasi lingkungan Customer.

9.7.1 Klasifikasi Insiden & Eskalasi

Peristiwa pemulihan bencana diklasifikasikan menurut taksonomi tingkat keparahan berikut:

9.7.2 Prosedur Failover

Prosedur failover berikut dijalankan secara berurutan setelah penetapan kejadian DR-1 atau DR-2:

9.7.3 Failover Wilayah Sekunder

Apabila wilayah Azure utama dinyatakan tidak dapat dipulihkan oleh Microsoft atau oleh CTO Provider, Provider wajib melaksanakan failover penuh ke wilayah sekunder ke wilayah Azure pasangan geografis. Prosedur ini mencakup:

• (a) Inisiasi failover GRS: Azure Storage secara otomatis melakukan failover ke wilayah sekunder. Akun RA-GRS menyediakan akses baca langsung ke data yang direplikasi.
• (b) Penataan ulang VM: Virtual machine baru disediakan di wilayah sekunder dari Azure Backup vault terbaru (cross-region restore diaktifkan).
• (c) Pemulihan basis data: Basis data SQL Server dipulihkan dari backup geo-redundan atau, jika Enhanced DR disediakan, dari server read-replica sekunder di wilayah pasangan.
• (d) Rekonfigurasi DNS: Azure Traffic Manager atau record DNS diperbarui untuk mengarahkan seluruh lalu lintas Customer ke endpoint wilayah sekunder.
• (e) Validasi & deklarasi: Seluruh rangkaian verifikasi aplikasi dijalankan sebelum menyatakan layanan pulih dari wilayah sekunder. Target RTO untuk failover penuh ke wilayah sekunder adalah 24 jam sejak titik deklarasi wilayah utama. Customer wajib terus diinformasikan setidaknya setiap 2 jam selama prosedur failover melalui kanal komunikasi yang disepakati.

Pemulihan Bencana Lintas Wilayah Azure

9.8 Perencanaan Kelangsungan Bisnis

9.8.1 Analisis Dampak Bisnis (BIA)

Provider memelihara Business Impact Analysis untuk Platform ProjectVIEW ERP yang mengidentifikasi proses bisnis kritis, memetakan ketergantungannya pada komponen Platform, dan mengkuantifikasi dampak gangguan layanan. BIA ditinjau dan diperbarui:

• (a) Setidaknya setiap tahun sebagai bagian dari siklus tinjauan manajemen BCMS.
• (b) Setelah setiap perubahan material pada arsitektur Platform, konfigurasi wilayah Azure, atau topologi penerapan Customer.
• (c) Setelah setiap insiden DR-1 atau DR-2 yang mengungkap celah dalam BIA yang ada.

BIA menjadi dasar kalibrasi tujuan pemulihan (RPO/RTO), keputusan frekuensi backup, dan desain arsitektur replikasi untuk setiap lingkungan Customer.

9.8.2 Business Continuity Plan (BCP)

Business Continuity Plan milik Provider mendokumentasikan prosedur, peran, protokol komunikasi, dan alokasi sumber daya yang diperlukan untuk mempertahankan atau memulihkan layanan Platform selama gangguan. BCP mencakup:

• (a) Komposisi Crisis Management Team (CMT): CTO (Incident Commander), Cloud Operations Lead, DBA Lead, Customer Account Manager, dan Communications Lead.
• (b) Rencana komunikasi: Template yang telah ditetapkan sebelumnya untuk pemberitahuan Customer (peringatan awal, pembaruan progres, pemberitahuan penyelesaian, distribusi PIR), matriks eskalasi internal, dan daftar kontak vendor (Microsoft Azure Support, registrar domain, penyedia SSL).
• (c) Inventaris sumber daya: Inventaris terdokumentasi atas seluruh sumber daya Azure per lingkungan Customer (VM, instans SQL, akun penyimpanan, komponen jaringan, rahasia Key Vault), dipelihara dalam CMDB dan divalidasi triwulanan.
• (d) Prosedur lokasi alternatif: Prosedur langkah demi langkah untuk mengaktifkan wilayah Azure sekunder, termasuk template infrastruktur yang telah dipra-sediakan (Azure Resource Manager / Bicep) dan skrip penerapan otomatis.
• (e) Kelangsungan pemasok: Penilaian atas ketergantungan pihak ketiga yang kritis (komitmen SLA Microsoft Azure, registrar domain, certificate authority) dan langkah kontinjensi untuk masing-masing.

9.8.3 Program Latihan DR

Provider wajib menyelenggarakan latihan DR secara berkala untuk memvalidasi efektivitas rencana BCDR dan memastikan kesiapan operasional:

Semua hasil latihan didokumentasikan, disimpan minimum tiga (3) tahun, dan tersedia bagi Customer atas permintaan tertulis. Jika suatu latihan mengungkap penyimpangan dari tujuan RPO/RTO yang dikontrakkan, Provider wajib menerapkan tindakan perbaikan dalam tiga puluh (30) hari kalender dan mengulangi latihan terkait untuk mengonfirmasi perbaikan.

9.9 Kepemilikan & Portabilitas Data Customer

Customer mempertahankan kepemilikan tunggal dan eksklusif atas seluruh Data Customer yang diproses, disimpan, atau dihasilkan dalam Platform. Provider tidak memeriksa, menyetujui, memantau, atau mengklaim hak kepemilikan apa pun atas Data Customer kapan pun, baik selama Masa Langganan maupun setelah berakhir atau diakhirinya Masa Langganan.

Microsoft, sebagai penyedia infrastruktur yang mendasari, tidak mengetahui jenis data apa yang dipilih Customer untuk disimpan di Azure dan tidak mengklaim kepemilikan data atas informasi Customer yang dimasukkan ke layanan Azure.

9.9.1 Ekspor Data & Portabilitas

Provider wajib menyediakan Data Customer untuk diekspor dengan cara berikut:

• (a) Ekspor berdasarkan permintaan: Customer dapat meminta ekspor penuh atau sebagian Data Customer kapan saja selama Masa Langganan. Provider wajib menyerahkan ekspor tersebut dalam waktu dua (2) Hari Kerja sejak menerima permintaan tertulis yang sah, dalam format standar industri yang dapat dibaca mesin (file backup SQL, CSV, JSON, atau XML sesuai kesepakatan).
• (b) Ekspor saat pengakhiran: Setelah berakhir atau diakhirinya Framework, Provider wajib menyediakan seluruh Data Customer untuk diekspor dalam waktu dua (2) Hari Kerja sejak permintaan tertulis Customer, sesuai dengan ketentuan pengembalian data pada Bab 7, §7.13 (Pengembalian Data Saat Pengakhiran). Jendela ekspor keseluruhan akan tetap terbuka selama minimum enam puluh (60) hari kalender sejak tanggal efektif pengakhiran.
• (c) Ekspor audit & kepatuhan: Customer dapat meminta log audit, log akses, dan catatan pelacakan perubahan untuk tujuan kepatuhan. Ekspor tersebut disediakan dalam waktu dua (2) Hari Kerja sejak permintaan tertulis.

9.9.2 Pengelolaan Catatan

Customer bertanggung jawab untuk mengidentifikasi sendiri kebutuhan retensi catatannya sesuai hukum yang berlaku dan regulasi industri. Provider mendukung kewajiban pengelolaan catatan Customer dengan:

• (a) Kebijakan retensi yang dapat dikonfigurasi: Platform mendukung aturan retensi data yang dapat dikonfigurasi pada tingkat aplikasi, sehingga Customer dapat menetapkan periode retensi untuk kategori rekaman yang berbeda.
• (b) Pelestarian jejak audit: Kebijakan retensi Azure Storage dan change tracking SQL Server menyediakan jejak audit yang tidak dapat diubah untuk seluruh modifikasi data. Catatan audit disimpan minimum selama periode yang disepakati dalam Kontrak Komersial (default: tujuh tahun).
• (c) Ekspor untuk arsip eksternal: Customer dapat mengekspor data dan laporan audit untuk arsip eksternal kapan saja selama Masa Langganan. Provider wajib memfasilitasi ekspor massal dalam format standar atas permintaan tertulis.

9.9.3 Electronic Discovery (e-Discovery)

Customer bertanggung jawab untuk mematuhi persyaratan e-discovery dalam penggunaan Platform. Provider wajib mendukung kewajiban e-discovery Customer dengan:

• (a) Penahanan pelestarian data: Atas permintaan tertulis dari Customer yang menyebutkan kebutuhan litigation-hold atau investigasi regulasi, Provider wajib menerapkan penahanan pelestarian atas Customer Data yang ditentukan, dengan menangguhkan seluruh penghapusan otomatis dan penerapan kebijakan retensi untuk kumpulan data yang terdampak.
• (b) Ekspor data untuk e-discovery: Provider wajib mengekspor dan menyerahkan kumpulan data yang ditentukan dalam format yang sesuai untuk peninjauan e-discovery (termasuk metadata dan jejak audit) dalam waktu dua (2) Hari Kerja sejak permintaan penahanan pelestarian.
• (c) Dokumentasi chain-of-custody: Provider wajib menyediakan dokumentasi chain-of-custody untuk seluruh ekspor e-discovery, yang mengesahkan kelengkapan dan integritas data yang diekspor.

9.10 Ketahanan Platform Azure

Provider memanfaatkan kapabilitas ketahanan native Azure berikut dalam lingkungan sovereign privat khusus setiap Customer:

• (a) Availability Zones: Jika tersedia di region Azure yang dipilih Customer, resource kritis (VM, managed disks, load balancers) diterapkan di beberapa Availability Zones untuk melindungi dari kegagalan pada satu zona.
• (b) Azure Resource Health: Memantau kesehatan VM dan memeriksa apakah sumber daya berjalan sebagaimana mestinya, dengan mendeteksi masalah platform Azure yang diketahui yang memengaruhi sumber daya yang ada. Peringatan dialihkan ke tim Cloud Operations melalui Azure Monitor.
• (c) Azure Backup Vault: Pengelolaan pencadangan terpusat dengan kemampuan pemulihan lintas region, perlindungan soft-delete (14 hari), dan otorisasi multi-pengguna untuk operasi penghapusan cadangan yang kritis.
• (d) Azure Resource Locks: Lock CanNotDelete dan ReadOnly diterapkan pada seluruh sumber daya produksi untuk mencegah penghapusan atau modifikasi yang tidak disengaja maupun berbahaya terhadap komponen infrastruktur kritis.
• (e) Azure DDoS Protection: Perlindungan DDoS tingkat Standard diaktifkan pada seluruh jaringan virtual Customer, memberikan mitigasi serangan otomatis dengan telemetri real-time dan pelaporan pascaserangan.
• (f) Azure Key Vault: Kunci enkripsi, rahasia, dan sertifikat disimpan di Azure Key Vault dengan soft-delete dan purge-protection diaktifkan, sehingga material kriptografis tetap dapat dipulihkan bahkan jika terjadi penghapusan tidak sengaja.

Gambaran Umum Azure Availability Zones Gambaran Umum Azure Resource Health Arsitektur Azure Backup

9.11 Tanggung Jawab Customer

Customer mengakui dan menyetujui tanggung jawab berikut dalam mendukung program BCDR:

• (a) Penetapan kontak: Customer wajib menetapkan dan memelihara setidaknya dua (2) kontak yang berwenang untuk komunikasi terkait DR, termasuk detail kontak darurat di luar jam kerja. Detail kontak wajib diperbarui dalam waktu lima (5) Hari Kerja setelah ada perubahan personel.
• (b) Partisipasi uji coba DR: Customer wajib melakukan upaya yang wajar untuk berpartisipasi dalam Secondary-Region Failover Drills tahunan dan Tabletop Exercises triwulanan, serta memberikan umpan balik mengenai efektivitas komunikasi dan akurasi dampak bisnis.
• (c) Spesifikasi kebijakan retensi: Customer wajib menetapkan persyaratan retensi datanya secara tertulis selama onboarding dan memperbaruinya bila diperlukan. Provider wajib mengonfigurasi kebijakan retensi Platform sesuai hal tersebut.
• (d) Validasi ekspor data: Setelah setiap operasi ekspor data (berdasarkan permintaan atau pengakhiran), Customer wajib memverifikasi kelengkapan dan integritas data yang diekspor dalam jendela validasi yang disepakati. Kegagalan menyampaikan keberatan atas kelengkapan data dalam jendela validasi akan dianggap sebagai penerimaan atas ekspor tersebut.
• (e) Perencanaan kelangsungan pengguna akhir: Customer bertanggung jawab atas perencanaan kelangsungan bisnis internalnya sendiri, termasuk komunikasi pengguna akhir, alternatif proses manual, dan ketergantungan sistem internal yang berada di luar cakupan Platform.

9.12 Peningkatan Berkelanjutan

Program BCDR Provider tunduk pada siklus peningkatan berkelanjutan yang selaras dengan metodologi Plan-Do-Check-Act (PDCA) yang ditetapkan oleh ISO 22301:2019:

• (a) Plan: Tinjauan BIA tahunan, kalibrasi tujuan pemulihan, dan pembaruan rencana BCDR berdasarkan perubahan pada Platform, kapabilitas Azure, dan kebutuhan Customer.
• (b) Lakukan: Pelaksanaan jadwal pencadangan, konfigurasi replikasi, dan program latihan DR sebagaimana didefinisikan dalam bab ini.
• (c) Periksa: Pemantauan tingkat keberhasilan backup, hasil latihan DR (RPO/RTO terukur dibandingkan target), tinjauan pasca insiden, dan umpan balik Customer.
• (d) Tindak: Implementasi tindakan korektif, peningkatan arsitektur, dan penyempurnaan prosedur yang diidentifikasi melalui fase Check. Seluruh perbaikan dilacak dalam BCDR Improvement Register dan dilaporkan dalam rapat Service Review triwulanan (lihat Bab 4, §4.10).

9.13 Jaminan Perangkat Lunak Seumur Hidup

Penyedia menjamin bahwa Platform akan, selama seluruh durasi Subscription Term dan setiap perpanjangannya (“ Masa Jaminan ”):

• (a) Kesesuaian: beroperasi secara material sesuai dengan spesifikasi, fungsionalitas, dan tingkat layanan yang dijelaskan dalam Framework ini dan Commercial Contract yang berlaku;
• (b) Perbaikan Cacat: bebas dari cacat material yang mencegah Customer menggunakan Platform untuk tujuan bisnis yang dimaksudkan. Setiap cacat yang terkonfirmasi harus diperbaiki oleh Provider tanpa biaya tambahan bagi Customer dalam target respons dan penyelesaian SLA yang berlaku sebagaimana didefinisikan dalam Chapter 3;
• (c) Kebaruan Versi: tetap berada pada tumpukan teknologi yang saat ini didukung dan dipelihara. Provider wajib secara proaktif meningkatkan semua komponen COTS yang mendasarinya (database engine, application framework, operating system, middleware) ke versi yang didukung vendor dalam siklus rilis yang ditetapkan di Section 4.7;
• (d) Pemeliharaan Keamanan: menerima patch keamanan berkelanjutan selama Masa Jaminan, termasuk penanganan kerentanan Critical dan High dalam jangka waktu yang ditetapkan dalam Bab 8;
• (e) Tanpa Penurunan Kinerja: mempertahankan karakteristik kinerja yang memenuhi atau melampaui target SLO dan objective pemulihan (RPO/RTO) yang ditetapkan dalam Framework ini. Provider tidak boleh memperkenalkan perubahan yang secara material menurunkan kinerja Platform tanpa persetujuan Customer. Garansi ini merupakan garansi seumur hidup yang berlaku seluas sama dengan Subscription aktif Customer. Garansi ini tidak berakhir, tidak dipersempit ruang lingkupnya, dan tidak memerlukan perpanjangan terpisah. Garansi ini tetap berlaku melewati transisi versi berdasarkan Chapter 10 dan berlaku sama terhadap versi penerus sejak tanggal General Availability-nya.

Pengecualian: Jaminan ini tidak mencakup cacat yang timbul dari (i) modifikasi Customer terhadap Platform di luar proses manajemen perubahan milik Penyedia; (ii) penggunaan Platform dengan cara yang tidak sesuai dengan dokumentasinya; (iii) perangkat lunak atau perangkat keras pihak ketiga yang tidak disediakan atau disetujui oleh Penyedia; atau (iv) Force Majeure Events.

9.14 Escrow Source Code

Untuk memberikan jaminan kontinuitas jangka panjang kepada Customer, Penyedia wajib menjaga pengaturan escrow source code sebagai berikut:

9.14.1 Setoran Escrow

• (a) Escrow Agent: Penyedia wajib menunjuk agen escrow pihak ketiga yang bereputasi dan independen (“Escrow Agent”) untuk menyimpan source code Platform. Identitas Escrow Agent akan diungkapkan kepada Customer atas permintaan.
• (b) Isi Setoran: Setoran escrow harus mencakup: (i) source code lengkap Platform; (ii) skrip build dan instruksi kompilasi; (iii) skema basis data dan skrip migrasi; (iv) manifes dependensi pihak ketiga dan dokumentasi lisensi; (v) dokumentasi arsitektur sistem; dan (vi) prosedur deployment yang memadai untuk memungkinkan profesional perangkat lunak yang kompeten mengompilasi, menerapkan, dan mengoperasikan Platform.
• (c) Frekuensi Pembaruan: Setoran escrow harus diperbarui dalam waktu tiga puluh (30) hari sejak setiap rilis versi utama (Upgrade) dan setidaknya satu kali per kuartal kalender untuk rilis inkremental (Update).
• (d) Verifikasi: Escrow Agent wajib melakukan verifikasi tahunan atas setoran untuk memastikan kelengkapan dan kemampuan dibangun. Sertifikat verifikasi ringkasan akan diberikan kepada Customer atas permintaan.

9.14.2 Kondisi Pelepasan

Escrow Agent wajib melepaskan source code yang di-escrow kepada Customer apabila salah satu kondisi pelepasan berikut terjadi:

• (a) Kepailitan: Provider masuk ke likuidasi, administrasi, receivership, atau proses insolvensi serupa di yurisdiksi mana pun;
• (b) Penghentian Usaha: Provider menghentikan kegiatan usaha atau secara substansial seluruh kegiatan usahanya;
• (c) Pelanggaran Material: Provider melakukan pelanggaran material terhadap Framework ini yang tetap belum diperbaiki selama enam puluh (60) hari setelah pemberitahuan tertulis dari Customer;
• (d) Penghentian: Provider secara permanen menghentikan Platform tanpa menyediakan produk penerus atau jalur transisi yang wajar secara komersial.

9.14.3 Hak Customer Setelah Pelepasan

Setelah source code yang di-escrow dilepaskan, Customer akan diberikan lisensi non-eksklusif, tidak dapat dialihkan, dan tidak dapat dibatalkan untuk menggunakan, mengompilasi, memodifikasi, dan menerapkan source code semata-mata untuk tujuan melanjutkan pengoperasian Platform bagi kebutuhan bisnis internal Customer sendiri. Lisensi ini tidak mencakup hak untuk mendistribusikan ulang, mensublisensikan, atau mengeksploitasi source code secara komersial.

9.14.4 Biaya

Biaya pembentukan dan pemeliharaan pengaturan escrow, termasuk biaya Escrow Agent, pembaruan setoran, dan verifikasi tahunan, menjadi tanggungan Customer. Penyedia akan memfasilitasi pengaturan awal dengan Escrow Agent dan akan bekerja sama dalam seluruh aktivitas setoran dan verifikasi, namun Customer sepenuhnya bertanggung jawab atas biaya Escrow Agent dan biaya terkait lainnya selama Subscription Term.

9.15 Peran & Tanggung Jawab (Matriks RACI)

Matriks RACI berikut mengalokasikan tanggung jawab untuk aktivitas BCDR utama di antara peran Penyedia dan Customer:

Legenda: R = Responsible (melaksanakan aktivitas) · A = Accountable (otoritas keputusan akhir) · C = Consulted (memberikan masukan sebelum keputusan) · I = Informed (diberi tahu setelah keputusan).

9.16 Register Proses

Register proses berikut mengatalogkan seluruh proses formal yang didefinisikan dalam bab ini. Setiap proses diberi pengenal unik, kondisi pemicu, penanggung jawab, pemberi persetujuan yang akuntabel, hasil yang diharapkan, dan referensi silang ke bagian yang mengatur.

9.17 Skema Alur Proses

Siklus hidup sembilan tahap berikut menggambarkan alur end-to-end manajemen business continuity dan disaster recovery dalam program BCDR Penyedia:

① BIA & Penilaian Risiko → ② Pengembangan BCP & Rencana DR → ③ Backup & Replikasi

Konfigurasi

↓

④ Pemantauan & Deteksi → ⑤ Klasifikasi & Eskalasi Insiden → ⑥ Failover & Pemulihan

Pelaksanaan

↓

⑦ Pemulihan & Verifikasi Layanan → ⑧ Tinjauan Pasca Insiden & PIR → ⑨ Peningkatan

Berkelanjutan & Program Latihan

Tahap ① BIA & Penilaian Risiko: Business Impact Analysis tahunan mengidentifikasi proses kritis, memetakan dependensi Platform, dan mengkuantifikasi dampak gangguan. Peringkat prioritas pemulihan dan target RPO/RTO dikalibrasi berdasarkan output BIA (P-9.01).

Tahap ② Pengembangan BCP & DR: Business Continuity Plan dan prosedur DR dikembangkan atau diperbarui berdasarkan temuan BIA, dengan memasukkan komposisi CMT, template komunikasi, inventaris sumber daya, dan prosedur aktivasi wilayah sekunder (P-9.02).

Tahap ③ Konfigurasi Backup & Replikasi: Jadwal backup, kebijakan retensi, dan arsitektur replikasi (LRS/ZRS/GRS/RA-GRS) dikonfigurasi untuk setiap lingkungan Customer. Read-replica DR yang disempurnakan disediakan bila dipilih (P-9.03).

Tahap ④ Pemantauan & Deteksi: Azure Monitor, SIEM, dan Resource Health memantau seluruh komponen Platform secara berkelanjutan. Penyelesaian dan integritas backup diverifikasi secara otomatis dengan peringatan saat terjadi kegagalan (P-9.04, P-9.05, P-9.06).

Tahap ⑤ Klasifikasi & Eskalasi Insiden: Insiden yang terdeteksi diklasifikasikan (DR-1 hingga DR-4) dan diekalasikan sesuai taksonomi tingkat keparahan. Timeline pemberitahuan Customer dipicu berdasarkan tingkat keparahan (P-9.07, P-9.08).

Tahap ⑥ Pelaksanaan Failover & Pemulihan: Failover basis data, pemulihan VM, dan verifikasi aplikasi dilaksanakan secara berurutan sesuai tabel prosedur failover. Failover wilayah sekunder dilakukan untuk kejadian DR-1 ketika wilayah utama tidak dapat dipulihkan (P-9.09 hingga P-9.11, P-9.14).

Tahap ⑦ Pemulihan & Verifikasi Layanan: Layanan dinyatakan pulih setelah seluruh fase pemulihan selesai. Jam SLA dilanjutkan dan pemantauan yang ditingkatkan dipertahankan selama 72 jam. Cutover DNS/jaringan diverifikasi (P-9.12).

Tahap ⑧ Tinjauan Pasca Insiden & PIR: Root Cause Analysis dilakukan dalam 5 Hari Kerja. Post-Incident Report disampaikan kepada Customer dengan tindakan korektif, pembaruan rencana BCDR, dan pelajaran yang diperoleh (P-9.13).

Tahap ⑨ Peningkatan Berkelanjutan & Program Latihan: Latihan DR (tabletop, komponen, full-stack, regional) dilaksanakan sesuai program terjadwal. Penyimpangan dari target RPO/RTO memicu tindakan korektif yang dilacak dalam Improvement Register. Siklus PDCA kembali ke Tahap ① (P-9.15, P-9.18).