El artículo 18 de la LFPDPPP obliga a toda empresa que trate datos personales en México a establecer y mantener "medidas de seguridad administrativas, técnicas y físicas" que protejan esos datos contra daño, pérdida, alteración, destrucción o uso, acceso o tratamiento no autorizado. La ley no entrega una lista cerrada de esas medidas, y esa ausencia genera la duda más común de quien está implementando cumplimiento: ¿qué controles cuentan, exactamente, como suficientes?

Este artículo detalla lo que la LFPDPPP exige, y lo que el mercado ya consolidó como respuesta práctica ante la falta de una lista cerrada, incluyendo qué cambia cuando el dato es sensible, qué hacer ante un incidente, y cómo entra el tamaño de la empresa en la ecuación.

La diferencia entre este tema y la privacidad de datos en sí misma está detallada en otro artículo de este hub; aquí el enfoque está exclusivamente en la capa técnica y administrativa de la seguridad.

La decisión de no fijar un estándar técnico específico dentro del texto legal es deliberada. La tecnología de seguridad de la información cambia en ciclos de meses, un cifrado considerado robusto hoy puede quedar obsoleto en pocos años, y una ley que fijara un estándar técnico específico quedaría desactualizada rápidamente.

Por eso, el propio artículo 18 delega en el responsable la tarea de definir el nivel de seguridad adecuado, estableciendo un piso claro: ese nivel no puede ser inferior al que la empresa utiliza para proteger su propia información, y debe considerar el riesgo existente, las consecuencias para los titulares, la sensibilidad de los datos y el desarrollo tecnológico disponible en cada momento.

Esto no significa vacío normativo. Significa que la exigencia varía: una clínica que trata datos de salud necesita controles más rígidos que un boletín de noticias que solo trata nombre y correo electrónico.

Una medida técnica es todo control implementado en la propia infraestructura tecnológica de la empresa, sin depender de una decisión humana en el momento del uso. Seis categorías aparecen con más frecuencia en las implementaciones consideradas adecuadas por el mercado.

El dato en tránsito es el que se mueve entre sistemas, por ejemplo entre el navegador del cliente y el servidor de la empresa. El dato en reposo es el que queda almacenado en una base de datos o archivo. Ambos necesitan cifrado: las conexiones HTTPS cubren el primer caso, y algoritmos como AES-256 aplicados a la base de datos cubren el segundo.

No todo empleado necesita ver todo dato. El control de acceso por rol significa que el equipo de atención ve el historial de compra del cliente, pero no ve, por ejemplo, el dato bancario completo, que queda restringido al equipo financiero.

Una contraseña sola se considera insuficiente para sistemas que almacenan volumen relevante de datos personales. La autenticación de doble factor es hoy el piso mínimo esperado para el acceso administrativo a cualquier sistema que trate datos personales.

El artículo 18 habla de proteger contra "pérdida" y "destrucción" del dato, no solo contra acceso indebido. Un respaldo regular, probado periódicamente, garantiza que un ataque de ransomware o una falla de hardware no se convierta en pérdida permanente de información.

Sistemas que registran y alertan sobre comportamiento fuera de lo normal permiten que la empresa descubra un incidente en horas, y no en meses. El tiempo entre la ocurrencia de una filtración y su descubrimiento es, históricamente, uno de los factores que más agrava el daño final.

En la práctica, mantener el nivel de seguridad "no inferior" al exigido por el artículo 18 se traduce en probar los controles periódicamente, ya sea con auditoría interna o con pruebas de penetración externas, para verificar que lo implementado sigue funcionando conforme el sistema evoluciona.

Una medida administrativa es el control que depende de proceso organizacional y comportamiento humano, no solo de configuración de sistema. Cuatro frentes aparecen como los más relevantes.

Un documento formal, aprobado por la dirección de la empresa, que define reglas claras: quién puede acceder a qué sistema, cómo debe crearse una contraseña, qué hacer al identificar un intento de phishing. Sin este documento, cada empleado aplica su propio criterio, justo en el punto más sensible de la operación.

La mayoría de los incidentes de seguridad en el mundo real no empiezan con un ataque técnico sofisticado, empiezan con un empleado haciendo clic en un enlace malicioso o compartiendo una contraseña por error. La capacitación recurrente, no solo en la inducción, reduce este vector de forma medible.

Cuando la empresa contrata un proveedor que va a procesar datos personales en su nombre (un servicio de correo de marketing, una plataforma de atención, una CMP), la responsabilidad por la seguridad del dato no desaparece solo porque está con un tercero. Contratos con cláusulas específicas de seguridad, y un proceso de evaluación del proveedor antes de la contratación, forman parte de la medida administrativa exigida.

