What Is Cloud Computing? What OJK Still Holds the Bank To

Cloud computing is "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources" that can be provisioned and released with minimal management effort. That is the NIST SP 800-145 definition (September 2011): five characteristics, three service models, four deployment models. For an Indonesian bank, POJK 11/POJK.03/2022 mentions cloud computing exactly once, and the sentence before it already settles the question: a bank that hands IT to a provider "remains the operator of the Electronic System".

This piece is about what happens after a channel moves to cloud. Which obligations move to the provider, and which evidence a bank, insurer or multifinance company still has to produce when the Financial Services Authority (OJK) examines it. Short answer: almost nothing moves. Every regulatory quotation below was read from the PDFs on ojk.go.id and peraturan.bpk.go.id on 21 October 2026. OJK publishes no official English text, so the Indonesian original is quoted and the English rendering is ours.

The NIST definition: three service models, four deployment models

Google's AI Overview for "what is cloud computing", fetched from Indonesia on 21 October 2026, lists four deployment types: public, private, hybrid and multicloud. NIST also lists four, but not those four. Multicloud isn't a NIST deployment model. The one the overview drops is community cloud: infrastructure shared by a group of organisations with a common concern, compliance requirements among them. We also checked the served page text of the five hyperscaler explainers on that page one (AWS, Google Cloud, IBM, Microsoft Azure, Oracle). None contains the phrase "community cloud". Which is odd, since it's the model closest to what a regulated sector actually needs.

• Service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS).
• Deployment models: private cloud, community cloud, public cloud, hybrid cloud.
• Essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.

For a regulated institution the taxonomy is a starting point and not much more. OJK uses only one of its axes, and it isn't the deployment model.

How often OJK regulation says "cloud"

We counted the terms across six instruments, using whole-word search over PDF text with normalised whitespace. The results:

