Cloud computing adalah model penyediaan sumber daya komputasi (jaringan, server, penyimpanan, aplikasi, layanan) yang diakses lewat jaringan sesuai kebutuhan, lalu disediakan dan dilepas dengan cepat dan dengan upaya pengelolaan minimal. Begitu definisi NIST SP 800-145 (September 2011): lima karakteristik, tiga model layanan, empat model penerapan. Bagi bank, POJK 11/POJK.03/2022 hanya sekali menyebut komputasi awan. Kalimat sebelumnya sudah memuat seluruh jawabannya: bank yang menyerahkan TI ke penyedia jasa "tetap bertindak sebagai penyelenggara Sistem Elektronik".
Artikel ini membahas apa yang terjadi setelah channel pindah ke cloud. Kewajiban mana yang ikut pindah ke penyedia, dan bukti apa yang tetap harus dipegang bank, asuransi atau multifinance saat diperiksa OJK. Jawaban singkatnya: hampir tidak ada yang ikut pindah. Semua kutipan regulasi dibaca dari PDF ojk.go.id dan peraturan.bpk.go.id pada 21 Oktober 2026.
Definisi NIST: tiga model layanan, empat model penerapan
Penjelasan populer biasanya berhenti di tiga model penerapan: public, private dan hybrid. NIST menulis empat. Yang tertinggal adalah community cloud, yaitu infrastruktur yang dipakai bersama oleh sekelompok organisasi dengan kepentingan yang sama, misalnya persyaratan kepatuhan. Untuk sektor keuangan, justru model inilah yang paling dekat dengan kebutuhannya.
- Model layanan: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS).
- Model penerapan: private cloud, community cloud, public cloud, hybrid cloud.
- Lima karakteristik: layanan mandiri sesuai permintaan, akses jaringan luas, penggabungan sumber daya, elastisitas cepat, layanan yang terukur.
Untuk institusi keuangan, taksonomi ini cuma titik berangkat. OJK hanya memakai satu sumbu darinya, dan sumbu itu bukan model penerapan.
Berapa kali regulasi OJK menyebut cloud
Kami menghitung istilahnya di enam instrumen dengan pencarian per kata utuh atas teks PDF yang spasinya sudah dinormalkan. Hasilnya:
| Instrumen | "komputasi awan" / "cloud computing" | "cloud" (kata utuh) | IaaS / PaaS / SaaS |
|---|---|---|---|
| POJK 11/POJK.03/2022 (bank) | 1 / 1, kalimat yang sama | 1 | 0 |
| PADK 1 Tahun 2026 (bank) | 0 / 0 | 0 | 0 |
| SEOJK 29/SEOJK.03/2022 (bank, siber) | 0 / 0 | 20 | 2 kali masing-masing |
| POJK 4/POJK.05/2021 (LJK nonbank) | 0 / 0 | 0 | 0 |
| SEOJK 22/SEOJK.05/2021 (LJK nonbank) | 0 / 0 | 0 | 0 |
| PP 71/2019 (PSTE) | 0 / 0 | 0 | 0 (teks OCR) |
Satu-satunya penyebutan di POJK 11 tidak ada di batang tubuh. Letaknya di Penjelasan Pasal 29 ayat (1):
"Contoh penyelenggaraan TI yang menggunakan pihak penyedia jasa TI antara lain penggunaan komputasi awan (cloud computing) sebagai Pusat Data dan/atau Pusat Pemulihan Bencana Bank."
Hanya itu. POJK 11 tidak mendefinisikan cloud; Pasal 1 hanya mendefinisikan Pusat Data, Pusat Pemulihan Bencana dan Rencana Pemulihan Bencana. Bagi perusahaan asuransi dan multifinance, POJK 4/2021 dan SEOJK 22/2021 sama sekali tidak menyebut cloud. Cloud masuk lewat istilah umum "pihak penyedia jasa TI".
Akibatnya praktis: tidak satu pun instrumen membedakan public, private atau hybrid cloud. Kewajiban melekat pada fakta alih daya, bukan pada model penerapannya. Private cloud yang dikelola pihak ketiga tetap alih daya, dan pemeriksa akan menanyakan berkas yang sama.
OJK memeringkat IaaS, PaaS dan SaaS menurut risiko
Satu-satunya pembedaan model layanan dalam seluruh set regulasi ini ada di Lampiran SEOJK 29/2022, parameter 1.5 penilaian risiko inheren siber bank:
"Penggunaan cloud service memberikan risiko inheren yang lebih tinggi dibandingkan penggunaan penyediaan jasa teknologi non- cloud service."
Lembar kerja di Lampiran II memberi skor sebagai berikut:
| Penyelenggaraan pusat data | Skor risiko inheren |
|---|---|
| Tanpa penyedia jasa TI | 1 (Low) |
| Penyedia selain cloud service provider, mis. colocation | 2 (Low to Moderate) |
| Cloud berupa SaaS | 3 (Moderate) |
| Cloud berupa PaaS | 4 (Moderate to High) |
| Cloud berupa IaaS | 5 (High) |
SEOJK 29 tidak menulis alasannya, tetapi urutannya sejalan dengan porsi tumpukan teknologi yang dipegang bank: di IaaS, bank sendiri mengonfigurasi sistem operasi, jaringan dan kontrol aksesnya. Skor ini masuk ke profil risiko siber bank. Pindah dari colocation ke IaaS menaikkan parameter itu tiga tingkat. Menurut kami, komite risiko harus melihat angka ini sebelum menandatangani migrasi, bukan menemukannya di laporan profil risiko berikutnya.
Sepuluh kontrol cloud yang ditanggung bank
SEOJK 29 Bab IV angka 3 huruf h meminta pelindungan yang memadai dalam kerja sama dengan penyedia jasa TI, "termasuk dalam penggunaan cloud". Rinciannya ada di Lampiran I.c kontrol 2.h. Inilah garis tanggung jawab bersama dalam bahasa OJK sendiri:
- kontrol akses logis ke sistem bank;
- klasifikasi kekritisan dan sensitivitas data yang disimpan di cloud;
- memastikan pengamanan yang menjadi tanggung jawab bank sudah dikonfigurasi sesuai standar dan best practices;
- SDM bank yang mampu mengonfigurasi kontrol pengamanan di cloud;
- memakai authorized cloud storage;
- traffic cloud hanya untuk kebutuhan bisnis dan operasional bank;
- traffic cloud dibatasi ke alamat IP yang dikenal bank;
- memastikan penyedia sudah menerapkan MFA;
- memastikan penyedia punya data recovery center yang terpisah secara geografis, dengan RPO dan RTO terdokumentasi;
- akses SSO melalui tunnel SSL VPN.
Delapan dari sepuluh butir itu pekerjaan bank sendiri. Hanya butir 8 dan 9 yang berupa verifikasi atas penyedia.
Matriks tanggung jawab: tujuh kewajiban yang tetap di institusi
Karena regulasi tidak membedakan model penerapan, sembilan kombinasi (IaaS, PaaS, SaaS × public, private, hybrid) memakai pasal yang sama. Yang berbeda hanya skor SEOJK 29 tadi. Kolom bank merujuk POJK 11/2022 dan PADK 1 Tahun 2026 (berlaku 1 Maret 2026, mencabut SEOJK 21/2017). Kolom nonbank merujuk POJK 4/POJK.05/2021 dan SEOJK 22/SEOJK.05/2021.
| Kewajiban | Bank umum | Asuransi, multifinance (LJKNB) |
|---|---|---|
| Penilaian penyedia | POJK 11 Pasal 29(2)–(3), 30(2), 31; PADK 1 Lamp. I Bab V B.2.b (13 butir uji tuntas, diulang berkala) | POJK 4 Pasal 21(2)d–e, 21(4); SEOJK 22 Bab V angka 41 b.6) (4 butir) |
| Isi perjanjian | POJK 11 Pasal 30(3)a–i (9 butir); PADK 1 Bab V B.3.a (16 baku, 8 opsional) | POJK 4 Pasal 21(2)h (11 butir), 21(3) tertulis; SEOJK 22 V.41.b.5) |
| Lokasi Pusat Data dan DRC | POJK 11 Pasal 35(1) di Indonesia; luar negeri dengan izin, Pasal 35(2) dan 36 | POJK 4 Pasal 22 (berjenjang menurut aset), 23(1)–(3) |
| Uji DRP/BCP | POJK 11 Pasal 18(3), minimal 1 kali setahun; 30(4)b; PADK 1 Bab IV B.3.b libatkan penyedia | POJK 4 Pasal 16(3)–(5), berkala; SEOJK 22 V.39 libatkan penyedia |
| Audit dan akses OJK | POJK 11 Pasal 30(3)c, 30(3)i, 30(5)b; 32(3) | POJK 4 Pasal 21(2)f–g, 32(2) |
| Exit dan pengembalian data | POJK 11 Pasal 32(4)a–c; Penjelasan 32(4)c | POJK 4 Pasal 21(2)h.9, 21(11); tidak ada aturan eksplisit pengembalian data |
| Pelaporan insiden | POJK 11 Pasal 60(1): 24 jam, lalu 5 hari kerja; 32(2): 3 hari kerja | POJK 4 Pasal 31(2): 5 hari kerja; 21(6): 5 dan 10 hari kerja |
Ada tiga baris yang paling sering dilewatkan. Uji DRP: PADK 1 menegaskan bahwa jika bank memakai penyedia jasa TI, pengujian "juga perlu melibatkan pihak eksternal tersebut", dan penyedia wajib menguji DRP-nya sendiri. Hasilnya dipakai bank untuk memperbarui rencananya. Whitepaper ketahanan yang dipublikasikan hyperscaler bukan pengujian itu. Akses OJK: Pasal 30(3)i POJK 11 mensyaratkan kesediaan penyedia memberi akses pemeriksaan kepada OJK, dan PADK 1 Bab V C menambahkan bahwa penyedia di luar negeri "tidak boleh menghambat pengawasan atau pemeriksaan". Periksa apakah klausul ini benar-benar tertulis di perjanjian penyedia, bukan hanya di kebijakan internal bank. Exit: Penjelasan Pasal 32(4)c meminta bank memastikan "semua data nasabah dan/atau calon nasabah telah dikembalikan atau dimusnahkan" oleh penyedia. Untuk LJKNB, kami mencari "dikembalikan", "dimusnahkan" dan "pengembalian data" di POJK 4 dan SEOJK 22 dan tidak menemukan satu pun. Klausul pengembalian data tetap layak masuk kontrak, tetapi dasarnya kehati-hatian, bukan pasal.
Rincian jadwal pengujian dan alur pelaporan insiden sudah kami bahas di sepuluh jenis keamanan siber dan dokumen buktinya dan di checklist SoW pentest bank. Penilaian dampak pelindungan data untuk penyedia cloud ada di panduan DPIA Pasal 34 UU PDP. Cara menguji sertifikat ISO 27001 penyedia ada di uji sertifikat empat kolom.
Lokasi data: kebebasan PP 71/2019 dan aturan sektor keuangan
PP 71/2019 (ditetapkan 4 Oktober 2019) memberi kebebasan kepada penyelenggara sistem elektronik lingkup privat. Pasal 21 ayat (1):
"Penyelenggara Sistem Elektronik Lingkup Privat dapat melakukan pengelolaan, pemrosesan, dan/atau penyimpanan Sistem Elektronik dan Data Elektronik di wilayah Indonesia dan/atau di luar wilayah Indonesia."
Bank dan perusahaan asuransi termasuk lingkup privat, karena Pasal 2 ayat (5) huruf a mencakup penyelenggara yang diatur atau diawasi kementerian atau lembaga. Syaratnya hanya efektivitas pengawasan (ayat 2) dan akses (ayat 3). Sebagai pembanding, lingkup publik wajib menyimpan di dalam negeri menurut Pasal 20 ayat (2), kecuali teknologinya tidak tersedia di Indonesia.
Kebebasan itu berhenti di Pasal 21 ayat (4): ketentuan bagi lingkup privat "di sektor keuangan diatur lebih lanjut oleh otoritas pengatur dan pengawas sektor keuangan". Jadi tidak ada konflik norma. PP 71 sendiri yang menyerahkan pertanyaan ini kepada OJK. Jawaban OJK untuk bank ada di POJK 11 Pasal 35 ayat (1): "Bank wajib menempatkan Sistem Elektronik pada Pusat Data dan Pusat Pemulihan Bencana di wilayah Indonesia." Penempatan di luar negeri memerlukan izin (ayat 2), dan permohonannya harus memenuhi syarat Pasal 36, antara lain analisis risiko negara dan surat pernyataan bahwa pengawasan OJK tidak berkurang. Pasal 39 ayat (1) menambahkan bahwa pemrosesan transaksi juga dilakukan di Indonesia. Bank yang menjalankan channel Indonesianya dari region Singapura grup induknya harus bisa menunjukkan surat izin itu. Kalau tidak, itu temuan.
Untuk LJKNB, POJK 4 Pasal 22 membuat kewajibannya berjenjang menurut total aset:
- sampai Rp500 miliar: cukup rekam cadang berkala;
- di atas Rp500 miliar sampai Rp1 triliun: Pusat Data dan rekam cadang;
- di atas Rp1 triliun, atau yang kegiatan usahanya sebagian besar berbasis TI: Pusat Data dan Pusat Pemulihan Bencana.
Yang memiliki Pusat Data atau DRC wajib menempatkannya di Indonesia, di lokasi yang berbeda "dengan memperhatikan faktor geografis", dan hanya boleh ke luar negeri dengan persetujuan OJK (Pasal 23 ayat 1–3).
Region Jakarta tiga hyperscaler, dibaca 21 Oktober 2026
| Penyedia | Region | Zona | Lokasi tercatat |
|---|---|---|---|
| AWS | ap-southeast-3 | 3 AZ, opt-in wajib | Jakarta |
| Google Cloud | asia-southeast2 | 3 (a, b, c) | Jakarta |
| Microsoft Azure | indonesiacentral | 3 AZ, tanpa paired region | Jakarta |
Sumbernya halaman region masing-masing penyedia: daftar region AWS, region dan zona Google Cloud dan daftar region Azure.
Region domestik menjawab Pasal 35 ayat (1). Ia tidak menjawab penilaian penyedia, akses pemeriksaan OJK, atau exit. Dan ada satu pertanyaan yang masih terbuka: ketiga region mencatat semua zonanya di Jakarta. Apakah beberapa zona di satu wilayah metropolitan memenuhi syarat "terpisah secara geografis" (SEOJK 29 kontrol 9) dan "faktor geografis" (POJK 4 Pasal 23 ayat 2)? Regulasinya tidak memberi jarak minimum. Kami tidak menemukan penegasan OJK atas pertanyaan ini, jadi tanyakan ke pengawas sebelum desain DRC dikunci, jangan diasumsikan.
"Kekurangan cloud" dibaca sebagai risiko yang ditahan institusi
Halaman Google tentang keunggulan cloud punya bagian keterbatasan. Ia menyebut masalah migrasi datang dari ketidakpahaman soal "tugas keamanan apa yang tetap menjadi tanggung jawab pelanggan", lalu tidak merinci tugas itu. Bagi institusi yang diawasi OJK, tiga keterbatasan yang paling sering disebut sudah punya pasal:
- Vendor lock-in menjadi rencana exit, kajian kelangsungan dan uji simulasi (POJK 11 Pasal 32 ayat 4), ditambah klausul escrow dan back-up data dari daftar opsional PADK 1.
- Kontrol infrastruktur yang lebih sedikit menjadi hasil audit independen (Pasal 30 ayat 3 huruf c dan ayat 5 huruf b) dan akses OJK (Pasal 30 ayat 3 huruf i). Bila pengawasan terhambat, OJK dapat memerintahkan bank menghentikan penyedia sebelum kontrak berakhir, atau melarang rencana penggunaannya (Pasal 32 ayat 3).
- Gangguan layanan penyedia menjadi uji DRP minimal setahun sekali yang melibatkan penyedia (Pasal 18 ayat 3). Ganti rugi berupa kredit layanan tidak menutup kerugian channel. Hitungannya ada di SLA adalah: menit downtime, kredit cloud, dan klausul OJK.
Apa artinya bagi compliance, risk dan SKAI
Sebelum sebuah channel pindah ke cloud, berkas yang perlu sudah ada di meja kepatuhan adalah tujuh baris matriks di atas, ditambah satu hal yang sering terlupa: skor parameter 1.5 SEOJK 29 yang baru. Pertanyaan "public atau private?" tidak mengubah daftar berkasnya. Pertanyaan "IaaS atau SaaS?" mengubah skor risiko dan menentukan berapa banyak dari sepuluh kontrol cloud yang dikonfigurasi tim bank sendiri. Kalau SKAI hanya sempat mengajukan satu pertanyaan ke tim proyek, ajukan yang kedua.
Jika channel tersebut juga melayani onboarding nasabah, kontrak vendornya punya lapisan kedua: rencana kontinjensi vendor (pusat data, DRC, BCP dan DRP) dan tenggat akses bagi OJK, seperti kami uraikan di APU PPT adalah: syarat POJK 8/2023 untuk onboarding digital.
Satu pengungkapan. Pengalaman cloud WEBARQ yang terdokumentasi berada di luar sektor keuangan. Studi kasus Olaif (produk konsumen) mencatat aplikasi berarsitektur microservices di Google Cloud Platform. Kami tidak mengklaim pekerjaan cloud, DR atau kepatuhan untuk bank, asuransi atau multifinance mana pun. Bila tim Anda sedang menyiapkan arsitektur channel yang nantinya harus dipertanggungjawabkan ke OJK, lihat layanan pengembangan cloud native application kami. Artikel ini disusun dengan bantuan AI dari teks regulasi primer yang dirujuk di atas.







