Mexico software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Mexico, two sets of rules decide most of what your security programme has to prove. The first is data protection: a new Federal Law on the Protection of Personal Data Held by Private Parties (Ley Federal de Protección de Datos Personales en Posesión de los Particulares, LFPDPPP) was published in the Official Gazette of the Federation (Diario Oficial de la Federación, DOF) on 20 March 2025 and replaced the 2010 law, and protection of personal data is now the job of the Ministry of Anticorruption and Good Government (Secretaría Anticorrupción y Buen Gobierno), not the dissolved INAI. The second is financial supervision: the National Banking and Securities Commission (Comisión Nacional Bancaria y de Valores, CNBV) and the Bank of Mexico (Banco de México, Banxico) set the most detailed technical rules in the country, including immediate incident notice, two independent penetration tests a year for banks, remediation plans due in 10 business days, and a SPEI cybersecurity framework whose last phase took effect on 19 December 2025.

Above both sits a federal cybersecurity plan for 2025 to 2030 run by the Digital Transformation and Telecommunications Agency (Agencia de Transformación Digital y Telecomunicaciones, ATDT). It sets work for the federal public administration, but it is not a statute, and no general cybersecurity law is in force.

This guide reads each rule from its primary text where we could load it, maps it to the evidence a supervisor or auditor will ask for, and ends with a 30/60/90-day plan that works with whatever tools you already have. It is a practical reading of public documents, not legal advice. Where a rule needs interpretation for your entity, take it to counsel or to your supervisor.

Key takeaways

• Data protection changed authority, not direction. The 2025 LFPDPPP keeps the familiar duties (privacy notice, consent, ARCO rights, security measures, breach notice to data subjects, a person or department responsible for personal data). The Secretaría Anticorrupción y Buen Gobierno now holds the private sector data protection role, as its own site states.
• Banks run on CNBV clocks. Under the general provisions for credit institutions (Disposiciones de carácter general aplicables a las instituciones de crédito, often called the CUB), article 168 Bis 16 requires immediate notice to the CNBV of serious information security incidents, the Annex 64 and 64 Bis report within 5 business days, a remediation work plan within 15 business days of the incident ending, and customer notice within 48 hours when sensitive information was taken or altered.
• Banks must test and fix on a calendar. Article 168 Bis 12 asks for a vulnerability scanning calendar with quarterly reviews, scans before new components go live, two independent penetration tests a year, and remediation plans sent to the CNBV within 10 business days.
• Supplier work needs notice, and offshore work needs approval. Article 326 asks for notice to the CNBV 20 business days before contracting a third party to run an operational process or administer databases and IT systems. Article 328 requires CNBV authorisation when such services run partly or wholly outside Mexico.
• SPEI participants follow Banxico's rule 58a. Circular 12/2023 rewrote the security requirements in Circular 14/2017, phasing them in on 19 December 2023, 19 December 2024 and 19 December 2025: vulnerability detection and management, no unnecessary software, blocking unauthorised files, central logging and penetration tests.
• The federal plan is a plan. The ATDT's work covers federal bodies, with milestones in 2026 to 2030.
• Safeguard capabilities in this guide are all GA: SBOM generation and analysis, SCA and vulnerability management, reachability analysis, autonomous remediation (ships off, every category Manual), policies and gates, license compliance, CSAF and VEX upload, the Compliance and GRC suite with a Mexico LFPDPPP framework page, TPRM, Trust Center, Package Firewall, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, the CLI and local runner, Zero AI mode, bring your own model, and private VPC, on-prem and air-gapped deployment.

Who this applies to in Mexico

Mexico's rules split by who you are and what data you hold, and most organisations sit under more than one regime.

Two points catch foreign suppliers. A bank's supplier is not supervised by the CNBV directly, but its contract and location are: the bank files a notice before signing and sometimes needs authorisation first. And a SaaS provider processing personal data for a Mexican company is a processor (encargado) under the LFPDPPP, so expect requests for written terms and security evidence.

The rules, regulator by regulator