Aunque la LFPDPPP no exige de forma expresa la figura de un encargado de protección de datos como otras leyes de la región, en la práctica alguien dentro de la empresa necesita ser el responsable de que la política de seguridad exista, se siga, y se actualice cuando el riesgo cambie. Sin un responsable claro, las políticas de seguridad tienden a quedar desactualizadas de forma silenciosa.

La LFPDPPP considera datos sensibles aquellos que afectan la esfera más íntima del titular, cuyo uso indebido puede dar origen a discriminación o conllevar un riesgo grave: origen racial o étnico, estado de salud, información genética, creencias religiosas, filosóficas y morales, afiliación sindical, opiniones políticas y preferencia sexual, entre otros. El artículo 9 exige consentimiento expreso y por escrito para el tratamiento de estos datos, salvo excepciones específicas.

Esa exigencia mayor se extiende directamente a la seguridad: datos sensibles suelen requerir segregación física o lógica del resto de la base de datos, registro de acceso más granular (quién visualizó el registro específico de un titular, no solo quién accedió al sistema en general), minimización más agresiva en la recolección, y revisión de acceso más frecuente para retirar permisos de empleados que ya no los necesitan.

El artículo 18 aplica igual a cualquier responsable, pero lo que cuenta como medida "adecuada" cambia según el tipo de dato y el sector de la empresa. Tres ejemplos ilustran esa diferencia en la práctica.

Una tienda en línea trata dato de pago (aunque casi siempre a través de una pasarela externa), dirección de envío, historial de compra y, en muchos casos, preferencia de producto inferida por comportamiento de navegación.

El riesgo principal no es solo el robo directo de tarjeta, sino la reconstrucción de un perfil de consumo detallado a partir de datos aparentemente inocuos cruzados entre sí. Control de acceso segmentado entre el equipo de atención al cliente y el equipo financiero, y cifrado del historial de pedidos, son controles de peso desproporcional frente a su costo de implementación.

Una clínica o consultorio trata dato considerado sensible bajo el artículo 9: diagnóstico, tratamiento, resultado de laboratorio. Aquí la exigencia de segregación física o lógica del resto de la base de datos, y el registro granular de quién accedió a qué expediente específico, deja de ser una buena práctica opcional y se vuelve la expectativa mínima razonable ante cualquier revisión.

Una fintech o institución que procesa transacción, historial de crédito o score de riesgo enfrenta el escenario de mayor daño potencial por filtración, porque el dato financiero es directamente monetizable por un atacante. Autenticación reforzada en cada capa del sistema (no solo en el login inicial, sino en cada operación sensible), monitoreo de anomalía transaccional y auditoría externa periódica suelen ser el piso esperado, no el techo.

En los tres sectores, la seguridad técnica de los datos no sustituye la obligación de transparencia frente al titular: el aviso de privacidad sigue siendo el documento donde la empresa declara qué datos trata y con qué medidas los protege, y ese documento debe reflejar la realidad técnica implementada, no una lista aspiracional de controles que la empresa todavía no tiene.

"La ley exige un antivirus y ya está listo." Un antivirus es una medida técnica entre varias decenas posibles, y por sí solo no cubre control de acceso, respaldo, ni gestión de proveedores. Reducir el cumplimiento a un solo control técnico es el error de interpretación más común.

"Si no hay reglamento técnico publicado, no hay obligación real." El artículo 18 ya es ley vigente y exigible, independientemente de que exista o no un reglamento que detalle controles específicos. La ausencia de reglamento no suspende la obligación, solo deja más criterio de interpretación en manos del responsable.

"Contratar un buen proveedor de nube transfiere toda la responsabilidad." Como se detalla más adelante en este artículo, la responsabilidad legal por el dato tratado no se transfiere solo porque la infraestructura está tercerizada.

"Esto es un problema exclusivo del equipo de tecnología." La política interna, la capacitación del equipo y la gestión de proveedores son medidas administrativas, no técnicas, y dependen de decisiones de negocio y de recursos humanos tanto como de configuración de sistema.

México no está solo en esta exigencia. El Reglamento General de Protección de Datos europeo exige, en su artículo 32 (texto oficial, EN), medidas técnicas y organizativas apropiadas al riesgo, en una redacción con un espíritu casi idéntico al del artículo 18 mexicano. En la región, Colombia exige algo equivalente en su régimen de habeas data, y Perú lo hace en su Ley 29733.

