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

# Peru Ley 29733 Data-Protection Rules

> How the consent, ARCO-rights, breach-notification, and register duties Peru's Ley 29733 and its 2021 security-measures reglamento place on you map onto Orbit's consent ledger, DSAR queue, and breach-incident register, and the MAS+STI operator posture for sends to +51.

# Peru Ley 29733 Data-Protection Rules

Peru has regulated personal data in private hands since the
**Ley 29733** (2011), read with its reglamento, the **Decreto Supremo
003-2013-JUS**, both overseen by the Dirección General de Protección
de Datos Personales of the Ministry of Justice and Human Rights, and
reinforced in 2021 by a security-measures reglamento
(D.S. 021-2021-JUS) that wrote breach notification and security
measures into law. The regime is consent-first marketing: processing
personal data for commercial purposes needs prior consent, and a
Peruvian mobile identifier used as a marketing destination is
personal data. On the telecom side, OSIPTEL supervises the market and
MAS+STI line authentication for origination defines the current
operator expectations on A2P traffic.

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
Peru and owns the legal position.

<Note>
  This page is documentation, not legal advice. Have Peruvian counsel
  confirm your consent posture, your consent-evidence trail, and your
  breach-notification timing before you rely on any mapping here.
</Note>

***

## The regime in one paragraph

Ley 29733 applies to anyone processing personal data of individuals
in Peru, regardless of where the processor sits. It requires prior,
express, informed, and unequivocal consent before processing —
silence and inaction do not constitute consent — with express
consent demanded for sensitive data; it limits processing to the
purpose named at collection; it grants the data subject the ARCO
rights (access, rectification, cancellation, opposition) with
statutory response windows; and it requires the breach-like duties
the security reglamento adds: security measures proportionate to the
risk and notification when an incident compromises encryption or
data integrity.

***

## Obligations → Orbit surface

| Ley 29733 duty | What it requires | Orbit surface |
| - | - | - |
| **Prior consent and purpose** | Consent before processing, for the named purpose; express consent for sensitive categories; silence never counts | The [consent ledger](/compliance/consent-management), whose `lawful_basis` and `purpose` fields carry the per-recipient claim |
| **ARCO rights** | Honour access, rectification, cancellation, and opposition requests inside the statutory windows | The [DSAR queue](/compliance/dsar): file every Peruvian request the day it arrives so the queue's audit trail is your ARCO evidence |
| **Security and breach notification** | Security measures proportionate to the risk; notification when an incident compromises integrity | The [breach-incident register](/compliance/breach-incident-register), which time-stamps detection, assessment, and notification |
| **Processor contracts** | Processors bound to the controller's instructions and to security obligations | The [Data Processing Agreement](/compliance/data-processing-agreement), which allocates controller and processor roles for the data Orbit processes on your behalf |
| **Transfers** | A lawful transfer basis where personal data leaves Peru | 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 Peru, and none
changes what the statute requires of you:

* **Consent-default policy `refuse` for Peru.** The
  [unknown-marketing policy](/compliance/consent-default-policy)
  decides what happens to a recipient with no recorded consent. Keep
  it at `refuse` for Peru-bound marketing; where Peruvian law demands
  prior consent, a fail-open default is the wrong posture.
* **Spanish opt-out aliases.** Peruvian 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 Peru at volume, set a Lima-local window
  deliberately; a 02:00 promo draws the complaint even where no
  statute fixes the hour.
* **Operator posture under OSIPTEL.** Peru operates no DLT-style
  statutory sender register; MAS+STI line authentication covers
  origination, and 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 ARCO 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 Peruvian promotional SMS assembles the posture
end to end:

<Steps>
  <Step title="Stamp the consent">
    Capture prior, purpose-bound consent for each +51 recipient and
    record it in the [consent ledger](/compliance/consent-management)
    with the purpose the notice named. An imported list with no
    consent trail is not a sendable list under Ley 29733, whatever
    the channel says.
  </Step>

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

  <Step title="Receive rights requests in the queue">
    A +51 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 ARCO
    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 a Dirección
    General inquiry reads as proof.
  </Step>
</Steps>

***

## Related references

* [Regional Posture Hub](/compliance/country-rules-directory) — the
  matrix this page is registered in.
* [Chile Ley 21.719 Data-Protection Rules](/compliance/chile-ley-21719-data-protection) —
  the Andean-pocket sibling mid-reform.
* [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 ARCO 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.