Implementación de DLP en Microsoft 365: reglas, excepciones y buenas prácticas

Implantar correctamente la prevención de pérdida de datos (DLP) en Microsoft 365 no va solo de activar un par de políticas y cruzar los dedos. Requiere entender muy bien qué datos manejas, quién los utiliza, dónde se mueven y qué impacto tiene bloquear o permitir determinadas acciones. Si no se diseña con cabeza, una política DLP puede frenar procesos clave del negocio, generar falsos positivos a montones y terminar desactivada “para que la gente pueda trabajar”.

En este artículo te voy a explicar de forma muy completa cómo abordar la implementación de DLP en Microsoft 365 (Exchange, SharePoint, OneDrive, Teams, dispositivos, aplicaciones en la nube y tráfico web), cómo funcionan las reglas, condiciones, acciones y excepciones, y qué estrategia seguir para desplegarlo sin cargarte la operativa diaria. Está orientado a entornos reales, con regulaciones, usuarios que van con prisa y equipos de TI que no tienen tiempo que perder.

Conceptos básicos de DLP en Microsoft 365 y Microsoft Purview

En el ecosistema de Microsoft 365, la funcionalidad DLP se integra dentro de Microsoft Purview, que es el paraguas de cumplimiento, protección de la información y gobierno de datos. Desde el portal de Purview puedes crear directivas que detectan, supervisan y protegen datos confidenciales en múltiples ubicaciones y escenarios:

Aplicaciones empresariales y dispositivos: correo de Exchange Online, sitios de SharePoint, cuentas de OneDrive, chats y canales de Teams, aplicaciones de Office (Word, Excel, PowerPoint), dispositivos Windows 10/11 y macOS, repositorios de archivos locales y SharePoint local, áreas de trabajo de Fabric y Power BI, Microsoft 365 Copilot, aplicaciones SaaS integradas a través de Defender for Cloud Apps.
Tráfico web inspeccionado: datos que salen por la red y por Microsoft Edge para empresas hacia aplicaciones en la nube no administradas, como servicios de almacenamiento, herramientas colaborativas o plataformas de IA generativa (ChatGPT, Google Gemini, DeepSeek, etc.).

Antes de empezar: licencias, permisos y componentes clave

Para desplegar DLP en serio, necesitas revisar primero licenciamiento y permisos. Muchas de las capacidades avanzadas (por ejemplo, DLP de punto de conexión, clasificación avanzada, EDM, clasificadores entrenables o tráfico web inspeccionado) están ligadas a planes de Microsoft 365 y Microsoft Purview de gama media-alta (E5, add-ons de cumplimiento, etc.). Conviene revisar la guía de licenciamiento de seguridad y cumplimiento de Microsoft 365 porque incluso dentro de la misma característica hay opciones que cambian según el plan.

En cuanto a permisos, la cuenta que crea y gestiona las directivas debe pertenecer a grupos de rol como Administrador de cumplimiento, Administrador de datos de cumplimiento, Administrador de Information Protection o Administrador de Seguridad. Además, hay roles granulares específicos de DLP e Information Protection (administrador, analista, investigador, lector) que permiten repartir responsabilidades y limitar el acceso según el principio de mínimo privilegio. Esta separación es clave cuando entran en juego datos muy sensibles y auditorías.

Otro componente importante son las unidades administrativas de Microsoft Purview. Te permiten segmentar el ámbito de administración por regiones, filiales, departamentos o conjuntos de usuarios, de modo que un administrador regional solo gestione las directivas de su parte del negocio. Las directivas DLP pueden restringirse a estas unidades para respetar límites organizativos y regulatorios.

Planificación de la implementación de DLP: stakeholders, datos y estrategia

Una implantación sólida de DLP arranca siempre con una fase de planificación estructurada. Aquí es donde se suele fallar por ir demasiado deprisa. Hay cuatro piezas que debes alinear desde el principio: personas clave, categorías de datos, objetivos de protección y plan de despliegue.

Identificación de las partes interesadas

