Configurar Microsoft Purview paso a paso: guía práctica para proteger y gobernar los datos

Configurar Microsoft Purview correctamente no consiste en entrar en el portal, crear varias etiquetas, habilitar una plantilla DLP y considerar terminado el proyecto.

Purview puede actuar sobre información de Exchange Online, SharePoint, OneDrive, Microsoft Teams, endpoints, repositorios locales, Microsoft 365 Copilot, Azure, Microsoft Fabric, bases de datos y otras fuentes compatibles. Eso significa que una política mal diseñada puede afectar a muchos procesos diferentes.

Por ejemplo, cifrar automáticamente un documento puede impedir que una aplicación externa lo procese. Bloquear la copia a USB puede afectar a un departamento que utiliza soportes autorizados. Una regla DLP demasiado amplia puede generar cientos de avisos irrelevantes. Una política de retención incorrecta puede conservar durante años información que debería haberse eliminado.

Por eso el orden importa.

Una implantación madura debería avanzar desde visibilidad → clasificación → simulación → educación → protección selectiva → investigación → gobierno continuo.

Además, Microsoft Purview ha evolucionado significativamente. En 2026 no deberíamos diseñar una implantación centrada únicamente en etiquetas y DLP. Debemos tener también en cuenta Data Security Posture Management (DSPM), Data Security Investigations, el nuevo esquema moderno de etiquetas, la experiencia actual de eDiscovery, las capacidades modernas de Endpoint DLP y los modelos pay-as-you-go.

En Kloudeal planteamos estos proyectos empezando por los datos y los casos de uso. Primero identificamos qué información es realmente importante, dónde se encuentra, qué usuarios trabajan con ella y qué riesgo queremos reducir. Después revisamos licencias, roles y dependencias, diseñamos un piloto y solo entonces comenzamos a aplicar controles.

Esta guía explica cómo configurar Microsoft Purview paso a paso en 2026, qué deberías preparar antes de tocar producción, cómo desplegar etiquetas, DLP y Endpoint DLP, cómo incorporar repositorios locales con el Information Protection scanner, cómo preparar Audit y eDiscovery y qué PowerShell tiene sentido seguir utilizando actualmente.

Índice

1. Definir el objetivo antes de configurar Purview
2. Arquitectura recomendada de despliegue
3. Prerequisitos técnicos y organizativos
4. Roles y mínimo privilegio
5. Licencias y facturación
6. Diseñar correctamente el piloto
7. Visibilidad antes de enforcement
8. Configurar Data Security Posture Management
9. Data Classification, Activity Explorer y Content Explorer
10. 1. Crear etiquetas de sensibilidad
11. Esquema moderno de etiquetas
12. 2. Publicar etiquetas
13. Etiquetas en SharePoint, Teams y Groups
14. 3. Configurar auto-etiquetado
15. 4. Configurar DLP
16. Simulation mode y validación
17. Ejemplo de piloto DLP
18. 5. Configurar Endpoint DLP
19. Onboarding de dispositivos
20. Comprobar salud de Endpoint DLP
21. Diseñar controles endpoint
22. 6. Configurar Information Protection scanner
23. Arquitectura del scanner
24. Instalación y configuración
25. Discovery antes de clasificación automática
26. 7. Preparar Insider Risk Management
27. 8. Communication Compliance
28. 9. Configurar Microsoft Purview Audit
29. 10. Configurar eDiscovery
30. 11. Data Security Investigations
31. 12. Retention y Records Management
32. 13. Preparar Purview para Microsoft 365 Copilot
33. 14. Data Map y Unified Catalog
34. PowerShell actual para Microsoft Purview
35. Reporting y métricas
36. Roadmap de 90 días
37. Errores frecuentes
38. Checklist de implantación
39. Preguntas frecuentes
40. Documentación oficial

Definir el objetivo antes de configurar Microsoft Purview

Purview contiene demasiadas capacidades como para empezar configurando sin tener un objetivo.

Una organización que únicamente necesita impedir que determinados contratos salgan de SharePoint no tiene el mismo proyecto que otra que necesita preparar un procedimiento eDiscovery, gobernar un data lake o controlar datos introducidos en aplicaciones de IA.

