Microsoft Purview

Verificaciones automáticas

Gobierno y clasificación de información de Microsoft. Evidencia que existen etiquetas de sensibilidad publicadas y que las solicitudes de privacidad se atienden en plazo.

• Categoría: Gobierno de datos (Data Governance en el catálogo)
• Verificaciones: 3 (aportan evidencia a tus marcos)
• Documentación oficial: Microsoft Purview

Qué evidencia aporta

Cada ejecución de la conexión corre estas 3 verificaciones y deja el resultado como evidencia en tus auditorías, asociado al control que aparece en la última columna.

Verificación	Severidad si falla	Aporta al control
Etiquetas de sensibilidad publicadas	Alta	A.5.12 Clasificación de la información
Etiquetas aplicables por los usuarios	Media	A.5.13 Etiquetado de la información
Solicitudes de privacidad dentro de plazo	Alta	A.5.34 Privacidad y protección de la información personal

Los controles corresponden al Anexo A de la norma ISO/IEC 27001:2022. Si trabajas con otro marco, los cruces entre marcos trasladan el resultado a los requisitos equivalentes.

Qué te va a pedir la plataforma

Al crear la conexión completarás estos campos. Las credenciales se guardan cifradas y no vuelven a mostrarse.

Campo	Tipo	¿Obligatorio?
Tenant ID	Texto	Sí
Application (Client) ID	Texto	Sí
Client Secret	Secreto	Sí

Requisitos y permisos mínimos

Tipo de credencial: el mismo app registration que usan los demás conectores Microsoft (Entra ID, Intune, Defender…), con dos permisos de APLICACIÓN adicionales, ambos de solo lectura:

• InformationProtectionPolicy.Read.All (etiquetas de sensibilidad)
• SubjectRightsRequest.Read.All (solicitudes de privacidad)

Ambos requieren consentimiento del administrador.

⚠️ Endpoint en beta: las etiquetas de sensibilidad a nivel de organización solo se exponen en /beta de Graph. Microsoft advierte que las APIs beta pueden cambiar sin aviso; si un día el check empieza a fallar con 404, es esta la causa a revisar.

⚠️ ALCANCE (verificado en la documentación oficial, no asumido):

• Las etiquetas de retención NO son alcanzables: su API solo admite permisos delegados (un usuario interactivo), y este conector usa credenciales de aplicación. Por eso A.5.33 (protección de registros) y A.8.10 (borrado de información) siguen requiriendo evidencia manual.
• Las políticas DLP no tienen recurso en Graph (se gestionan por PowerShell de Security & Compliance). La cobertura parcial de A.8.12 la aporta Zscaler ZIA.

Licenciamiento: las etiquetas de sensibilidad requieren un plan que las incluya (Microsoft 365 E3/E5 o AIP); las solicitudes de derechos de titulares requieren E5 o el complemento de cumplimiento. Sin licencia, los endpoints responden vacío o 403.

La integración solo lee: nunca crea ni modifica etiquetas ni solicitudes.

Configuración paso a paso

Estos pasos se hacen en Microsoft Purview. Cuando termines, vuelve a Preceptix y crea la conexión con los datos obtenidos (ver Conecta tu primera integración).

1. Reutiliza el app registration de Microsoft

   Si ya configuraste Entra ID, Intune o Defender, usa esa misma aplicación: Tenant ID, Client ID y Client Secret son los mismos.

2. Agrega los permisos de aplicación

   Portal de Azure → Microsoft Entra ID → App registrations → tu app → API permissions → Add a permission → Microsoft Graph → Application permissions:

   • InformationProtectionPolicy.Read.All
   • SubjectRightsRequest.Read.All

   Luego pulsa ‘Grant admin consent’ (sin ese clic los permisos quedan solicitados pero no efectivos, y la API responde 403).

3. Verifica que tu plan incluya las funciones

   Las etiquetas de sensibilidad necesitan M365 E3/E5 o AIP; las solicitudes de privacidad necesitan E5 o el complemento de cumplimiento. Sin licencia los checks reportarán ausencia de datos.

4. Completa esta pantalla

   • Tenant ID, Client ID y Client Secret del paso 1.
   • Dominio: donde aterrizarán los controles y la evidencia.

   Pulsa ‘Probar conexión’ antes de guardar.

---

¿Falla la conexión o una verificación queda en rojo? Revisa Estado y cobertura.