No basta con que TI decida qué se bloquea y qué no. Las políticas DLP afectan a procesos de negocio transversales, así que hay que sentar a la mesa a cumplimiento, legal, riesgos, seguridad, propietarios de datos y negocio. Son ellos quienes pueden:

Enumerar las normativas, leyes y estándares que aplican (RGPD, HIPAA, CCPA, regulaciones financieras, sectoriales, etc.).
Definir las categorías de información sensible prioritarias (financiera, salud, privacidad, propiedad intelectual, datos personalizados).
Describir los procesos de negocio donde se usan esos datos (facturación, auditoría, atención al cliente, RR.HH., I+D, soporte, etc.).
Determinar qué comportamientos de riesgo deben limitarse (envío externo, uso de nubes no autorizadas, copia a USB, impresión, pegado en webs de IA, etc.).
Fijar la prioridad de protección: qué tipos de datos y procesos deben cubrirse primero.
Diseñar el proceso de revisión y respuesta ante alertas DLP: quién investiga, quién decide, tiempos de respuesta y flujo de escalado.

En la práctica, muchas organizaciones concluyen que la demanda es sobre todo de cumplimiento normativo y regulatorio (protección de datos personales, financieros, clínicos…) y en menor medida de protección de propiedad intelectual. Ambas dimensiones deben estar presentes en tu estrategia, pero con pesos distintos según tu sector.

Describir las categorías de información confidencial

El siguiente paso consiste en aterrizar, con palabras del negocio, qué datos entran en cada categoría. Microsoft Purview diferencia, entre otros, datos financieros, sanitarios, de privacidad y personalizados, pero tú tienes que traducir eso a tu realidad. Ejemplos típicos:

“Actuamos como encargados de tratamiento, así que debemos imponer controles sobre todos los datos de interesados y datos financieros que nos ceden nuestros clientes.”
“Nuestra prioridad es proteger planos, código fuente, documentación técnica y estudios de I+D, además de impedir que claves y contraseñas salgan fuera.”

Esta definición se alinea después con tipos de información confidencial nativos (números de tarjeta de crédito, IBAN, SSN, datos personales de EEUU, de la UE, etc.), clasificadores entrenables (p.ej. “contratos laborales”, “documentación de red”), coincidencia exacta de datos para registros maestros o datos de clientes, y etiquetas de confidencialidad.

Objetivos de protección y tolerancia a la fuga

Con las categorías claras y los procesos identificados, las partes interesadas deben definir objetivos concretos y tolerancia al riesgo. Algunas preguntas clave:

¿Qué regulaciones debo demostrar que cumplo y con qué nivel de detalle de evidencia?
¿Qué tipo de fuga es inaceptable (por ejemplo, nunca enviar tarjetas de crédito fuera, nunca publicar historiales médicos en la nube, etc.)?
¿Hasta qué punto estoy dispuesto a aceptar falsos positivos o impacto en productividad a cambio de más protección?
¿En qué casos los usuarios deben poder invalidar un bloqueo con justificación y en cuáles no?

Ejemplo típico: seguridad y legal exigen “cero filtraciones” de números de tarjeta de crédito fuera de la organización, pero el área de auditoría interna necesita enviarlos a auditores externos de forma periódica. Si aplicas un bloqueo duro sin excepciones, rompes el proceso y generas costes extra. La solución pasa por combinar bloqueo general con excepciones controladas (ciertos usuarios o grupos, modos solo auditoría, etiquetado+cifrado, dominios permitidos, etc.). Incidentes como filtración que expuso datos de usuarios ilustran el riesgo real y por qué conviene planificar las excepciones.

Cómo localizar drivers problemáticos sin reinstalar Windows

Definir el plan de implementación

Con las bases claras, toca diseñar un plan con estado inicial, estado objetivo y pasos intermedios. Un plan completo suele incluir:

Mapa de situación actual: qué datos hay, dónde están (M365, sistemas locales, nubes de terceros), qué protecciones existen, qué se está compartiendo.
Enfoque para descubrir y clasificar datos: uso de clasificación de datos de Purview, explorador de contenido y actividad, analizador de información para repositorios locales, integración con Defender for Cloud Apps, etc.
Estrategia de diseño de directivas: orden de despliegue (por plataforma, por grupo de usuarios, por tipo de dato), plantillas que se aprovecharán, escenarios prioritarios.
Plan de requisitos previos técnicos: versiones de Windows y macOS, instalación de agentes de punto de conexión, configuración del analizador para repositorios locales, extensión de navegador para Chrome/Firefox, KBs requeridos, etc.
Secuencia de modo simulación → simulación con sugerencias → aplicación completa, con criterios claros para avanzar de fase.
Plan de formación y comunicación al usuario final: mensajes, FAQs, ejemplos, explicación de las sugerencias de directiva y del porqué de los cambios.
Ciclo de revisión y ajuste continuo: frecuencia de revisión, uso de informes, explorador de actividad, alertas y telemetría para ir afinando.

Descubrimiento de datos confidenciales y clasificación

Antes de decidir qué bloquear, debes saber qué datos sensibles tienes y dónde residen. Aquí entran en juego varias capacidades de Microsoft Purview:

Clasificación de datos con representaciones gráficas y estadísticas de tipos de información confidencial detectados en M365 y, extendido, en nubes de terceros y en local.
Explorador de contenido para ver dónde están los elementos que contienen ciertos tipos de información o etiquetas de confidencialidad.
Explorador de actividad para revisar qué se está haciendo con esos elementos: quién los abre, los comparte, los mueve, los etiqueta, etc.
Analizador de Information Protection para examinar repositorios locales (compartidos de archivos, SharePoint on-prem, etc.) y aplicar clasificación y protección.
Integración con Defender for Cloud Apps para descubrir, clasificar y etiquetar datos en nubes como Box o Google Drive.

Mientras defines tu estrategia, puedes empezar a proteger de forma progresiva con etiquetado manual, automático y por defecto. Por ejemplo, configurar etiquetas de confidencialidad con acciones de cifrado, marcas de contenido, restricciones de acceso y obligatoriedad de justificación al bajar de nivel. Después, conectas esas etiquetas con directivas DLP que las usan como condición (“si el documento está etiquetado como ‘Extremadamente confidencial’, no permitir compartir externo, imprimir o copiar a USB”).

Arquitectura de una directiva DLP: ubicaciones, condiciones, acciones y excepciones

Las directivas DLP de Microsoft Purview comparten una estructura común que se aplica tanto a correo, SharePoint, OneDrive y Teams como a dispositivos, aplicaciones en la nube y tráfico web. Cada directiva define:

Qué quieres supervisar (plantilla predefinida o directiva personalizada).
Ámbito administrativo (unidad administrativa completa o subconjunto).
Ubicaciones a las que se aplica (Exchange, SharePoint, OneDrive, Teams, Dispositivos, repositorios locales, Fabric/Power BI, Copilot, Defender for Cloud Apps, tráfico web).
Condiciones que deben cumplirse (tipos de información confidencial, etiquetas, quién envía y recibe, dominios, tamaño, protección con contraseña, etc.).
Excepciones (las mismas condiciones, pero invertidas: remitentes, destinatarios, ubicación, etc., que deben quedar fuera de la regla).
Acciones que se ejecutan cuando se cumple la condición (bloquear, bloquear con invalidación, auditar solo, cifrar, redirigir, enviar a cuarentena, mostrar sugerencias de directiva, modificar encabezados, anteponer texto al asunto, etc.).

Ubicaciones admitidas y ámbito

En el asistente de creación de directivas eliges dónde quiere que Purview supervise y aplique controles. Cada ubicación tiene sus propias opciones de inclusión/exclusión:

Ubicación	Filtrado de ámbito
Correo de Exchange Online	Por usuarios, grupos y grupos de distribución.
Sitios de SharePoint	Por sitios concretos o todos.
Cuentas de OneDrive	Por cuentas individuales o grupos de distribución.
Mensajes de Teams (chats y canales)	Por usuarios o grupos.
Dispositivos Windows 10/11 y macOS	Por usuarios y grupos, y por dispositivos y grupos de dispositivos.
Defender for Cloud Apps	Por instancia de aplicación en la nube.
Repositorios locales	Por rutas de archivo o carpetas.
Fabric y Power BI	Por áreas de trabajo.
Microsoft 365 Copilot	Por usuarios o grupos.

Este nivel de detalle te permite crear, por ejemplo, una directiva que solo afecte a auditores internos y a sus sitios de trabajo, o una directiva de punto de conexión para equipos de Call Center y evitar, por ejemplo, que adjunten determinados tipos de archivos o datos a correos o chats.

Condiciones y excepciones: cómo se detectan los escenarios

Las condiciones de una regla DLP definen el patrón de datos y contexto que debe cumplirse para disparar la acción. En Exchange, SharePoint, OneDrive y Teams hay un gran número de condiciones disponibles; algunas se centran en remitentes/destinatarios, otras en contenido, asunto, datos adjuntos o propiedades del mensaje. Para cada condición existe, por lo general, su equivalente como excepción, con la que puedes refinar y evitar falsos positivos.

Algunos grupos importantes de condiciones en Exchange (válidas también como excepciones):

Remitentes: “El remitente es”, “El remitente es miembro de”, “Dominio del remitente es”, “Ámbito del remitente (interno/externo)”, propiedades Entra ID del remitente que contienen palabras o coinciden con patrones, dirección del remitente que contiene palabras o coincide con expresiones regulares. Además, puedes elegir si la evaluación se hace sobre la dirección de encabezado, el sobre SMTP o ambos.
Destinatarios: “El destinatario es”, “Dominio del destinatario es”, “Enviado al miembro de”, propiedades Entra ID del destinatario, recuento de destinatarios únicos, recuento de dominios destinatarios, ámbito del destinatario (interno/externo). Algunas disparan bifurcación del mensaje (se entrega solo a parte de los destinatarios).
Contenido, asunto y cuerpo: asunto o cuerpo que contienen palabras o patrones; contenido que contiene tipos de información confidencial; contenido sin etiqueta de confidencialidad; combinación de asunto o cuerpo con expresiones regulares.
Datos adjuntos: adjuntos protegidos con contraseña, extensiones de archivo específicas, adjuntos no reconocidos o cuyo análisis excede los límites, nombre del documento que contiene palabras o patrones, propiedades personalizadas, tamaño del adjunto, contenido del adjunto que contiene palabras o patrones.
Propiedades del mensaje: importancia, juegos de caracteres, mensajes con invalidación de remitente previa, tipo de mensaje (respuesta automática, reenvío, cifrado, calendario, correo de voz, IRM, etc.), tamaño del mensaje.

Por ejemplo, puedes crear una regla que coincida cuando un correo interno de un usuario de finanzas, con asunto que contiene “estado financiero” y un adjunto Excel de más de X MB, se envía a un dominio externo no aprobado, y la hoja incluye un cierto tipo de información confidencial. A la inversa, una excepción podría excluir a un grupo de auditores externos y a un dominio socio específico, permitiendo esa comunicación.

Acciones disponibles: bloqueo, cifrado, redirección y más

Cuando las condiciones se cumplen (y no aplica ninguna excepción), la regla ejecuta una o varias acciones. Algunas son puramente de transporte de correo y otras afectan a cómo se puede acceder al contenido en servicios de Microsoft 365:

qué es una búsqueda semántica en Copilot

DLP de punto de conexión: dispositivos, rutas excluidas y clasificación avanzada

La parte más potente (y a la vez delicada) de DLP en Microsoft 365 es el componente de punto de conexión, que supervisa actividades de archivos en Windows 10/11 y macOS. Aquí no miras solo correos o sitios, sino cualquier acción sobre ficheros en el dispositivo: copiar a USB, copiar a recursos compartidos de red, imprimir, copiar al portapapeles, cargas a servicios en la nube, uso de Bluetooth, RDP, etc.