Crear un documento de objetivos

Antes del portal recomendamos dejar por escrito:

Este pequeño ejercicio evita que el departamento técnico tenga que decidir por sí solo qué significa “dato confidencial”.

Arquitectura recomendada: visibility before enforcement

Una buena implantación de Purview debería poder dibujarse como una sucesión de capas.

Saltarnos las primeras capas y comenzar directamente por Protect es una de las mejores formas de generar problemas.

Prerequisitos técnicos y organizativos

Antes de configurar Purview conviene comprobar un conjunto mínimo de condiciones.

No olvidar las aplicaciones

Antes de introducir cifrado o restricciones DLP debemos identificar procesos que consumen documentos automáticamente.

Por ejemplo:

ERP, CRM, RPA, procesos Power Automate, aplicaciones que generan PDF, OCR, soluciones de firma y aplicaciones que leen ficheros desde SharePoint.

El usuario puede abrir perfectamente un documento protegido mientras una aplicación legacy deja de procesarlo.

Roles y permisos: no utilizar Global Administrator por comodidad

Microsoft Purview dispone de un sistema de roles y role groups para que cada persona disponga únicamente de las capacidades necesarias.

Los permisos se administran actualmente desde:

Microsoft Purview portal → Settings → Roles and scopes.

Separación orientativa

Dos niveles de sensibilidad

No es lo mismo poder:

crear una política

que poder:

ver el contenido exacto que provocó una coincidencia.

Las capacidades de visualización de contenido sensible deben limitarse especialmente.

Global Administrator tampoco ve todo por defecto

En soluciones especialmente sensibles como Insider Risk Management o Communication Compliance, Microsoft aplica controles específicos y no debemos asumir que ser Global Administrator concede automáticamente acceso de investigación.

Referencia oficial: Microsoft – Permissions in the Microsoft Purview portal.

Licencias y facturación: comprobar antes de construir

Purview utiliza actualmente dos modelos complementarios.

Licenciamiento por usuario

Se utiliza principalmente para capacidades aplicadas a:

Microsoft 365 y endpoints Windows/macOS.

Pay-as-you-go

Extiende Purview a determinados escenarios:

fuentes no Microsoft 365, gobierno de datos, aplicaciones de IA y otras capacidades no ligadas directamente a un usuario.

La facturación se asocia normalmente a una suscripción Azure.

No asignar licencias basándonos únicamente en el departamento

Puede resultar más útil determinar:

quién genera el dato, quién lo manipula, quién necesita ser investigado/cubierto por una política y quién administra la solución.

Referencias oficiales:

• Microsoft – Purview service description
• Microsoft – Purview billing models

Diseñar el piloto antes de crear políticas

El piloto debería reproducir la realidad.

No basta con seleccionar cinco usuarios de TI que conocen perfectamente lo que estamos probando.

Criterios de aceptación

Antes de comenzar definimos qué significa éxito.

Antes de bloquear: utilizar las capacidades de visibilidad

Una de las ventajas de Purview es que podemos obtener información antes de imponer restricciones.

Las herramientas más útiles para esta fase son:

DSPM, Activity Explorer, Content Explorer, Data Classification y Audit.

Qué queremos averiguar

Configurar Data Security Posture Management antes de añadir más controles

Data Security Posture Management debería formar parte de la fase inicial de un proyecto Purview moderno.

La versión actual se encuentra en:

Microsoft Purview portal → Solutions → DSPM.

No confundir con las experiencias clásicas

Microsoft mantiene referencias a:

Data Security Posture Management (classic)

y

DSPM for AI (classic).

Para un nuevo despliegue debemos trabajar sobre la experiencia DSPM actual cuando esté disponible para nuestro tenant.

Primer uso

En el acceso inicial DSPM puede proponer diferentes tareas de configuración para activar las señales que necesita.

En lugar de habilitarlas automáticamente, conviene revisar:

qué servicio activa cada tarea, qué datos procesa y qué licenciamiento implica.