The 2025 LFPDPPP and the end of the INAI

Mexico's constitutional reform on organic simplification, published in the DOF on 20 December 2024, ordered the extinction of several autonomous bodies, including the National Institute for Transparency, Access to Information and Personal Data Protection (INAI). The extinction took effect when the replacement laws came into force. Those laws were issued together in one decree published in the DOF on 20 March 2025: a General Law on Transparency and Access to Public Information, a General Law on the Protection of Personal Data Held by Obligated Subjects for the public sector, and a new LFPDPPP for private parties. The new LFPDPPP took effect on 21 March 2025 and abrogated the 2010 law.

The Secretaría Anticorrupción y Buen Gobierno's own site carries the notice that protection of personal data "es ahora atribución" of the ministry, meaning it is now the ministry's responsibility. That is the regulator to name in your policies, privacy notices and incident playbooks. Replace any reference to the INAI as the current authority.

We could not load the DOF or the Chamber of Deputies' consolidated text from our location on the day of review, so this guide describes the law's duties without quoting its new article numbers. Published comparisons of the two laws show that several articles moved, often by one number. If your policies cite LFPDPPP article numbers, check each citation against the consolidated text on the Chamber of Deputies' site before an audit.

What the law asks of a controller (responsable), in plain terms:

• Privacy notice and consent. Tell data subjects what you collect and why, and get consent where required. Published commentary notes the new law is stricter about reusing data for a new purpose.
• ARCO rights. Answer access, rectification, cancellation and opposition requests through a defined procedure.
• Security measures. Keep administrative, technical and physical security measures that protect personal data against damage, loss, alteration, destruction and unauthorised use, access or processing.
• Breach notice to data subjects. Security breaches that significantly affect data subjects' property or moral rights are reported to them promptly, so they can protect themselves.
• A responsible person or department. Designate who handles data subject requests and promotes protection of personal data inside the organisation.
• Transfers and processors. Transfers to third parties need consent unless an exception applies, and processors act only on the controller's instructions.

For a software team, security measures, breach assessment and processor oversight all need an accurate list of the systems and components that handle personal data.

CNBV: information security for banks

The CUB is the CNBV's consolidated rulebook for credit institutions, first published in the DOF on 2 December 2005 and amended many times since; the CNBV's own consolidated copy lists amendments up to 1 September 2026. The information security rules sit in articles 168 Bis 11 to 168 Bis 17, with incident reporting annexes 64 and 64 Bis.

Article 168 Bis 11: the control system. The chief executive is responsible for an internal control system for information security. The framework must ensure that technology infrastructure, whether owned or supplied by third parties, meets a set of requirements. Item II asks that processes, functions and configurations, "including its development or acquisition methodology", and the "detailed inventory of each component" are documented. Item III asks for security across the life cycle, including release processes with "vulnerability tests and code analysis" before production. Item IV asks that components are tested before they are deployed or changed, without using real production data. Item V asks that the institution holds the licences or authorisations it needs.

Article 168 Bis 12: reviews, scans, tests and fixes. The chief executive must:

1. Approve a security master plan (Plan Director de Seguridad) and report it to the board.
2. Run security reviews at least once a year, or after significant changes, covering authentication, access, software updates before and after deployment, and unauthorised changes to original software.
3. Keep an annual calendar of vulnerability scans for components that store, process or transmit information, with quarterly reviews so that every component holding critical information is covered by year end, and scan every new component before it goes into production.
4. Hire an independent third party with certified staff for penetration tests of systems and applications, "at least two a year" on different systems, or when the CNBV orders one. The test includes checking the integrity of hardware and software components. A report of conclusions goes to the CNBV within 20 business days of the tests ending.
5. Classify vulnerabilities using a methodology approved by the risk committee.
6. Prepare remediation plans for findings from reviews, scans and tests, validated by the CISO, naming the people responsible, deadlines and resources, and send them to the CNBV within 10 business days.
7. Track remediation to completion, verified by the CISO.

