El INE convierte la ciberseguridad en una condición de entrada para sus sistemas

La Junta General Ejecutiva del Instituto Nacional Electoral (INE) aprobó el 14 de septiembre de 2026, en una sesión extraordinaria realizada por el propio instituto, los Lineamientos para la gestión integrada de desarrollo, seguridad y operaciones (DevSecOps) de sus sistemas y servicios tecnológicos. En la misma agenda se incluyó la primera modificación al proyecto G090310, destinado a fortalecer la resiliencia tecnológica y operativa del INE durante el ejercicio fiscal 2026. ([portal.ine.mx](https://portal.ine.mx/sesion-extraordinaria-de-la-junta-general-ejecutiva-14-de-septiembre-de-2026/))

La decisión coloca la seguridad informática dentro de todo el ciclo de vida de los sistemas: desde la planeación y el diseño hasta el despliegue, la operación y la mejora continua. En términos prácticos, el INE ya no plantea la ciberseguridad como una revisión al final de un proyecto, sino como una condición que debe cumplirse antes de que una aplicación o componente llegue a producción.

En breve

• Los lineamientos aplican de manera gradual a sistemas electorales, plataformas con datos personales, servicios expuestos a redes públicas y nuevos desarrollos o mantenimientos mayores.
• Se exigirá escaneo automatizado de código, dependencias, contenedores, infraestructura y secretos; las vulnerabilidades críticas, altas y medias deberán corregirse antes del despliegue, salvo excepciones documentadas.
• La implementación deberá comenzar de forma gradual y alcanzar una adopción plena en un plazo de tres meses desde la aprobación, lo que llevaría el primer límite operativo al 14 de diciembre de 2026.

Qué sistemas quedan dentro del marco

El documento no declara que cada sistema del INE deba migrar de inmediato al mismo nivel de controles. La aplicación será gradual y proporcional al riesgo, la exposición, la criticidad, la madurez tecnológica y la disponibilidad presupuestal.

Sin embargo, los criterios de inclusión son amplios. El marco considera vinculantes los sistemas que soporten procesos sustantivos, electorales o misionales; que almacenen, procesen o transmitan datos personales o información reservada; que estén expuestos a internet o presten servicios directamente a la ciudadanía; que correspondan a nuevos desarrollos o a mantenimientos evolutivos mayores iniciados después de su entrada en vigor; y que utilicen integración y despliegue continuos.

Esto alcanza potencialmente a una parte importante de la infraestructura digital del instituto, aunque los lineamientos no publican en el texto consultado un catálogo detallado con los nombres de cada plataforma. Esa ausencia es una de las primeras preguntas de rendición de cuentas: el Grupo de Gobierno de Tecnologías de la Información y Comunicaciones deberá mantener actualizado el inventario de sistemas sujetos al marco, pero no se establece en el documento si ese catálogo será público, parcialmente reservado o únicamente de uso interno.

Controles concretos para impedir errores y ataques

Los lineamientos fijan controles técnicos más específicos que una declaración general de buenas prácticas. Exigen análisis estático del código, pruebas dinámicas de seguridad, revisión de componentes de terceros, detección de secretos, escaneo de contenedores y revisión de la infraestructura definida como código.

La regla más importante es el bloqueo por riesgo: un flujo de trabajo deberá impedir el paso a producción cuando encuentre vulnerabilidades críticas, altas o medias que no hayan sido remediadas. Las fallas de severidad baja no bloquearán necesariamente el despliegue, pero deberán registrarse como deuda técnica y contar con un plan de corrección. Cualquier excepción tendrá que autorizarse y documentarse conforme a los procedimientos institucionales.

El marco también exige firmar digitalmente los artefactos de software, utilizar imágenes base confiables, elaborar un inventario de componentes mediante un SBOM, aplicar controles de acceso por roles y operar bajo el principio de mínimo privilegio. Para los datos personales se prevé cifrado o enmascaramiento, mientras que las bitácoras de eventos de seguridad, accesos, escaneos y despliegues deberán conservarse para análisis y auditoría. ([repositoriodocumental.ine.mx](https://repositoriodocumental.ine.mx/xmlui/bitstream/handle/123456789/188820/JGEor202606-17-ap-5-1-a.pdf))

En los despliegues, el INE deberá conservar evidencia sobre quién autorizó el cambio, qué versión se liberó, cuándo ocurrió y en qué ambiente se ejecutó. Además, ningún despliegue podrá autorizarse sin un mecanismo probado de reversión inmediata. Este punto conecta la seguridad con la continuidad operativa: no basta con detectar una intrusión o un error, también se necesita recuperar una versión estable sin improvisaciones.

La medición será el verdadero examen

La Unidad Técnica de Servicios de Informática será responsable de coordinar la verificación del cumplimiento y reportar los resultados al Grupo de Gobierno de TIC. La revisión deberá hacerse por lo menos una vez al año, aunque también podrá activarse después de incidentes relevantes, cambios tecnológicos o modificaciones normativas.

El texto permite emplear métricas DORA, como frecuencia de despliegue, tiempo de entrega de cambios, tasa de fallas y tiempo medio de recuperación. También contempla indicadores de cobertura de pruebas, defectos, vulnerabilidades y cumplimiento de niveles de servicio. Estas métricas pueden ayudar a pasar de una evaluación basada en declaraciones a una revisión con datos, pero el instituto todavía tendrá que explicar qué metas considera aceptables y qué consecuencias habrá cuando un área no las cumpla. ([repositoriodocumental.ine.mx](https://repositoriodocumental.ine.mx/xmlui/bitstream/handle/123456789/188820/JGEor202606-17-ap-5-1-a.pdf))

La obligación de conservar reportes de escaneos, bitácoras de CI/CD, registros de excepciones y evidencias de remediación abre una oportunidad para la transparencia. La pregunta central será qué parte de esa información puede publicarse sin exponer la arquitectura del INE. Divulgar vulnerabilidades activas sería irresponsable; ocultar de manera permanente todos los resultados impediría evaluar si el marco funciona. El equilibrio entre seguridad operacional y supervisión pública deberá definirse con criterios claros.

Proveedores: la zona que aún requiere mayor claridad

Los lineamientos alcanzan proyectos desarrollados internamente o en colaboración con terceros. También señalan que deben integrarse la gestión de proveedores, el análisis de riesgos y la trazabilidad del ciclo de vida tecnológico. No obstante, el documento no sustituye las reglas de contratación ni detalla, por sí mismo, un esquema completo para evaluar a cada proveedor.

Por ello, la implementación deberá responder preguntas prácticas: si las empresas contratadas tendrán que usar las herramientas institucionales autorizadas; cómo entregarán sus registros de seguridad; quién validará el código y las dependencias que aporten; qué ocurrirá cuando un proveedor no pueda corregir una vulnerabilidad antes de una fecha electoral; y si los contratos incluirán penalizaciones, derechos de auditoría y obligaciones de notificación de incidentes.

El reto es especialmente relevante porque un sistema puede cumplir formalmente con una revisión interna y conservar, aun así, riesgos en bibliotecas externas, servicios en la nube, cuentas privilegiadas o componentes administrados por contratistas. El enfoque DevSecOps reduce esos puntos ciegos sólo si la cadena de suministro también queda sujeta a controles verificables.

Resiliencia tecnológica y presupuesto

La Junta también incluyó la modificación del proyecto G090310, orientado a anticipar, resistir, responder y recuperarse de eventos de ciberseguridad y fallas tecnológicas. El modelo contempla operación de ciberseguridad, monitoreo y respuesta a amenazas, resiliencia e infraestructura crítica, gobernanza y cumplimiento, además de servicios especializados bajo demanda. ([repositoriodocumental.ine.mx](https://repositoriodocumental.ine.mx/xmlui/bitstream/handle/123456789/188947/JGEor202606-17-ap-5-2.pdf))

El proyecto tenía un presupuesto aprobado de 235 millones 94 mil 824 pesos. La modificación reduce 788 mil 823 pesos en los capítulos de bienes y servicios, amplía en 784 mil 476 pesos el capítulo de servicios personales y deja un total modificado de 235 millones 90 mil 477 pesos. El ajuste busca financiar tres plazas de ingeniero especialista en seguridad informática para el segundo semestre de 2026, con recursos provenientes de economías del propio proyecto. ([repositoriodocumental.ine.mx](https://repositoriodocumental.ine.mx/xmlui/bitstream/handle/123456789/188947/JGEor202606-17-ap-5-2.pdf))

La cifra no representa un aumento neto del proyecto; es una reasignación interna. Esa diferencia importa porque la ciberseguridad electoral no se fortalece únicamente con licencias, monitoreo o servicios administrados. También requiere personal capaz de interpretar alertas, cuestionar a proveedores, validar excepciones y responder cuando los controles automáticos detecten un problema.

Por qué importa para la confianza electoral

La ciberseguridad electoral no se limita a proteger una jornada de votación. Incluye la disponibilidad de los servicios, la integridad de la información, la protección de datos personales y la capacidad de demostrar que los cambios en los sistemas fueron autorizados y auditados.

El nuevo marco puede contribuir a la confianza pública si sus controles se traducen en evidencia verificable. También puede quedarse en una norma interna de difícil evaluación si el INE no publica indicadores agregados, avances de implementación, número de sistemas incorporados, vulnerabilidades corregidas y excepciones autorizadas.

El siguiente paso no será sólo tecnológico. Será institucional: definir qué información puede conocer la ciudadanía, cómo se auditarán los resultados y quién asumirá responsabilidades cuando una plataforma no cumpla los controles. En el terreno de la ciberseguridad electoral en México, la credibilidad dependerá tanto de blindar los sistemas como de explicar, con datos, cómo se blindaron.

Fuentes consultadas

• Instituto Nacional Electoral, sesión extraordinaria de la Junta General Ejecutiva del 14 de septiembre de 2026.
• INE, Lineamientos para la gestión integrada de Desarrollo, Seguridad y Operaciones (DevSecOps).
• INE, acuerdo sobre la primera modificación al proyecto G090310 de resiliencia tecnológica y operativa.
• INE, Bases Generales del Presupuesto 2026.