Qué revisar

DSPM no debe convertirse en una lista ciega de recomendaciones

Cada recomendación debería convertirse en una decisión:

aceptar → probar → implementar

o

descartar → documentar motivo.

Referencia oficial: Microsoft – Data Security Posture Management.

Data Classification, Content Explorer y Activity Explorer

Estas herramientas nos ayudan a pasar de la teoría a la realidad.

Content Explorer

Permite obtener visibilidad sobre contenido clasificado y determinados datos sensibles.

El acceso al contenido debe limitarse cuidadosamente mediante roles específicos.

Activity Explorer

Permite analizar actividades relacionadas con:

etiquetado, DLP, endpoints y otras operaciones soportadas.

Qué buscar antes de construir DLP

Por ejemplo:

qué tipos de datos sensibles aparecen realmente, en qué sitios, qué departamentos los utilizan y cómo se comparten.

1. Crear etiquetas de sensibilidad

Una etiqueta debería expresar un significado empresarial comprensible.

Ejemplo inicial

No proteger todas desde el primer día

Durante el piloto podemos comenzar utilizando las etiquetas principalmente como clasificación.

Después añadimos:

markings → encryption → DLP → restrictions

solo donde tengan sentido.

Ruta actual en el portal

Microsoft Purview portal → Solutions → Information Protection → Sensitivity labels.

Crear la etiqueta

1. Seleccionar Create a label.
2. Definir nombre.
3. Definir descripción administrativa.
4. Definir descripción para usuarios.
5. Seleccionar scopes.
6. Configurar protección cuando proceda.
7. Configurar markings si son necesarios.
8. Revisar configuración.
9. Crear.

La descripción de usuario importa mucho

No utilizar simplemente:

“Información confidencial.”

Es más útil:

“Utiliza esta etiqueta para contratos, información financiera y documentación de clientes que no debe compartirse públicamente.”

Referencia oficial: Microsoft – Create and configure sensitivity labels.

Esquema moderno de etiquetas: importante en tenants nuevos

Microsoft está utilizando actualmente un nuevo modern label schema.

Los tenants creados a partir del 1 de octubre de 2025, y los tenants migrados expresamente, utilizan esta experiencia moderna.

Cómo identificarlo

El propio portal muestra información sobre el esquema en la página de etiquetas.

Por qué importa

Algunos scripts, procedimientos antiguos y capturas de pantalla de Internet corresponden al esquema clásico.

Por eso recomendamos:

diseñar y administrar primero desde el portal actual y utilizar PowerShell únicamente cuando exista una necesidad clara.

2. Publicar etiquetas: crear una etiqueta no significa que los usuarios la vean

Después de crear las etiquetas debemos publicarlas.

Ruta actual

Microsoft Purview portal → Solutions → Information Protection → Publishing policies.

Primera publicación

Seleccionamos un grupo piloto, no toda la organización.

Tiempo de propagación

No deberíamos interpretar que una etiqueta que no aparece segundos después de publicar la política está mal configurada.

Las políticas requieren propagación y la experiencia puede variar por aplicación.

Pruebas mínimas

Validar:

Word, Excel, PowerPoint, Outlook, Office web, SharePoint y cualquier aplicación crítica.

Etiquetas para SharePoint, Teams y Microsoft 365 Groups

Las etiquetas también pueden utilizarse sobre contenedores de colaboración compatibles.

Pueden controlar aspectos como

Activar integración con SharePoint y OneDrive

En tenants donde todavía no está habilitada, Purview puede mostrar un banner para activar la compatibilidad de sensitivity labels con Office files en SharePoint y OneDrive.

Conviene comprobarlo antes de diseñar auto-labeling para estos workloads.

Referencia oficial: Microsoft – Sensitivity labels for groups and sites.

3. Configurar auto-etiquetado

El auto-etiquetado puede reducir la dependencia de decisiones manuales del usuario.

Pero debe llegar después de tener una taxonomía madura.

Ruta actual

Microsoft Purview portal → Solutions → Information Protection → Policies → Auto-labeling policies.

