Privacidad de datos y seguridad de datos suenan como sinónimos, pero no lo son. La privacidad es el derecho de la persona a decidir qué pasa con su información personal: quién puede recolectarla, para qué se usa, cuánto tiempo se conserva. La seguridad es el conjunto de medidas administrativas, técnicas y físicas que impiden que esa información se filtre, se altere o sea accedida por quien no debería.

Una empresa puede tener un aviso de privacidad impecable, redactado con total transparencia sobre las finalidades del tratamiento, y aun así guardar los datos de sus clientes en una base sin cifrado, accesible por cualquier empleado.

Cumpliría con la privacidad en el papel y fallaría en la seguridad en la práctica. El camino inverso también existe: un sistema con control de acceso riguroso y respaldo constante, pero que recolecta datos sin avisar al titular o sin una finalidad clara. Seguridad de sobra, privacidad en cero.

La LFPDPPP mexicana trata ambos conceptos como obligaciones separadas, pero conectadas. Este artículo explica dónde empieza y termina cada uno, qué exige la ley mexicana de cada uno, y por qué atender solo uno de los dos deja a tu empresa expuesta a la mitad.

La privacidad de datos es el principio que le da al titular control sobre su propia información. No se trata de esconder datos de todo el mundo, se trata de decidir quién tiene acceso, para qué finalidad y por cuánto tiempo.

La LFPDPPP construye este principio sobre un conjunto de derechos que el titular puede ejercer en cualquier momento, conocidos como derechos ARCO: acceso, rectificación, cancelación y oposición. El titular puede confirmar qué datos tiene una empresa sobre él, pedir que se corrija información incorrecta, solicitar la eliminación de sus datos cuando ya no exista finalidad para conservarlos, y oponerse a un tratamiento específico.

La privacidad también define los límites de la recolección. Toda recolección de dato personal necesita una finalidad específica, comunicada al titular a través del aviso de privacidad antes de que la recolección ocurra. Recolectar un dato "por si acaso se necesita después", sin finalidad definida, ya contradice el principio de finalidad, aunque ese dato nunca se filtre.

Tres elementos sostienen la privacidad de datos en el día a día de una empresa:

• Transparencia: el titular sabe qué se recolecta, quién lo hace y para qué, generalmente a través del aviso de privacidad y del banner de cookies.
• Finalidad clara y consentimiento cuando aplica: cada tratamiento de dato tiene una justificación específica, documentada y comunicada.
• Derechos ARCO atendidos: las solicitudes de acceso, rectificación, cancelación u oposición se resuelven dentro del plazo legal.

Una Consent Management Platform (CMP) organiza justamente ese lado: registra el consentimiento del visitante, documenta la base de cada cookie, y mantiene el historial auditable en caso de que la autoridad pida cuentas después.

La seguridad de datos es otra capa. No pregunta "¿el titular autorizó esto?", pregunta "¿este dato está protegido contra acceso indebido, pérdida o alteración?". Es una disciplina técnica, cercana a la seguridad de la información clásica, aplicada específicamente a los datos personales.

El artículo 18 de la LFPDPPP es directo al respecto: todo responsable debe establecer y mantener medidas de seguridad administrativas, técnicas y físicas que permitan proteger los datos personales contra daño, pérdida, alteración, destrucción o el uso, acceso o tratamiento no autorizado.

La ley también señala que el nivel de esas medidas no puede ser inferior al que el propio responsable utiliza para proteger su propia información, considerando el riesgo existente, las consecuencias para los titulares, la sensibilidad de los datos y el desarrollo tecnológico disponible.

En la práctica, seguridad de datos se traduce en una lista concreta de controles:

• Cifrado de datos en tránsito y en reposo.
• Control de acceso, para que solo quien necesita el dato para su trabajo pueda verlo.
• Autenticación reforzada, incluyendo doble factor en sistemas sensibles.
• Respaldo y recuperación, para que un incidente no signifique pérdida definitiva.
• Monitoreo de anomalías, para detectar una filtración antes de que se vuelva una crisis pública.
• Plan de respuesta a incidentes, necesario para poder actuar y, en su caso, notificar cuando exista una vulneración de seguridad relevante.

La forma más rápida de fijar la diferencia es comparar las preguntas que cada concepto responde:

Una forma simple de recordarlo: la privacidad define las reglas del juego, la seguridad garantiza que nadie las incumpla por fuera.

Las empresas que tratan la privacidad como "cumplimiento de marketing" y delegan la seguridad por completo al equipo de TI, sin conexión entre ambos frentes, tienden a repetir el mismo error: tratan como dos proyectos separados algo que la ley trata como una sola obligación.

