Skip to main content

​
Mexico LFPDPPP Data-Protection Posture

Mexico regulates messaging to its residents on two tracks. Mexico 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.
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.

​
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

​
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 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.
  • 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 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:
1

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

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

Export the evidence

Pull the request’s audit trail and the recipient’s consent and suppression rows through the consent and 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.
4

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 keep unconsented promotional sends out at dispatch.