Proceso recomendado

No automatizar una mala clasificación

Si una regla identifica incorrectamente el dato, el auto-labeling simplemente hará que el problema se aplique a mayor escala.

Referencia oficial: Microsoft – Automatically apply sensitivity labels.

4. Configurar Data Loss Prevention

DLP permite definir qué comportamiento queremos cuando determinados datos se utilizan de una forma concreta.

Ruta

Microsoft Purview portal → Solutions → Data Loss Prevention → Policies.

Proceso

1. Seleccionar Create policy.
2. Seleccionar plantilla o Custom.
3. Definir Admin Units si se utilizan.
4. Seleccionar locations.
5. Definir condiciones.
6. Definir acciones.
7. Configurar avisos.
8. Configurar alertas.
9. Seleccionar simulation mode.
10. Revisar antes de enforcement.

Diseñar la regla en lenguaje natural antes del portal

Por ejemplo:

Si un usuario intenta compartir externamente un documento etiquetado como “Altamente confidencial”, registrar el evento, mostrar una advertencia y generar una alerta al equipo de seguridad durante el piloto.

Después convertimos esa frase en condiciones y acciones.

Qué puede utilizar una política

Entre otras señales:

Sensitive Information Types, sensitivity labels, classifiers, contexto de compartición, usuarios, grupos y locations.

Simulation mode: probar DLP antes de bloquear

La documentación actual de Microsoft recomienda utilizar simulation mode para probar y ajustar políticas DLP.

Simulation permite comprobar qué elementos coincidirían con la política sin aplicar necesariamente las acciones restrictivas.

Qué revisar durante la simulación

Una secuencia práctica

Simulation → Policy Tip → Block with override → Block

no es una obligación técnica, pero sí una buena forma de aumentar progresivamente el control.

Referencia oficial: Microsoft – Test your DLP policies.

Ejemplo de piloto DLP

Supongamos que queremos reducir el envío externo de información financiera.

Qué documentamos

falsos positivos, excepciones, volumen, usuarios, procesos afectados y ajustes realizados.

5. Configurar Endpoint DLP

Una vez que el fichero se descarga desde SharePoint al dispositivo, las políticas cloud dejan de ser suficientes para controlar todo lo que ocurre con él.

Endpoint DLP amplía el modelo de DLP al sistema operativo.

Puede monitorizar o controlar acciones como

Sistemas soportados

La documentación actual cubre dispositivos Windows compatibles y macOS incorporados a Purview.

Para macOS Microsoft mantiene compatibilidad con las tres versiones principales más recientes en el contexto documentado de Endpoint DLP.

Referencia oficial: Microsoft – Get started with Endpoint DLP.

Onboarding de dispositivos para Endpoint DLP

Intune es una opción muy habitual, pero no la única.

Windows

Microsoft documenta métodos como:

Intune, Group Policy, Configuration Manager y script local

según el escenario.

macOS

Puede utilizarse:

Intune o JAMF Pro

en escenarios compatibles, incluyendo integraciones con Defender for Endpoint.

Esto es importante

No debemos escribir en el alcance de un proyecto que:

“Endpoint DLP requiere Intune”

si no hemos revisado antes el método de onboarding del cliente.

Comprobar la salud de los dispositivos antes del enforcement

Microsoft Purview dispone actualmente de un device health reporting dashboard.

Ruta

Settings → Device onboarding → Device report.

Qué revisar

Regla práctica

No convertir una política Endpoint DLP a Block si no sabemos primero qué porcentaje de dispositivos está realmente preparado para recibirla.

Referencia oficial: Microsoft – Endpoint DLP device health dashboard.

Diseñar controles Endpoint DLP progresivamente

Las excepciones pueden ser más precisas que “excluir usuario”

Endpoint DLP permite diseñar controles sobre:

grupos de impresoras, dispositivos, redes, aplicaciones y otros contextos compatibles.

Esto permite evitar excepciones enormes del tipo:

“Finanzas queda fuera de DLP”.

6. Microsoft Purview Information Protection scanner