El riesgo de atender solo la privacidad es regulatorio y reputacional a la vez. Un aviso de privacidad bien redactado no impide una filtración de datos. Y cuando la filtración ocurre, la responsabilidad recae sobre la empresa independientemente de qué tan bien redactado estuviera el aviso, porque la falla fue de seguridad, no de transparencia.

El riesgo de atender solo la seguridad es más sutil: una empresa puede tener la infraestructura más robusta del mercado y aun así ser sancionada por recolectar datos sin avisar la finalidad, o por no ofrecer al titular una forma sencilla de ejercer sus derechos ARCO. Seguridad técnica no es defensa jurídica cuando el problema es la legitimidad de la recolección en sí misma.

El ejemplo más común de colisión entre ambos conceptos ocurre en el propio aviso de cookies del sitio web. Un banner mal configurado puede registrar el consentimiento (parte de privacidad) pero transmitir el dato a servidores de terceros sin ninguna verificación de a dónde va (falla de seguridad), o registrar correctamente el rechazo del titular mientras las cookies de rastreo permanecen activas por una falla de configuración técnica.

Es justo en ese punto de unión, entre lo que el titular autorizó y lo que el sistema realmente hace, donde una CMP como AdOpt existe para cerrar la brecha. No basta con preguntar y guardar la respuesta, hay que garantizar que la infraestructura técnica, desde la cookie hasta la capa de activación en Google y Meta, respete lo autorizado.

La conversación sobre consentimiento suele detenerse en la recolección: el visitante acepta o rechaza, el banner lo registra, listo. Pero el consentimiento solo tiene valor si sobrevive todo el recorrido del dato, desde la recolección hasta la plataforma publicitaria que va a usarlo.

Esto significa tres cosas concretas: registro auditable del consentimiento (fecha, hora, versión del aviso, decisión del titular); bloqueo técnico previo al consentimiento (los scripts de terceros no deberían cargar antes de la decisión del titular); y propagación de la señal hasta la activación (cuando el titular rechaza cookies de marketing, ese rechazo tiene que impedir realmente el envío del dato a Google y Meta, no solo ocultar un banner en pantalla).

Este último punto es donde más fallan las implementaciones, de forma silenciosa. La integridad del consentimiento, desde el clic hasta la activación, es lo que separa a una empresa en cumplimiento en el papel de una empresa en cumplimiento en la práctica.

Pensar que el cifrado resuelve el cumplimiento con la LFPDPPP. Resuelve parte de la seguridad, pero no sustituye la finalidad declarada ni los derechos ARCO del titular.

Pensar que un aviso de privacidad genérico, copiado de otro sitio, cubre la obligación de seguridad. El documento describe una intención declarada al público; la seguridad se mide por el control técnico real.

Delegar la seguridad al 100% al equipo de TI sin involucrar al área legal o de producto. Las decisiones de retención de datos (cuánto tiempo se guarda un registro) son decisiones de privacidad que impactan directamente el diseño de la seguridad: un dato que debió eliminarse es un dato que puede filtrarse.

Tratar el incidente de seguridad como un problema exclusivamente técnico. Una filtración relevante no es solo un asunto de TI, es al mismo tiempo un asunto legal, reputacional y de comunicación con los titulares afectados.

Una tienda en línea trata datos de pago, dirección de entrega e historial de compra. La privacidad aparece al configurar el aviso de cookies y las finalidades de marketing (recomendación de producto, remarketing). La seguridad aparece en la integración con las pasarelas de pago: el dato de tarjeta nunca debería transitar en texto plano por el servidor de la tienda.

El dato de salud eleva la exigencia en ambos lados a la vez. La privacidad exige finalidad estrictamente ligada a la atención del paciente. La seguridad exige control de acceso por rol, registro de auditoría de quién accedió a qué, y cifrado de extremo a extremo en cualquier sistema que almacene el historial clínico.

Bancos y fintechs suman la LFPDPPP con regulación sectorial específica, lo que suele hacer que la seguridad técnica sea más madura que el promedio del mercado. El punto ciego más común aquí no es la seguridad técnica, es la privacidad: usar el dato para un score crediticio o una oferta personalizada sin que el titular tenga claridad de que ese uso específico fue autorizado.

Quien opera el portal del titular y responde las solicitudes ARCO no puede estar desconectado del equipo técnico de seguridad. Cuando ocurre un incidente, quien evalúa la gravedad y decide si corresponde notificar a los titulares afectados necesita información técnica precisa, no solo criterio legal.

