> ## 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 Korea PIPA + KISA Opt-Out Posture

> South Korea's Personal Information Protection Act (PIPA) and the KISA opt-out notice rules mapped to the consent ledger, the `080` free-to-reply withdrawal path, sender pre-registration, data-subject requests, and the recording-consent controls you configure on Orbit.

# South Korea PIPA + KISA Opt-Out Posture

South Korea (`KR`) shapes messaging along the same two axes you see in
Japan and Brazil: the **Personal Information Protection Act (PIPA)**,
enforced by the Personal Information Protection Commission (PIPC),
decides what you owe each `+82` recipient on consent, data-subject
rights, and overseas processing — while the **KISA opt-out regime**
(Korea Internet & Security Agency, via the mobile operators) decides
whether your SMS traffic delivers at all: sender pre-registration,
respect for `080` withdrawal numbers, and Korean opt-out keywords on
every marketing send. This page is the canonical South Korea reference
on Orbit — same role the [Brazil LGPD page](/compliance/lgpd-brazil)
and the [France rules page](/compliance/fr-marketing-sms-rules) play
for their markets.

<Note>
  Everything below is a **tenant-owned control**. Orbit ships the
  surfaces — the consent ledger, suppression and the opt-out keyword
  libraries, tenant-configurable quiet hours, sender-registration
  status, recording-consent enforcement — defaults-open; your
  organization configures them for South Korea. Compliance with PIPA,
  the KAKS (formerly KISA) standards, and carrier rules remains your
  responsibility, and the regulators and carriers enforce them
  regardless of what any toggle says.
</Note>

***

## 1. The KR route: sender pre-registration and the `080` opt-out path

Read the KR row of `GET /compliance/country-rules?channel=sms` (see
[Country Compliance Requirements](/compliance/country-requirements)).
The two entries you meet first:

| Rule         | KR value                      | What it means for you                                                                                                                                                                                        |
| ------------ | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Sender types | `alphanumeric` supported      | Alphanumeric sender IDs are accepted, but only once registered — see below.                                                                                                                                  |
| Registration | `required` (pre-registration) | Unregistered sender traffic is filtered at the carrier edge rather than delivered. The send-time gate holds KR until a registered sender is attached — unlike France's `recommended` level, this one blocks. |

Register the sender before any production traffic: the
[Sender-ID Registration](/compliance/sender-id-registration)
submit-and-track flow covers the pre-registration KR requires, and the
[send-gate surface](/compliance/send-gates) will refuse the country
otherwise. Budget lead time accordingly — pre-registration is not a
same-day operation.

### The `080` withdrawal number — Korea's version of FR's `STOP au 36111`

