LFPDPPP and Mexico Data Privacy for Software Outsourcing

Mexico's LFPDPPP applies to far more than a vendor's production database. An outsourced software team can encounter customer and employee records, support tickets, logs, credentials, analytics, test data, repositories, candidate information, and data sent to cloud or generative-AI tools.

The buyer's task is to map each purpose, party, system, location, and onward provider. Processor status covers only activities performed on documented client instructions. A provider may follow client instructions for customer data while deciding its own payroll, billing, fraud-prevention, recruiting, or legal-claims processing.

This guide applies Mexico's current private-sector data-protection framework to software delivery. The primary sources were checked on August 13, 2026. The federal legal-order database still publishes the 2011 Regulation, but that text predates the 2025 replacement law. Confirm regulation-based controls against the current statute before relying on them.

The current Mexican privacy-law baseline

Mexico published a new Ley Federal de Protección de Datos Personales en Posesión de los Particulares on March 20, 2025. The previous 2010 statute was abrogated. The current text was amended on November 14, 2025 and assigns the federal functions identified in the law to the Secretaría Anticorrupción y Buen Gobierno.

The LFPDPPP protects personal data held by private parties and regulates legitimate, controlled, and informed processing. It is its own legal framework. Describing it as “Mexico's GDPR” invites mistakes about roles, rights, transfers, breach timing, regulators, and sanctions.

The law defines:

• a responsable as the private actor responsible for processing personal data;

• a persona encargada as a person or entity that processes personal data on the controller's behalf; and

• a transfer as communication of data to someone other than the holder, controller, or processor.

The Mexico outsourcing hub covers broader provider-selection factors; the privacy review here stays with data governance and evidence.

Start with exposure, not contract labels

When buyers compare software development companies, the same provider can create very different exposure across engagements.

Data minimization can remove entire legal and security workstreams. If engineers can reproduce a defect with synthetic data, do not copy a production dataset into a development environment.

Build a system-level data map

For every relevant system, record:

• data categories and affected people;

• collection source;

• business and technical purpose;

• controller, processor, recipient, and subprocessor roles;

• hosting, support, and access locations;

• users, privileges, and authentication method;

• transfers, remissions, and onward paths;

• retention, backup, legal hold, and deletion;

• incident owner; and

• evidence available at exit.

A questionnaire response alone is weak evidence. Match the map to repositories, cloud tenants, ticketing tools, analytics, observability, support consoles, and actual delivery-team access.

Determine privacy roles purpose by purpose

When outsourcing software development, one engagement can place the provider in different roles, depending on the purpose and data involved.

For example, a provider may remain a processor while handling support tickets on the client's instructions yet act as a controller if it reuses ticket data for its own analytics purpose.

Role and legal permission answer different questions. The role analysis identifies who decides the purpose and processing; the legal analysis establishes whether that processing is allowed. A data processing agreement documents the arrangement, while the controller's underlying permission comes from the applicable legal basis.

Principles, purposes, privacy notices, and consent

Articles 5–13 address lawfulness, purpose, fairness, consent, quality, proportionality, information, and accountability. The operational record should connect each data element to a disclosed and necessary purpose.

The privacy notice must cover the controller's identity and address, the data processed (including sensitive data), purposes, options to limit use or disclosure, the ARCO process, and how notice changes are communicated.

Consent is not the only possible route. Article 9 sets out exceptions, including processing required by law or needed to exercise rights or meet obligations arising from a legal relationship. Financial or patrimonial data generally requires express consent. Sensitive personal data requires express written consent unless a statutory exception applies.

The useful review is purpose-specific:

Do not collect data simply because a delivery tool can store it.

What the data-processing terms need to cover

Articles 50–51 of the published 2011 Regulation describe a processor that follows instructions, avoids unauthorized purposes, applies security, preserves confidentiality, deletes data when instructed or at the end of the relationship unless retention is required, and avoids unauthorized transfers. Because that Regulation predates the 2025 replacement statute, use its provisions only where they remain consistent with current law.

The processor relationship should be evidenced in a contract or other legal instrument that identifies its scope and content.

For software outsourcing, cover:

• subject matter, term, systems, data, and affected people;

• documented purposes and instructions;

• prohibited secondary use;

• confidentiality and authorized personnel;

• access, authentication, logging, secrets, and environment separation;

• secure development, testing, vulnerability, and remediation duties;

• subprocessors and cloud services;

• locations, remissions, transfers, and government requests;

• incident identification and escalation;

• ARCO and regulatory assistance;

• retention, return, deletion, and legal holds;

• audit, scoped evidence, and remediation;

• business continuity and recovery; and

• exit and downstream deletion.

The privacy terms and software outsourcing contract need the same systems, parties, acceptance process, and exit model.

Subprocessors need a current register

Articles 54–55 of that Regulation address controller authorization and equivalent duties for subprocessors. Maintain a register with:

Require advance notice of material changes and a right to object, remediate, or exit where the risk cannot be accepted. A usable register names the relevant legal entities, purposes, and locations.

Cloud and generative-AI tools need configuration evidence

Article 52 of that Regulation addresses cloud services offered on standard terms. For buyers assessing cloud computing providers, its controls include aligned privacy policies, subcontractor disclosure, no ownership claim over client information, confidentiality, notice of policy changes, limits on processing, security, deletion after recovery, and prevention of unauthorized access.

Generative-AI review should identify whether the delivery team sends any of the following to an external tool:

• source code and repository context;

• tickets, logs, or production errors;

• customer, employee, or candidate data;

• credentials, configuration, or architecture;

• prompts and outputs;

• telemetry or user identifiers; and

• evaluation or training data.