Articles 168 Bis 13 to 168 Bis 15: the CISO. Every institution needs a chief information security officer (oficial en jefe de seguridad de la información) one level below the chief executive and reporting directly, with no conflict of interest with IT, audit or business units. Article 168 Bis 14 adds the duties: managing alerts and incidents, presiding over incident response, a monthly report to the chief executive and, under item XIII, implementing security rules from other financial authorities, Banxico included.

Article 168 Bis 16: incident clocks. When an information security incident hits the institution's infrastructure, its customer channels, or "the technology infrastructure of any third party" that affects its operations, the chief executive must:

Incidents that need immediate notice are those that cause economic loss, loss of information or service interruption; whose method, "including the vulnerabilities exploited", could be repeated at other institutions; that could affect customers, financial stability or payment systems; or that the institution considers serious. Others are kept on record.

Article 168 Bis 17: the register. Institutions keep a database of incidents, failures and vulnerabilities in their technology infrastructure, with dates, duration, affected service, affected customers and amounts, and corrective measures, kept for at least 10 years.

Articles 326 to 328: third parties and offshore services. Before contracting a third party to run an operational process or to administer databases and IT systems, a bank gives the CNBV notice at least 20 business days ahead (article 326). The CNBV can object if the contract, controls or infrastructure suggest the bank could not comply; silence counts as approval. Article 327 requires a technical report on how the supplier will meet the minimum operation and security guidelines of Annex 52 when the service uses third party technology or telecommunications infrastructure. Article 328 requires CNBV authorisation, requested at least 20 business days ahead, whenever such services are provided or run partly or wholly outside Mexico, or by residents abroad.

CNBV: fintech and other entities

The CNBV applied the same model to fintech. Its resolution of 25 March 2019 added an information security framework for crowdfunding institutions, with a CISO (article 66) and, in article 67, immediate incident notice to the CNBV and the Annex 11 and 12 information within five business days. Payment fund institutions and other licences have their own CNBV provisions; check the one that matches yours.

For credit information companies, the CNBV's communique of 22 February 2023 summarises the duties in Chapter V of their provisions: access controls, encryption, physical security, backups and vulnerability testing "at least annually".

Banxico: SPEI cybersecurity rules

Banxico runs SPEI, the interbank electronic payment system, and sets the rules for participants in Circular 14/2017. Circular 12/2023, published in the DOF on 22 November 2023, rewrote the SPEI cybersecurity framework to strengthen participants' cyber resilience and to make clear which infrastructure the rules cover.

Rule 58a, section I, part A asks each participant to have documented and implemented policies and procedures that include:

• a) an area designated as responsible for security in the technology infrastructure under SPEI's internal rules.
• b) 1 to 6, security and cyber resilience controls: secure communication protocols; tools and procedures to detect malicious code; integrity monitoring (2 bis); tools and procedures for "detection and management of vulnerabilities" (3); disabling any service or software not needed for SPEI (4); blocking execution of unauthorised files (4 bis); detecting and managing incidents, including in other infrastructure that could affect SPEI operations (5); central logging that spots anomalous patterns (5 bis); and penetration tests with work plans and reports (6). Appendix M of the SPEI manual sets the detailed specifications.
• c) a policy for implementing the SPEI application, whether built in house or by an external software developer, with a formal, documented development process covering design, development, validation, implementation and change tracking.
• d) to f) secure handling of information, access controls, and network controls such as segmentation and restricted internet access.

Rule 59a Bis requires a SPEI information security officer and a deputy, independent of business, IT and audit, ratified to Banxico every May.

Circular 12/2023 phased in. Its first transitory rule set 19 December 2023; changes to several controls applied from 19 December 2024; and the remaining items, including integrity monitoring, central logging, file blocking and the penetration test wording, applied from 19 December 2025. All phases are now in force. The SPEI rules keep changing on other topics: Circular 9/2026, published on 17 June 2026, adjusted the user experience for mobile transfers.

Federal cybersecurity: the ATDT plan