En la práctica, las empresas más maduras convierten al responsable de datos en el punto de encuentro formal entre dos comités que en muchas organizaciones nunca se hablan: el comité de privacidad (legal, marketing, producto) y el comité de seguridad de la información (TI, infraestructura, seguridad).

• ¿El aviso de privacidad refleja lo que el sistema realmente hace?
• ¿Existe un inventario de dónde está almacenado cada dato personal?
• ¿El equipo de seguridad sabe qué datos se consideran sensibles bajo la ley?
• ¿Existe un plazo de conservación definido para cada tipo de dato?
• ¿El consentimiento de cookies se aplica técnicamente, o solo se registra?

Una respuesta "no lo sé" en cualquiera de estas preguntas es una señal de que la privacidad y la seguridad de la empresa todavía operan por separado.

Con la reforma del 20 de marzo de 2025, el Instituto Nacional de Transparencia (INAI) fue extinto y sus funciones de vigilancia sobre datos personales en posesión de particulares pasaron a la Secretaría Anticorrupción y Buen Gobierno. Esto cambió a quién se reporta un incidente o una queja, pero no cambió el fondo de la obligación: la ley sigue exigiendo finalidad clara para la privacidad y medidas adecuadas para la seguridad, ahora bajo una autoridad distinta.

Para una empresa que operaba bajo el esquema anterior, esto significa revisar que cualquier referencia interna al INAI en su documentación de cumplimiento (avisos de privacidad, políticas internas, contratos con proveedores) se actualice a la nueva autoridad, y que el canal de contacto para ejercer derechos ARCO refleje el cambio.

Al momento de escribir este artículo, el reglamento de la nueva LFPDPPP (2025) sigue pendiente de publicación, lo que significa que varios detalles operativos, como plazos exactos y formatos específicos de notificación, todavía no están completamente definidos a nivel reglamentario. Esto no reduce la obligación de fondo del artículo 18, pero sí introduce cierta incertidumbre sobre el detalle procesal.

La forma más segura de operar mientras el reglamento no se publica es aplicar el estándar más exigente conocido (por ejemplo, los plazos y contenidos mínimos que otras jurisdicciones de la región, como Colombia y Perú, ya exigen de forma expresa) en lugar de esperar a que la claridad reglamentaria llegue para empezar a implementar medidas de seguridad adecuadas.

El español conecta México con varios mercados regulatorios distintos, y la seguridad de datos aparece en todos ellos con el mismo espíritu, aunque con nombres y artículos diferentes. En Colombia, la Ley 1581 de 2012 exige medidas de seguridad bajo el principio de habeas data. En Perú, la Ley 29733 impone una obligación equivalente sobre el responsable del tratamiento.

Para una empresa que opera en más de un país de la región, diseñar la seguridad técnica una sola vez, con el estándar más exigente del conjunto, suele ser más eficiente que mantener implementaciones distintas para cada país, ya que la lógica de fondo (proteger el dato contra daño, pérdida, alteración o acceso no autorizado) es prácticamente la misma en las tres legislaciones.

"Si la empresa nunca ha sufrido una filtración, la seguridad es adecuada." No haber sufrido un incidente no es prueba de que los controles sean adecuados, es solo ausencia de un evento observado hasta ahora.

"El consentimiento resuelve cualquier tratamiento de datos." El consentimiento es solo una de las bases posibles para el tratamiento, y la más frágil de todas porque puede revocarse en cualquier momento.

"La seguridad de datos es un problema de TI, no de la dirección general." Una sanción por falla de seguridad impacta directamente la operación y la reputación de la empresa, lo que la convierte en una decisión de riesgo de negocio, no solo técnica.

"Si el sitio tiene certificado SSL, los datos están seguros." El SSL protege la conexión entre el navegador y el servidor. No protege el dato una vez que llega al servidor, ni sustituye ninguna otra medida exigida por el artículo 18 de la LFPDPPP.

Imagina un sitio que muestra correctamente el aviso de cookies, registra el rechazo del visitante para cookies de marketing, y muestra en pantalla un mensaje de confirmación. Desde el punto de vista de la privacidad, todo parece correcto: el titular fue informado y eligió rechazar.

Solo que, detrás de la pantalla, la etiqueta de remarketing de Facebook ya había cargado en el momento en que la página se abrió, antes incluso de que apareciera el banner. El píxel ya capturó el identificador del visitante y ya envió el evento de visita a la plataforma publicitaria. El rechazo mostrado en pantalla no deshizo el envío que ya había ocurrido en los primeros segundos de la navegación.

Este patrón de falla es más común de lo que parece, porque el equipo de marketing suele configurar las etiquetas directamente en el Google Tag Manager, sin que su carga dependa técnicamente del resultado del banner de consentimiento.

