> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# South Africa POPIA Posture

> South Africa's Protection of Personal Information Act (POPIA) and the Electronic Communications and Transactions Act (ECTA) direct-marketing opt-out, mapped to the consent records, DSAR surface, sender registration, and quiet-hours controls you configure on Orbit.

# South Africa POPIA Posture

South Africa's data-protection regime for messaging traffic runs on
two laws, and operators usually meet the opt-out one first. The
**Electronic Communications and Transactions Act (ECTA)** gives every
recipient of a direct-marketing message the right to refuse further
sends, and the carriers enforce opt-out handling at the edge. The
**Protection of Personal Information Act (POPIA)**, enforced by the
Information Regulator, then defines what you owe the person behind
each +27 number — a lawful justification for processing, documented
consent, and a working data-subject-access process. This page maps
both to the Orbit surfaces you configure: consent records,
suppression, the DSAR workflow, sender registration status, and
tenant-configurable quiet hours.

<Note>
  Everything below is a **tenant-owned control**. Orbit ships the
  surfaces — consent records, suppression, the DSAR workflow,
  tenant-configurable quiet hours, sender registration status —
  defaults-open; your organization configures them for South Africa.
  Compliance with POPIA, ECTA, and carrier rules remains your
  responsibility, and the Information Regulator and carriers enforce
  them regardless of what any toggle says.
</Note>

***

## 1. Scope: which traffic touches POPIA

POPIA applies to the processing of personal information of natural
persons in South Africa. For messaging, that covers every channel
where the recipient's phone number is the identifier — SMS, WhatsApp,
and RCS. Voice calls to +27 recipients are personal-information
processing too, so the same consent and DSAR posture applies to
calling campaigns.

The lawful-basis and data-subject-rights obligations are
channel-independent. Pick a POPIA-compliant justification per
recipient first, then route the message over whichever channel your
sender readiness supports.

***

## 2. ECTA: direct marketing must offer a working opt-out

ECTA's direct-marketing provisions are the operating rule South
African carriers and recipients notice first:

* **Every direct-marketing message must carry opt-out instructions.**
  A marketing send without a way to refuse further messages is a
  violation before content review even starts.
* **Opt-out must be honored across all your senders.** A recipient who
  replies `STOP` on one sender must not receive marketing from another
  sender you run. Manage the opt-out keyword list and the suppression
  flow per tenant — see [Opt-Out & Suppression
  Lists](/compliance/opt-out-suppression) and the [opt-out keyword
  alias table](/compliance/opt-out-keyword-alias-table).
* **Suppression feeds every channel.** An opt-out outcome flows into
  the suppression ledger, so a suppressed contact does not re-enter
  marketing sends via a later import.

Treat opt-out handling as a sender-readiness requirement for any
marketing send to +27 recipients: unsure handling is deliverability
risk, not only legal risk.

***

## 3. POPIA lawful bases for messaging

POPIA does not require consent for every message, but it requires a
documented justification for processing each recipient's personal
information — and for direct marketing on electronic channels, ECTA
pushes that analysis toward opt-in (or the documented soft opt-in for
existing customers, which fails at the first refusal).

| Basis                           | When it fits                                                                                                                 | What you record                                                                 |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **Consent**                     | Promotional / marketing sends                                                                                                | An explicit opt-in captured per recipient, with the disclosure version they saw |
| **Legitimate interest**         | Service-adjacent messaging your interest test supports (order status, account alerts your customers would reasonably expect) | The documented justification, retained                                          |
| **Contract / legal obligation** | Strictly transactional traffic (OTP, appointment confirmation, mandated notifications)                                       | The contract or obligation the message serves                                   |

Whatever basis you rely on, stamp it on the consent record so the
claim survives audit. Orbit's consent surface carries
`lawful_basis` (`consent`, `legitimate_interests`, `contract`,
`legal_obligation`, `vital_interests`, `public_task`) alongside the
channels and the purpose:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "+27821234567",
    "channels": ["sms", "whatsapp"],
    "opt_in": true,
    "lawful_basis": "consent",
    "purpose": "Promotional messaging the recipient agreed to receive",
    "consent_text_version": "za-promo-v1",
    "consent_proof_url": "https://signup.example.com/consent/evt_8b21de"
  }'