Korean marketing and ad-posting messages must give the recipient a
free-of-charge way to withdraw consent. The common form the operators
expect is a **toll-free `080`-series withdrawal number** (or the
carrier's equivalent short-code/unsubscribe link) printed in the
message footer — the analog of France's `STOP au 36111` requirement.
Strip the number and Korean gateways will start failing your
compliance checks.

What to do on Orbit:

* **Put the withdrawal path in every KR marketing template.** Add the
  `080` number (or your registered withdrawal link) as the last line of
  the template, the same way you would add `STOP` text for FR.
* **Wire inbound opt-out replies regardless of channel.** A recipient
  who replies `수신거부` / `중지` / `STOP` or calls the `080` number
  must write a suppression entry; see
  [Opt-Out & Suppression Lists](/compliance/opt-out-suppression).
* **Extend your keyword rules with Korean aliases.** The default alias
  vocabulary covers the canonical `STOP` family — see the
  [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
  — and you add Korean-language rows (`수신거부`, `중지`) yourself as
  custom rules; the policy-scanner's Korean `ko` bundle already knows
  the `중지` opt-out phrase for compose-time linting.

The opt-out suppression you receive through an `080` IVR is still
yours to record — the number is the path, the suppression entry is the
record, and the ledger is what survives an audit.

***

## 2. PIPA's marketing-standard consent form

PIPA is consent-first for promotional messaging, and its standard
consent form has fixed fields the PIPC checks for: the identity of the
collector, the purpose of collection, the data categories collected,
the retention period, and the data subject's right to refuse. For
messaging, map those fields onto the consent ledger before the first
marketing send:

| PIPA consent-form field                                | Consent-ledger field                                                   |
| ------------------------------------------------------ | ---------------------------------------------------------------------- |
| Collector identity / purpose                           | `purpose` + free-text on the record                                    |
| Data categories (phone number, name, purchase history) | `channels` (sms/whatsapp/rcs) + the `contacts` record                  |
| Retention period                                       | your tenant [Data Retention Policy](/compliance/data-retention-policy) |
| Right to refuse / withdraw                             | the opt-out + suppression surfaces (section 1)                         |

Record a KR marketing opt-in before dispatch with a
`lawful_basis` of `consent`:

```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": "+8210551234567",
    "channels": ["sms", "kakao"],
    "opt_in": true,
    "lawful_basis": "consent",
    "purpose": "KR marketing — promotional SMS/Kakao per PIPA standard form",
    "consent_text_version": "kr-pipa-standard-form-v3",
    "consent_proof_url": "https://signup.example.com/consent/evt_krp_4a"
  }'
```

For recipients with **no recorded consent**, your tenant-owned
[unknown-marketing policy](/compliance/consent-default-policy) decides
what happens — it defaults to `refuse` for marketing sends, which is
the correct default for Korea-bound promotional traffic. See
[Consent Management](/compliance/consent-management) for the record
contract, and the
[GDPR-style posture assembly model](/compliance/gdpr-posture-guide)
for the end-to-end pattern that transfers to PIPA.

KakaoTalk is the dominant messaging channel in Korea alongside SMS.
Alimtalk (template transactional) and Friendtalk (free-form to friends
of your channel) both carry the same PIPA consent rules — pick the
template in `pt`-equivalent code per message via
`metadata.kakao_message_type` and keep the consent record on SMS +
Kakao channels, not one. See the
[KakaoTalk channel page](/channels/kakao) and the
[Asia channels onboarding guide](/guides/asia-channels-onboarding).

***

## 3. Data-subject requests and the PIPA clock

PIPA follows Korea's data-subject request rules, and Orbit's DSAR
surface handles APAC regimes via the `pdpa` applicable-jurisdiction
family — the 30-day SLA applies to KR subjects, same as Singapore /
Thailand PDPA subjects (see
the jurisdiction table on the [DSAR page](/compliance/dsar)). Requests
arrive through operator workflows or the
[self-service portal](/guides/self-service-dsar-portal), and erasure
runs the lifecycle that page documents (cooling-off window, then the
scheduled hard-delete).

To handle Korea-bound subjects correctly:

1. **File with the right jurisdiction.** Set
   `applicable_jurisdiction: "pdpa"` on intake (or reclassify when a
   request arrives generically) so the 30-day APAC clock applies
   from the start.
2. **Erasure flows feed 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).
3. **The KR no-send gate respects the suppression.** Because KR is a
   `required` registration country, a send against a suppressed
   identifier fails the send-time gate — the suppression ledger and
   the [send-gates surface](/compliance/send-gates) work together.

***

## 4. PIPA and overseas processing — data localization

PIPA requires a **written record and consent-specific handling** when
Korean resident data is processed overseas, and certain regulated
verticals (financial services under KISA-adjacent guidance, health
data) impose localization duties beyond the general PIPA rule. Two
controls are relevant on Orbit:

* **Document the cross-border transfer posture.** Your
  [Data Residency Overview](/compliance/data-residency-overview) maps
  which surface answers which channel's residency question — voice is
  the one channel where you pin a resident region directly; SMS,
  Kakao, and the audit trail are covered by the platform geography
  Devotel publishes and your BYOK layer.
  For PIPA, that map is the record you show the PIPC when it asks
  where Korean person data lives.
* **Encrypt Korean-resident data with your own keys where you need a
  localization claim.** The
  [BYOK customer-managed keys](/compliance/byok-customer-managed-keys)
  surface lets you hold the encryption key for the tenant, which is
  the strongest localization posture available without an in-Korea
  region.

If your counsel determines your KR traffic falls under a strict
localization rule, treat that as the constraint that decides whether
you use Orbit for KR at all — this page describes the general PIPA +
KISA posture, not the supervised-sector carve-outs.

***

## 5. Recording consent for KR calls

Korea's Protection of Communications Secrets Act is one of the
**all-party-consent** regimes — every party to the call must consent
before a recording starts. Orbit resolves `KR` DIDs to the
`two_party_explicit` recording-consent mode automatically; turn
enforcement on for your tenant via Settings → Compliance → Recording,
and the voicemail + conference recording gate refuses to start a
recording without a captured consent receipt. See
[Recording Consent](/compliance/recording-consent). Combined with the
KR opt-out obligations above, this is the difference between an
enforced posture and a default-open one.

***

## Frequently asked questions

**Does Orbit register my Korean sender ID with the carriers?**
No — carrier-facing pre-registration is yours to file (or to file
through your aggregator), the same as every market. Orbit exposes the
KR country-rules row (`registration: required`) so you can confirm the
sender is attached, and it delivers your traffic once it is.

**Is the `080` number mandatory, or can I use a link instead?**
Korean operators and the KAKS standards accept either an `080`
toll-free withdrawal number or a compliant unsubscribe link, but every
marketing message must carry one. The in-template placement is your
obligation; Orbit records the resulting suppression either way.

**What clock does a PIPA data-subject request carry?**
30 days — Orbit files APAC regimes under the
`applicable_jurisdiction: "pdpa"` family, so reclassify with `pdpa`
and the SLA tracker applies the APAC clock. Remember opt-out
keywords in-market: a recipient's `수신거부` / `중지` reply must
write a suppression entry on every sender you run in Korea.

**Does the FR-style no-marketing-after-20:00 window exist for KR?**
Korea does not impose a federal SMS no-send window the way France does;
the practical restraint is carrier filtering and PIPA's purpose
limitation. Set tenant **quiet hours** deliberately for Korea-bound
marketing (recipient-timezone-resolved, +82 UTC+9) the same way you
would for FR — see
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) and the
[Quiet-Hours Preview](/compliance/quiet-hours-preview) surface.

