Why South African data residency stopped being a checkbox in 2026

*The opening hospital scenario below is a composite, drawn from procurement-cycle interviews and Information Officer audit experiences across South African regulated sectors in late 2025 and early 2026. It does not describe a single named hospital group.*

Imagine a South African private hospital group running a vendor selection in March. The shortlist has four global backup platforms, all credible, all with strong feature parity, all priced within 20% of each other. The selection process moves through technical evaluation and into procurement. At procurement, the Information Officer asks one question that none of the four global vendors can answer cleanly: "If our patient data is subpoenaed by a foreign court without notice to us, what stops the vendor from complying?"

Three of the four vendors offer to add a data processing addendum with an "obligation to notify" clause. The Information Officer's outside counsel reviews the clauses and points out that an obligation to notify is not a defence — it is a courtesy. The actual question is about jurisdiction: which country's courts have legal authority over the keys that decrypt the hospital's data. The answer in all three cases is: not South Africa.

The fourth vendor — and a fifth that gets added late in the process — can answer differently. The hospital chooses the fifth.

This article is about why that question is now the procurement question for SA buyers in regulated sectors as of 2026, what POPIA actually requires, and what "SA residency" means once you look past the marketing slide.

Why residency stopped being a checkbox

For most of the last decade, "data residency" was a procurement preference. Buyers wanted their data near them for latency, for the optics of local hosting, sometimes for narrow regulatory reasons. The actual operational consequence was usually small. Most platforms could satisfy a residency clause with a flag that pinned a tenant to a regional storage cluster, and most buyers accepted that as sufficient.

Three things changed.

The first is the maturation of POPIA enforcement. The Information Regulator's office has been visibly active since its first R5-million administrative fine against the Department of Justice in mid-2023. The wave of enforcement notices through late 2025 — to OUTA, the State Security Agency, Kudung CPA, and Oceana — together with the Regulator's March 2026 priorities announcement and its explicit identification of health as a priority enforcement sector for 2026/27, has shifted SA compliance posture decisively. Information Officers have moved from compliance-by-attestation to compliance-by-evidence. They are now asked by their boards, their auditors, and their cyber-insurers to produce documentation about where data lives, not just claims that it lives somewhere acceptable.

The second is the proliferation of foreign legal-process risk. The CLOUD Act in the United States, comparable extraterritorial provisions in other jurisdictions, and the general expansion of cross-border legal compulsion have made it possible for a foreign court to compel a vendor to produce data even when the data is stored outside that jurisdiction. The strength of the compulsion depends on where the vendor — or its parent company — has legal presence.

The third is the cyber-insurance underwriting cycle. Insurers in 2026 are no longer satisfied with attestations of "compliance" as a checkbox. They want to know which party is the subject of compulsion if a court order arrives, and how the architecture of the data-storage stack constrains that. They have begun pricing risk based on the structural answer, not just the contractual one.

The convergence of these three pressures has turned residency from a marketing preference into a procurement requirement. The vendors who can answer cleanly are advancing. The ones who cannot are losing the late-stage selection conversations they used to win.

What the regulator actually asks for

Section 72 of POPIA is the cross-border transfer provision. It prohibits the transfer of personal information about a data subject outside South Africa unless one of five conditions is satisfied. The conditions allow transfer when:

(a) the recipient is subject to a law, binding corporate rules, or binding agreement providing protection substantially similar to POPIA; (b) the data subject consents; (c) the transfer is necessary for the performance of a contract between the data subject and the responsible party; (d) the transfer is necessary for the conclusion or performance of a contract concluded in the data subject's interest between the responsible party and a third party; or (e) the transfer is for the data subject's benefit, it is not reasonably practicable to obtain consent, and the data subject would likely consent if asked.

The honest reading of Section 72 is that it permits cross-border transfer in many ordinary commercial cases. It does not require physical residency. But it places the evidentiary burden on the responsible party — the SA company processing the personal information — to demonstrate that the transfer satisfies one of the five conditions.

The mechanics of demonstrating that have become the source of friction. An Information Officer asked at audit "where does this data go?" must produce a written record. The record has to identify the recipient country, the legal mechanism under which the transfer is permitted, the safeguards in place, and the evidence that those safeguards are operational. If the safeguards depend on the vendor's contractual undertakings, the record has to demonstrate that the undertakings are enforceable in practice — not just on paper.

This is harder than it sounds. A clause that obliges a vendor to notify the customer of foreign legal process can be rendered ineffective by a non-disclosure order from the foreign court. A clause that obliges the vendor to refuse to comply with foreign process is unenforceable if the vendor's parent company has legal presence in that jurisdiction. A "binding corporate rules" framework only applies if the vendor and the customer are in the same corporate group, which they almost never are.