The single mention in POJK 11 is not in the operative articles. It sits in the Elucidation to Article 29(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."

In English: an example of IT operated through a third-party IT service provider is the use of cloud computing as the bank's Data Center and/or Disaster Recovery Center. That's the whole treatment. POJK 11 never defines cloud; Article 1 defines only the Data Center, the Disaster Recovery Center and the Disaster Recovery Plan. For insurers and multifinance companies, which OJK groups as non-bank financial institutions (LJKNB), POJK 4/2021 and SEOJK 22/2021 don't mention cloud at all. It arrives through the generic term "IT service provider".

The practical consequence: no instrument distinguishes public, private or hybrid cloud. The obligations attach to the fact of outsourcing, not to the deployment model. A private cloud run by a third party is still outsourcing, and the examiner will ask for the same files.

OJK ranks IaaS, PaaS and SaaS by risk

The only service-model distinction anywhere in this body of regulation is in the Appendix to SEOJK 29/2022, parameter 1.5 of the bank's inherent cyber-risk assessment:

"Penggunaan cloud service memberikan risiko inheren yang lebih tinggi dibandingkan penggunaan penyediaan jasa teknologi non- cloud service."

Using a cloud service carries higher inherent risk than using a non-cloud technology provider. The worksheet in Appendix II scores it like this:

SEOJK 29 doesn't give its reasoning, but the order tracks how much of the stack the bank itself holds: on IaaS, the bank configures the operating system, the network and the access controls. The score feeds the bank's cyber-risk profile. Moving a channel from colocation to IaaS lifts that parameter by three steps, and the risk committee should see the number before it signs off the migration, not after.

The ten cloud controls the bank carries

SEOJK 29, Chapter IV, point 3.h requires adequate protection in arrangements with IT service providers, "termasuk dalam penggunaan cloud" (including the use of cloud). The detail is in Appendix I.c, control 2.h. This is the shared responsibility line drawn in OJK's own words:

1. logical access control to the bank's systems;
2. classifying the criticality and sensitivity of data stored in the cloud;
3. making sure the security settings that are the bank's responsibility are configured to standards and best practice;
4. bank staff able to configure security controls in the cloud;
5. using authorised cloud storage;
6. cloud traffic limited to the bank's business and operational needs;
7. cloud traffic restricted to IP addresses the bank recognises;
8. confirming the provider has implemented MFA;
9. confirming the provider has a geographically separate data recovery center, with documented RPO and RTO;
10. SSO access through an SSL VPN tunnel.

Eight of the ten are work the bank does itself. Only items 8 and 9 are checks on the provider.

Responsibility matrix: seven obligations that stay with the institution

Because the rules don't distinguish deployment models, all nine combinations (IaaS, PaaS, SaaS × public, private, hybrid) fall under the same articles. Only the SEOJK 29 score changes. The bank column cites POJK 11/2022 and PADK 1 of 2026 (in force 1 March 2026, replacing SEOJK 21/2017). The non-bank column cites POJK 4/POJK.05/2021 and SEOJK 22/SEOJK.05/2021.

Three rows get skipped most often. DRP testing: PADK 1 is explicit that where a bank uses an IT service provider, testing "juga perlu melibatkan pihak eksternal tersebut" (must also involve that external party), and the provider has to test its own DRP. The bank then uses the results to update its own plan. A hyperscaler's published resilience whitepaper is not that test. OJK access: POJK 11 Article 30(3)i requires the provider to agree to give OJK access for examination, and PADK 1 Chapter V C adds that an offshore provider "tidak boleh menghambat pengawasan atau pemeriksaan" (must not obstruct supervision or examination). Check that this clause is actually written into the provider's agreement, not only into the bank's internal policy. Exit: the Elucidation to Article 32(4)c asks the bank to make sure "semua data nasabah dan/atau calon nasabah telah dikembalikan atau dimusnahkan", that all customer and prospective-customer data has been returned or destroyed by the provider. For LJKNB, we searched POJK 4 and SEOJK 22 for "dikembalikan", "dimusnahkan" and "pengembalian data" (returned, destroyed, data return) and found none. A data-return clause still belongs in the contract, but the basis is prudence, not an article.

The testing schedule and incident-reporting flow are covered in ten types of cyber security and the evidence each one needs and in our penetration testing scope of work for banks. The data protection impact assessment for a cloud provider is in the DPIA guide under Article 34 of Indonesia's PDP Law. How to test a provider's certificate is in the four-column ISO 27001 certification check.

Data location: the freedom in PP 71/2019 and the financial-sector carve-out

Government Regulation (PP) 71/2019, enacted 4 October 2019, gives private-scope electronic system operators a free hand. Article 21(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."

Private-scope operators may manage, process and store electronic systems and data inside and/or outside Indonesia. Banks and insurers are private scope, because Article 2(5)a covers operators regulated or supervised by a ministry or agency. The conditions are only effective supervision (paragraph 2) and access (paragraph 3). Public-scope operators, by contrast, must store domestically under Article 20(2) unless the technology isn't available in Indonesia.

The freedom ends at Article 21(4): for private-scope operators "di sektor keuangan" (in the financial sector), the rules are set by the financial-sector regulator and supervisor. So there is no conflict of norms. PP 71 itself hands the question to OJK. OJK's answer for banks is POJK 11 Article 35(1): "Bank wajib menempatkan Sistem Elektronik pada Pusat Data dan Pusat Pemulihan Bencana di wilayah Indonesia", the bank must place its electronic systems in a Data Center and Disaster Recovery Center inside Indonesia. Offshore placement needs approval (paragraph 2), and the application has to meet Article 36, including a country-risk analysis and a statement that OJK's supervision will not be reduced. Article 39(1) adds that transaction processing also happens in Indonesia. A regional bank group running its Indonesian channel out of Singapore has an approval file to show for it, or a finding waiting.

For LJKNB, POJK 4 Article 22 tiers the obligation by total assets:

• up to IDR 500 billion: periodic backups are enough;
• above IDR 500 billion up to IDR 1 trillion: a Data Center plus backups;
• above IDR 1 trillion, or where the business is mostly IT-based: a Data Center and a Disaster Recovery Center.

Institutions that have a Data Center or DRC must place it in Indonesia, at separate sites "dengan memperhatikan faktor geografis" (with regard to geographic factors), and may move it offshore only with OJK approval (Article 23(1)–(3)).

The three hyperscalers' Jakarta regions, read 21 October 2026

Sources are each provider's own region pages: the AWS region list, Google Cloud regions and zones and the Azure region list. All three providers rank on page one for "what is cloud computing" in Indonesia. In the served text of their explainer pages, checked the same day, the word "Jakarta" appears zero times.

A domestic region answers Article 35(1). It doesn't answer provider assessment, OJK examination access or exit. And one question stays open. All three regions list every zone in Jakarta. Do several zones in one metropolitan area meet "geographically separate" (SEOJK 29 control 9) and "geographic factors" (POJK 4 Article 23(2))? Neither instrument sets a minimum distance. We found no OJK clarification on the point, so put the question to your supervisor before the DRC design is locked, rather than assuming the answer.

Cloud "disadvantages", read as risk the institution keeps

Google's own advantages of cloud computing page has a limitations section. It says migration problems come from not understanding "what security tasks remain the responsibility of the customer", then doesn't list those tasks. For an OJK-supervised institution, the three limitations cited most often already have articles attached:

• Vendor lock-in becomes an exit plan, a continuity review and a simulation test (POJK 11 Article 32(4)), plus the escrow and data back-up clauses from PADK 1's optional list.
• Less control over infrastructure becomes independent audit results (Article 30(3)c and 30(5)b) and OJK access (Article 30(3)i). Where supervision is obstructed, OJK can order the bank to stop using the provider before the contract ends, or bar a planned engagement (Article 32(3)).
• Provider outages become a DRP test at least once a year with the provider involved (Article 18(3)). Service credits don't cover a channel's losses. The arithmetic is in service level agreement: downtime minutes, cloud credits and the OJK clauses.

What this means for compliance, risk and internal audit

Before a channel moves to cloud, the files that should already be on the compliance desk are the seven rows of the matrix above, plus one that's easy to forget: the new SEOJK 29 parameter 1.5 score. "Public or private?" doesn't change the file list. "IaaS or SaaS?" changes the risk score, and decides how many of the ten cloud controls the bank's own team has to configure. For internal audit (SKAI), that second question is the one to ask first.

If the channel also handles customer onboarding, its vendor contract has a second layer: the vendor's contingency plan (data center, DRC, BCP and DRP) and a deadline for OJK access, as set out in AML/CFT in Indonesia: POJK 8/2023 for digital onboarding.

One disclosure. WEBARQ's documented cloud work is outside financial services. The Olaif case study (a consumer product) records a microservices application on Google Cloud Platform. We don't claim cloud, DR or compliance work for any bank, insurer or multifinance company. If your team is designing a channel architecture that will later have to be defended to OJK, see our cloud native application development service. This article was prepared with AI assistance from the primary regulatory texts cited above.