What Is a CDN? What a Bank May Cache at the Edge

A CDN, or content delivery network, is a network of edge servers that keeps copies of a site's responses and serves them from the location nearest the user. As of 23 October 2026, Cloudflare, Amazon CloudFront and Google Cloud CDN all list a point of presence (PoP) in Jakarta. For a bank, insurer or multifinance company, a CDN may store static assets and public pages. It may not store authenticated dashboards, APIs that return personal data, or OTP and session endpoints. Once the CDN decrypts TLS at the edge, its operator is, on our reading, processing customers' personal data within the meaning of Article 16(1) of Law No. 27 of 2022 on Personal Data Protection (UU PDP), enacted 17 October 2022.

This isn't another "what is a CDN" explainer. It's a decision list for the CTO choosing what goes behind the CDN, and for the DPO or CISO who has to defend that choice in front of an OJK examiner. It closes this week's cluster, after service level agreements: downtime minutes and the OJK clauses and what cloud computing leaves with a bank under OJK.

The cache-policy table: what a CDN may store for a bank channel

Five response classes cover almost everything a bank's digital channel sends. The headers below are WEBARQ's synthesis of RFC 9111, HTTP Caching (IETF Standards Track, June 2022), not a quotation from any single document. The s-maxage value in the second row is only an example; set it to how often that page actually changes.

Hashed assets are safe to keep for a year because every deploy produces new file names, so an old copy is never served in place of a new one. For public pages, s-maxage applies only to shared caches such as a CDN. Under RFC 9111 §5.2.2.10 it overrides max-age there, while the browser still revalidates every time.

The worst trap sits in the API row. RFC 9111 §3.5 forbids a shared cache from reusing a response to a request that carried an Authorization header, unless the response includes must-revalidate, public or s-maxage. A developer who adds public to a balance API "to make it faster" has just made that response shareable with other users. One word, one line of code.

Headers aren't enough

RFC 9111 itself says no-store "is not a reliable or sufficient mechanism for ensuring privacy." The reason is practical. Cloudflare's documentation (updated 14 September 2026) says it doesn't cache responses marked private, no-store, no-cache or max-age=0, responses carrying Set-Cookie, or non-GET requests, and that HTML and JSON aren't cached by default. All of that holds only "unless an Edge Cache TTL cache rule overrides the headers."

So the real control point is the CDN configuration, not the application's headers. Pin paths such as /api/* and the account area to a cache-bypass rule, and treat every cache-rule change as an approved change request, exactly as you would a firewall change. If we could keep only one control, we'd keep the bypass rule on the CDN. One rule in one console is easier to audit than header discipline across every application team.

The failure your compliance team will actually see is web cache deception. An attacker lures a logged-in customer to a URL such as /account/profile/x.css. If the edge caches by file extension and the origin ignores the trailing segment, the customer's profile page is stored at the edge and the attacker can fetch it. That's a personal-data breach, and Article 46(1) of UU PDP sets a notification deadline of 3 x 24 hours.

TLS at the edge makes the CDN a personal data processor

UU PDP never mentions CDNs, caching or TLS. What follows is our analysis, not the wording of the statute. Article 16(1) lists "storage" (point c) and "display, announcement, transfer" (point e) among the forms of processing. An edge node that decrypts a response and then stores or forwards it does both. Article 1(5) defines a Processor as a party that processes "on behalf of the Personal Data Controller". The bank is the Controller; the CDN operator is the Processor.

The consequences can be read off article by article:

• Article 51(1) and (3): the CDN processes on the bank's instructions, and that processing remains the bank's responsibility.
• Article 51(5): the CDN needs the bank's written approval before bringing in another processor.
• Article 51(6): processing outside the bank's instructions becomes the CDN's own liability.
• Article 52: the duties in Article 36 (confidentiality) and Article 39 (preventing unauthorised access) bind the CDN too.
• Article 37: the bank must supervise every party involved in processing, the CDN included.

Article 74 gave a two-year adjustment period from enactment, so on our count these duties have applied in full since 17 October 2024. Article 34(2) names "large scale" (point c) and "new technology" (point f) as triggers for an impact assessment, and a CDN in front of a bank's retail channel hits both. How to run one is in our guide to the data protection impact assessment under UU PDP Article 34.

Who holds the private key

There are three models to put to the vendor in writing: a certificate issued and managed by the provider, the bank's own certificate with its key uploaded to the provider, or a key that stays on the bank's infrastructure. The third model reduces the risk of a leaked key. It doesn't change the basic fact that after the handshake the edge still sees plaintext. The only way to keep a specific field unreadable at the edge is per-field encryption; CloudFront calls this Field-Level Encryption.

Contract clauses OJK already requires

The Elucidation of Article 29(1) of POJK 11/POJK.03/2022 (issued 6 July 2022) states that a bank "remains the Electronic System operator" even when it uses an IT service provider. A CDN is one of those providers. Article 30(3) requires the contract to include, among other things, a commitment to keep customer data confidential (point b), a reporting mechanism for critical incidents (point e), and inspection access for OJK (point i). Point d, written approval for subcontracting, is covered in our SLA and OJK clause article; it lines up with Article 51(5) of UU PDP.

CDN PoPs in Indonesia, read on 23 October 2026

This table is compiled from each provider's own network page, not from third parties.

The fact that matters most to a DPO is on Cloudflare's side. Regional Services (updated 1 July 2026) restricts which data centres may decrypt and inspect HTTPS traffic. The Asian regions on offer are India, Japan, Singapore, South Korea, Hong Kong and Taiwan. Indonesia isn't on that list; a custom region has to be arranged through the account team. So, as of this date, Cloudflare decryption can't be pinned to Indonesia from the standard menu, despite four PoPs in the country.

