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

# Mexico LFPDPPP Data-Protection Posture

> How the privacy-notice, ARCO, consent, breach-notification, and transfer duties Mexico's LFPDPPP and the 2025 Ley General place on you map onto Orbit's DSAR queue, consent ledger, and breach-incident register, through the transition that absorbed INAI's functions on 11 February 2025.

# Mexico LFPDPPP Data-Protection Posture

Mexico regulates messaging to its residents on two tracks.
[Mexico NOM-184 Consent](/compliance/mx-nom-184-consent) covers the
SMS-marketing-consent track: the disclosure language a subscriber must
see before opt-in and the consent artifact carriers expect at
dispatch. This page covers the data-protection track: the
**Ley Federal de Protección de Datos Personales en Posesión de los Particulares**
(LFPDPPP), the private-sector statute governing how you
treat the personal data behind every +52 identifier, and the **2025
Ley General en Materia de Protección de Datos Personales en Posesión
de Sujetos Obligados**, which absorbed INAI's functions on 11
February 2025 and sets the enforcement picture during the reform
transition.

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

<Note>
  This page is documentation, not legal advice, and doubly so during
  the 2025 reform transition, when the enforcement body and the
  secondary reglamento are in flux. Have Mexican counsel confirm your
  aviso de privacidad, your ARCO response deadlines, and your
  breach-notification timing before you rely on any mapping here.
</Note>

***

## The regime in one paragraph

The LFPDPPP (2010) applies to private parties that process personal
data of individuals in Mexico, regardless of where the processor
sits. It requires a privacy notice (aviso de privacidad) at or before
collection, limits processing to the purposes the notice names,
requires express consent for sensitive data, grants data subjects the
ARCO rights (access, rectification, cancellation, opposition), and
mandates breach notification. The 2025 Ley General reorganised the
institutional side and absorbed INAI's functions on 11 February 2025.
The private-sector duties below did not change with that transition,
but the counterparty for complaints and guidance did, so cite the
current successor authority in any notice you publish, not the
pre-reform one.

***

## Obligations → Orbit surface

| LFPDPPP duty | What it requires | Orbit surface |
| - | - | - |
| **Aviso de privacidad** | A privacy notice naming the controller, the purposes, and how ARCO rights are exercised, provided at or before collection | Your privacy-policy posture plus the [Data Processing Agreement](/compliance/data-processing-agreement), which allocates controller and processor roles for the data Orbit processes on your behalf |
| **ARCO rights** | Honour access, rectification, cancellation, and opposition requests inside the statutory windows | The [DSAR queue](/compliance/dsar) and its SLA clocks: file every Mexican request so the queue's audit trail is your ARCO evidence |
| **Sensitive data and consent** | Express consent for sensitive categories; purpose limitation on everything else | The [consent ledger](/compliance/consent-management), whose `lawful_basis` and `purpose` fields carry the per-recipient claim |
| **Breach notification** | Notify data subjects, and the authority under the reglamento, without undue delay | The [breach-incident register](/compliance/breach-incident-register), which time-stamps detection, assessment, and notification |
| **Cross-border transfers** | A transfer basis (consent or an exception) before personal data leaves Mexico, with transfers disclosed in the notice | 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 Mexico, and none
changes what the statute requires of you:

* **The ARCO SLA clock is yours.** The DSAR tracker ships statutory
  clocks for the jurisdictions in its table (GDPR, CCPA/CPRA, LGPD,
  PDPA, PIPEDA, DPDP); Mexico is not among them. The absence is not an
  absence of duty: set your internal ARCO deadline with counsel, file
  every Mexican request in the queue, and work the queue against your
  clock. The queue gives you the trail; the deadline is operator
  discipline, not a platform-enforced countdown.
* **Consent-default policy `refuse` for Mexico.** The
  [unknown-marketing policy](/compliance/consent-default-policy)
  decides what happens to a recipient with no recorded consent. Keep
  it at `refuse` for Mexico-bound marketing so only recipients with a
  stamped consent record receive promotional traffic; that posture
  satisfies LFPDPPP consent and NOM-184 disclosure in the same move.
* **Spanish opt-out aliases.** Mexican recipients revoke in Spanish.
  Wire the local family, above all `ALTO`, into your opt-out rules
  next to STOP 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: with
  no window set, sends go out at any local hour. If you send
  marketing to Mexico at volume, set a Mexico City-local window
  deliberately; a 02:00 promo draws the complaint even where no
  statute fixes the hour.
* **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: who was suppressed, when, and
  by which alias or request.

***

## Worked configuration

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

<Steps>
  <Step title="Receive the ARCO request">
    A +52 subject writes asking what you hold (access), what is
    wrong (rectification), to be deleted (cancellation), or to stop
    (opposition). File it in the [DSAR queue](/compliance/dsar) the
    day it arrives, through operator intake or the self-service
    portal, with the requester's statement verbatim and your internal
    ARCO deadline noted from the start.
  </Step>

  <Step title="Act on the request in the queue">
    Work the verb the subject asked for: access runs the portability
    export, rectification runs the correction flow, cancellation runs
    the erasure lifecycle (cooling-off window, then scheduled
    hard-delete), and opposition lands in suppression. Amend the
    request record if the ask narrows after intake, so the trail
    matches what you did.
  </Step>

  <Step title="Export the evidence">
    Pull the request's audit trail and the recipient's consent and
    suppression rows through the
    [consent and suppression export](/compliance/consent-suppression-export),
    and pair them with the consent ledger's `lawful_basis`,
    `purpose`, and `consent_text_version` for that identifier. The
    assembled bundle, not the assertion, is what an ARCO response or
    a successor-authority inquiry reads as proof.
  </Step>

  <Step title="Close the loop with suppression">
    Confirm the cancellation or opposition outcome sits in
    suppression before the next campaign, so a deleted or revoked
    contact cannot re-enter a Mexican send via a later import.
    Verify with the consent lookup
    (`GET /compliance/consent/lookup?identifier=%2B525512345678&channel=sms`)
    that the record reads as revoked, and let the
    [NOM-184 gate](/compliance/mx-nom-184-consent) keep unconsented
    promotional sends out at dispatch.
  </Step>
</Steps>

***

## Related references

* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the queue
  and SLA clocks every ARCO request flows through.
* [Consent Management & Receipts](/compliance/consent-management) —
  the `lawful_basis` / `purpose` record contract.
* [Mexico NOM-184 Consent](/compliance/mx-nom-184-consent) — the
  SMS-consent sibling: disclosure language and the MX send gate.
* [Brazil LGPD + Anatel](/compliance/lgpd-brazil) — the LATAM
  data-protection posture this page is modelled on.
* [Data Processing Agreement](/compliance/data-processing-agreement)
  — controller/processor allocation and the transfer basis behind
  the aviso.


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