El Information Protection scanner sigue siendo una herramienta importante cuando la organización conserva información en repositorios locales.

Anteriormente fue conocido como:

Azure Information Protection unified labeling scanner

y

on-premises scanner.

Actualmente puede trabajar con

UNC network shares mediante SMB, NFS en preview y bibliotecas/carpetas de SharePoint Server en versiones compatibles.

Qué puede hacer

No trabaja en tiempo real

El scanner recorre sistemáticamente los repositorios configurados.

Puede ejecutarse una vez o programarse periódicamente.

Referencia oficial: Microsoft – Information Protection scanner.

Arquitectura del Information Protection scanner

El scanner funciona como un servicio sobre Windows Server.

Una implantación necesita revisar:

Escalar con múltiples nodos

Microsoft permite desplegar varios nodos utilizando el mismo scanner cluster y base de datos.

Esto puede ser útil cuando hay un gran volumen de repositorios.

Instalar y configurar el scanner

1. Crear cluster

Desde:

Microsoft Purview portal → Settings → Information Protection → Information protection scanner.

En Clusters, crear el cluster.

2. Crear content scan job

Definir:

repositorios, schedule y comportamiento del escaneo.

3. Preparar Windows Server

Revisar prerequisitos oficiales, cuenta de servicio y conectividad.

4. Instalar el scanner

Install-Scanner `
    -SqlServerInstance "SQLSERVER\INSTANCE" `
    -Cluster "Purview-Europe"

5. Configurar autenticación

Preparar el token Microsoft Entra siguiendo el procedimiento vigente.

6. Ejecutar discovery

Antes de permitir que el scanner modifique ficheros.

7. Revisar resultados

Evaluar:

volumen, tipos de fichero, información sensible, errores y rendimiento.

8. Habilitar clasificación/protección

Solo después del piloto.

Referencia oficial: Microsoft – Configure and install the Information Protection scanner.

Discovery antes de aplicar etiquetas sobre millones de ficheros

El primer job debería priorizar visibilidad.

Ejemplo

Qué queremos saber

qué ficheros existen, qué puede inspeccionarse, qué información sensible aparece y qué pasaría si aplicásemos las etiquetas actuales.

Después diseñamos enforcement

No al revés.

7. Preparar Insider Risk Management

Insider Risk no debería ser simplemente la siguiente casilla del roadmap técnico.

Antes de configurarlo tenemos que acordar:

objetivo, base legal, responsables, privacidad, procedimiento de investigación y escalado.

Participantes

Casos de uso concretos

Es preferible:

“analizar posibles movimientos de datos de empleados en proceso formal de salida”

que:

“monitorizar a todos los usuarios por si hacen algo raro”.

Privacidad

Microsoft incluye mecanismos como seudonimización y separación de roles, pero esto no sustituye la evaluación legal y laboral de cada organización.

Referencia oficial: Microsoft – Plan for Insider Risk Management.

8. Configurar Communication Compliance cuando exista un caso de uso

Communication Compliance está orientado a la revisión de determinadas comunicaciones compatibles cuando existen:

requisitos regulatorios, riesgo de conducta, información sensible o políticas de comunicación empresarial.

Antes de crear políticas

Definir:

qué comunicaciones, qué usuarios, qué riesgo, quién revisa y qué procedimiento existe después de una coincidencia.

No utilizar revisores genéricos

El acceso debe limitarse a personal autorizado y utilizar los roles específicos disponibles.

9. Configurar Microsoft Purview Audit

Audit es una de las primeras soluciones que conviene revisar porque será fundamental para investigar el resto del entorno.

Estado actual

Audit Standard está habilitado por defecto para organizaciones con las suscripciones correspondientes.

Retención

La política no es retroactiva

Si necesitamos conservar registros durante varios años, hay que preparar la retención antes de que desaparezcan.

Qué probar

Buscar eventos relacionados con:

SharePoint, Exchange, OneDrive, Teams, actividad administrativa, DLP y eDiscovery.

Referencia oficial: Microsoft – Audit solutions.

10. Configurar eDiscovery antes de una investigación real