***

<Warning>
  This page is documentation, not legal advice — an engineering map of
  the Orbit surfaces, not a legal opinion. PIPA, the KAKS/KISA opt-out
  standards, and carrier pre-registration carry real enforcement (PIPC
  fines, carrier-edge filtering, 080-number audits). Have counsel
  review your standard consent form, your template footers, and your
  overseas-processing posture before you send to Korean recipients.
</Warning>

***

## Related references

* [Country Compliance Requirements](/compliance/country-requirements) —
  the per-country matrix this page expands the KR row of.
* [Asia channels onboarding](/guides/asia-channels-onboarding) — the
  ordered playbook for KakaoTalk and the other APAC channels Korea
  uses.
* [KakaoTalk channel page](/channels/kakao) — Alimtalk vs Friendtalk
  and the `kakao_message_type` field.
* [Consent Management](/compliance/consent-management) — the consent
  record contract (`lawful_basis`, proof URL, text version).
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the
  erasure/portability surface where the APAC `pdpa` jurisdiction
  family and its 30-day clock live.
* [Opt-Out & Suppression](/compliance/opt-out-suppression) — how
  `080`-number opt-outs and Korean-language replies flow into
  suppression.
* [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
  — the canonical STOP aliases plus the `ko` bundle the policy
  scanner knows.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
  submit-and-track flow for KR pre-registration.
* [Data Residency Overview](/compliance/data-residency-overview) — the
  per-channel residency map PIPA's overseas-processing rules ask for.
* [Recording Consent](/compliance/recording-consent) — the
  all-party-consent enforcement KR shares with UAE and Turkey.