El problema no es jurídico en sentido estricto (el aviso de privacidad puede estar correcto) ni es una falla clásica de seguridad de la información (no hubo intrusión ni filtración por acceso indebido). Es una falla de integridad entre lo que se le prometió al titular y lo que el sistema técnico realmente ejecutó.

Fallar en privacidad y fallar en seguridad generan dos tipos de exposición diferentes, y entender esa diferencia ayuda a priorizar dónde invertir primero.

Una falla de privacidad suele nacer de una queja o reclamo del propio titular: alguien percibe que su dato se usó para una finalidad que no autorizó, o que una empresa no respondió a una solicitud ARCO dentro del plazo. La autoridad recibe la queja, abre un proceso administrativo, y la revisión normalmente se enfoca en documentación: ¿existía finalidad clara? ¿el titular fue informado? ¿se atendieron sus derechos?

Una falla de seguridad suele nacer de un evento técnico: una filtración, un acceso indebido, un ataque de ransomware. La exposición aquí es doble y simultánea: la exposición regulatoria por la falla de seguridad en sí, y la exposición reputacional inmediata, porque a diferencia de una queja individual de privacidad, una filtración de datos suele hacerse pública y afecta la confianza del cliente de forma visible, generando un daño a la marca que con frecuencia supera el valor de cualquier sanción.

Alinear privacidad y seguridad no depende de una sola persona. El equipo legal o de cumplimiento define la finalidad y redacta el aviso de privacidad. El equipo técnico configura el control de acceso, el cifrado y el monitoreo.

El equipo de marketing gestiona las etiquetas de conversión que, como se explicó arriba, son uno de los puntos más frecuentes de falla silenciosa. Y el responsable de datos es quien conecta a los tres, revisando periódicamente que lo que el aviso de privacidad promete coincida con lo que el sistema técnico realmente hace.

Una empresa donde estos tres equipos nunca se sientan juntos, ni siquiera trimestralmente, tiende a descubrir la brecha entre privacidad y seguridad solo cuando ya se convirtió en un incidente reportable.

No exactamente. La privacidad es el principio más amplio, el derecho de la persona a controlar su información. La protección de datos es el conjunto de reglas jurídicas, como la LFPDPPP, que convierte ese principio en obligaciones concretas para las empresas. La seguridad de datos, a su vez, es la capa técnica que sostiene esa protección.

No. La ley no exige una certificación específica. El artículo 18 habla de medidas administrativas, técnicas y físicas de forma general, dejando que el responsable las defina según el riesgo. Certificaciones como ISO/IEC 27001 ayudan a demostrar buenas prácticas, pero no son un requisito legal directo.

El artículo 18 no distingue por tamaño de empresa: toda organización que trata datos personales necesita medidas de seguridad proporcionales al riesgo y a la sensibilidad de los datos tratados. Un negocio pequeño que guarda datos de contacto de clientes tiene la misma obligación legal que una empresa grande, aunque la complejidad de las medidas técnicas pueda variar.

La empresa puede ser responsabilizada aunque tenga un aviso de privacidad correcto, porque la filtración es una falla de seguridad bajo el artículo 18, no de privacidad. La autoridad evalúa ambos puntos por separado: si el tratamiento tenía finalidad clara y si las medidas de seguridad eran adecuadas al riesgo.

La forma más directa es auditar el comportamiento real de los scripts del sitio: verificar si las etiquetas de marketing y analítica realmente permanecen bloqueadas hasta que el consentimiento sea dado, y si el rechazo del titular detiene el envío de datos a plataformas como Google y Meta. Una CMP que integra el registro del consentimiento con el bloqueo técnico de scripts resuelve esta brecha sin depender de configuración manual en cada página del sitio.

La ley no exige, como requisito formal, una auditoría externa periódica. Lo que exige es que las medidas sean adecuadas al riesgo. Empresas que tratan volumen relevante de datos sensibles suelen contratar auditorías externas porque una evaluación independiente identifica fallas que el propio equipo interno, acostumbrado al sistema, deja de percibir.

Separar ambos conceptos ayuda a entender la ley, pero en la operación del día a día necesitan funcionar juntos. Empieza gratis con AdOpt y descubre cómo registrar el consentimiento, bloquear scripts antes de la autorización y mantener el historial auditable en una sola plataforma.

• Medidas de Seguridad de Datos en la LFPDPPP: Qué Exige la Ley en México
• Seguridad de Datos en el Consentimiento: Cómo Proteger los Datos del Usuario desde la Recolección hasta la Activación