La experiencia moderna de eDiscovery está organizada alrededor de cases.

Preparación inicial

Crear un caso de laboratorio

Es preferible descubrir ahora cómo funcionan búsquedas, permisos, holds y exports que hacerlo mientras legal espera resultados urgentes.

Review sets

Las capacidades avanzadas permiten copiar contenido hacia review sets para:

buscar, filtrar, etiquetar, analizar near-duplicates, revisar conversaciones y aplicar otras funciones de análisis.

eDiscovery y PowerShell en 2026

Existe un cambio técnico importante.

Para utilizar cmdlets de eDiscovery como:

*-ComplianceSearch

o

New-ComplianceSearchAction

Microsoft requiere actualmente:

ExchangeOnlineManagement 3.9.0 o posterior + Connect-IPPSSession -EnableSearchOnlySession.

Referencia oficial: Microsoft – eDiscovery features and components.

11. Data Security Investigations

Una arquitectura moderna de Purview debería contemplar también cómo responderemos cuando ocurra un incidente sobre datos.

Data Security Investigations puede ayudar a comprender qué información sensible estuvo implicada.

Ejemplo

Una cuenta comprometida descarga 2.000 documentos.

Audit puede ayudarnos a determinar:

qué actividad realizó.

Data Security Investigations puede ayudarnos a analizar:

qué tipo de información había dentro del conjunto potencialmente afectado.

Billing

La solución utiliza modelos de:

storage + AI capacity.

Por tanto, antes de habilitarla debemos configurar y estimar costes.

Proactive AI insights

Determinadas configuraciones de insights proactivos desde DSPM pueden provocar procesamiento periódico y, por tanto, consumo mientras permanezcan habilitadas.

Referencia oficial: Microsoft – Data Security Investigations.

12. Retention y Records Management

Configurar protección sin definir el ciclo de vida deja incompleto el proyecto.

Preguntas

Para cada categoría:

¿cuánto tiempo debe conservarse?, ¿quién decide?, ¿puede eliminarse antes?, ¿qué ocurre al vencer?, ¿es un record formal?

No conservar todo indefinidamente

“Por si acaso” no es una política de lifecycle.

Puede aumentar:

volumen, costes, exposición y complejidad de eDiscovery.

13. Configurar Purview antes y después de Microsoft 365 Copilot

Copilot hace todavía más importante conocer los permisos y los datos.

Antes de ampliar Copilot

Purview no sustituye a Permissions Governance

La primera corrección para un documento accesible por error sigue siendo:

corregir el permiso.

Después utilizamos labels, DLP y otras protecciones.

Referencia oficial: Microsoft – Purview for Microsoft 365 Copilot.

14. Configurar Data Map y Unified Catalog

Esta parte debe tratarse como un proyecto de Data Governance, no como una extensión directa de DLP.

Prerequisito comercial importante

La experiencia moderna de Data Governance utiliza actualmente pay-as-you-go.

Necesitamos:

suscripción Azure en el mismo tenant + resource group.

Proceso orientativo

Facturación vigente

El modelo PAYG moderno entró en vigor para esta experiencia el 6 de enero de 2025.

Actualmente existen medidores relacionados con:

governed assets y data governance processing.

No escanear todo el entorno el primer día

Comenzar por:

un dominio, una plataforma o un data product realmente importante.

Referencia oficial: Microsoft – Billing in Microsoft Purview Data Governance.

PowerShell actual para Microsoft Purview

PowerShell sigue siendo útil, pero ya no recomendamos construir un despliegue completo alrededor de scripts antiguos.

El portal actual debería ser la referencia para diseño y configuración inicial, especialmente con el esquema moderno de etiquetas.

Security & Compliance PowerShell

Se utiliza el módulo:

ExchangeOnlineManagement.

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Import-Module ExchangeOnlineManagement

Connect-IPPSSession -UserPrincipalName admin@empresa.com

REST

Las versiones actuales del módulo utilizan modo REST para prácticamente todos los cmdlets Security & Compliance compatibles, evitando la dependencia histórica de Basic Authentication en WinRM.

eDiscovery