Desde la configuración central de DLP de punto de conexión en el portal de Purview puedes ajustar:

Clasificación avanzada (envío a la nube para tecnologías como EDM, clasificadores entrenables, OCR, entidades con nombre), con posibilidad de limitar ancho de banda diario por dispositivo.
Protección avanzada basada en etiquetas, que permite trabajar con archivos etiquetados (incluso no Office y PDF) en estado sin cifrar en local, pero asegurar que se cifran justo antes de salir del dispositivo.
Exclusión de rutas de archivo para reducir ruido y carga: patrones específicos y variables de entorno en Windows, rutas recomendadas en macOS. Hay rutas excluidas por defecto (carpetas temporales, cachés de navegador, etc.).
Cobertura de recursos compartidos de red y exclusiones, así como interacción con repositorios locales DLP y protección Just-In-Time.
Aplicaciones restringidas y grupos de aplicaciones: colecciones de aplicaciones cuyas acciones sobre archivos protegidos puedes auditar o bloquear (incluyendo variantes web accedidas desde Edge).
Bluetooth no permitido, extensiones de archivo no admitidas, grupos de dispositivos USB, grupos de impresoras y grupos de recursos compartidos de red para un control fino.
Configuración de VPN: aplicar acciones distintas cuando el tráfico pasa por una red corporativa concreta.

Si habilitas la clasificación avanzada, ten en cuenta límites de tamaño (64 MB para texto, 50 MB para imagen con OCR) y compatibilidad de versiones de Windows. Al superarse el límite de ancho de banda configurado, el cliente deja de enviar contenido a la nube y recurre a la clasificación local reducida, por lo que algunos tipos avanzados dejan de detectarse hasta que el contador baja. Para casos de endpoint y privacidad, consulta cómo controlar la telemetría en Windows 11.

Control de aplicaciones, almacenamiento en la nube y IA generativa

Un escenario cada vez más crítico es evitar que datos sensibles acaben en aplicaciones no autorizadas (nubes de terceros, clientes de sincronización, apps de escritorio o navegadores no permitidos) y, sobre todo, que se peguen o suban a sitios de IA generativa. Para ello, Microsoft Purview ofrece varios mecanismos combinados:

Aplicaciones restringidas: lista de ejecutables (y en vista previa, también sus interfaces web en Edge) que, al acceder a un archivo protegido, disparan acciones de “solo auditar”, “bloquear con invalidación” o “bloquear”. Por ejemplo, puedes marcar como restringidas apps de sincronización de nubes no corporativas.
Grupos de aplicaciones restringidas: conjuntos de apps con una política de restricción homogénea. Puedes incluso crear un modelo “lista blanca”: permitir un grupo concreto con acción “Permitir” y poner como “bloquear” a todas las demás aplicaciones.
Cuarentena automática: cuando una app restringida intenta acceder a un archivo sensible bajo una directiva de bloqueo, DLP puede mover ese archivo a una carpeta de cuarentena local y dejar un marcador de posición con mensaje para el usuario, evitando bucles de notificaciones (como sucede con algunas apps de sincronización que reintentan una y otra vez).
Restricciones de navegador y dominios: definir qué navegadores están permitidos (Edge por defecto) y qué dominios de servicio en la nube se permiten o bloquean. Esto controlará la acción “cargar en dominio de servicio en la nube restringido”, así como “pegar en navegadores admitidos”, “imprimir sitio”, “copiar datos del sitio” y “guardar como”.
Grupos de dominios de servicio confidencial: colecciones de sitios web que reciben un tratamiento DLP específico. Por ejemplo, un grupo preconfigurado para sitios de IA generativa donde puedes bloquear o auditar el pegado de contenido sensible y la carga de ficheros.

La lógica de los dominios de servicio distingue entre listas en modo Permitir (solo esos dominios quedan exentos de restricciones, todo lo demás se controla) y modo Bloquear (solo esos dominios se controlan explícitamente y el resto se dejan pasar). Hay una tabla de comportamiento muy clara que combina el modo de dominio (Permitir/Bloquear) con la acción DLP seleccionada (“Solo auditoría”, “Bloquear con invalidación”, “Bloquear”) para saber si se generan alertas, se aplica la política o solo se audita.

