Your Website Is Sending Customer Data Overseas

If your website runs Google Analytics, carries a Meta Pixel, sends its mailing list through Mailchimp or Brevo, is hosted anywhere other than South Africa, or forwards enquiry notifications to a Gmail address, it is transferring personal information outside the Republic. POPIA permits that, but only on one of a closed list of grounds set out in Section 72, and the responsible party remains liable either way. Most South African business websites are doing it. Very few have documented why they are allowed to.

This is not the exotic end of data protection law. It is the most routine thing a website does, and it is the compliance gap almost every POPIA checklist skips, because checklists stop at the privacy policy and the cookie banner. Section 72 sits underneath all of that and is far more likely to be the thing you cannot evidence.

This is an operational guide, not legal advice. For a formal opinion on your specific position, use an attorney with data protection expertise.

What Section 72 Actually Says

POPIA regulates cross-border transfer of personal information in a single provision. Section 72 prohibits a responsible party in South Africa from transferring personal information about a data subject to a third party in a foreign country unless one of a defined set of grounds applies.

The grounds, in practical terms, are these.

The recipient is subject to adequate protection. A law, binding corporate rules, or a binding agreement that upholds principles for lawful processing substantially similar to POPIA’s conditions, and that includes provisions substantially similar to Section 72 itself for any onward transfer. That last part is easy to miss and it means the protection has to follow the data if the recipient passes it on again.

The data subject consents to the transfer. Consent under POPIA is voluntary, specific and informed, which means a generic tick box agreeing to your terms is not it.

The transfer is necessary for performance of a contract between the data subject and the responsible party, or for pre-contractual steps taken at the data subject’s request.

The transfer is necessary for a contract concluded in the data subject’s interest between the responsible party and a third party.

The transfer benefits the data subject and it is not reasonably practicable to obtain consent, and if it were, they would probably give it.

In practice, most website transfers rely on the first ground, adequate protection through a binding agreement, which in commercial terms means the vendor’s data processing agreement. That is a reasonable position. It is only a defensible position if you have actually accepted that agreement, know what it says, and can produce it.

The Detail Most Guidance Gets Wrong

Two points separate a real understanding of Section 72 from a superficial one, and both have direct consequences for how a website is built and operated.

Access counts, not just storage

The intuitive reading of a cross-border transfer is data physically moving to a server in another country. That reading is probably too narrow, and this is worth stating carefully because it is not settled.

Section 72 has not yet been tested by the South African courts, and the Act does not define transfer. The prevailing view among South African data protection practitioners is that access and storage activities may both constitute transfers, which means allowing something to be read from outside the country may engage Section 72 even where nothing was deliberately sent anywhere. Cloud services are the obvious case, and firms advising on this treat cloud arrangements as carrying real Section 72 risk for exactly that reason.

Because it is untested, the sensible operating assumption is the cautious one. Treating offshore access as a transfer costs you a row in a spreadsheet. Treating it as outside the Act and being wrong costs considerably more.

Read that against how a typical website is actually operated and the scope becomes obvious. A developer in another country with WordPress administrator access can read every enquiry form submission in your database. An offshore support agent screen-sharing into your admin panel is doing the same thing. An analytics platform where a team abroad can view user-level data, and a backup replicating to an offshore region that nobody ever opens, both sit in the same category.

Hosting locally does not, by itself, resolve this. A South African hosted website with an offshore support arrangement and a US analytics platform is transferring personal information regardless of where the server sits.

POPIA protects companies, GDPR does not

This is the point that catches businesses who assumed their GDPR-compliant vendors had them covered.

POPIA’s definition of a data subject includes juristic persons. Company information is personal information under South African law. GDPR applies only to natural persons.

This is not a technicality. Section 72’s own wording requires the recipient’s protection to uphold principles substantially similar to POPIA’s conditions for lawful processing of information relating to a data subject who is a natural person and, where applicable, a juristic person. The adequacy test explicitly reaches company data.

The consequence is direct. A vendor’s standard European contractual clauses are drafted to protect the data of individuals. They are not drafted with the data of your business customers in mind, because in the jurisdiction they were written for, that data is not protected at all. South Africa is an outlier in extending protection to juristic persons, and practitioners advising on cross-border transfers flag precisely this: other jurisdictions are unlikely to have adequate standards applicable to company data, because they do not regulate it.