Cuando vayamos a utilizar los cmdlets de Compliance Search:

Connect-IPPSSession `
    -UserPrincipalName admin@empresa.com `
    -EnableSearchOnlySession

Esta modalidad requiere actualmente ExchangeOnlineManagement 3.9.0 o posterior.

Inventariar etiquetas

Get-Label |
    Select-Object Name,DisplayName,Guid,Priority

Inventariar políticas de publicación

Get-LabelPolicy |
    Format-Table Name

Inventariar políticas DLP

Get-DlpCompliancePolicy |
    Select-Object Name,Mode

Revisar distribución de una política DLP

Get-DlpCompliancePolicy `
    -Identity "DLP - Finanzas" `
    -DistributionDetail |
    Format-List Name,DistributionStatus

Inventariar reglas DLP

Get-DlpComplianceRule |
    Select-Object Name,Policy,Disabled

Probar una política DLP sobre un fichero SharePoint/OneDrive

Test-DlpPolicies `
    -Workload ODB `
    -FileUrl "https://tenant-my.sharepoint.com/personal/usuario/Documents/Contrato.docx" `
    -SendReportTo "dlp-admin@empresa.com"

Este cmdlet puede resultar especialmente interesante para comprobar qué reglas coinciden con un elemento concreto.

Buscar auditoría

$Start = (Get-Date).AddDays(-7)
$End   = Get-Date

Search-UnifiedAuditLog `
    -StartDate $Start `
    -EndDate $End `
    -ResultSize 5000

Grandes volúmenes de auditoría

Search-UnifiedAuditLog dispone de mecanismos de paginación y puede utilizar SessionCommand ReturnLargeSet, pero para integraciones programáticas de gran volumen Microsoft recomienda utilizar APIs apropiadas como Microsoft 365 Management Activity API.

Microsoft Graph para inventario de usuarios

Si necesitamos cruzar usuarios y licencias podemos utilizar Microsoft Graph PowerShell en lugar de los módulos AzureAD o MSOnline heredados.

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