The cleanest way to satisfy the Section 72 evidentiary burden for high-sensitivity data is to make the question moot — to keep the data, and the keys to the data, inside South Africa.

Where data lives, where keys live, where decisions live

There are three layers to the residency question, and the difference between them is what determines whether a residency claim actually answers what the regulator is asking.

The first layer is **storage residency** — where the bytes physically sit. This is the easiest to demonstrate and the most often marketed. A platform with an SA region can pin a tenant's storage to that region, and the location of the disks is verifiable.

The second layer is **key residency** — where the cryptographic keys that decrypt the storage actually live. This is the layer that determines whether storage residency is meaningful. Encrypted data in an SA region is mathematically inaccessible without the key. If the key is held by a vendor's central key management service in another jurisdiction, the storage residency is a comfort but not a guarantee. A foreign court compelling the vendor to release the key effectively defeats the residency claim.

The third layer is **operational residency** — who can make the decision to access the data. Even when storage and keys are local, a remote operations team with administrative privileges over the platform represents a potential channel for foreign legal compulsion. The party that can compel the operations team is the party that ultimately controls access. If the operations team reports through a foreign parent, the parent's jurisdiction is in play.

A complete residency answer addresses all three layers. Most marketing material addresses only the first.

POPIA Section 72 and the cross-border transfer test

Section 72 is often discussed as if it were a binary — transfer is either permitted or not. The reality is that the section creates a documentation burden that scales with risk.

Unlike the EU GDPR — which maintains a formal adequacy list — POPIA places the adequacy assessment squarely on the responsible party. The Information Regulator has indicated that a Guidance Note on Transborder Flows is forthcoming, but as of 2026 has not published an adequacy list. SA responsible parties typically rely on EU adequacy decisions and recognised data-protection regimes (UK, Switzerland, EU member states) as a starting reference, but each transfer requires its own documented analysis.

Where the receiving country does not satisfy the substantially-similar-protection test, responsible parties typically fall back to a written transfer agreement. POPIA itself does not name standard contractual clauses; SA practice often builds these agreements on EU SCC templates as a starting point, with POPIA-specific schedules added to extend protection to juristic persons (which POPIA covers but EU SCCs do not). The test is whether the agreement, in substance, provides protection substantially similar to POPIA's eight conditions — not whether it follows any particular template.

The weakness of the contractual-safeguard approach is that it depends on the vendor's contractual capacity to refuse foreign legal process. If the vendor is subject to foreign compulsion, the contract does not protect the data — it only obligates the vendor to apologise after the fact. The SA Information Officer who relies solely on contractual safeguards for high-sensitivity data is taking a position that may be defensible in litigation but does not give the regulator the comfort it is increasingly seeking.

The cleanest defence — for high-sensitivity data — is to keep the data, the keys, and the operational decisions in SA. Section 72 then does not engage at all, because there is no cross-border transfer to document.

What "SA-built" adds beyond SA-hosted

A platform can be hosted in an SA region without being built by an SA team. The distinction matters operationally and increasingly legally.

A foreign-headquartered platform with an SA hosting region typically has its product engineering, security operations, customer support, and incident response teams elsewhere. When an incident happens — a credential leak, a misconfiguration, a customer support escalation — the people resolving it are usually in the parent jurisdiction. Their access to customer data is governed by the parent's policies and subject to the parent's legal environment.

A platform built by a team in the same jurisdiction as the data and the customers has a different operational profile. Engineering decisions are made under the legal regime that governs the data. Security operations report through SA management. Incident response is handled by people who can be physically subpoenaed. The chain of operational decision-making does not cross a border.

This is not a claim that foreign-built platforms cannot be trusted. Many of them are excellent, and many SA buyers will reasonably choose them based on feature breadth, vendor stability, or commercial terms. The point is that the operational residency layer is real, and the SA buyer who is being asked by their regulator to demonstrate sovereign control over their data has an easier story to tell when the operational residency is local.

The mechanics: Azure Key Vault SA-North, Z1 Storage, SA workforce

The implementation answers the operational layer with three concrete commitments.

First, the platform's master encryption key is stored in **Azure Key Vault SA-North**, the South African Azure region (Johannesburg). The key is in a hardware security module (Managed HSM is FIPS 140-3 Level 3) under SA jurisdiction. Purge protection is enabled, which means the key cannot be permanently deleted within the retention window even by an authorised administrator. Per-tenant data encryption keys are derived from the master via HKDF, and the per-tenant keys never leave the platform's encryption boundary. A foreign court compelling the platform's parent company to release a key would be compelling the company to access an HSM that is not in the foreign court's jurisdiction.