The ATDT, the federal agency for digital transformation and telecommunications, publishes a cybersecurity agenda on gob.mx. It lists a comprehensive cybersecurity risk management programme for the federal public administration (the National Cybersecurity Plan), a vulnerability evaluation programme (Programa Operativo de Evaluación de Vulnerabilidades) that "detects vulnerabilities in public systems", a national catalogue of critical infrastructure and essential services, and a national protocol for notifying, reporting and escalating cybersecurity incidents in the federal public administration. Its milestones for 2026 to 2027 include consolidating a national cybersecurity operations centre and a methodology to identify critical infrastructure; 2028 adds using AI to anticipate and respond to attacks.

Mexico's previous National Cybersecurity Strategy dates from 2017. The ATDT plan covers federal bodies; for private companies its effect today is indirect, through public sector contracts and future critical infrastructure designation. We found no general cybersecurity statute in force. Treat any announced general cybersecurity law as pending until it is published in the DOF.

AI rules

We found no AI-specific statute in force in Mexico. AI systems are covered by the same rules as other software: the LFPDPPP when they process personal data, the CUB's life cycle, testing and outsourcing rules when a bank uses them, and the SPEI rules when they touch payment infrastructure. A model API run by a provider abroad, used for a bank's operational process, is a third party service the CNBV outsourcing chapter can reach.

What the rules ask of software and open source

None of these rules uses the word SBOM, but several ask for what an SBOM provides: a current inventory of components and versions.

Data residency. The LFPDPPP does not require data to stay in Mexico; it governs transfers. For banks, location matters in a different way: article 328 makes services run outside Mexico subject to CNBV authorisation. That is a reason to decide early where a security platform runs and whether source code or findings leave the country.

Open source. Open source packages are components of the technology infrastructure like anything else. The CUB's inventory, testing and licence items apply to them, and SPEI rule 58a's vulnerability management applies to whatever runs on SPEI infrastructure.

Real public incidents in or affecting Mexico

We looked for incidents from the last three years with official or primary reporting that we could load. We found none in that window from Mexican regulators' own pages. The most recent regulator-published case we could confirm falls just outside it, and we include it because it shows how the CNBV responds.

Buró de Crédito database sale, reported February 2023

In its communique of 22 February 2023, the CNBV said that on 19 December 2022 the credit bureau Buró de Crédito informed it that a database was being offered for sale on the dark web. The bureau identified the sale in 2022, but the database dated from 2016. The CNBV activated its follow-up protocol, required detailed information, worked with Banxico on monitoring, and began a special inspection visit on 26 January 2023. According to the communique, a specialist firm hired by the bureau concluded that current systems had not been breached, but a compromise of the earlier system between 2016 and its replacement could not be ruled out.

The personas who own the problem

The CISO (oficial en jefe de seguridad de la información). In a bank this is a regulatory role. The CISO validates remediation plans, approves penetration test scope and presides over incident response. They need one register of vulnerabilities and incidents with the fields of article 168 Bis 17, and plans that can reach the CNBV within 10 business days, every scan cycle, test report and incident.

The Head of AppSec or VP of Engineering. They own the tests and code analysis before production. They need gates in the pipeline and a fix path that does not stall releases.

The SPEI information security officer. Independent of IT and business, ratified each May. They need evidence for rule 58a's controls, including vulnerability management and the SPEI application development policy, before May and before any Banxico review.

The GRC or regulatory compliance lead. They prepare article 326 notices and article 328 requests, keep the Annex 64 templates and answer supervisors. They need supplier technical reports, evidence mapped by article and a clock for each deadline, before each contract and during inspections.

The person or department responsible for personal data. They need a list of systems and suppliers that process personal data, privacy notices naming the right authority, and a fast breach procedure. Now, if any document still names the INAI.

Procurement and vendor risk. They need the supplier's inventory, vulnerability process, hosting location and incident terms before signing, and at the latest 20 business days before the contract.

The fintech CTO. Often also the compliance owner. They need what is enough for their licence category, kept in one place.

A practical 30/60/90-day plan