For a business to business operation this is the difference between an assumption and a gap. Your trade account records, procurement contacts, company registration numbers and account histories are all personal information under POPIA. If your only safeguard is a vendor’s GDPR-shaped agreement, you have safeguarded the individual contact names and arguably not the company records sitting alongside them.

Where the Transfers Actually Are

Most business owners will accept the principle and still not know where their own exposure sits. Here is the practical inventory for an ordinary South African business website.

Analytics. Google Analytics processes visitor data on international infrastructure. Identifiers, behaviour and approximate location, tied to a persistent identifier, is personal information.

Advertising and remarketing pixels. The Meta Pixel and Google Ads remarketing tags exist specifically to identify individuals across websites and send that to a foreign platform. This is the clearest transfer on the list and the one most often dropped into a website without a thought.

Email marketing platforms. Mailchimp, Brevo, MailerLite and their peers hold your subscriber list, which is names, email addresses, engagement behaviour and frequently more, on international servers.

Website hosting. Offshore hosting means your entire database, including every form submission and customer account, lives outside the country. Note also that many locally marketed hosting products run on international infrastructure underneath, so the question worth asking is where the data physically resides, not where the company invoices from.

Form notifications and business email. Enquiry notifications routed through Gmail or Microsoft 365 place the contents of every enquiry on foreign infrastructure. Almost nobody counts this and it is one of the largest volumes of personal information the average business moves.

CRM and support tools. Whatever your enquiries flow into next.

Payment gateways. Local gateways process locally, which is worth knowing. International gateways do not.

Backups. Frequently offshore, frequently in a different region from the primary hosting, and almost always forgotten in these assessments.

Chat widgets, booking tools, review platforms, heatmap and session recording tools. Session recording deserves specific mention: it captures what an individual did on your website in detail, which is among the most sensitive data an ordinary website collects, and it is usually installed by whoever set up the marketing.

Ten to fifteen distinct cross-border transfers is normal for a modest business website. Most owners, asked without warning, will name two.

The Operator Relationship Underneath It

Section 72 does not operate alone. Every third party processing personal information on your instruction is an operator under POPIA, and Section 21 requires a written contract with them obliging them to maintain appropriate security safeguards.

So for each of the transfers above you need two things: a lawful ground under Section 72, and a written operator arrangement under Section 21. In practice the vendor’s data processing agreement usually does both jobs, which is convenient, and is exactly why it matters whether you have actually accepted one.

The word that carries the weight throughout is accountability. The first condition for lawful processing makes you responsible for compliance across your operators, not just within your own business. You cannot outsource liability to a vendor. If your email platform mishandles your subscriber list, the Information Regulator’s counterparty is you.

What Compliance Actually Looks Like

This is achievable without a legal department. It is a documentation exercise more than a technical one.

Build a data flow inventory. One table listing every third party that touches personal information from your website. For each: what it collects, where that data resides, whether the vendor’s data processing agreement is in place and where the signed or accepted copy is, and which Section 72 ground you are relying on. This single document is the artefact that turns an assumption into a defensible position, and building it for an ordinary website takes an afternoon.

Accept the data processing agreements properly. Most major platforms make a DPA available, frequently requiring an explicit acceptance in account settings rather than applying automatically. Accepting it is a two minute task that nobody does. Do it, and save a dated copy.

Disclose the transfers in your privacy policy. POPIA requires disclosure of whether personal information will be transferred outside South Africa and what safeguards apply. Naming the categories of recipient and the countries involved is substantially better than a vague reference to third party service providers, and it costs nothing.

Reduce what you transfer. The strongest position is not transferring data you did not need. Turn off session recording you never review. Remove the remarketing pixel from a campaign that ended two years ago. Configure analytics to minimise what it collects. Every removed transfer is one you no longer have to justify, and most websites are carrying tools nobody has looked at since installation.

Control administrative access. Audit who holds WordPress administrator accounts, where those people are, and whether they still need it. Former developers with live credentials are both a security exposure and an undocumented cross-border transfer.

Decide deliberately about hosting. Local hosting reduces the surface, improves latency for South African visitors and simplifies the compliance story. It does not eliminate transfers on its own, but it is a meaningful reduction and it is a decision most businesses have never actively made.

The Regulatory Position Right Now

Some honesty about where this stands is more useful than false certainty.

The Information Regulator has been developing a Guidance Note on transborder flows of information under Section 72, covering the grounds for lawful transfer, and has been consulting counterpart authorities including the UK’s Information Commissioner’s Office and the EU. As at the Regulator’s 2025/26 Annual Performance Plan, presented to Parliament’s Portfolio Committee on Justice and Constitutional Development on 05/05/2026, that guidance note was described as being finalised rather than published.