Second, customer data — backups, audit chains, threat scan results, eDiscovery indexes — is stored on **Z1 Storage** in South Africa. Z1 is an SA-headquartered, SA-staffed S3-compatible storage provider with a Ceph-based architecture, an SA-resident operations team, and data centres in Johannesburg and Cape Town. The storage residency is verifiable; the operations team is local; the legal entity is SA-registered.

Third, the platform is **built and operated by an SA team**. Product engineering, security operations, customer support, and incident response are SA-resident. The legal entity that contracts with customers is SA-registered. Disputes are resolved under SA law. There is no parent company in another jurisdiction whose legal exposure can be propagated to customers.

The combination of these three commitments collapses the three-layer residency question into a single answer: the data is in SA, the keys are in SA, the people are in SA. Section 72 does not engage. Foreign legal process does not have an obvious channel. The Information Officer's audit response is short.

Cross-border data transfer when it actually has to happen

Some workloads do legitimately need to cross a border. A multinational customer with operations in multiple jurisdictions may need to share backup data with their headquarters team. A South African company that contracts with a global SOC may need its threat intelligence to flow outside SA. A regulator may request that data be produced to a foreign counterpart under a mutual legal assistance treaty.

For these cases the platform supports an explicit, audited, opt-in cross-border transfer flow. A transfer is initiated by an authorised user, recorded in the audit chain, and accompanied by a Section 72 documentation record that captures the recipient country, the legal mechanism (consent, contract performance, or other), the data scope, and the safeguards. The transfer is reversible — the recipient receives a time-bound, audit-logged copy, and the source of truth remains in SA.

The point is that cross-border transfer is something the platform makes the customer do consciously, with documentation, rather than something that happens by default because of where the platform's keys are kept. The default residency story is local; the cross-border story is explicit.

What this looks like at a regulator audit

An audit by the Information Regulator focuses on the responsible party's compliance with POPIA's eight conditions. Condition 7 — security safeguards — and Condition 8 — data subject participation — are the conditions where vendor architecture matters most.

The Regulator's auditor asks: where is the personal information stored? The answer is "Z1 Storage in South Africa" with a region attestation from the storage provider.

The auditor asks: who has access to the encryption keys? The answer is "the platform's master key is in Azure Key Vault SA-North under HSM custody; per-tenant keys are derived from the master and never leave the encryption boundary; no platform employee can decrypt a tenant's data without a platform-side audit-chained access event".

The auditor asks: under whose jurisdiction is the platform vendor? The answer is "Kapardyn (Pty) Ltd, SA-registered, governed by SA law".

The auditor asks: what happens if a foreign court orders the vendor to produce the data? The answer is "the vendor would receive the order, would assess it under SA law, would notify the customer where lawful, and would have no operational ability to comply because the keys are not in foreign jurisdiction and the operations team is not subject to foreign compulsion".

The auditor asks: what evidence supports these claims? The answer is the audit chain extracts, the destruction certificates, the key-access logs, and the residency attestations from Azure and Z1.

The audit moves to the next topic. The conversation is shorter than it would be with a foreign-hosted platform requiring the production of transfer impact assessments, parent-company indemnities, and contractual safeguard analyses. The compliance burden has shifted from documentation to architecture.

What this is not

It is not a claim that foreign-hosted platforms cannot be made compliant with POPIA. They can. It takes more documentation, more legal review, and more ongoing attestation, but it is achievable.

It is not a claim that data residency solves all sovereignty concerns. It does not. A platform that is fully SA-resident but poorly secured has worse outcomes than a foreign platform that is well-secured. Residency is one variable in the sovereignty equation, not the whole equation.

It is not a claim that SA buyers should always prefer SA platforms. There are reasons — feature breadth, vendor maturity, ecosystem fit, commercial terms — for buyers to choose foreign platforms. The right answer depends on the buyer's specific workload and risk profile.

It is a claim that for SA buyers in regulated sectors with high-sensitivity data, the residency question has stopped being a checkbox and has become a procurement gate. Platforms that can answer the question cleanly are winning the late-stage selection conversations they used to lose. As of 2026, the buyers asking the question are increasingly the ones with the largest budgets.

The hospital group from the start of the article completed its rollout earlier this year. The Information Officer's audit response for the new platform is one paragraph long. The previous platform's response was twelve pages, including a transfer impact assessment, a Section 72 attestation, and two pages of contractual safeguard analysis. The shorter response is not just a paperwork win. It is the operational consequence of architectural decisions that were made before any data was loaded — where the keys live, where the people are, which jurisdiction's courts can compel what.

For SA buyers who care about that question, the architectural answer is what matters. For everyone else, it is still worth understanding what the question is, because it is the question their auditor will ask next year.