When GDPR reaches an SA company
GDPR does not stop at the EU border. Article 3(2) applies it to companies with no EU presence at all on two tests. The targeting test: you offer goods or services to people in the EU — shown by things like EUR pricing, EU-market landing pages or languages, EU customer references, or sales outreach aimed at EU markets. The monitoring test: you track the behaviour of people in the EU — behavioural analytics, tracking cookies, profiling of EU users inside your product. A website that is merely reachable from Berlin triggers neither; a Stellenbosch SaaS company running a paid pilot with a Dutch customer triggers the first, and its product analytics on that customer's users usually trigger the second.
Selling to EU businesses does not change the answer. GDPR protects natural persons, not companies — but a B2B SaaS contract still means processing the personal data of the customer's employees, end-users and contacts, so the regime applies to that processing just the same. The B2B/B2C split matters for marketing rules and contract structure, not for whether GDPR reaches you.
Once caught, Article 27 adds a structural obligation that surprises most SA founders: a non-EU company within Article 3(2) must designate, in writing, an EU representative established in a member state where its data subjects are — the local contact point for supervisory authorities and data subjects. There is an exception for occasional, low-risk processing without large-scale special-category data, but routine production processing of EU customer data rarely qualifies. The UK GDPR imposes a parallel UK-representative requirement for UK-facing sales.
The dual-regime mapping table
The regimes share DNA — POPIA was drafted with the EU framework in view — which is exactly why the differences are dangerous: they sit where you least expect them. This is the mapping that should sit behind every control in a dual-compliance programme:
| GDPR | POPIA | |
|---|---|---|
| Legal basis | Article 6 — six lawful bases: consent, contract, legal obligation, vital interests, public task, legitimate interests (with a documented balancing test). | Section 11 — a similar but differently-worded list: consent, contract, legal obligation, protecting the data subject's legitimate interest, public-law duty, legitimate interests of the responsible party or a third party. POPIA also protects juristic persons, which GDPR does not. |
| Consent standard | Freely given, specific, informed and unambiguous, by statement or clear affirmative action — pre-ticked boxes are invalid. Explicit consent for special-category data. | A voluntary, specific, informed expression of will (s 1). Section 11(2) puts the burden of proving consent on the responsible party. The standards converge in practice: build consent records to the GDPR bar. |
| Privacy notice content | Articles 13–14 are prescriptive: identity, DPO contacts, purposes and the legal basis for each, recipients, transfers and safeguards, retention periods, each data-subject right, the right to complain to a supervisory authority, automated decision-making. | Section 18 lists what must be supplied at collection: what is collected, the source where collected indirectly, the responsible party's identity, purpose, whether supply is voluntary or mandatory, cross-border intentions, and the rights of access, correction, objection and complaint. Less granular on legal basis and retention. |
| Data subject rights + deadlines | Access, rectification, erasure, restriction, portability and objection — answered within one month, extendable by two months for complex requests. | Access (s 23, via PAIA mechanics), correction and deletion (s 24), objection (s 11(3)) — answered within a "reasonable time". No portability right. Build the response pipeline to the one-month GDPR clock. |
| Breach notification | Article 33 — notify the supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk. Article 34 — notify data subjects where the risk is high. | Section 22 — notify the Information Regulator and affected data subjects "as soon as reasonably possible", subject only to the legitimate needs of law enforcement and prescribed-form requirements. No fixed hour-count — but no licence to wait either. |
| Cross-border transfers | Chapter V — adequacy decisions (Art 45), appropriate safeguards (Art 46: SCCs, BCRs), or narrow derogations (Art 49), plus transfer impact assessments after Schrems II. | Section 72 — transfers out of SA are prohibited unless a ground applies: a binding agreement or law giving substantially similar protection (including onward-transfer restrictions), data-subject consent, contract necessity, or the data subject's benefit. |
| Penalties | Article 83 — administrative fines up to the higher of €20 million or 4% of total worldwide annual turnover in the top band (€10m / 2% in the lower band). | Administrative fines up to R10 million, plus a narrow set of criminal offences (obstruction of the Regulator, account-number offences, breach of an enforcement notice) carrying fines or imprisonment. Smaller numbers — but a real enforcement regime. |
| Officer requirements | A Data Protection Officer only where Article 37 conditions are met: large-scale regular and systematic monitoring, large-scale special-category processing, or public authorities. | Every responsible party has an Information Officer — by default the head of the body — with section 55 and Regulation 4 duties, and the IO must be registered with the Information Regulator before taking up duties. There is no opt-out. |
For the POPIA baseline that sits under the right-hand column, see the firm's POPIA for tech companies guide.
Cross-border transfers both ways
An export SaaS business moves data in two directions, and each direction runs on a different statute. Inbound — EU customer data into SA: South Africa has no EU adequacy decision under Article 45, so the transfer from the EU customer to the SA provider needs an Article 46 safeguard. In practice that means the 2021 Standard Contractual Clauses — usually Module 2 (controller to processor), with the SA provider signing as data importer — annexed to the DPA, plus a transfer impact assessment examining SA law-enforcement access to data and the supplementary measures (encryption, access controls, challenge commitments) that answer it. Enterprise EU customers will send you their TIA questionnaire; having the answers pre-packaged is a sales asset, not just a compliance one.
Outbound — SA personal information to EU or US sub-processors: the moment your stack uses EU-region hosting, a US-hosted LLM API or any offshore analytics tool, POPIA section 72 governs. The workhorse ground is a binding agreement imposing protections substantially similar to POPIA's conditions, including onward-transfer restrictions — which is what a properly drafted sub-processor DPA delivers. Transfers to GDPR-bound EU recipients clear the "substantially similar" bar comfortably; US and other recipients need the contract itself to carry the weight. Consent and contract-necessity are the fallback grounds. Where your infrastructure choices interact with data-residency promises to customers, see cloud computing and data sovereignty.
Contracts: one DPA, two regimes
The Article 28 processor terms and the POPIA section 21 operator-agreement terms overlap around 80%: process only on documented instructions, confidentiality, security measures, sub-processor control, assistance with data-subject requests, breach notification, return or deletion on exit. Running two separate DPAs doubles the negotiation surface and guarantees drift — the better build is one DPA drafted to satisfy both regimes, with the differences handled deliberately. These are the clauses where the regimes diverge and the drafting has to do real work:
Definitions mapping
One clause translating the vocabularies: controller = responsible party, processor = operator, personal data = personal information. Without it, every obligation has to be written twice — with it, the Article 28 and section 21 terms read as one set.
Sub-processor consent mechanics
Article 28(2) requires general or specific written authorisation for sub-processors, with a right to object on general authorisation. POPIA is silent, so the contract does the work — adopt the GDPR mechanics for both regimes: maintained sub-processor list, advance notice of changes, objection window.
Audit rights
Article 28(3)(h) requires the processor to demonstrate compliance and allow audits and inspections. POPIA prescribes no audit right, so an SA-only DPA often omits it — a dual-regime DPA cannot. Audit-by-report (SOC 2 / ISO 27001) with an escalation to on-site audit is the standard middle ground.
Breach notification timelines
Article 33(2) requires the processor to notify the controller without undue delay; POPIA section 21(2) requires the operator to notify the responsible party immediately on reasonable grounds to believe personal information has been compromised. Hard-code a defined hour-window (24–48 hours is market) so the customer can hit its own 72-hour Article 33 clock.
International-transfer annexes
For EU/UK customer data the DPA annexes the 2021 SCC modules (and the UK Addendum or IDTA) with completed Annexes I–III; for SA personal information leaving the country, the DPA itself is drafted to qualify as the section 72 "binding agreement providing substantially similar protection". Two transfer engines, one document.
Liability allocation
Article 82 gives data subjects compensation claims against controllers and processors with joint-and-several exposure; POPIA section 99 gives data subjects a civil action against the responsible party without proof of intent or negligence. The cap, the carve-outs (data-protection breaches often sit at a super-cap), and the indemnity flow need to survive both regimes.
The stricter-standard playbook
Dual compliance does not mean running two programmes. It means one set of controls, each built to whichever regime is stricter on that control — so that the laxer regime is satisfied automatically. Neither regime is uniformly the strict one:
| Control | Stricter / unique | What you build |
|---|---|---|
| Breach notification deadline | GDPR | Run one incident playbook with a 72-hour regulator-notification SLA. A notification that satisfies Article 33 will comfortably satisfy section 22's "as soon as reasonably possible" — the reverse is not guaranteed. |
| Impact assessments | GDPR | Article 35 makes DPIAs mandatory for high-risk processing, with prior consultation where residual risk stays high. POPIA's regulations require the Information Officer to ensure a personal information impact assessment is done, but with far less prescription. Run Article 35-grade DPIAs firm-wide and let them satisfy both. |
| Records of processing | GDPR | Keep Article 30 records of processing activities for the whole business, not just EU-touching flows — they double as the evidence base for POPIA accountability and your PAIA manual. |
| Data subject request deadlines | GDPR | Answer every request — SA or EU origin — inside the one-month GDPR window. "Reasonable time" under POPIA is then never in issue. |
| Direct marketing | POPIA | Section 69 makes unsolicited electronic direct marketing opt-in across all electronic channels, with only the narrow existing-customer exception — and POPIA protects juristic persons, so B2B prospecting is squarely covered. EU e-marketing rules vary by member state. Run the marketing stack to the POPIA opt-in standard globally. |
| Prior authorisation | POPIA | Sections 57–58 require the Information Regulator's prior authorisation for listed processing — linking unique identifiers across purposes, criminal-behaviour and credit-reporting data, and transferring special or children's personal information to countries without adequate protection. GDPR has no general equivalent. Screen for the triggers: caught processing must pause until authorisation is granted. |
| Officer requirements | POPIA | Register the Information Officer with the Regulator (mandatory, every responsible party), then run the Article 37 test separately — most SA SaaS providers will not need a DPO, but the assessment should be documented. |
| Local representation | GDPR | Article 27 requires a written-mandated EU representative (and the UK GDPR a UK representative) for non-EU providers caught by Article 3(2), unless the occasional, low-risk processing exception applies. POPIA has no inbound equivalent. Appoint via a representative-service provider; publish the details in the privacy notice. |
Frequently asked
Does GDPR apply to my SA SaaS company?
It does if Article 3(2) reaches you: you offer goods or services to people in the EU (the targeting test — EUR pricing, EU-market language or content, EU customer logos, sales activity aimed at the EU), or you monitor the behaviour of people in the EU (tracking cookies, behavioural analytics, profiling of EU users). A merely accessible .co.za website is not enough — but the moment you sign an EU customer and process their users' personal data, you are inside the regime. POPIA continues to apply to you as an SA responsible party or operator regardless: the regimes stack, they do not displace each other.
Do I need an EU representative under Article 27?
If Article 3(2) catches you and you have no EU establishment, Article 27 requires you to designate in writing a representative in one of the member states where your data subjects are — the contact point for supervisory authorities and data subjects. The exception is processing that is occasional, does not include large-scale special-category or criminal data, and is unlikely to risk rights and freedoms — a bar most production SaaS processing of EU customer data will not fit under. The UK GDPR carries a parallel UK-representative requirement. Representative services run on annual subscription and the appointment belongs in your privacy notice.
Can I use one privacy policy for both POPIA and GDPR?
Yes, with care. The notice lists overlap heavily, but Articles 13–14 demand items POPIA does not (the legal basis per purpose, retention periods, the right to complain to a supervisory authority), and section 18 demands items GDPR frames differently (whether supply is voluntary or mandatory, the source of indirectly-collected information). The clean approach is one layered policy: a common core, plus an EU/UK addendum and an SA addendum carrying the regime-specific disclosures. One document, no contradictions, and each regulator finds what its statute requires.
Is South Africa "adequate" under the GDPR?
No. The European Commission has not issued an adequacy decision for South Africa under Article 45, so EU personal data cannot flow to an SA provider on adequacy alone. In practice every EU customer contract rests on the 2021 Standard Contractual Clauses — usually Module 2 (controller to processor) with the SA provider signing as data importer — plus a transfer impact assessment. POPIA's existence helps the assessment; it does not replace the SCCs.
Which breach deadline do we follow — 72 hours or "as soon as reasonably possible"?
Both — which operationally means one: build the incident-response plan to the 72-hour GDPR clock. Article 33 requires notification to the supervisory authority without undue delay and where feasible within 72 hours; section 22 requires notification to the Information Regulator and affected data subjects as soon as reasonably possible. A response capability that reliably hits 72 hours satisfies both regulators off a single playbook; one calibrated to "reasonable" SA timing risks blowing the EU deadline on the same incident.
Do I need both a DPO and an Information Officer?
You always need the Information Officer: POPIA gives every responsible party one by default (the head of the body, with power to delegate), and the IO must be registered with the Information Regulator before taking up duties. The DPO is conditional: Article 37 requires one only where core activities involve large-scale regular and systematic monitoring, large-scale special-category processing, or you are a public authority. Many SA SaaS companies need the IO and not the DPO — but document the Article 37 assessment, and nothing stops one suitably-skilled person holding both roles.
Does the UK count as a third regime after Brexit?
Functionally it is the same architecture with separate paperwork. The UK GDPR mirrors the EU GDPR — including the extraterritorial reach, the 72-hour breach clock and the representative requirement — but is supervised by the ICO, and transfers of UK data to SA need the UK IDTA or the UK Addendum to the EU SCCs rather than the EU SCCs alone. A well-built dual-compliance pack treats the UK as a configuration of the GDPR workstream: same controls, separate transfer annex, separate representative appointment.
What does POPIA + GDPR dual compliance cost?
From R18,000 for the dual-compliance pack: a dual-regime gap analysis and control mapping, one DPA satisfying Article 28 and section 21 with SCC and section 72 transfer annexes, a layered privacy policy, and the breach-response playbook built to the 72-hour standard. EU/UK representative appointments, transfer impact assessments for complex stacks, and prior-authorisation applications under sections 57–58 are quoted on scope.