Diseño y creación de directivas DLP: de la intención a la configuración

Microsoft recomienda empezar cada directiva con una instrucción de intención: una frase que describa, en lenguaje natural, qué quieres conseguir. Por ejemplo: “Impedir que el equipo de Call Center envíe ficheros sensibles a destinatarios externos, salvo PDFs e imágenes autorizadas” o “Evitar que empleados copien información de tarjetas de crédito a dispositivos USB no corporativos”.

A partir de ahí se traduce esa intención en la configuración de la directiva:

Elegir la plantilla (financiera, médica, privacidad, personalizada…) o directiva en blanco.
Fijar el ámbito administrativo (inquilino completo o unidades administrativas específicas).
Seleccionar ubicaciones de destino (Exchange, SharePoint, OneDrive, Teams, dispositivos, tráfico web, repositorios locales, etc.).
Definir condiciones: tipos de información confidencial, etiquetas, contexto de compartición (interno/externo), dominios, recuento de coincidencias, tamaño, rutas, aplicaciones, VPN, etc.
Configurar acciones para cada regla: permitir/auditar, bloquear, bloquear con override, cifrar, mover a cuarentena, restringir solo ciertas actividades (copiar a USB, imprimir, pegar, etc.).
Añadir notificaciones (correo a usuarios, administradores, SOC) y sugerencias de directiva (mensajes emergentes en Office, Edge y otros clientes).
Elegir el estado de implementación: mantener desactivada, modo de simulación, simulación con sugerencias o activación completa.

Cómo solucionar el error “Fallo en la fase de instalación SAFE_OS” en Windows

En el caso práctico que mencionabas de bloquear datos sensibles solo en correos no cifrados, una aproximación robusta sería: 1) etiquetar y cifrar automáticamente (o exigir al usuario que lo haga) cuando se detecta cierto tipo de dato, 2) aplicar una regla DLP que bloquee el envío de esos datos si el mensaje o el adjunto no tienen una etiqueta o cifrado específicos, combinando condiciones de información confidencial con condiciones de “contenido no etiquetado” o atributivas de cifrado IRM, y 3) usar excepciones para dominios de confianza o grupos concretos.

Estrategia de implementación: estado, acciones y ámbito

Una clave para que DLP no se convierta en un dolor de cabeza es gestionar bien los tres ejes de implementación: estado de la directiva, acciones configuradas y ámbito de ubicaciones/personas. El enfoque recomendado es siempre incremental.

Estados de la directiva

Los estados disponibles permiten controlar el impacto:

Mantenerla desactivada: se usa mientras diseñas y revisas la política. No se evalúa ni se registra nada.
Ejecutar la directiva en modo de simulación: se evalúan las reglas, se generan eventos de auditoría y alertas, pero no se aplican acciones de bloqueo ni notificaciones a usuarios. Ideal para comprobar el impacto real en todos los sistemas sin ruido a usuarios.
Ejecutar en modo de simulación y mostrar sugerencias de directiva: misma evaluación sin bloqueo, pero ahora sí se avisa al usuario con pop-ups o mensajes contextualizados y se pueden enviar correos. Sirve como fase de educación para que entendan que su comportamiento es de riesgo.
Activarla inmediatamente: modo de cumplimiento completo, las acciones de bloqueo o restricción se ejecutan realmente.

Puedes cambiar de estado cuando lo necesites, pero conviene atarte a un plan por fases acordado con negocio: cuánto tiempo permanecer en simulación, qué métricas vigilar (volumen de coincidencias, falsos positivos, impacto previsto), qué umbrales justifican pasar a modo restrictivo.

Acciones y nivel de severidad

En las ubicaciones de dispositivos y repositorios, las acciones que se usan como “palancas de dureza” son:

