SLA adalah singkatan dari Service Level Agreement, perjanjian tingkat layanan yang menetapkan layanan dan kinerja yang disepakati antara penyedia dan pengguna. Untuk kanal digital bank, angka di SLA harus dibaca dalam menit: 99,9% dalam bulan 30 hari mengizinkan 43,2 menit gangguan, atau 8,76 jam setahun. POJK 11/POJK.03/2022 Pasal 30 ayat (5) huruf c mewajibkan bank menilai kinerja vendor TI-nya terhadap perjanjian tingkat layanan itu. Jadi SLA adalah tolok ukur resmi penilaian vendor, bukan lampiran formalitas di belakang kontrak.
Definisi di atas mengikuti rumusan pemerintah sendiri. Peraturan Dirjen Perbendaharaan PER-8/PB/2020 (31 Maret 2020) Pasal 1 angka 5 menyebut SLA sebagai perjanjian yang "mengidentifikasi layanan dan kinerja yang disepakati". Artikel ini ditulis untuk Head of Digital atau CIO yang menandatangani kontrak vendor kanal, dan untuk tim compliance yang harus menunjukkan ke OJK bahwa jadwal SLA memuat butir kontrak yang diminta.
Berapa lama downtime yang diizinkan SLA: tabel menitnya
Rumusnya cuma satu: downtime yang diizinkan = (1 − A) × menit dalam periode ukur. Bulan 30 hari punya 43.200 menit, tahun 365 hari punya 525.600 menit. Kolom terakhir menambahkan satu asumsi contoh: jendela pemeliharaan 4 jam per minggu yang dikecualikan dari hitungan. Dirata-rata, itu 30/7 × 240 = 1.028,6 menit per bulan 30 hari, dan target availability hanya berlaku untuk 42.171 menit sisanya.
| Availability | Per bulan (30 hari) | Per tahun | Total gelap per bulan, termasuk pemeliharaan |
|---|---|---|---|
| 99,0% | 432 menit | 5.256 menit (87,6 jam) | 1.450,3 menit |
| 99,5% | 216 menit | 2.628 menit (43,8 jam) | 1.239,4 menit |
| 99,9% | 43,2 menit | 525,6 menit (8,76 jam) | 1.070,7 menit |
| 99,95% | 21,6 menit | 262,8 menit (4,38 jam) | 1.049,7 menit |
| 99,99% | 4,32 menit | 52,6 menit (0,88 jam) | 1.032,8 menit |
Kolom terakhir itu yang tidak pernah dicetak. AI Overview Google untuk kueri "sla adalah", saat kami ukur pada 16 Oktober 2026, hanya menyebut "99,9%" tanpa hitungan menit sama sekali. Padahal hasilnya mencolok: kanal yang dijual "99,99%" boleh gelap sekitar 1.033 menit, kira-kira 17,2 jam, dalam sebulan, dan laporan SLA-nya tetap hijau. Pada "99,9%" angkanya 17,8 jam. Dalam bulan kalender, jendela mingguan itu jatuh 4 atau 5 kali, jadi waktu yang dikecualikan berkisar 960 sampai 1.200 menit.
Pendapat kami: angka empat sembilan tanpa batas jam pemeliharaan adalah angka pemasaran, bukan janji. Selisih antara 99,9% dan 99,99% hanya 38,9 menit per bulan, sedangkan jendela pemeliharaan yang tidak dibatasi bisa sekitar 26 kali lebih besar dari selisih itu.
Februari 28 hari hanya penting kalau SLA menulis menit, bukan persen: 99,9% di Februari berarti 40,3 menit, bukan 43,2. Kalau kontrak menulis persen, yang menentukan adalah definisi periode ukur. Minta definisi itu tertulis.
Tiga hal yang tidak tertulis di angka 99,9%
Di mana availability diukur
Penyedia cloud mengukur di batas infrastrukturnya sendiri. SLA Google Cloud Compute Engine mendefinisikan downtime sebagai "loss of external connectivity or persistent disk access", dan gangguan di bawah satu menit tidak dihitung. SLA Amazon Compute mengecualikan masalah internet "beyond the demarcation point of Amazon EC2". Nasabah tidak mengalami infrastruktur. Nasabah mengalami login yang gagal di aplikasi mobile banking. Karena itu SLA kanal bank sebaiknya menyebut titik ukur yang bisa diaudit: probe sintetis dari jaringan operator seluler dan ISP rumahan di Indonesia, dari Jakarta dan minimal satu kota lain, yang menjalankan perjalanan login sampai cek saldo, dengan interval tertulis dan aturan berapa probe gagal berturut-turut yang dihitung downtime.
Apa yang dikecualikan
Ketentuan umum SLA Microsoft Azure (edisi Oktober 2026) menulisnya terang: "Downtime does not include Scheduled Downtime", yaitu pemeliharaan jaringan, perangkat keras, atau layanan yang diumumkan paling lambat lima hari sebelumnya. Tabel di atas menunjukkan seberapa lebar celah itu. Klausul yang perlu diminta: batas jam pemeliharaan per bulan, jendela di luar jam transaksi puncak (untuk bank ritel, sekitar tanggal gajian dan hari-hari menjelang Lebaran jelas bukan waktunya), dan pemeliharaan yang melewati batas dihitung sebagai downtime.
Respons bukan resolusi
Availability, waktu respons, dan waktu resolusi adalah tiga kewajiban terpisah. Vendor bisa merespons tiket P1 dalam 15 menit dan tetap butuh 9 jam untuk memulihkan layanan. Masing-masing perlu target, titik ukur, dan konsekuensi sendiri di jadwal SLA. Untuk bank yang menyelenggarakan layanan digital, POJK 21 Tahun 2023 (ditetapkan 19 Desember 2023) Pasal 26 mewajibkan fungsi penanganan pertanyaan dan pengaduan nasabah yang beroperasi 24 jam sehari. Jadi tier respons 24x7 punya dasar regulasi, bukan sekadar preferensi.
Kredit layanan cloud mengembalikan biaya hosting, bukan kerugian
Pada 19 Oktober 2026 kami membaca jadwal kredit tiga penyedia yang punya region di Jakarta: Google Cloud asia-southeast2, AWS ap-southeast-3, dan Azure Indonesia Central. Angka di bawah untuk tier multi-zona, yaitu VM yang tersebar di dua zona atau lebih.
| Penyedia (dokumen, tanggal) | Target | Kredit 10% | Kredit 100% |
|---|---|---|---|
| Google Cloud Compute Engine (diubah 14 Okt 2026) | ≥ 99,99% | 99,00% s.d. < 99,99% | < 95,00% |
| AWS Amazon Compute (diperbarui 25 Mei 2022) | 99,99% | < 99,99% s.d. ≥ 99,0% | < 95,0% |
| Azure VM, dua AZ atau lebih (Okt 2026) | 99,99% | < 99,99% s.d. 99% | < 95% |
Tingkat tengahnya berbeda: 25% di Google Cloud dan Azure, 30% di AWS, untuk availability 95% sampai di bawah 99%. Yang penting polanya. Di ketiga penyedia, pita kredit 10% yang sama membentang dari 99,99% sampai 99,0%. Dalam bulan 30 hari, gangguan 5 menit dan gangguan 432 menit, lebih dari 7 jam, menghasilkan kompensasi yang persis sama.
Kredit itu juga dihitung dari tagihan layanan yang terganggu, bukan dari kerugian Anda. Google Cloud menyebut SLA-nya "sole and exclusive remedy"; kredit dipakai untuk tagihan berikutnya, harus diklaim dalam 60 hari, dan dibatasi tagihan bulanan layanan itu. AWS menulis bahwa kredit "will not entitle you to any refund or other payment". Azure paling eksplisit: kredit tidak diberikan untuk "lost revenue, operational costs, or any indirect losses".
Contoh hitung dengan angka ilustratif: jika tagihan compute kanal Rp100 juta per bulan, gangguan 7 jam menghasilkan kredit Rp10 juta, dipotong dari tagihan bulan depan. Kerugian bank dari 7 jam itu berupa transaksi yang gagal, beban contact center, dan risiko reputasi. Kami tidak menemukan angka biaya per jam gangguan kanal bank Indonesia di sumber primer OJK, BI, atau BPS. Hitung sendiri dari volume transaksi per jam dan biaya per transaksi bank Anda, dan jangan meminjam angka luar negeri dari blog vendor.
Kesimpulannya: perlindungan finansial atas outage tidak datang dari SLA hyperscaler. Ia harus datang dari kontrak dengan vendor kanal dan dari arsitektur. Kontrak itu sebaiknya memuat penalti yang dikaitkan dengan durasi gangguan, bukan persentase tagihan hosting.
RTO dan RPO: klausul yang harus diminta
Uptime dan pemulihan adalah dua janji yang berbeda. Penyedia bisa memenuhi 99,9% dan tetap kehilangan data 4 jam terakhir saat terjadi kegagalan. POJK 11/2022 tidak menetapkan angka RTO atau RPO; istilah RTO bahkan tidak muncul di teksnya. Angkanya ditetapkan bank sendiri lewat analisis dampak bisnis (BIA). PADK 1 Tahun 2026 (ditetapkan 23 Januari 2026, berlaku 1 Maret 2026, mencabut SEOJK 21/SEOJK.03/2017), Lampiran I Bab IV.B.3.a.1)c) tentang Analisis Dampak Bisnis, butir (4), menyebut hal yang harus dianalisis BIA: MTD dan/atau RTO, serta RPO. Tugas SLA adalah membawa angka itu menjadi kewajiban vendor. Klausul yang kami sarankan diminta:
- RTO dan RPO dalam menit, per layanan kritikal, sama dengan hasil BIA bank.
- Uji DRP bersama paling sedikit sekali setahun dengan vendor ikut serta. POJK 11 Pasal 18 ayat (3) mewajibkan uji tahunan atas aplikasi kritikal, dan PADK 1/2026 Bab IV.B.3.b menyatakan pengujian "perlu melibatkan" penyedia jasa TI bila bank memakainya.
- Untuk vendor berbasis cloud, bukti pusat pemulihan data yang terpisah secara geografis dengan RTO dan RPO terdokumentasi. SEOJK 29/SEOJK.03/2022 (27 Desember 2022), Lampiran I.c, kontrol 2.h, menaruh kewajiban itu di pundak bank: bank harus "memastikan penyedia cloud memiliki data recovery center yang terpisah secara geografis". Kewajibannya milik bank, bukan penyedia cloud. Justru karena itu ia harus tertulis di kontrak, karena hanya lewat kontrak bank bisa menagih buktinya.
- Notifikasi insiden dari vendor ke bank dalam hitungan jam, jauh di bawah 24 jam, karena POJK 11 Pasal 60 ayat (1) huruf a memberi bank 24 jam sejak insiden diketahui untuk notifikasi awal ke OJK.
- Frekuensi backup dan uji restore, dengan hasil yang dilaporkan.
Jenis pengendalian dan dokumen bukti untuk DR sudah kami uraikan di 10 jenis keamanan siber dan dokumen buktinya.
Bagaimana jadwal SLA membawa butir kontrak wajib OJK
POJK 11/POJK.03/2022 (ditetapkan 6 Juli 2022) Pasal 30 ayat (3) mewajibkan perjanjian bank dengan penyedia jasa TI memperhatikan paling sedikit 9 butir, huruf a sampai i. Tak satu pun dari kesembilan butir itu menyebut SLA. SLA masuk lewat jalur lain: Pasal 30 ayat (5) huruf c tentang penilaian kinerja, yang penjelasannya menyatakan "Perjanjian tingkat layanan dikenal dengan istilah service level agreement", dan PADK 1/2026 Lampiran I Bab V.B.3.a.5), yang menjadikan "jaminan tingkat pelayanan (Service Level agreement/SLA)" salah satu isi minimum perjanjian standar, termasuk saat terjadi perubahan kepemilikan. Pelanggaran Pasal 30 ayat (3) diancam sanksi di Pasal 33, sampai larangan menerbitkan produk baru.
Untuk asuransi dan multifinance, POJK 4/POJK.05/2021 (ditetapkan 9 Maret 2021) lebih langsung. Pasal 21 ayat (2) huruf h memuat 11 hal yang harus dipastikan dari penyedia, dan butir 10 adalah memenuhi tingkat layanan "sesuai dengan service level agreement". SEOJK 22/SEOJK.05/2021 (24 Agustus 2021) menambahkan bahwa SLA tetap berlaku bila kepemilikan berubah.
Pemetaan di bawah adalah bacaan kami atas kedua rezim, bukan teks OJK. Gunanya agar compliance bisa menunjuk satu pasal untuk tiap bagian jadwal SLA.
| Bagian jadwal SLA | Bank: POJK 11 / PADK 1/2026 | Non-bank: POJK 4 / SEOJK 22 |
|---|---|---|
| Target availability dan kinerja | Psl 30(5)c; PADK V.B.1.b, V.B.3.a.5, V.B.5.c | Psl 21(2)h.10; SEOJK 22 V.41.b.5.f |
| Laporan SLA bulanan | PADK V.B.3.a.6 | Psl 21(2)e |
| Notifikasi kejadian kritis | Psl 30(3)e; Psl 60(1)a; PADK V.B.3.a.11 | Psl 21(2)h.7; Psl 31 |
| RTO/RPO dan uji DR bersama | Psl 30(4)b; Psl 18(3); PADK IV.B.3.a.1)c)(4), IV.B.3.b | Psl 21(2)h.8; SEOJK 22 angka 39 |
| SLA tetap berlaku saat ganti pemilik | PADK V.B.3.a.5 | SEOJK 22 V.41.b.5.g(1) |
| Pengakhiran, termasuk atas perintah OJK | Psl 30(3)f; PADK V.B.3.a.14–15 | Psl 21(2)h.9 |
| Subkontrak (cloud, CDN) dengan persetujuan tertulis | Psl 30(3)d; PADK V.B.3.a.8 | Psl 21(2)h.6 |
| Akses OJK dan auditor ke bukti SLA | Psl 30(3)c, i; PADK V.B.3.a.9 | Psl 21(2)h.3–4 |
| Lokasi data, API, keamanan | Psl 30(4)c dan penjelasannya | Psl 21(2)h.5 |
Dua baris yang paling sering terlewat: subkontrak dan pengakhiran. Bila vendor aplikasi berjalan di atas cloud dan CDN pihak ketiga, Pasal 30(3)d meminta subkontrak itu disetujui bank secara tertulis. Dan kalau SLA vendor bergantung pada SLA hyperscaler, angka yang dijanjikan ke bank tidak bisa lebih tinggi dari rantai di bawahnya, kecuali arsitekturnya menambah redundansi. Pasal 30 ayat (4) huruf c juga menempatkan lokasi data dan API sebagai persyaratan keamanan yang dimuat dalam perjanjian.
Yang perlu dilakukan sebelum tanda tangan
Untuk Head of Digital: ubah setiap persen di draf SLA menjadi menit per bulan dengan tabel di atas, lalu tanyakan berapa menit pemeliharaan yang dikecualikan. Jika jawabannya lebih dari 240 menit per minggu, angka 99,99% di halaman depan tidak banyak artinya. Minta titik ukur dari sisi nasabah, pisahkan respons dari resolusi, dan kaitkan penalti dengan durasi, bukan dengan tagihan hosting.
Untuk compliance: pastikan setiap baris di tabel pemetaan punya klausul yang bisa ditunjuk, dan laporan SLA bulanan disimpan sebagai bukti penilaian kinerja menurut Pasal 30 ayat (5). Pasal itu bicara soal penilaian kinerja, jadi buktinya adalah laporan dan tindak lanjutnya, bukan kontraknya saja. Pemeriksa yang menemukan kontrak rapi tanpa satu pun laporan bulanan sedang melihat celah, bukan kepatuhan.
Penalti dan biaya SLA pada akhirnya masuk ke anggaran pengadaan; cara menaruhnya di harga perkiraan kami bahas di HPS adalah: menyusun HPS website dan aplikasi. Jika Anda sedang menyiapkan kanal baru, tim kami membangun aplikasi cloud native dan website untuk perusahaan, dan kami bisa membantu menyusun bagian teknis jadwal SLA bersama tim TI Anda.