Para una empresa que opera en más de un país de la región, esta convergencia es una ventaja práctica: un programa de seguridad de la información bien diseñado, alineado a un estándar como ISO/IEC 27001, tiende a satisfacer el criterio de "medida adecuada" en México, Colombia y Perú al mismo tiempo, sin necesidad de mantener programas de seguridad separados por jurisdicción.

Incluso con controles adecuados, los incidentes ocurren. Ante una vulneración de seguridad relevante, lo esperado es que el responsable evalúe la gravedad del incidente, tome medidas inmediatas de contención, y considere la notificación a los titulares afectados cuando el riesgo para sus derechos así lo amerite.

Con la extinción del INAI y el traslado de sus funciones de vigilancia a la Secretaría Anticorrupción y Buen Gobierno tras la reforma de marzo de 2025, el canal formal de reporte y algunos detalles operativos siguen definiéndose conforme se publique el reglamento correspondiente. Mientras eso ocurre, documentar internamente cada incidente, su gravedad evaluada y las medidas tomadas es la práctica más segura, independientemente de si existe ya o no una obligación reglamentaria específica de notificación externa.

El término "filtración de datos" se popularizó para describir cualquier evento de exposición indebida de información, pero el concepto legal más amplio de "vulneración de seguridad" cubre distintos escenarios: acceso no autorizado, pérdida, alteración indebida y destrucción del dato. Un ataque de ransomware que cifra y vuelve inaccesible el dato para la propia empresa, sin necesariamente copiarlo hacia afuera, también es una vulneración de seguridad, aun sin "filtración" en el sentido popular del término.

Un incidente de seguridad relevante también puede activar el ejercicio de los derechos ARCO por parte de los titulares afectados, en particular la cancelación del dato una vez que consideran que el riesgo de mantenerlo almacenado supera el beneficio de conservarlo. Un canal de ejercicio de derechos que ya funciona de forma ágil antes de cualquier incidente reduce considerablemente la fricción operativa el día en que ese canal se vuelve crítico.

La ley contempla un catálogo de infracciones y sanciones para el responsable que incumpla sus obligaciones, incluidas las relativas a seguridad de datos. Las sanciones pueden incluir apercibimiento y multas, cuyo monto se calcula considerando factores como la naturaleza del dato, el volumen de tratamientos, la reincidencia y la capacidad económica del infractor, entre otros criterios que la autoridad valora caso por caso.

Más allá de la sanción administrativa, una empresa que sufre una vulneración de seguridad relevante enfrenta un costo reputacional que, en la mayoría de los casos documentados en el mercado, supera ampliamente el valor de cualquier multa: la confianza del cliente, una vez rota por una filtración pública, tarda considerablemente más en reconstruirse que el tiempo que toma pagar una sanción.

Un error común es pensar que la LFPDPPP exige el mismo nivel de inversión técnica de una pequeña empresa y de una multinacional. La ley habla de medidas "no inferiores" a las que la propia empresa aplica a su información, considerando el riesgo, lo que abre espacio a la proporcionalidad, pero no a la ausencia de control.

Una microempresa que trata solo nombre, correo y teléfono de clientes para facturación no necesita el mismo aparato de seguridad que un banco. Aun así, necesita control de acceso básico, respaldo funcional y un mínimo de higiene de contraseñas, precisamente porque el artículo 18 no establece un piso cero para ningún tratamiento de datos personales.

La ausencia de un reglamento técnico detallado no significa que el mercado mexicano parta de cero. La norma ISO/IEC 27001, referencia internacional para sistemas de gestión de seguridad de la información, cubre desde política documentada hasta control técnico y respuesta a incidentes. Empresas que buscan esta certificación tienden a cumplir, casi como efecto colateral, la mayor parte de lo que un fiscalizador esperaría encontrar en una auditoría de seguridad bajo la LFPDPPP.

Para una empresa mexicana que también atiende clientes en otros países de la región (Colombia, Perú) o fuera de ella, alinear la seguridad interna a un estándar internacional reconocido reduce el retrabajo de justificar controles separados para cada régimen legal, porque la base técnica de seguridad suele ser la misma independientemente de cuál ley se esté evaluando.

• ¿Existe un inventario de dónde está almacenado cada tipo de dato personal?
• ¿El acceso a datos sensibles está restringido por rol, y no abierto a todo el equipo?
• ¿Los sistemas administrativos exigen doble factor de autenticación?
• ¿Existe una rutina de respaldo probada, no solo configurada?
• ¿Existe monitoreo activo de acceso anómalo a los sistemas que guardan datos personales?
• ¿Existe una política de seguridad de la información formal, aprobada por la dirección?
• ¿Los proveedores que procesan datos personales en nombre de la empresa tienen cláusula contractual de seguridad?
• ¿Existe un plan de respuesta a incidentes, con responsable definido y probado al menos una vez?
• ¿El dato sin finalidad activa se elimina de forma efectiva, y no solo se archiva indefinidamente?