Permitir: la acción se permite, solo se audita. No hay notificaciones ni alertas automáticamente.
Solo auditoría: igual que permitir, pero puedes añadir notificaciones y alertas. Es útil para concienciar y preparar a la organización para políticas más estrictas.
Bloquear con invalidación: se bloquea la acción por defecto, pero el usuario puede invalidarla justificando. Sirve para capturar feedback sobre casos legítimos y depurar falsos positivos.
Bloquear: no hay opción, la acción está totalmente prohibida. Debe reservarse para escenarios muy claros, acordados y probados.

En las sugerencias de directiva, puedes decidir qué opciones de justificación mostrar: texto libre, lista de motivos predefinidos o combinación de ambos. Configurar bien estos mensajes (idioma, tono, explicación corta de por qué se bloquea y qué hacer) mejora bastante la aceptación.

Ámbito y grupos de autorización

El ámbito de la directiva no solo se controla por ubicación general (Exchange, dispositivos, etc.), sino también por un conjunto de grupos específicos que te permiten granularidad extra:

Grupos de impresoras: limitar impresión de documentos muy sensibles a una lista de impresoras de confianza (por ejemplo, solo las del departamento legal o de archivo central).
Grupos de dispositivos USB extraíbles: definir qué discos externos están autorizados (copias de seguridad corporativas, por ejemplo) y qué se bloquea.
Grupos de recursos compartidos de red: delimitar qué rutas de red son repositorios “seguros” y en cuáles se prohíbe guardar documentos confidenciales.
Grupos de dominios de servicio confidencial: agrupar webs por tipo (IA generativa, SaaS de ventas, almacenamiento, etc.) y aplicar políticas específicas.
Listas de VPN: distinguir comportamiento cuando el usuario está conectado por la VPN corporativa frente a cuando opera en una red doméstica o pública.

Al principio, es aconsejable empezar con un grupo piloto de usuarios y ubicaciones claras, en lugar de apuntar directamente a toda la empresa. Ese grupo piloto se convierte en “early adopters” y te ayuda a refinar reglas antes de escalar.

Supervisión, informes y ajuste continuo

Una vez tus políticas están en marcha (aunque sea en simulación), tendrás un flujo constante de telemetría que debes saber leer. DLP alimenta varios paneles y herramientas en Microsoft Purview y el portal de Defender:

Página de Información general de DLP: visión de alto nivel de estado de sincronización de directivas, estado de dispositivos, principales actividades detectadas y tendencias.
Panel de alertas DLP en Microsoft Purview y en el portal de Defender: lista de alertas generadas cuando una regla se dispara según los umbrales y ventanas de tiempo configuradas. Puedes verlas, evaluar su gravedad, asignar estado (nuevo, en investigación, resuelto) y seguimiento.
Explorador de actividad: consola detallada donde filtrar por tipo de actividad (endpoint, salida, actividades DLP, reglas, políticas, invalidaciones de usuario, etc.) y revisar cada evento con contexto enriquecido (usuario, dispositivo, app, dominio, texto de coincidencia en ciertos casos).
Registros de auditoría de Microsoft 365: repositorio central de eventos que después se explotan desde muchas de estas vistas.
PowerShell de Seguridad y Cumplimiento y Exchange: cmdlets específicos para extraer informes DLP personalizados.

Una función especialmente útil es el resumen contextual en eventos DLPRuleMatch, que permite ver el texto que rodea al contenido coincidente (por ejemplo, las líneas cercanas a un número de tarjeta de crédito) cuando se ha aplicado la KB adecuada en Windows 10/11. Esto facilita confirmar si la coincidencia es legítima o un falso positivo. También es importante monitorizar nuevas amenazas, por ejemplo las ciberamenazas financieras impulsadas por IA, que pueden cambiar patrones de riesgo y requerir ajustes.

Con estos datos, el equipo de cumplimiento y TI debería establecer un bucle de mejora continua: ajustar ubicaciones, añadir o quitar excepciones, endurecer o suavizar acciones, modificar listas de dominios o apps, ampliar grupos de autorización, etc. La experiencia de los usuarios, recogida a través de las justificaciones de invalidación y del soporte, es oro puro para refinar las políticas.