DLP en 2026: ISO 27001 para el RGPD de la UE, NIS2 y DORA
Todo empieza con una hoja de cálculo.
A las 08:17 de un lunes, un responsable de éxito de clientes exporta 14.000 contactos corporativos desde el CRM para preparar una campaña de renovación. A las 08:24, adjunta la hoja de cálculo a un correo electrónico. A las 08:26, el correo se envía a una cuenta personal de Gmail porque el empleado quiere trabajar durante un viaje en tren. A las 08:31, el mismo archivo se carga en un servicio de notas con IA no aprobado para “limpiar duplicados”.
Todavía nada parece una brecha de seguridad. No hay nota de ransomware, ni beacon de malware, ni cuenta de administrador comprometida, ni filtración pública. Pero para el CISO, el responsable de cumplimiento y el delegado de protección de datos (DPO), la pregunta real ya ha llegado: ¿puede la organización demostrar que ese movimiento estaba permitido, clasificado, registrado, cifrado, justificado y que era reversible?
El mismo escenario se repite cada semana en los servicios financieros. Un desarrollador intenta cargar Q1_Investor_Projections_DRAFT.xlsx en una unidad personal en la nube porque la VPN va lenta. Un responsable comercial exporta una lista de clientes a una aplicación de colaboración de consumo. Un analista de soporte pega registros de clientes en una herramienta de IA no aprobada. En todos los casos, la intención puede ser la comodidad y no la mala fe, pero el riesgo es el mismo. Los datos sensibles han cruzado, o casi han cruzado, un límite que la organización no controla.
Ese es el problema moderno de la prevención de pérdida de datos. DLP ya no es solo una regla de pasarela de correo electrónico o un agente de endpoint. En 2026, la prevención de pérdida de datos eficaz es un sistema de controles gobernado y respaldado por evidencias en SaaS, almacenamiento en la nube, endpoints, dispositivos móviles, proveedores, interfaces de programación de aplicaciones, entornos de desarrollo, exportaciones de copias de seguridad, herramientas de colaboración y atajos humanos.
El Article 32 del RGPD de la UE exige medidas técnicas y organizativas adecuadas para la seguridad del tratamiento. El Article 21 de NIS2 exige medidas de ciberseguridad basadas en riesgos, incluidas ciberhigiene, control de acceso, gestión de activos, seguridad de la cadena de suministro, gestión de incidentes, cifrado y pruebas de eficacia. DORA exige que las entidades financieras gestionen el riesgo de TIC mediante gobernanza, detección, respuesta, recuperación, pruebas, supervisión de terceros y auditabilidad. ISO/IEC 27001:2022 proporciona la columna vertebral del sistema de gestión para hacer que esas obligaciones sean operativas, medibles y auditables.
El error que cometen muchas organizaciones es comprar una herramienta DLP antes de definir qué significa “pérdida”. El enfoque de Clarysec empieza antes: clasificar los datos, definir transferencias permitidas, aplicar la política, supervisar excepciones, preparar evidencias de respuesta y conectar todo con el SGSI.
Como indica Zenith Blueprint: hoja de ruta de 30 pasos para auditores en la fase Controles en acción, paso 19, Controles tecnológicos I:
La prevención de fuga de datos consiste en impedir la divulgación no autorizada o accidental de información sensible, ya salga por correo electrónico, cargas en la nube, soportes portátiles o incluso un documento impreso olvidado. El control 8.12 aborda la necesidad de supervisar, restringir y responder ante cualquier dato que salga de los límites de confianza de la organización, con independencia de que sea digital, físico o impulsado por una acción humana. Zenith Blueprint
Esa frase resume el núcleo de DLP en 2026: supervisar, restringir y responder.
Por qué DLP es ahora una cuestión de cumplimiento para el consejo
El consejo no suele preguntar si una expresión regular de DLP detecta números nacionales de identificación. Pregunta si la organización puede proteger la confianza del cliente, seguir operando, evitar exposición regulatoria y demostrar una seguridad razonable cuando algo sale mal.
Ahí es donde convergen el RGPD de la UE, NIS2 y DORA.
El RGPD de la UE se aplica ampliamente al tratamiento automatizado de datos personales, incluidos responsables y encargados establecidos en la UE, y organizaciones no pertenecientes a la UE que ofrecen bienes o servicios a personas en la UE o supervisan su comportamiento. Define los datos personales de forma amplia y cubre operaciones como recopilación, almacenamiento, uso, divulgación, supresión y destrucción. La divulgación no autorizada de datos personales, o el acceso no autorizado a ellos, puede constituir una brecha de datos personales. El Article 5 del RGPD de la UE también explicita la responsabilidad proactiva: las organizaciones no solo deben seguir principios como minimización de datos, limitación del plazo de conservación, integridad y confidencialidad, sino que deben poder demostrar el cumplimiento.
NIS2 amplía la presión más allá de la privacidad. Se aplica a muchas entidades esenciales e importantes, incluidos sectores como banca, infraestructuras de mercados financieros, proveedores de servicios de computación en la nube, proveedores de centros de datos, proveedores de servicios gestionados, proveedores de servicios gestionados de seguridad, mercados en línea, motores de búsqueda y plataformas de redes sociales. El Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos análisis de riesgos, políticas de seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, pruebas de eficacia, ciberhigiene, formación, criptografía, control de acceso, gestión de activos y autenticación.
DORA se aplica desde el 17 de enero de 2025 y actúa como el marco normativo específico de resiliencia de las TIC para el sector financiero. Para las entidades financieras incluidas en su ámbito, se trata como el acto jurídico sectorial específico de la Unión a efectos de solapamiento con NIS2. DORA incorpora DLP a la gestión del riesgo de TIC, la clasificación de incidentes, la pérdida de datos que afecte a la disponibilidad, autenticidad, integridad o confidencialidad, las pruebas de resiliencia operativa digital, la gestión de terceros de TIC y los controles contractuales.
La pregunta de DLP en 2026 no es “¿tenemos una herramienta?”. Es:
- ¿Sabemos qué información es sensible?
- ¿Sabemos dónde se almacena, trata y transfiere?
- ¿Están definidas las rutas de transferencia permitidas y prohibidas?
- ¿Los usuarios están formados y técnicamente limitados?
- ¿Están gobernadas las rutas en nube y SaaS?
- ¿Son suficientes los registros para la investigación?
- ¿Las alertas se someten a triaje y los incidentes se clasifican con rapidez?
- ¿Los proveedores y servicios de TIC externalizados están vinculados contractualmente?
- ¿Podemos demostrar que los controles están operando?
ISO/IEC 27001:2022 es muy adecuada para responder a estas preguntas porque exige contexto, requisitos de partes interesadas, evaluación de riesgos, tratamiento de riesgos, objetivos medibles, control operacional, evidencias documentadas, control de proveedores, auditoría interna, revisión por la dirección y mejora continua. No es una norma DLP, pero transforma DLP de una configuración tecnológica aislada en un proceso controlado del sistema de gestión.
La cadena de controles ISO 27001 detrás de un DLP eficaz
Un programa DLP creíble no se construye sobre un único control. Se construye sobre una cadena.
Zenith Controls: guía de cumplimiento transversal de Clarysec mapea el control ISO/IEC 27002:2022 8.12, prevención de fuga de datos, como un control preventivo y detectivo centrado en la confidencialidad, alineado con los conceptos de ciberseguridad Proteger y Detectar, con la protección de la información como capacidad operativa y la protección/defensa como dominio de seguridad. Zenith Controls
Esto importa porque los auditores esperan tanto bloqueo como visibilidad. Una regla DLP preventiva sin revisión de alertas está incompleta. Un enfoque solo de registro, sin aplicación para transferencias de alto riesgo, también es débil.
La misma guía mapea el control ISO/IEC 27002:2022 5.12, Clasificación de la información, como preventivo, de apoyo a la confidencialidad, integridad y disponibilidad, y alineado con Identificar. Mapea el control 5.14, Transferencia de información, como preventivo, de apoyo a la confidencialidad, integridad y disponibilidad, y alineado con Proteger, gestión de activos y protección de la información.
En términos prácticos, la cadena de controles DLP es la siguiente:
| Área de control ISO/IEC 27002:2022 | Función de DLP | Qué falla si falta |
|---|---|---|
| 5.9 Inventario de información y otros activos asociados | Identifica activos, propietarios y ubicaciones de datos | Los repositorios sensibles quedan fuera del alcance de DLP |
| 5.12 Clasificación de la información | Define la sensibilidad y las necesidades de tratamiento | Las reglas DLP bloquean de forma aleatoria o no detectan datos críticos |
| 5.13 Etiquetado de la información | Hace visible la clasificación y permite acciones automáticas por sistemas | Los usuarios y las herramientas no pueden distinguir datos públicos de datos confidenciales |
| 5.14 Transferencia de información | Define rutas y condiciones de transferencia aprobadas | El personal usa correo personal, unidades en la nube de consumo o mensajería no gestionada |
| 5.15 a 5.18 Control de acceso, identidad, autenticación y derechos de acceso | Limita quién puede acceder a los datos y exportarlos | Los permisos excesivos habilitan riesgo interno y extracción masiva |
| 5.19 a 5.23 Controles de proveedores y nube | Gobierna SaaS, nube y tratamiento externalizado | Los datos se fugan mediante proveedores no evaluados o shadow IT |
| 5.24 a 5.28 Gestión de incidentes | Convierte alertas DLP en acciones de respuesta y evidencias | Las alertas se ignoran, no se someten a triaje o no se notifican a tiempo |
| 5.31 y 5.34 Controles legales, regulatorios, contractuales y de privacidad | Conecta DLP con el RGPD de la UE, contratos y normas sectoriales | Los controles no reflejan obligaciones reales |
| 8.12 Prevención de fuga de datos | Supervisa, restringe y responde al movimiento saliente de datos | La información sensible sale sin detección ni control |
| 8.15 Registro de eventos y 8.16 Actividades de supervisión | Proporciona evidencias y visibilidad forense | La organización no puede demostrar qué ocurrió |
| 8.24 Uso de la criptografía | Protege los datos en tránsito y en reposo | Las transferencias aprobadas siguen exponiendo datos legibles |
Zenith Blueprint, paso 22, explica la dependencia entre inventario de activos, clasificación y DLP:
Revise su inventario de activos actual (5.9) para asegurarse de que incluye activos físicos y lógicos, propietarios y clasificaciones. Vincule este inventario a su esquema de clasificación (5.12), asegurándose de que los activos sensibles estén etiquetados y protegidos adecuadamente. Cuando sea necesario, defina conservación, copia de seguridad o aislamiento en función de la clasificación.
Por eso Clarysec rara vez empieza un encargo DLP ajustando reglas. Empezamos conciliando activos, propietarios, tipos de datos, etiquetas de clasificación, rutas de transferencia y registros de evidencias. Si la organización no puede indicar qué conjuntos de datos son confidenciales, regulados, propiedad del cliente, relacionados con pagos o críticos para sus operaciones, una herramienta DLP solo puede hacer conjeturas.
Los tres pilares de un programa DLP moderno
Un programa DLP moderno se sostiene sobre tres pilares que se refuerzan mutuamente: conocer los datos, gobernar el flujo y defender el perímetro. Estos pilares hacen que ISO/IEC 27001:2022 sea práctico para el cumplimiento del RGPD de la UE, NIS2 y DORA.
Pilar 1: Conozca sus datos mediante clasificación y etiquetado
No se puede proteger lo que no se comprende. Los controles ISO/IEC 27002:2022 5.12 y 5.13 exigen que las organizaciones clasifiquen la información y la etiqueten según su sensibilidad y sus necesidades de tratamiento. No es un ejercicio documental. Es la base de la aplicación automatizada de controles.
Para pymes, la Política de Clasificación y Etiquetado de Datos establece:
Confidencial: requiere cifrado en tránsito y en reposo, acceso restringido, aprobación explícita para compartir y destrucción segura en la eliminación. Política de Clasificación y Etiquetado de Datos - Pyme
Esta cita, de la sección “Requisitos de implementación de la política”, cláusula 6.3.3, proporciona al programa DLP cuatro condiciones aplicables: cifrado, acceso restringido, aprobación para compartir y eliminación segura.
En entornos empresariales, la Política de Clasificación y Etiquetado de Datos es aún más directa. De la sección “Requisitos de implementación de la política”, cláusula 6.2.6.2:
Bloqueo de la transmisión (por ejemplo, correo electrónico externo) para datos sensibles etiquetados incorrectamente Política de Clasificación y Etiquetado de Datos
Y de la sección “Aplicación y cumplimiento”, cláusula 8.3.2:
Validación automatizada de la clasificación mediante prevención de pérdida de datos (DLP) y herramientas de descubrimiento
Estas cláusulas convierten la clasificación en un control. Un archivo marcado como Confidencial puede activar cifrado, bloquear la transmisión externa, requerir aprobación o generar una alerta de seguridad. DLP se convierte entonces en la capa de aplicación de una política que usuarios, sistemas y auditores pueden entender.
Pilar 2: Gobierne el flujo mediante transferencia segura de información
Una vez clasificados los datos, la organización debe gobernar cómo se mueven. El control ISO/IEC 27002:2022 5.14, Transferencia de información, suele pasarse por alto, pero es donde empiezan muchos fallos DLP.
Zenith Blueprint plantea el control 5.14 como la necesidad de gobernar el flujo de información para que la transferencia sea segura, intencional y coherente con la clasificación y el propósito de negocio. Esto se aplica al correo electrónico, el intercambio seguro de archivos, las interfaces de programación de aplicaciones, las integraciones SaaS, los soportes extraíbles, los informes impresos y los portales de proveedores.
El trabajo remoto hace que esto sea especialmente importante. La Política de Trabajo Remoto, sección “Requisitos de implementación de la política”, cláusula 6.3.1.3, exige a los empleados:
Utilizar únicamente soluciones aprobadas de intercambio de archivos (por ejemplo, M365, Google Workspace con controles de prevención de pérdida de datos (DLP)) Política de Trabajo Remoto
Para móviles y BYOD, la Política de dispositivos móviles y BYOD, sección “Requisitos de implementación de la política”, cláusula 6.6.4, proporciona una aplicación concreta en el endpoint:
Las políticas de prevención de pérdida de datos (DLP) deben bloquear cargas no autorizadas, capturas de pantalla, acceso al portapapeles o intercambio de datos desde aplicaciones gestionadas hacia áreas personales. Política de dispositivos móviles y BYOD
Esto importa porque los datos no salen solo por correo electrónico. Salen mediante capturas de pantalla, sincronización del portapapeles, perfiles de navegador no gestionados, unidades personales, hojas de compartir móviles, complementos de colaboración y herramientas de IA.
La gobernanza de la nube es igualmente importante. En la Política de Uso de la Nube para pymes, sección “Requisitos de gobernanza”, cláusula 5.5:
El shadow IT, definido como el uso de herramientas en la nube no aprobadas, debe tratarse como un incumplimiento de la política y ser revisado por la dirección general y el proveedor externo de TI para determinar el riesgo y la remediación necesaria. Política de Uso de la Nube - Pyme
Para organizaciones empresariales, la Política de Uso de la Nube, sección “Requisitos de gobernanza”, cláusula 5.5, eleva el nivel de supervisión:
El equipo de seguridad de la información debe evaluar de forma rutinaria el tráfico de red, la actividad DNS y los registros para detectar el uso no autorizado de la nube (shadow IT). Los incumplimientos detectados deben investigarse con prontitud. Política de Uso de la Nube
El shadow IT no es solo una molestia para TI. Bajo el RGPD de la UE puede convertirse en divulgación ilícita o tratamiento no controlado. Bajo NIS2 es una debilidad de ciberhigiene y de cadena de suministro. Bajo DORA puede convertirse en un riesgo de terceros de TIC y en un problema de clasificación de incidentes.
Pilar 3: Defienda el perímetro con tecnología, política y concienciación DLP
El control ISO/IEC 27002:2022 8.12, prevención de fuga de datos, es el control que la mayoría asocia con DLP. Pero en un programa maduro es la última línea de defensa, no la primera.
Zenith Blueprint explica que DLP requiere un enfoque de tres capas: tecnología, política y concienciación. La tecnología incluye DLP en endpoints, seguridad del correo electrónico, inspección de contenido, seguridad de acceso a la nube, controles SaaS, controles de navegador, filtrado de tráfico saliente de red y enrutamiento de alertas. La política define lo que las herramientas aplican. La concienciación asegura que los empleados entiendan por qué el correo personal, el almacenamiento en la nube de consumo y las herramientas de IA no aprobadas no son métodos aceptables para tratar información regulada o confidencial.
El componente de respuesta es tan importante como la prevención. Zenith Blueprint, paso 19, indica:
Pero DLP no es solo prevención; también es respuesta. Si se detecta una posible fuga:
✓ Las alertas deben someterse a triaje con rapidez, ✓ El registro de eventos debe respaldar el análisis forense, ✓ El plan de respuesta a incidentes debe activarse sin demora.
Un programa DLP que bloquea eventos pero no los somete a triaje, no los investiga ni aprende de ellos no está preparado para auditorías. Solo está parcialmente desplegado.
De la fuga de una hoja de cálculo a una respuesta preparada para auditorías
Volvamos a la hoja de cálculo del lunes por la mañana.
En un programa débil, la organización descubre la carga tres semanas después durante una revisión de privacidad. Nadie sabe quién aprobó la exportación, si los datos eran datos personales, si había categorías especiales de datos, si la herramienta de IA conservó el archivo o si debe notificarse a los clientes.
En un programa diseñado por Clarysec, la secuencia es diferente.
Primero, la exportación del CRM se etiqueta como Confidencial porque contiene datos personales e información comercial de clientes. Segundo, se registra el evento de exportación. Tercero, la pasarela de correo electrónico detecta un adjunto confidencial dirigido a un dominio de correo personal y lo bloquea salvo que exista una excepción aprobada. Cuarto, el intento de carga en un servicio en la nube no aprobado genera una alerta de uso de la nube. Quinto, la alerta se somete a triaje conforme al procedimiento de respuesta a incidentes. Sexto, el equipo de seguridad determina si hubo divulgación efectiva, si los datos estaban cifrados, si el proveedor los trató o conservó, si se cumplen los criterios de brecha del RGPD de la UE y si aplican los umbrales de incidente de NIS2 o DORA.
La Política de registro y supervisión para pymes, sección “Requisitos de gobernanza”, cláusula 5.4.3, indica al equipo exactamente qué debe ser visible:
Registros de acceso: acceso a archivos (especialmente para datos sensibles o personales), cambios de permisos, uso de recursos compartidos Política de registro y supervisión - Pyme
Esa cláusula es breve, pero decisiva. Si no se registran el acceso a archivos, los cambios de permisos y el uso de recursos compartidos, la investigación DLP se convierte en conjeturas.
Bajo el Article 23 de NIS2, los incidentes significativos exigen notificación por fases: una alerta temprana en las 24 horas siguientes a tener conocimiento, una notificación de incidente en 72 horas y un informe final no más tarde de un mes después de la notificación del incidente. Bajo DORA, los Articles 17 to 19 exigen que las entidades financieras detecten, gestionen, clasifiquen, registren, escalen y notifiquen incidentes importantes relacionados con las TIC. La clasificación incluye la pérdida de datos que afecte a la disponibilidad, autenticidad, integridad o confidencialidad, junto con clientes afectados, duración, extensión geográfica, criticidad e impacto económico. Bajo el RGPD de la UE, una divulgación no autorizada de datos personales puede exigir una evaluación de brecha y, cuando se alcancen los umbrales, una notificación.
Por tanto, una alerta DLP no es simplemente un evento de seguridad. Puede convertirse en una evaluación de brecha de privacidad, un flujo de trabajo de incidente NIS2, una clasificación de incidente de TIC bajo DORA, un desencadenante de notificación a clientes y un paquete de evidencias de auditoría.
Controles DLP para el Article 32 del RGPD de la UE
El Article 32 del RGPD de la UE suele traducirse en una lista de medidas: cifrado, confidencialidad, integridad, disponibilidad, resiliencia, pruebas y restauración. Para DLP, la clave es la protección del ciclo de vida.
Los datos personales se mueven por recopilación, almacenamiento, uso, transferencia, divulgación, conservación y supresión. El Article 5 del RGPD de la UE exige minimización de datos, limitación de la finalidad, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. El Article 6 del RGPD de la UE exige base jurídica y compatibilidad de finalidad. El Article 9 del RGPD de la UE exige salvaguardas más estrictas para categorías especiales de datos personales.
DLP apoya estas obligaciones cuando está conectado con la clasificación de datos, los registros de tratamiento lícito y las rutas de transferencia aprobadas.
| Cuestión del RGPD de la UE | Implementación de DLP | Evidencias que conservar |
|---|---|---|
| Minimización de datos personales | Detectar exportaciones masivas o replicación innecesaria | Alertas de exportación y justificaciones de excepciones |
| Integridad y confidencialidad | Bloquear el uso compartido externo de datos confidenciales no cifrados | Regla DLP, requisito de cifrado y registro de evento bloqueado |
| Limitación de la finalidad | Restringir transferencias a herramientas de análisis o IA no aprobadas | Lista de SaaS permitidos, EIPD o registro de revisión de riesgos |
| Datos de categoría especial | Aplicar etiquetas y reglas de bloqueo más estrictas | Reglas de clasificación, revisión de acceso y flujo de aprobación |
| Responsabilidad proactiva | Mantener evidencias de alertas, decisiones y remediación | Tickets de incidentes, pista de auditoría y registros de revisión por la dirección |
La Política de Enmascaramiento de Datos y Seudonimización para pymes de Clarysec, sección “Propósito”, cláusula 1.2, apoya este enfoque de ciclo de vida:
Estas técnicas son obligatorias cuando no se requieren datos en producción, incluidos escenarios de desarrollo, analítica y servicios de terceros, con el fin de reducir el riesgo de exposición, uso indebido o brecha de seguridad. Política de Enmascaramiento de Datos y Seudonimización - Pyme
Este es un control práctico para el Article 32 del RGPD de la UE. Si desarrolladores, analistas o proveedores no necesitan datos personales reales, DLP no debería ser la única barrera. El enmascaramiento y la seudonimización reducen el radio de impacto antes de que los datos se muevan.
Una matriz DLP sólida alineada con la privacidad debe mapear tipos de datos personales con etiquetas de clasificación, base jurídica, sistemas aprobados, métodos de exportación aprobados, requisitos de cifrado, reglas DLP, reglas de conservación y desencadenantes de incidentes. Esa matriz se convierte en el puente entre la gobernanza de la privacidad y las operaciones de seguridad.
Ciberhigiene NIS2 y DLP más allá del equipo de privacidad
NIS2 cambia la conversación sobre DLP porque encuadra la fuga como parte de la ciberhigiene y la resiliencia, no solo de la privacidad.
El Article 20 exige que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implementación y reciban formación en ciberseguridad. El Article 21 exige medidas adecuadas y proporcionadas en políticas, gestión de incidentes, continuidad, cadena de suministro, desarrollo seguro, pruebas de eficacia, ciberhigiene, formación, criptografía, seguridad de RR. HH., control de acceso y gestión de activos. El Article 25 fomenta el uso de normas y especificaciones técnicas europeas e internacionales pertinentes.
DLP contribuye directamente a estas áreas:
| Área del Article 21 de NIS2 | Contribución de DLP |
|---|---|
| Análisis de riesgos y políticas de seguridad de los sistemas de información | Identifica escenarios de fuga de datos y define requisitos de tratamiento |
| Gestión de incidentes | Enruta la exfiltración sospechosa hacia triaje, escalado y flujos de notificación |
| Continuidad del negocio | Protege información operativa crítica y de clientes |
| Seguridad de la cadena de suministro | Gobierna transferencias de datos a terceros y acceso de proveedores |
| Desarrollo seguro | Evita fugas de código fuente, secretos y datos de prueba en producción |
| Pruebas de eficacia | Permite simulaciones DLP, ejercicios de mesa y seguimiento de remediación |
| Ciberhigiene y formación | Enseña a los usuarios prácticas seguras de transferencia y riesgos de shadow IT |
| Criptografía | Aplica cifrado para transferencias confidenciales |
| Control de acceso y gestión de activos | Limita quién puede exportar activos sensibles y registra la actividad |
La Política de Seguridad de Redes para pymes, sección “Objetivos”, cláusula 3.4, hace explícito el objetivo de exfiltración:
Prevenir la propagación de malware y la exfiltración de datos a través de canales de red Política de Seguridad de Redes - Pyme
Para NIS2, este tipo de objetivo proporciona a los auditores una ruta directa de prueba: mostrar filtrado saliente, supervisión DNS, registros de proxy, alertas de endpoint, intentos de carga bloqueados y tickets de investigación.
Zenith Blueprint, paso 23, añade una acción específica de nube que ya es esencial para proveedores digitales y de TIC cubiertos por NIS2:
Liste todos los servicios en la nube actualmente en uso (5.23), incluido el shadow IT cuando se conozca. Identifique quién los aprobó y si se realizó diligencia debida. Desarrolle una lista de verificación ligera de evaluación que cubra ubicación de datos, modelo de acceso, registro de eventos y cifrado. Para servicios futuros, asegúrese de que la lista de verificación se integre en el proceso de adquisición o de incorporación de TI.
Muchas organizaciones fallan aquí. Tienen un alcance del SGSI y un registro de proveedores, pero no una lista real de herramientas SaaS donde los empleados mueven datos regulados o de clientes. DLP sin descubrimiento de nube está ciego.
Riesgo de TIC de DORA: DLP para entidades financieras y proveedores
Para las entidades financieras, DLP debe encajar en el marco de gestión del riesgo de TIC de DORA.
El Article 5 de DORA exige un marco interno de gobernanza y control para la gestión del riesgo de TIC. El órgano de dirección sigue siendo responsable del riesgo de TIC, de políticas que preserven la disponibilidad, autenticidad, integridad y confidencialidad de los datos, roles claros de TIC, estrategia de resiliencia operativa digital, tolerancia al riesgo de TIC, planes de continuidad y respuesta/recuperación, planes de auditoría, recursos, política de terceros y canales de notificación.
El Article 6 exige un marco documentado de gestión del riesgo de TIC que cubra estrategias, políticas, procedimientos, protocolos de TIC y herramientas para proteger la información y los activos de TIC. El Article 9 aborda protección y prevención. Los Articles 11 to 14 añaden continuidad, respuesta, recuperación, copia de seguridad, restauración, comprobaciones de integridad de datos, lecciones aprendidas, formación de concienciación y comunicaciones de crisis.
DLP encaja en ese marco como capacidad de protección, detección, respuesta y prueba.
DORA también hace inevitable la gestión del riesgo de terceros. Los Articles 28 to 30 exigen gestión del riesgo de terceros de TIC, registros de contratos de servicios de TIC, diligencia debida previa a la contratación, requisitos contractuales, derechos de auditoría e inspección, derechos de terminación, estrategias de salida, descripciones de servicio, ubicaciones de tratamiento y almacenamiento de datos, acceso a datos, recuperación y devolución, asistencia en incidentes, cooperación con autoridades, medidas de seguridad y condiciones de subcontratación.
Para una fintech o un banco, DLP no puede detenerse en el perímetro de Microsoft 365 o Google Workspace. Debe cubrir procesadores de pagos, proveedores de verificación de identidad, plataformas CRM, almacenes de datos, infraestructura en la nube, mesas de soporte externalizadas, proveedores de servicios gestionados e integraciones SaaS críticas.
| Expectativa de DORA | Evidencia DLP |
|---|---|
| Gobernanza de TIC asumida por el consejo | Riesgo DLP aceptado por la dirección, roles asignados y presupuesto aprobado |
| Disponibilidad, autenticidad, integridad y confidencialidad de los datos | Clasificación, cifrado, reglas DLP y restricciones de acceso |
| Ciclo de vida del incidente | Triaje de alertas DLP, clasificación, análisis de causa raíz y escalado |
| Pruebas de resiliencia | Simulaciones DLP, escenarios de exfiltración y seguimiento de remediación |
| Riesgo de terceros de TIC | Diligencia debida de proveedores, cláusulas DLP contractuales y evidencias de ubicación de datos |
| Auditabilidad | Registros, historial de cambios de reglas, aprobaciones de excepciones y revisión por la dirección |
Esto es especialmente importante cuando DORA actúa como el acto jurídico sectorial específico de la Unión para obligaciones NIS2 solapadas. Los controles siguen teniendo que existir. La vía de notificación y supervisión puede diferir.
Un sprint de 90 minutos para una regla DLP
Clarysec utiliza un sprint práctico con clientes que necesitan avances rápidos sin fingir que un programa DLP completo puede construirse en una sola reunión. El objetivo es implementar un control DLP de alto valor desde la política hasta la evidencia.
Paso 1: Elija un tipo de dato y una ruta de transferencia
Elija “datos personales de clientes exportados desde el CRM y enviados externamente por correo electrónico”. No empiece con todos los repositorios, países y tipos de datos.
Paso 2: Confirme la clasificación y la etiqueta
Use la política de clasificación para confirmar que esta exportación es Confidencial. En una pyme, la cláusula 6.3.3 exige cifrado, acceso restringido, aprobación explícita para compartir y destrucción segura. En una empresa, la Política de Clasificación y Etiquetado de Datos apoya el bloqueo de transmisión para datos sensibles etiquetados incorrectamente y la validación automatizada mediante DLP y herramientas de descubrimiento.
Paso 3: Defina el patrón de transferencia permitido
Permitido: exportación del CRM enviada a un dominio de cliente aprobado mediante correo cifrado o una plataforma aprobada de intercambio seguro de archivos, con justificación de negocio.
No permitido: correo personal, enlaces públicos de intercambio de archivos, herramientas de IA no aprobadas y unidades en la nube no gestionadas.
Esto se alinea con Zenith Blueprint, paso 22, que indica:
Si la información “Confidencial” no puede salir de la empresa sin cifrado, los sistemas de correo electrónico deben aplicar políticas de cifrado o bloquear la transmisión externa.
Paso 4: Configure la regla DLP mínima
Configure la plataforma de correo o colaboración para detectar la etiqueta confidencial, el patrón de datos personales o la convención de nombres de archivos de exportación. Empiece con supervisión si se esperan falsos positivos y después pase al bloqueo para dominios personales y destinatarios no aprobados.
Paso 5: Habilite el registro de eventos y el enrutamiento de alertas
Asegúrese de que los registros capturen acceso a archivos, cambios de permisos y uso de recursos compartidos, según exige la Política de registro y supervisión - Pyme. Enrute las alertas a la cola del sistema de tickets con severidad, tipo de dato, remitente, destinatario, nombre de archivo, acción realizada y revisor.
Paso 6: Pruebe tres escenarios
Pruebe una transferencia cifrada aprobada a un cliente, una transferencia bloqueada a un correo personal y un intento de carga en modo solo alerta a un dominio en la nube no aprobado.
Paso 7: Conserve evidencias
Guarde la referencia de la cláusula de la política, la captura de pantalla de la regla DLP, los resultados de las pruebas, el ticket de alerta, la decisión del revisor y la aprobación de la dirección. Añada el control al plan de tratamiento de riesgos y a la Declaración de Aplicabilidad.
En términos de ISO/IEC 27001:2022, este ejercicio conecta la cláusula 6.1.2 evaluación de riesgos, la cláusula 6.1.3 tratamiento de riesgos, la cláusula 8 planificación y control operacional, el Anexo A transferencia de información, prevención de fuga de datos, registro de eventos, supervisión, controles de proveedores y nube, y la cláusula 9 evaluación del desempeño.
Mapeo de cumplimiento transversal: un programa DLP, múltiples obligaciones
La fortaleza del enfoque de Clarysec es que evita construir pilas de controles separadas para el RGPD de la UE, NIS2, DORA, NIST y COBIT. Un programa DLP bien diseñado puede satisfacer múltiples expectativas si las evidencias se estructuran correctamente.
| Marco | Qué espera de DLP | Patrón de evidencias de Clarysec |
|---|---|---|
| ISO/IEC 27001:2022 | Controles basados en riesgos, Declaración de Aplicabilidad (SoA), propiedad, evidencias operativas y mejora continua | Registro de riesgos, SoA, mapeo de políticas, reglas DLP, registros y revisión por la dirección |
| RGPD de la UE Article 32 | Medidas técnicas y organizativas adecuadas para la seguridad de los datos personales | Clasificación, cifrado, control de acceso, enmascaramiento, alertas DLP y evaluación de brecha |
| NIS2 | Ciberhigiene, control de acceso, gestión de activos, cifrado, gestión de incidentes y seguridad de la cadena de suministro | Políticas aprobadas, formación, revisiones de proveedores, flujo de trabajo de incidentes y preparación para notificación en 24/72 horas |
| DORA | Gobernanza del riesgo de TIC, gestión de incidentes, pruebas de resiliencia y supervisión de terceros | Marco de riesgo de TIC, pruebas DLP, clasificación de incidentes, contratos de proveedores y pista de auditoría |
| NIST CSF 2.0 | Gobernanza, perfiles, riesgo de cadena de suministro, resultados de respuesta y recuperación | Perfil actual y objetivo, plan de deficiencias, criticidad de proveedores y registros de respuesta |
| COBIT 2019 | Objetivos de gobernanza, propiedad de controles, capacidad de procesos y evidencias de aseguramiento | RACI, métricas de proceso, informes de desempeño de controles y hallazgos de auditoría interna |
NIST CSF 2.0 es útil como capa de comunicación. Su función GOVERN apoya el seguimiento de requisitos legales, regulatorios y contractuales, apetito de riesgo, aplicación de políticas, roles y supervisión. Su método de perfiles ayuda a las organizaciones a delimitar la postura actual y objetivo, documentar deficiencias e implementar un plan de acción. Sus funciones RESPOND y RECOVER apoyan la contención de incidentes DLP, el análisis de causa raíz, la preservación de evidencias y la restauración.
COBIT 2019 añade una perspectiva de gobernanza. Un auditor orientado a COBIT preguntará si los objetivos DLP están alineados con los objetivos empresariales, si la propiedad está clara, si existen indicadores de rendimiento, si el apetito de riesgo está definido y si la dirección recibe informes significativos.
Cómo auditarán los auditores su programa DLP
Las auditorías DLP rara vez se reducen a una captura de pantalla. Distintos perfiles de auditoría generan distintas expectativas de evidencia.
| Perspectiva del auditor | Pregunta probable de auditoría | Evidencia que funciona |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿El riesgo DLP está identificado, tratado, implementado y evidenciado a través del SGSI? | Evaluación de riesgos, SoA, plan de tratamiento de riesgos, políticas, configuración DLP y registros operativos |
| Auditor del RGPD de la UE o de privacidad | ¿Puede demostrar que los datos personales están protegidos, minimizados, transferidos lícitamente y evaluados ante brechas? | Inventario de datos, alineación con el registro de actividades de tratamiento, clasificación, registros de transferencia, resultados de EIPD y registro de decisión de brecha |
| Evaluador NIS2 | ¿Las medidas relacionadas con DLP de ciberhigiene, acceso, incidentes, proveedores y cifrado están aprobadas y probadas? | Aprobación de la dirección, registros de formación, guías operativas de incidentes, comprobaciones de proveedores y ejercicio de cronograma de notificación |
| Supervisor DORA o auditoría interna | ¿DLP apoya el riesgo de TIC, la confidencialidad de los datos, la clasificación de incidentes, las pruebas de resiliencia y la supervisión de terceros? | Marco de riesgo de TIC, programa de pruebas, registros de clasificación de incidentes, contratos de proveedores y planes de salida |
| Evaluador NIST | ¿Los resultados DLP están gobernados, perfilados, priorizados, supervisados y mejorados? | Perfil actual y objetivo, POA&M, registros de gobernanza y evidencias de respuesta |
| Auditor COBIT 2019 o ISACA | ¿DLP se gobierna como un proceso con propietarios responsables, métricas y aseguramiento? | RACI, KPI, KRI, descripciones de proceso, pruebas de controles y seguimiento de remediación |
Un paquete de auditoría DLP sólido incluye declaración de alcance y riesgo, esquema de clasificación, métodos de transferencia aprobados, reglas DLP, aprobaciones de excepciones, diseño de registro de eventos, procedimiento de triaje de alertas, árbol de decisión de notificación de incidentes, inventario de proveedores y nube, resultados de pruebas y registros de remediación.
Fallos DLP comunes en 2026
Los fallos DLP más comunes son operativos, no exóticos.
Primero, la clasificación es opcional o incoherente. Las etiquetas existen en la política, pero los usuarios no las aplican, los sistemas no las hacen cumplir y los repositorios contienen años de archivos sensibles sin etiquetar.
Segundo, DLP se despliega en modo solo alerta para siempre. El modo solo alerta es útil durante el ajuste, pero una transferencia de alto riesgo por correo personal de datos confidenciales de clientes debería acabar bloqueándose salvo que exista una excepción aprobada.
Tercero, el shadow IT se trata como una molestia de TI en lugar de un riesgo de protección de datos. La Política de Uso de la Nube y la Política de Uso de la Nube para pymes están diseñadas para hacer que las herramientas en la nube no aprobadas sean visibles, revisables y remediables.
Cuarto, los registros no son suficientes para la investigación. Si el equipo de seguridad no puede reconstruir quién accedió, compartió, descargó, cargó o cambió permisos, la organización no puede evaluar con confianza las obligaciones de notificación del RGPD de la UE, NIS2 o DORA.
Quinto, los proveedores quedan fuera del modelo DLP. Los Articles 28 to 30 de DORA hacen esto especialmente peligroso para las entidades financieras, pero el problema afecta a todos los sectores. Los contratos deben definir ubicaciones de datos, acceso, recuperación, devolución, asistencia en incidentes, medidas de seguridad, subcontratación y derechos de auditoría.
Sexto, la respuesta a incidentes no incluye escenarios DLP. Un correo mal dirigido, una carga SaaS no autorizada o una exportación masiva del CRM deben tener un procedimiento de respuesta, criterios de severidad y una ruta de decisión de notificación.
Por último, las organizaciones olvidan los canales físicos y humanos. Zenith Blueprint recuerda que DLP incluye conductas de escritorio limpio, destrucción segura, colas de impresión bloqueadas, registros de auditoría de impresoras y concienciación de empleados. Un programa DLP que ignora el papel, las capturas de pantalla y las conversaciones está incompleto.
Construya un programa DLP en el que los auditores puedan confiar
Si su programa DLP es actualmente una configuración de herramienta, 2026 es el año para convertirlo en un sistema de controles gobernado y respaldado por evidencias.
Empiece con tres acciones prácticas:
- Seleccione sus tres principales tipos de datos sensibles, como datos personales de clientes, datos de pago y código fuente.
- Mapee dónde se mueven, incluidos correo electrónico, SaaS, almacenamiento en la nube, endpoints, interfaces de programación de aplicaciones, proveedores y entornos de desarrollo.
- Construya una regla DLP aplicable por cada tipo de dato, vinculada a política, registro de eventos, respuesta a incidentes y conservación de evidencias.
Clarysec puede ayudarle a acelerar este proceso mediante Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, Zenith Controls: guía de cumplimiento transversal Zenith Controls y políticas listas para adaptar, como la Política de Clasificación y Etiquetado de Datos Política de Clasificación y Etiquetado de Datos, Política de Trabajo Remoto Política de Trabajo Remoto, Política de Uso de la Nube Política de Uso de la Nube, Política de registro y supervisión para pymes Política de registro y supervisión - Pyme y Política de dispositivos móviles y BYOD Política de dispositivos móviles y BYOD.
El objetivo no es impedir que todos los archivos se muevan. El objetivo es que el movimiento seguro sea el valor por defecto, que el movimiento arriesgado sea visible, que el movimiento prohibido se bloquee y que toda excepción tenga rendición de cuentas.
Descargue los kits de herramientas de Clarysec, revise su paquete de evidencias DLP y reserve una evaluación de preparación para comprobar si sus controles actuales pueden resistir el escrutinio del Article 32 del RGPD de la UE, las expectativas de ciberhigiene de NIS2 y la revisión del riesgo de TIC de DORA.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
