> ## 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.

# Chile Ley 21.719 Data-Protection Rules

> How the consent, data-subject-rights, breach-notification, and transfer duties Chile's Ley 19.628 and its successor Ley 21.719 place on you map onto Orbit's consent ledger, DSAR queue, and breach-incident register, and what the reform transition means for sends to +56.

# Chile Ley 21.719 Data-Protection Rules

Chile's data-protection regime is mid-transition. The
**Ley 19.628** (1999) on the protection of private life in respect of
personal data processing, with its reglamento, governed for twenty-five
years; the **Ley 21.719** (2024) replaces it with a modern statute: an
Agencia de Protección de Datos Personales, a mandatory breach-notification
duty, GDPR-aligned principles, and materially higher fines, brought in
over a staged entry-into-force for the private sector. Whichever text
governs a given send today, the operating posture is the same: Chilean
law treats consent as the default basis for processing personal data,
and commercial messaging to +56 identifiers sits squarely on that basis.

The framing throughout is tenant-owned: Orbit ships the surfaces (the
consent ledger, the DSAR queue, the breach-incident register, the
subprocessor registry) and your organization configures them for Chile
and owns the legal position.

<Note>
  This page is documentation, not legal advice. The Ley 21.719
  transition, while the agency and its reglamentos land, is exactly
  when to have Chilean counsel confirm your consent posture and your
  breach-notification timing before you rely on any mapping here.
</Note>

***

## The regime in one paragraph

Ley 19.628 requires consent before personal data is processed, limits
processing to the purpose stated at collection, and grants data
subjects access, rectification, cancellation, and opposition.
Ley 21.719 keeps that spine and adds express consent for sensitive
data, a duty to notify the agency and the affected subjects of
breaches that can significantly harm them, cross-border transfer
rules, and processor contracts. On the telecom side, SUBTEL oversees
the market; Chile runs no statutory sender-ID register of the DLT
kind, so alphanumeric sender acceptance for A2P traffic arrives at the
operator level, on the major carriers' own terms.

***

## Obligations → Orbit surface

| Chilean duty | What it requires | Orbit surface |
| - | - | - |
| **Consent and purpose** | Process only what the granted consent covers, for the purpose named at collection; express consent for sensitive categories | The [consent ledger](/compliance/consent-management), whose `lawful_basis` and `purpose` fields carry the per-recipient claim |
| **Data-subject rights** | Honour access, rectification, cancellation, and opposition requests inside the statutory windows | The [DSAR queue](/compliance/dsar): file every Chilean request the day it arrives so the queue's audit trail is your rights-response evidence |
| **Breach notification** (Ley 21.719) | Notify the agency and the affected data subjects of a breach likely to cause them significant harm | The [breach-incident register](/compliance/breach-incident-register), which time-stamps detection, assessment, and notification |
| **Security and processor oversight** | Security measures proportionate to the risk; processors bound by contract | The [Data Processing Agreement](/compliance/data-processing-agreement), which allocates controller and processor roles for the data Orbit processes on your behalf |
| **Cross-border transfers** | A transfer basis before personal data leaves Chile | The [DPA](/compliance/data-processing-agreement) plus the [subprocessor registry](/compliance/subprocessor-registry), which names where Orbit processes and whom it hands data to |

***

## Send-time posture

These are tenant-owned knobs. None defaults on for Chile, and none
changes what the statute requires of you:

* **Consent-default policy `refuse` for Chile.** The
  [unknown-marketing policy](/compliance/consent-default-policy)
  decides what happens to a recipient with no recorded consent. Keep
  it at `refuse` for Chile-bound marketing so only recipients with a
  stamped, purpose-bound consent record receive promotional traffic.
* **Spanish opt-out aliases.** Chilean recipients revoke in Spanish.
  Wire the Spanish stop family alongside STOP into your opt-out rules
  so a revocation texts in whichever language the recipient writes,
  and every alias lands in the same suppression ledger. The alias
  surface is the
  [opt-out keyword alias table](/compliance/opt-out-keyword-alias-table).
* **Recipient-local quiet hours, opt-in.** Recipient-timezone quiet
  hours are a tenant-owned control, default off and fail-open. If you
  send marketing to Chile at volume, set a Santiago-local window
  deliberately; a 02:00 promo draws the complaint even where no
  statute fixes the hour.
* **Sender identity at the operator level.** With no statutory
  register, carriers accept senders on their own terms: keep an
  identifiable sender with your KYC-backed brand identity on file,
  filed through
  [Sender-ID Registration](/compliance/sender-id-registration).
* **Suppression-ledger export backs rights evidence.** The
  [consent and suppression export](/compliance/consent-suppression-export)
  produces the ledger your counsel hands over when an opposition or
  cancellation request asks for proof.

***

## Worked configuration

A tenant launching Chilean promotional SMS assembles the posture end
to end:

<Steps>
  <Step title="Stamp the consent">
    Capture prior, purpose-bound consent for each +56 recipient and
    record it in the [consent ledger](/compliance/consent-management)
    with the purpose the notice named. Consent stamped without a
    purpose is not consent under either statute.
  </Step>

  <Step title="Set the send-time posture">
    Point the [unknown-marketing policy](/compliance/consent-default-policy)
    at `refuse` for Chile-bound traffic, wire the Spanish stop family
    into the [opt-out keyword alias table](/compliance/opt-out-keyword-alias-table),
    and set a Santiago-local quiet-hours window if you send at volume.
  </Step>

  <Step title="Receive rights requests in the queue">
    A +56 subject writes asking what you hold, what is wrong, what
    must be deleted, or that you stop. File it in the
    [DSAR queue](/compliance/dsar) the day it arrives and work the
    verb the subject asked for; the queue's trail is your response
    evidence.
  </Step>

  <Step title="Close the loop and export evidence">
    Confirm every cancellation and opposition lands in suppression
    before the next campaign, then pair the consent ledger's
    `lawful_basis` and `purpose` with the
    [consent and suppression export](/compliance/consent-suppression-export)
    so the assembled bundle, not the assertion, is what an agency
    inquiry reads as proof.
  </Step>
</Steps>

***

## Related references

* [Regional Posture Hub](/compliance/country-rules-directory) — the
  matrix this page is registered in.
* [Mexico LFPDPPP Data-Protection Posture](/compliance/mexico-lfpdppp-posture) —
  the LATAM sibling covering the ARCO-family regime next door.
* [Colombia Habeas Data + CRC Sender Rules](/compliance/colombia-habeas-data-rules) —
  the sibling for Ley 1581 de 2012.
* [Brazil LGPD + Anatel](/compliance/lgpd-brazil) — the LATAM
  data-protection posture this page family is modelled on.
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the queue
  every rights request flows through.
* [Data Processing Agreement](/compliance/data-processing-agreement) —
  controller/processor allocation and the transfer basis.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.