This plan works with whatever tools you already have. Adapt the order to your licence and size.

Days 1 to 30: know what you have and set the clocks

1. Fix the authority references. Search policies, privacy notices and incident playbooks for "INAI" and replace current authority references with the Secretaría Anticorrupción y Buen Gobierno. Check every LFPDPPP article citation against the 2025 text.
2. Write down the incident clocks. For banks: immediate CNBV notice, 5 business days for the Annex 64 and 64 Bis report, 15 business days after the incident ends for the work plan, 48 hours for customer notice where sensitive information was affected. For crowdfunding institutions: immediate notice and five business days for the annex information. Name who starts each clock.
3. Inventory systems in scope. List systems holding critical information, SPEI infrastructure and personal data, with owner, hosting location and suppliers.
4. Produce component inventories. Generate an SBOM for each in-scope application and container image. This is the "detailed inventory of each component" that article 168 Bis 11 asks for, and the version list you need to assess an LFPDPPP breach.
5. List suppliers that run processes or administer data. Mark which are offshore or use offshore staff. Check that each has the article 326 notice or article 328 authorisation on file.
6. Inventory AI use. List model APIs, self-hosted models, agents and their tool access, with the data they see and where they run.

Template: incident clock card

Days 31 to 60: turn inventory into decisions

1. Set the scanning calendar. Build the annual calendar of article 168 Bis 12, item III, with quarterly coverage of critical components. Add the rule that new components are scanned before production.
2. Agree a classification method. Get the risk committee to approve how vulnerabilities are classified (item V). Use CVSS with EPSS and the CISA Known Exploited Vulnerabilities catalogue as inputs, and decide how reachability affects priority.
3. Gate releases. Add dependency, license and code checks in CI so that "vulnerability tests and code analysis" happen before production, with a written exception process.
4. Write a remediation plan template. Include owners, deadlines, resources, activities done and to do, so that plans can be sent within 10 business days of identification.
5. Ask suppliers for evidence. Request SBOMs, vulnerability handling commitments and incident notice terms from suppliers whose infrastructure could affect your operations, because article 168 Bis 16 reaches "the technology infrastructure of any third party" that affects you.
6. Review the SPEI development policy. If an external developer builds or maintains your SPEI application, confirm that the formal development process of rule 58a, I, A, c) covers them.

Decision table: what to do with a new critical finding

Days 61 to 90: make it repeatable and auditable