Get-MgUser -All `
    -Property DisplayName,UserPrincipalName,AccountEnabled |
    Select-Object DisplayName,UserPrincipalName,AccountEnabled

No publicar scripts destructivos en un artículo como receta universal

Para crear labels, policies, encryption, auto-labeling o retention a escala preferimos:

portal → validación → documentación → automatización controlada.

Eso reduce la probabilidad de que un lector copie un script sin adaptar scopes, licencias o versión del tenant.

Referencias oficiales:

• Microsoft – Connect to Security & Compliance PowerShell
• Microsoft – Connect-IPPSSession
• Microsoft – Get-DlpCompliancePolicy
• Microsoft – Search-UnifiedAuditLog

Reporting: qué métricas revisar después de implantar Purview

Medir únicamente cuántas políticas hemos creado no aporta demasiado.

El KPI más importante

Debería ser:

¿estamos reduciendo una situación real de riesgo sin generar una carga operativa desproporcionada?

Roadmap práctico de configuración de Microsoft Purview en 90 días

Días 1–15: assessment y visibilidad

Días 16–30: clasificación

Días 31–45: DLP en simulación

Días 46–60: Endpoint y enforcement limitado

Días 61–75: on-premises e investigación

Días 76–90: gobierno y siguiente iteración

Errores frecuentes al configurar Microsoft Purview

Checklist para configurar Microsoft Purview

Preguntas frecuentes sobre cómo configurar Microsoft Purview

Conclusión: configurar Purview significa diseñar un sistema, no activar funcionalidades

Configurar Microsoft Purview correctamente requiere entender primero qué información existe y qué riesgo queremos reducir.

La secuencia importa.

Antes de bloquear debemos descubrir. Antes de automatizar debemos clasificar. Antes de cifrar debemos probar. Antes de investigar debemos preparar Audit y eDiscovery. Y antes de gobernar miles de activos tenemos que definir quién es realmente responsable de ellos.

La experiencia actual de Microsoft Purview permite comenzar por DSPM para obtener una visión de la postura del dato y complementarla con Data Classification, Content Explorer y Activity Explorer.

Después podemos construir una taxonomía sencilla de sensitivity labels y publicarla a un grupo piloto.

Las políticas DLP deberían comenzar en simulation mode. Esta fase permite observar qué datos coinciden, qué departamentos se verían afectados y cuántos falsos positivos aparecen antes de aplicar restrictions.

Cuando el dato abandona Microsoft 365 y llega al dispositivo, Endpoint DLP amplía los controles. Pero tampoco deberíamos habilitar bloqueos hasta comprobar que los dispositivos están correctamente onboarded y preparados. El nuevo Device Health dashboard facilita precisamente esa validación.

Para información almacenada en file servers o SharePoint Server sigue siendo posible utilizar el Microsoft Purview Information Protection scanner. El procedimiento debería comenzar igualmente en discovery mode antes de permitir que un proceso automático modifique o proteja miles de archivos.

La investigación constituye otra capa diferente.

Audit nos ayuda a determinar qué actividad ocurrió. eDiscovery permite preservar y revisar contenido para investigaciones formales. Data Security Investigations añade capacidades para analizar qué información sensible pudo verse comprometida en un incidente.

Insider Risk Management y Communication Compliance deberían llegar únicamente cuando exista una base organizativa, legal y operativa clara.

Finalmente, Data Map y Unified Catalog amplían Purview hacia el gobierno empresarial de datos, con un modelo comercial diferente basado en pay-as-you-go.

Por eso un proyecto completo de Purview no puede reducirse a una lista de botones.

La pregunta final no debería ser:

“¿Cuántas funciones de Purview hemos activado?”

Sino:

“¿Sabemos qué datos importantes tenemos, quién puede acceder, cómo se utilizan, qué acciones hemos decidido permitir o impedir y cómo investigaremos un incidente cuando ocurra?”

Cuando podemos responder a esas preguntas con datos y procedimientos reales, Purview comienza a aportar valor.

Documentación oficial recomendada

Microsoft Purview y portal

• Microsoft – Learn about Microsoft Purview
• Microsoft – Microsoft Purview portal
• Microsoft – Permissions in Microsoft Purview

Data Security Posture Management

• Microsoft – Data Security Posture Management

Sensitivity Labels e Information Protection

• Microsoft – Get started with sensitivity labels
• Microsoft – Create and configure sensitivity labels
• Microsoft – Sensitivity labels for Teams, Groups and SharePoint
• Microsoft – Auto-labeling policies
• Microsoft – Encryption with sensitivity labels

Data Loss Prevention

• Microsoft – Data Loss Prevention
• Microsoft – DLP policy reference
• Microsoft – Test DLP policies

Endpoint DLP

• Microsoft – Get started with Endpoint DLP
• Microsoft – Endpoint DLP policy scenarios
• Microsoft – Endpoint DLP Device Health

Information Protection scanner

• Microsoft – Information Protection scanner
• Microsoft – Configure and install the scanner

Insider Risk y Communication Compliance

• Microsoft – Plan for Insider Risk Management
• Microsoft – Insider Risk privacy guide
• Microsoft – Communication Compliance

Audit

• Microsoft – Purview Audit
• Microsoft – Audit log retention policies

eDiscovery

• Microsoft – eDiscovery features and components
• Microsoft – eDiscovery permissions
• Microsoft – eDiscovery billing

Data Security Investigations

• Microsoft – Data Security Investigations
• Microsoft – Data Security Investigations billing

Data Governance

• Microsoft – Data Map
• Microsoft – Data Governance roles
• Microsoft – Data Governance billing

Microsoft 365 Copilot

• Microsoft – Purview for Microsoft 365 Copilot

PowerShell

• Microsoft – Connect to Security & Compliance PowerShell
• Microsoft – Connect-IPPSSession
• Microsoft – Get-Label
• Microsoft – Get-LabelPolicy
• Microsoft – Get-DlpCompliancePolicy
• Microsoft – Search-UnifiedAuditLog

Licenciamiento

• Microsoft – Purview service description
• Microsoft – Purview billing models