So there is no South African adequacy list, no standard contractual clauses issued by the Regulator, and no template you can adopt and consider the matter closed. What exists is the statute, which is clear enough on the grounds, and legal commentary. Section 72 has also not been tested in court, so its practical boundaries are a matter of professional opinion rather than precedent.

That argues for doing the inventory now rather than waiting, for two reasons. The Regulator has moved from establishing frameworks to active enforcement, and it has signalled that its priorities include targeted assessments in high-risk sectors, naming banking and financial services, insurance and health, retail, and telecommunications and social media. If you operate in or supply into those sectors, the question is arriving.

The second reason is simply practical. A business that already knows its own data flows will be able to respond to the guidance note in an afternoon when it lands. A business that does not will be starting the discovery exercise under time pressure, which is when it gets expensive and when things get missed.

Why This Matters Beyond the Regulator

For most small and medium businesses, an administrative fine is not the realistic risk. Three other things are, and they arrive sooner.

Enforcement notices. The Regulator can require specific remedial action within a defined period. The expensive outcomes in South African enforcement to date have generally followed from ignoring an instruction rather than from the original failure.

Losing contracts. Larger clients increasingly run vendor due diligence that asks where their data goes. A professional services firm bidding for corporate work, or any supplier selling into a listed company, will be asked this question. Having the inventory is a commercial asset in that conversation, and not having it is a visible weakness.

Breach consequences. If an offshore platform holding your data is breached, you are the responsible party notifying the Regulator and the affected people. At that point, whether you had documented the transfer and the safeguards is the difference between a manageable incident and a compliance failure layered on top of a breach.

The Reframe

The instinctive reaction to Section 72 is that it is an obstacle to using normal tools. It is not, and reading it that way leads businesses either to ignore it or to overreact.

POPIA explicitly recognises the free flow of information across international borders as an interest worth protecting. Section 72 does not say keep the data in South Africa. It says know where it is going, make sure it is protected when it gets there, and be able to show your reasoning.

That is a governance standard, not a technical restriction, and it is one most businesses could satisfy this month with a spreadsheet and a few hours of attention. The reason so few have is not difficulty. It is that nobody has told them the transfers are happening at all, which is what this article exists to correct.

Frequently Asked Questions

Does POPIA allow me to use Google Analytics?

POPIA does not prohibit it. Analytics processes personal information on international infrastructure, which makes it a cross-border transfer requiring a lawful ground under Section 72, in practice usually the vendor’s data processing agreement providing adequate protection. You need to have accepted that agreement, disclose the transfer in your privacy policy, and be able to evidence both.

What counts as a cross-border transfer under POPIA?

Offshore hosting clearly does. Beyond that the position is less settled, because POPIA does not define transfer and Section 72 has not been tested in the South African courts. The prevailing practitioner view is that access and storage activities may both count, which would bring an offshore developer with administrator access, offshore support staff, international backups and analytics viewed from abroad into scope. The prudent assumption is that they do.

Does hosting my website in South Africa make me compliant?

It reduces the surface but does not resolve it. A locally hosted website still transfers personal information through analytics, advertising pixels, email marketing platforms, business email such as Gmail or Microsoft 365, and any offshore support or development access. Local hosting is a worthwhile decision for latency and simplicity, not a compliance conclusion.

Is a GDPR-compliant vendor automatically POPIA compliant?

No, and the gap matters for business to business operations. POPIA’s definition of a data subject includes juristic persons, so company information is personal information under South African law. GDPR applies only to natural persons, so standard European contractual clauses are not drafted with your business customers’ company records in mind.

Has the Information Regulator published guidance on cross-border transfers?

Not yet. As at the Regulator’s 2025/26 Annual Performance Plan, presented to Parliament on 05/05/2026, the Guidance Note on transborder flows of information under Section 72 was described as being finalised rather than published. There is therefore no South African adequacy list and no official standard contractual clauses. The statutory grounds in Section 72 apply in full in the meantime, so the obligation is current even though the guidance is not.

What is the practical first step to comply with Section 72?

Build a data flow inventory: one table listing every third party touching personal information from your website, what it collects, where that data resides, whether a data processing agreement is in place and where the copy is, and which Section 72 ground you are relying on. For an ordinary business website this takes an afternoon and converts an assumption into a defensible position.