1. Run a tabletop exercise. Walk through a third party library compromise affecting a customer channel. Time each clock against the card above.
2. Fill the 10-year register. Make sure incidents, failures and vulnerabilities land in one database with the fields of article 168 Bis 17.
3. Prepare for the penetration tests. Give the independent tester an accurate component inventory, and agree with the CISO on scope.
4. Close the supplier loop. Re-check offshore services against article 328 and file any missing requests before renewal.
5. Publish answers once. Keep a current security page or trust portal so that bank and public sector customers can review your posture without a new questionnaire each time.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, and it holds no Mexican certification, approval or listing.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Mexico region. If a CNBV article 328 analysis or your own policy says code and findings should stay in your perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside your environment and signed offline snapshot delivery. The air-gapped deployment docs describe how every product runs inside the perimeter, including the CLI and the runner.
2. Keep source code on your machines if you prefer. The Safeguard CLI (GA) scans a directory, Git repository, container image or SBOM on your own machine and sends only results to the platform. The local runner (GA) executes the platform's scan jobs on your machine, uploading SBOMs and findings but never source. Install with curl -fsSL https://cli.safeguard.sh/install | bash, run safeguard, type /login, then /scan .. In the docs, safeguard scan builds an SBOM and matches it against vulnerability databases, and safeguard validate checks CycloneDX, SPDX and VEX documents you receive from suppliers. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use a model provider you have already approved.
3. Build the component inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries and uploaded files, as the Generate SBOM docs describe. That inventory is what article 168 Bis 11, item II and an LFPDPPP breach assessment both depend on.
4. Turn on the Mexico LFPDPPP framework page. In Compliance, the Mexico LFPDPPP framework is on unless you switch it off in Compliance › Manage. Each product scan checks six requirements against what the scan found, including the product's SBOM: security measures, breach assessment readiness, accountability for third party processing, data quality of the inventory, a reachable personal data officer and transfer documentation. The page also adds controls for the framework and policy templates, two of them written for LFPDPPP (an information security policy and an ARCO rights procedure). Some of the page's article references appear to follow the 2010 law's numbering, so check each one against the 2025 text before you cite it. The Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place. Safeguard has no framework page for the CUB or the SPEI rules; map those articles as custom controls or through your existing control set.
5. Scan on your calendar and before production. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the findings list. SAST and DAST (GA) cover first party code and verified running targets. Scans can run on push or on a schedule, which maps to a quarterly calendar and to the "scan before production" rule.
6. Rank and fix. Reachability analysis (GA) ranks vulnerable code paths your application actually calls, which supports a classification method your risk committee can approve. Autonomous remediation (GA) opens tested, policy gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
7. Gate releases. Policies, gates and guardrails (GA) evaluate scan results that combine SBOM, vulnerability, license and reachability data. Gate actions are Block, Warn and Notify, and approvals are handled through exceptions, which gives you the written exception trail. Policies can be written in plain English. License compliance (GA) covers SPDX expressions, policy and attribution, the evidence for article 168 Bis 11, item V.
8. Collect supplier evidence. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many, with a deadline, status tracking, automated reminders and validation of what comes back. CSAF and VEX upload (GA) lets suppliers' exploitability statements sit next to findings. This supports the technical report behind an article 326 notice and the third party reach of article 168 Bis 16.
9. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
10. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model files, prompt templates, notebooks, MCP server configuration, managed inference endpoints, vector stores and agents and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) evaluates LLM interactions against prompt injection, jailbreak and PII egress guardrails; in monitor mode it records a guardrail event for each prompt, response and tool call while traffic passes unchanged, so you can see what a policy would do before deciding on enforcement. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level.
11. Answer customers once. Trust Center (GA) publishes your security posture on a page managed from Compliance › Trust Center, which helps a supplier facing Mexican bank due diligence. Safeguard's own posture wording is "SOC 2 Type II compliant" and "designed for FedRAMP High".

What Safeguard does not do

• It does not notify anyone for you. CNBV notices, Annex 64 and 64 Bis reports, customer notices within 48 hours and LFPDPPP data subject notices are your institution's duty. Safeguard holds the inventory and evidence that feed them; a person decides and sends them.
• It has no framework page for the CUB or the SPEI rules. The Mexico page covers the LFPDPPP. Map CNBV and Banxico articles in your own control set.
• It is not your independent penetration tester. Article 168 Bis 12, item IV asks for an independent third party with certified staff. Safeguard's scanners and inventories help that tester start from accurate data; they are not the test.
• It does not file CNBV notices or authorisations. Article 326 notices and article 328 requests are filed by the bank's chief executive. Safeguard can supply supplier evidence for them.
• It has no Mexico SaaS region. If you need everything inside your environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not interpret the law or certify you. Framework pages map controls to articles. Whether an article applies, and whether your controls are enough, is a question for counsel and your supervisor.

Common mistakes

• Still naming the INAI. Privacy notices and incident playbooks that name the INAI as the current authority are out of date. The Secretaría Anticorrupción y Buen Gobierno holds the role.
• Citing old article numbers. The 2025 LFPDPPP renumbered several articles. Check every citation in policies, contracts and tools, including compliance tool mappings.
• Counting the CNBV clock from the wrong moment. The Annex report runs from identification, the work plan from when the incident ends, and the customer notice from when it happened or you learned of it. Write all three down.
• Forgetting suppliers' infrastructure. Article 168 Bis 16 covers third party incidents that affect you, so contracts need notice terms that fit your clock.
• Treating offshore SaaS as routine. Article 328 makes services provided outside Mexico subject to CNBV authorisation, not just notice. Check before signing, including for security tools.
• Treating the federal plan as law. The ATDT plan sets work for federal bodies. It does not, by itself, impose duties on private companies.