Across approved AI tools for developers, verify retention, model-training use, tenant isolation, support access, countries, downstream providers, deletion, and audit logs. “Enterprise AI” is a product label. The configured tenant and actual repository path are the evidence.

The buyer may prohibit personal data and secrets in consumer tools, allow approved enterprise tools for defined repositories, or require local models for certain work. Document the rule and test compliance.

Security evidence must match the engagement

Article 18 requires administrative, technical, and physical security measures based on risk, possible consequences for holders, data sensitivity, and technological development.

The review should follow the systems and team in scope:

A certificate can support this review, but it speaks only to the boundary for which it was issued. The buyer still needs evidence that the particular repository, cloud tenant, support system, or subprocessor chain falls inside that boundary.

The broader software outsourcing security guide provides the technical diligence framework.

Mexico's breach rule is not a generic 72-hour deadline

Article 18 requires security measures. Article 19 states that when a breach significantly affects holders' patrimonial or moral rights, the controller must inform affected holders immediately.

The current law contains no generic 72-hour notification rule, and Article 19 sets no general regulator-notification deadline.

The contract needs a much faster escalation path. If the provider waits until its own inquiry is complete, the controller loses the time needed to investigate the threshold, contain the incident, identify affected people, and prepare useful communication.

Define:

• immediate internal escalation for a suspected material event;

• a named 24/7 security contact and backup;

• the first report's minimum facts;

• evidence preservation and containment authority;

• staged updates as scope changes;

• decision authority for holder, customer, authority, insurer, and public communication;

• cooperation, forensics, and cost allocation; and

• a final record and remediation plan.

Articles 63–66 of the Regulation describe breach types, review steps, and notice content. Those provisions predate the 2025 statute; their application now depends on consistency with the current law.

Build for the four ARCO rights

The current LFPDPPP recognizes four ARCO rights:

1. access;

2. rectification;

3. cancellation; and

4. opposition.

Qualifying automated decision-making is addressed within opposition, one of the four ARCO rights.

The controller normally has up to 20 business days to communicate its determination. If the request is appropriate, it has another 15 business days to implement it. Each period can be extended once for an equal period when justified.

Article 29 requires a person or personal-data department to process holder requests without imposing the title “data protection officer” on every organization.

An outsourced-system workflow needs:

• intake and identity verification;

• search across live systems, archives, tickets, logs, repositories, and recipients;

• correction, cancellation, or opposition action;

• propagation to processors and other recipients;

• exception and retention analysis;

• response approval; and

• one case record containing the request, searches, decision, response, actions, and completion evidence.

The processor responds to a holder or authority on the client's behalf only when law or documented instruction authorizes it.

Transfers, remissions, and data location

Articles 35–36 govern transfers to third parties. The current official Regulation distinguishes controller-to-processor communications as remisiones, including international remissions.

Classify each external access by its actual route:

• exporting party;

• recipient legal entity;

• country;

• controller, processor, or third-party role;

• systems and data;

• purpose;

• onward path;

• applicable notice, consent, exception, and contract analysis; and

• return or deletion route.

The LFPDPPP does not impose a general rule that Mexican personal data must remain in Mexico; sector-specific laws or contractual obligations may set tighter location controls. Location still matters because it changes support access, onward providers, legal exposure, incident coordination, and exit.

“We comply with international transfer law” is not a mechanism. Name the actual route.

Retention follows purpose

Article 10 requires deletion after personal data is no longer necessary for disclosed purposes, subject to blocking and applicable retention. Its 72-month period applies specifically to data concerning breach of contractual obligations; other personal data follows its applicable purpose and retention basis.

Create a system-level schedule for:

• customer accounts and product records;

• support tickets and recordings;

• production logs and security evidence;

• repositories, branches, artifacts, and backups;

• applicant records and assessments;

• workforce, payroll, tax, and benefits records;

• model inputs, outputs, prompts, and evaluation data;

• legal holds and disputes; and

• returned, blocked, deleted, or retained data after exit.

Backups need an expiry and restoration rule. Deleting a live record while leaving it indefinitely restorable is not a complete retention process.

Sanctions depend on the violation category

Articles 58–60 provide warnings and UMA-based sanctions tied to specified violations. Article 59 includes ranges of 100–160,000 UMA for certain violations and 200–320,000 UMA for others, with an additional range for repeated violations and special treatment for sensitive-data infringements.

A single universal maximum misstates that structure. Actual treatment depends on the violation and statutory factors. A current peso conversion also needs the applicable UMA and a dated calculation.

The business exposure extends beyond an administrative sanction: incident response, affected-person support, contract claims, operational interruption, loss of access, remediation, and reputational impact can exceed the fine.

LFPDPPP delivery gates for software outsourcing

For nearshore software development in Mexico, use five decision points to tie the privacy review to delivery and software outsourcing onboarding.

The team moves to the next gate only after producing the required output.

Questions for a Mexico software outsourcing provider

When screening custom software development companies or planning to hire developers in Mexico through a provider, require answers against the proposed team, systems, and tenant:

• Which legal entities process our data, and for which purposes?

• Where do you act only on our instructions, and where do you decide your own purposes?

• Which repositories, environments, logs, tickets, and support systems are in scope?

• Which subprocessors and cloud services receive data or support access?

• Which countries are involved in hosting, support, administration, and incident response?

• Can our data, code, prompts, or outputs train a model or improve another service?

• Which privacy notice and consent or exception analysis covers each purpose?

• How quickly will you escalate a suspected incident?

• How will you support ARCO searches and actions across systems and recipients?

• What is retained at exit, why, for how long, and under whose control?

• Which security evidence applies to the exact team and tenant?

• How do you prove deletion from live systems, backups, and subprocessors?

The evidence should come from the proposed delivery configuration and its exact security boundary.