Google Cloud CDN says its cache resources are shared dynamically across the global edge network and that active PoPs "can change without notice". Jakarta on the list doesn't guarantee that a customer in Jakarta is served from Jakarta. For Akamai, the absence of a public list is itself a procurement finding: ask for PoP locations and decryption locations in writing.

If decryption happens outside Indonesia

On our reading, a decrypted response served from a Singapore PoP is a cross-border transfer of personal data under Article 56 of UU PDP. The bank must confirm that the receiving country offers equal or higher protection (paragraph 2); failing that, adequate and binding safeguards (paragraph 3); failing that, the customer's consent (paragraph 4). Paragraph 5 leaves the detail to a Government Regulation. We haven't confirmed whether that regulation has been issued, so check before relying on any of the three routes.

Article 35(1) of POJK 11 requires a bank's Electronic Systems to sit in a data centre in Indonesia, as our cloud computing article sets out. The part few people read is the Elucidation of Article 35(3) point d: a front-end system serving a global service is allowed, but the back end "that last processes individual, account and/or customer transaction data" must stay in Indonesia (our translation). It's the only place POJK 11 separates front end from back end, and it anchors our working rule: the edge may carry the front end, never the system of record. Whether a CDN PoP counts as a "Data Centre" under Article 1(4) has never been tested; the regulation doesn't mention CDNs.

For insurers and multifinance companies, the Elucidation of Article 23(4) point d of POJK 4/POJK.05/2021 (issued 9 March 2021) draws the same line. OJK's PADK No. 1 of 2026 (effective 1 March 2026) asks that any placement outside Indonesia still secure three things: confidentiality, integrity and availability; the bank's business continuity; and OJK supervision that is no less effective.

WAF and DDoS: what the edge closes, and what it doesn't

SEOJK 29/SEOJK.03/2022 (issued 27 December 2022) asks for web applications to be protected by a WAF running on all computing devices, and defines DDoS as an attack on availability. A CDN's WAF and DDoS absorption meet part of that, with two limits:

• An exposed origin bypasses all of it. If the origin IP is reachable directly, an attacker never has to pass the edge. The same SEOJK's appendix asks for cloud traffic to be restricted to IP addresses known to the bank. Here that means the origin accepts only the CDN's published IP ranges, ideally with authenticated edge-to-origin connections on top.
• A WAF doesn't replace authorisation. A well-formed API request for another customer's account passes the WAF. Access control is still the application's job; for open-banking APIs, see SNAP BI open API compliance evidence.

Availability: the CDN is also a point of failure

A CDN in the request path is one more dependency. If the CDN fails, the channel is down even with a healthy origin. The arithmetic is simple: two components in series at 99.9% each give 99.8% combined, about 86 minutes of downtime per 30 days rather than 43. The formula and the full minutes table are in our service level agreement article.

• Origin failover protects you from a dead origin, not a dead CDN. CloudFront describes it as a built-in ability to serve from a secondary origin.
• Multi-CDN protects you from a dead CDN, at the price of two cache configurations that must stay identical and two Processors under Articles 37 and 51 of UU PDP.
• stale-if-error (RFC 5861) only serves stale copies already stored when an error occurs. Per the table above, dashboards and APIs are no-store, so it rescues 0% of logged-in customer traffic. A CDN can keep the promotions page up while mobile-banking login is down.

Is a CDN safe for a bank?

Conditionally. Safe for static assets and public pages. Safe as a no-cache pass-through in front of authenticated channels, for WAF and DDoS, if five conditions hold: cache-bypass rules are locked under change control, the origin accepts only CDN IPs, the contract carries Article 30(3) of POJK 11, the DPIA is done, and the decryption location is confirmed in writing. Not safe if the CDN stores responses containing personal data, or decrypts outside Indonesia without an Article 56 basis.

Four common misconceptions about CDNs in a bank channel

1. "A CDN upgrades your site's TLS security." A CDN terminates the customer's TLS at the edge and opens a second connection to the origin. Two encrypted legs (if the origin leg is also TLS), plaintext in the middle.
2. "HTML is static." HTML can carry a customer's name and balance. Even Cloudflare doesn't cache HTML by default.
3. "Dynamic content can't be cached." Wrong in both directions. A personalised response can end up cached through misconfiguration, and a public page that changes often, such as a rupiah exchange-rate board, can be cached for a few seconds with s-maxage.
4. "100% SLA." Read the exclusions list. A figure without a measurement definition can't be claimed against.

For the CTO and CISO: the order of decisions before you sign

1. Classify every path into the five classes in the cache-policy table, and set the headers in code.
2. Lock cache rules on the CDN for API and account paths; changes go through a change request.
3. Get the vendor to name, in writing, the city where TLS is decrypted for Indonesian traffic.
4. Decide the private-key model and whether specific fields need per-field encryption.
5. Put the Article 30(3) POJK 11 items and Article 51 UU PDP into the contract, then run the DPIA.
6. Close the origin to the CDN's IP ranges, and test from outside that the origin refuses direct requests.
7. Calculate the combined availability of CDN and origin, then decide whether multi-CDN is worth its supervision cost.

Background on origin scalability is in cloud-native benefits for scalability and efficiency and what a cloud-native application is. If your channel is being redesigned, our team handles cloud-native application development and website development for corporate clients. This article was prepared by WEBARQ with AI assistance; every article of law, RFC and vendor page cited was read directly from its source, most recently on 23 October 2026.