FAQ

Who enforces Mexico's private sector data protection law now?

The Secretaría Anticorrupción y Buen Gobierno. The INAI was dissolved under the constitutional reform of 20 December 2024, effective when the new laws took effect in March 2025, and the ministry's site states that protection of personal data is now its responsibility.

When did the new LFPDPPP take effect?

It was published in the DOF on 20 March 2025 and took effect on 21 March 2025, replacing the 2010 law.

Does the new LFPDPPP require breach notification?

The law keeps the duty to inform data subjects about security breaches that significantly affect their property or moral rights, so they can protect themselves. Banks also have their own CNBV clocks under article 168 Bis 16.

How fast must a Mexican bank report a cyber incident to the CNBV?

Immediately for incidents that meet any of the article 168 Bis 16 criteria, with the Annex 64 and 64 Bis information within 5 business days of identification, a work plan within 15 business days after the incident ends, and customer notice within 48 hours when sensitive information was affected.

How many penetration tests must a Mexican bank run?

At least two a year on different systems, by an independent third party with certified staff, with a report of conclusions sent to the CNBV within 20 business days of finishing (article 168 Bis 12, item IV).

Is an SBOM mandatory in Mexico?

No rule uses the term. The CUB asks for a documented, detailed inventory of each technology component, and the LFPDPPP's breach and security duties depend on knowing what software handles personal data. An SBOM is the practical way to provide both.

What did Banxico's Circular 12/2023 change?

It strengthened SPEI's cybersecurity and IT requirements in rule 58a, adding cyber resilience, integrity monitoring, blocking of unauthorised files and central logging, phased in through 19 December 2025.

Does Mexico have an AI law?

We found no AI-specific statute in force. AI systems fall under the LFPDPPP when they process personal data and under CNBV and Banxico rules when financial entities use them.

Can Safeguard run without our code leaving our environment?

Yes. The local runner scans on your machine and sends only results, and private VPC, on-prem and air-gapped deployments keep the whole platform in your perimeter. There is no Mexico SaaS region.

Before you fix anything

Every rule in this guide comes back to the same point: when a component you ship is vulnerable, a supervisor will ask how fast the fix reached production and what you did while no fix existed. The section below covers how Safeguard closes both gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and pushes nothing. That is how a remediation plan item under CUB article 168 Bis 12 becomes a reviewed change with a record.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. For a Mexican bank weighing article 328 before it lets a service outside Mexico touch its systems, this is how inventories and findings are produced while source code stays on its own machines.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access a CISO and the personal data owner should inventory before AI agents reach systems that hold customer data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Secretaría Anticorrupción y Buen Gobierno, home page notice on personal data protection (gob.mx)
• Disposiciones de carácter general aplicables a las instituciones de crédito, consolidated (CNBV)
• CNBV resolution amending the provisions for financial technology institutions, DOF 25 March 2019 (CNBV)
• CNBV Communique No. 03 on the Buró de Crédito incident, 22 February 2023 (gob.mx)
• Banxico Circular 12/2023, DOF 22 November 2023 (Banxico)
• Banxico Circular 9/2026 and compiled amendments to Circular 14/2017 (Banxico)
• ATDT cybersecurity agenda (gob.mx)
• Estrategia Nacional de Ciberseguridad, 2017 (gob.mx)
• Nueva LFPDPPP law flash, 26 March 2025 (EY Mexico, secondary)
• Safeguard docs: Mexico LFPDPPP framework
• Safeguard docs: Safeguard CLI
• Safeguard docs: Generate SBOM
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: Package Firewall
• Safeguard docs: AI-BOM discovery
• Safeguard docs: AI Gateway
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Guardrails and enforcement
• Safeguard docs: Trust Center setup

Related reading: Latin America's evolving cybersecurity regulations and the Canada edition of this guide.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.