Your Website Is Hosted Overseas. That Is a Cross-Border Transfer.

General information, not legal advice, and not reviewed by a lawyer. Section 72 turns on the wording of your own supplier agreements and there is no published South African adequacy list, so check your contracts rather than relying on this page.

The transfer you did not know you were making

A customer fills in the contact form on your site. The submission lands on a server in Virginia, the notification goes through a mail provider in Colorado, a copy syncs to a CRM in Dublin, and your accountant can see it from a laptop in London.

That is four cross-border transfers of personal information, and section 72 of POPIA applies to every one of them. Nothing about it feels like an export. Nobody signed anything called a transfer agreement. But the section does not ask how it felt.

This is the condition most South African businesses have never looked at, precisely because it is invisible. You can read your POPIA obligations end to end, tick every box about notices and consent, and still be transferring personal information out of the country on a basis that does not exist.

What section 72 actually says

Section 72 sits under the heading "Transfers of personal information outside Republic". The rule is a prohibition with exceptions: you may not transfer personal information to a third party in a foreign country unless one of five things is true.

• 72(1)(a) — adequate protection. The recipient is subject to a law, binding corporate rules, or a binding agreement that provides an adequate level of protection. The section sets two tests for that: it must effectively uphold principles for reasonable processing substantially similar to POPIA's conditions, and it must include provisions for onward transfers that are substantially similar to section 72 itself.
• 72(1)(b) — consent. The data subject consents to the transfer.
• 72(1)(c) — the data subject's own contract. The transfer is necessary to perform a contract between the data subject and you, or to take steps at their request before entering one.
• 72(1)(d) — a contract in their interest. The transfer is necessary to conclude or perform a contract between you and a third party, where the contract is in the data subject's interest.
• 72(1)(e) — their benefit, consent impractical. The transfer is for the data subject's benefit, it is not reasonably practicable to obtain consent, and if it were, they would be likely to give it.

Section 72(2) then defines binding corporate rules as the internal policies of a group of undertakings governing transfers within that group, and defines a group of undertakings as a controlling undertaking and the undertakings it controls. That matters mainly to multinationals with a South African subsidiary.

Which gate are you actually standing in?

Here is where most compliance efforts go wrong. Businesses that think about section 72 at all tend to reach for consent, because consent feels like the familiar answer to every privacy question. For infrastructure it is close to the worst available option.

Consent under POPIA is voluntary, specific and informed, and it can be withdrawn. If your lawful basis for hosting a customer's record in Virginia is that they consented to it, then a withdrawal obliges you to stop, and you cannot stop, because the whole system runs there. A basis you cannot honour when it is invoked is not really a basis.

The gate almost every business is actually relying on, whether or not they know it, is 72(1)(a): a binding agreement with the recipient. That is a contract question, not a consent question, and it is one you can actually satisfy.

72(1)(c) is narrower than it looks. It covers transfers necessary to perform the contract with that data subject. Sending a delivery address to a courier abroad to deliver their parcel fits comfortably. Keeping your entire customer database on an offshore server because that is where you happen to host is not necessary to perform any individual customer's contract, and stretching the paragraph that far is not a position worth defending.

Access from abroad counts

A point that surprises people: a transfer does not require data to move. If personal information sits on a server in Cape Town but a support contractor in Manila can log in and read it, that is a transborder flow. The information has been made available to a person in a foreign country.

Practical consequences worth writing down:

• Offshore support, virtual assistants and outsourced bookkeeping are in scope even with local hosting.
• So is a developer overseas with production database access, which is a common arrangement for small South African sites.
• So is a foreign parent company whose staff can view the South African CRM.

If your web developer or agency holds credentials and is not in South Africa, that relationship needs the same treatment as the hosting itself.

Section 21 and section 72 are two different obligations

This is the distinction that saves the most confusion. Your cloud host, mail provider and CRM are almost certainly operators: they process personal information on your behalf and under your authority.

That triggers section 21, which requires a written contract obliging the operator to maintain the security safeguards in section 19 and to notify you immediately where there are reasonable grounds to believe personal information has been accessed by an unauthorised person.

Section 72 is a separate requirement about the same supplier. Section 21 asks whether they will keep it secure. Section 72 asks whether sending it to their country is permitted at all, and whether the protections travel with it when they pass it on to somebody else.

A data processing addendum that covers section 21 and says nothing about onward transfers has answered one of the two questions. The onward transfer limb of 72(1)(a) is explicit, and it is the limb that standard supplier paperwork most often omits.

What to actually do about it

None of this requires repatriating your infrastructure. It requires knowing what you rely on and having the paperwork match.

• List where personal information actually goes. Hosting, email, backups, CRM, analytics, payment processing, helpdesk, file storage, e-signature, accounting, and every human being with a login. Most businesses find twice as many as they expected.
• For each one, name the country and the gate. If the honest answer is "we never considered it", that is the finding, and it is better found by you than by the Regulator after a complaint.
• Get the agreement in place. Most large providers publish a data processing addendum you can accept. Read it for two things: whether it binds them to protection substantially similar to POPIA's conditions, and whether it controls what happens when they sub-process to somebody else.
• Check the sub-processor list. Reputable providers publish one. That list is the onward transfer you are agreeing to.
• Say so in your privacy notice. Section 18 requires telling people whether you intend to transfer information to a third country and the level of protection afforded. A notice silent on offshore processing is inaccurate for nearly every South African website. See how to write a POPIA privacy policy.

Two honest qualifications

First, there is no official South African list of countries with adequate protection. POPIA has no equivalent of the European adequacy decision, and the Information Regulator has not published one. So 72(1)(a) is assessed on the substance of the law or agreement, not by checking a country off a list. That is less certain than anyone would like, and it is a reason the contractual route is the practical one.

Second, comparisons to Europe only take you so far. The tests are similar in spirit, and a provider that takes GDPR seriously will usually have paperwork that does most of the work here. But POPIA's onward transfer wording is its own, and "we are GDPR compliant" is not by itself an answer to section 72. See POPIA vs GDPR for where the two diverge.

A short checklist

• Do you know every country your customer and employee data reaches?
• Have you named the section 72 gate for each provider, rather than assuming one?
• Are you relying on consent for infrastructure you could not switch off if consent were withdrawn?
• Does each provider agreement cover onward transfers, not just security?
• Do you have a section 21 written contract as well, for the same suppliers?
• Does anyone outside South Africa hold a login to a system containing personal information?
• Does your privacy notice tell people their information goes offshore?
• Have you looked at your analytics, which is a transfer most sites forget? See is Google Analytics POPIA compliant.

POPIA Ready generates a privacy policy that covers offshore processing, plus a PAIA manual and five other documents customised to your business, free to preview. The free checklist will show you what else is missing.

General guidance on South African law as at September 2026, not legal advice. Cross-border transfers turn on the wording of your specific supplier agreements, and a business moving significant volumes of personal information offshore deserves a professional opinion.