```

Verify the record before a campaign with
`GET /compliance/consent/lookup?identifier=%2B27821234567&channel=sms`.

For contacts with **no recorded consent**, your tenant-owned default
decides what happens: the [unknown-marketing
policy](/compliance/consent-default-policy) defaults to `refuse` for
marketing sends. See [Consent
Management](/compliance/consent-management) for the record contract.

***

## 4. DSAR posture: access and deletion requests from South African subjects

POPIA gives data subjects access, correction, and deletion rights, and
the Information Regulator sets no short statutory response clock the
way Brazil's LGPD does — you answer within the period your own
privacy notice commits to. Orbit's DSAR surface handles the full
request lifecycle (access, portability, correction, erasure), and the
default `gdpr` jurisdiction applies a 30-day clock you can meet or
beat for South African subjects. See the jurisdiction table on the
[DSAR page](/compliance/dsar) — file South African requests on the
default jurisdiction, or track them alongside a tighter internal SLA.

Two practices filed correctly from day one save the most rework:

1. **Route erasure outcomes into suppression.** When an erasure
   completes, the outcome flows into suppression — so a deleted
   contact does not re-enter marketing sends via a later import. See
   [Opt-Out & Suppression](/compliance/opt-out-suppression).
2. **Register the processing line.** Your privacy register records
   which activities carry South African subject data; the DSAR tracker
   and the register together are the audit answer when the Regulator
   asks. See the [privacy register](/compliance/privacy-register).

***

## 5. Sender registration and route readiness

South African carriers filter unmanaged alphanumeric sender ids on
SMS, and the dependable A2P types are registered alphanumeric sender
ids and long numbers provisioned for A2P. Confirm South Africa's row
before a launch date depends on SMS — filter
`GET /compliance/country-rules` with `region=AF` to read the Africa
rows (`sender_types`, `registration`, `sender_rules`,
`content_restrictions`).

End-to-end sender-id onboarding is covered in the [sender ID
registration](/compliance/sender-id-registration) page and the
[country requirements](/compliance/country-requirements) reference.

***

## 6. Quiet hours and marketing windows

South Africa has no federal SMS quiet-hours statute comparable to the
US TCPA calling window; the restraint comes from carrier filtering,
ECTA's direct-marketing rules, and POPIA's minimality principle —
marketing at 03:00 is a complaint magnet even where no statute forbids
it. Orbit's enforcement layer is therefore yours to configure:

* Set tenant **quiet hours** for South Africa-bound marketing in the
  quiet-hours configuration (per-channel, recipient-timezone-resolved)
  — see [quiet-hours
  configuration](/guides/quiet-hours-configuration) and [campaign
  limits and quiet hours](/guides/campaign-limits-quiet-hours).
* Preview a window before a campaign with the [quiet-hours
  preview](/compliance/quiet-hours-preview) surface so the gate's
  decision on a given recipient/time is visible before the send.

Use the recipient timezone (Africa/Johannesburg) set deliberately per
campaign; the resolver maps the +27 country prefix unless you override
it. A deliberately chosen window is the difference between a
tenant-controlled posture and an accidental default.

***

## Frequently asked questions

**Does POPIA require opt-in consent for all marketing SMS?**
POPIA requires a documented justification; ECTA's direct-marketing
rules on electronic channels push that toward opt-in (or the soft
opt-in for existing customers, which fails at the first refusal). For
practical purposes, run marketing to +27 recipients on `consent` and
record it on the consent ledger.

**Is there a POPIA-specific response clock for access requests?**
No short statutory clock the way Brazil's LGPD (15 days) or GDPR
(30 days) sets. Orbit's DSAR SLA tracker applies the default
jurisdiction's 30-day clock; meet your own privacy notice's commitment
inside that.

**Does the Mexico-style country send gate exist for South Africa?**
No. South Africa enforcement on Orbit = the consent ledger + the
DSAR/erasure surface + tenant-configured quiet hours + your
suppression flow. Check the ledger before the campaign, not after.

**Which opt-out keywords should I accept?**
Accept the recipient-language keywords you actually run in market —
`STOP` at minimum, plus any alias your campaign language implies. The
opt-out keyword alias table maps them into suppression so one refusal
holds across every sender you operate.

***

<Warning>
  This page is documentation, not legal advice — an engineering map of
  the Orbit surfaces, not a legal opinion. POPIA and ECTA carry real
  enforcement (Information Regulator findings, carrier
  edge-filtering); have counsel review your
  lawful-basis choices, consent capture language, and opt-out wording
  before you send to South African recipients.
</Warning>

***

## Related references

* [Country Compliance Requirements](/compliance/country-requirements)
  — the per-country row contract behind `GET /compliance/country-rules`.
* [Consent Management](/compliance/consent-management) — the consent
  record contract (`lawful_basis`, proof URL, text version).
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the
  access/erasure/portability surface and its jurisdiction clocks.
* [Opt-Out & Suppression](/compliance/opt-out-suppression) — how
  opt-out and erasure outcomes flow into suppression.
* [Opt-out keyword alias table](/compliance/opt-out-keyword-alias-table)
  — map recipient-language refusal keywords into one suppression flow.
* [Quiet-hours configuration](/guides/quiet-hours-configuration) —
  tenant-controlled marketing windows.
* [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide)
  — the model for assembling a jurisdiction posture end to end;
  transferable to POPIA with the bases above.