La adopción amplia del trabajo remoto cambió el perímetro de seguridad de muchas empresas. Antes, el dato quedaba dentro de una red corporativa cerrada; hoy, se accede desde casa, desde espacios de coworking, y en algunos casos desde equipos personales.

Esto no cambia la obligación del artículo 18, solo cambia dónde deben aplicarse los controles: VPN o acceso segmentado para cualquier sistema que almacene dato personal, gestión de dispositivo (antivirus actualizado, disco cifrado, bloqueo automático de pantalla), y una política de uso aceptable que cubra explícitamente escenarios como redes Wi-Fi públicas o uso de almacenamiento en la nube personal para archivos de trabajo.

Confundir cumplimiento documental con cumplimiento técnico real. Tener una política de seguridad impresa en el cajón no sustituye el control de acceso efectivamente configurado en el sistema.

Pensar que la seguridad es una inversión única. Configurar un control una vez y nunca revisarlo equivale a no tener control alguno después de algunos años, porque las amenazas y la tecnología cambian de forma continua.

Ignorar que la seguridad del consentimiento de cookies forma parte de la misma obligación. El aviso de cookies del sitio también trata datos personales (identificadores de navegador, comportamiento de navegación), y la integridad técnica de ese flujo está sujeta a la misma exigencia de seguridad. Este punto específico se detalla en Seguridad de Datos en el Consentimiento.

Confiar en resúmenes de terceros en lugar del texto oficial. El texto completo de la LFPDPPP está disponible en el sitio de la Cámara de Diputados, y vale la pena revisar directamente los artículos relevantes antes de tomar decisiones basadas solo en interpretaciones de terceros, incluyendo este propio artículo.

No toda empresa puede implementar las nueve categorías de control descritas en este artículo de una sola vez. Un orden práctico de prioridad, basado en el impacto por peso invertido, suele seguir esta secuencia: primero, control de acceso y autenticación reforzada, por ser el control más económico y el que más reduce la superficie de riesgo de inmediato; segundo, respaldo probado, porque protege contra el escenario de mayor daño irreversible; tercero, cifrado del dato en reposo para las bases que almacenan datos sensibles o financieros; cuarto, política documentada y capacitación, de costo bajo y efecto directo en la reducción del error humano; y por último, monitoreo y plan de respuesta a incidentes, que cobra pleno sentido una vez que los controles anteriores ya redujeron el volumen de eventos a vigilar.

La ley no fija un número de días específico en el texto vigente. Lo esperado es notificar sin dilación indebida una vez evaluada la gravedad del incidente, y el reglamento pendiente de publicación podría precisar este plazo con mayor detalle.

La obligación de seguridad se aplica a cualquier responsable del tratamiento, sin excepción de tamaño. Lo que varía es la proporcionalidad de la medida frente al riesgo, no la existencia de la obligación en sí.

No existe una lista cerrada y oficial al momento de publicar este artículo. La evaluación considera si la medida era adecuada al riesgo y a la sensibilidad del dato tratado, con base en la tecnología disponible al momento del tratamiento. Documentar las medidas adoptadas y la justificación de cada elección ayuda a demostrar buena fe ante una eventual revisión.

No por sí solo. Un proveedor de infraestructura en la nube confiable cubre parte de la seguridad física y de red, pero la empresa contratante sigue siendo responsable del control de acceso, de la política de retención y de la respuesta a incidentes dentro de la propia aplicación.

No existe una certificación que por sí sola garantice cumplimiento legal automático. Certificaciones como ISO/IEC 27001 ayudan a demostrar madurez en seguridad de la información, pero la evaluación final de adecuación es siempre casuística.

Sí. El artículo 18 exige medidas que incluyan la prevención de riesgo de error humano interno, no solo de ataque externo. Una falla causada por un empleado que compartió una contraseña indebidamente no exime a la empresa de responsabilidad si no existía capacitación, política o control técnico que pudiera haber mitigado ese riesgo específico.

El aviso de cookies de tu sitio trata datos personales como cualquier otro sistema, y merece la misma atención del artículo 18. Empieza gratis con AdOpt y organiza el registro de consentimiento con el mismo rigor técnico que ya aplicas al resto de tu operación.

• Privacidad vs Seguridad de Datos: Cuál Es la Diferencia
• Seguridad de Datos en el Consentimiento: Cómo Proteger los Datos del Usuario desde la Recolección hasta la Activación