Checklist ENS e ISO 27001 en Microsoft 365 y Azure (2025) — guía completa

Resumen ejecutivo y visión de conjunto

El cliente necesita demostrar que su información está protegida y que esa protección es sostenible. ENS fija medidas para la Administración Pública y proveedores; ISO 27001 organiza el sistema de gestión (ISMS) con políticas, riesgos, controles, métricas y revisión. La plataforma Microsoft aporta capacidades nativas para materializar esos controles y generar evidencias de forma repetible.

El flujo conceptual es simple: identidad fuerte (Entra ID) → datos clasificados y protegidos (Purview) → configuración gobernada (Azure Policy) → postura evaluada (Defender for Cloud, MDE) → registro y detección (Log Analytics, Sentinel) → respuesta y continuidad (playbooks, backup/DR). Cada bloque añade barreras técnicas y genera huella auditora.

ENS e ISO 27001: qué son, a quién aplican y cómo encajan

ENS (R.D. 311/2022) estructura medidas de seguridad por categorías (Básica/Media/Alta) y se apoya en guías CCN-STIC que aterrizan requisitos por tecnología (por ejemplo, perfiles para Azure y configuraciones seguras para Microsoft 365). Aplica a organismos públicos y a proveedores que les prestan servicios, con especial foco en proporcionalidad y trazabilidad.

ISO/IEC 27001:2022 define requisitos del ISMS y el Annex A con 93 controles. Integra la gestión del riesgo, el alcance, el Statement of Applicability (SoA) y la mejora continua (PDCA). Es certificable por tercera parte, lo que aporta reconocimiento externo y disciplina interna.

Ambos marcos son compatibles: ISO aporta el sistema y ENS aporta el catálogo nacional de medidas. En Microsoft, la equivalencia se apoya en mapeos oficiales (por ejemplo, iniciativas de Azure Policy para ISO 27001 y documentación específica de ENS para Azure/M365) que facilitan la verificación.

Modelo operativo en Microsoft: gobierno y responsabilidades

La estructura operativa evita que los controles dependan de personas concretas y facilita auditoría. Separar funciones y documentar la delegación es clave: quién diseña, quién aprueba, quién despliega y quién vigila.

Una cadencia práctica: mensual (privilegios, políticas de acceso, anomalías), trimestral (DLP/retención, excepciones de Policy, postura), semestral (pruebas de restauración), anual (auditoría interna completa y actualización del análisis de riesgos).

Prerequisitos, licencias y alcance funcional

Antes de desplegar, conviene confirmar qué piezas están disponibles en el inquilino y suscripciones. Esto evita huecos de cobertura y asegura visibilidad.

• Entra ID: autenticación multifactor, Acceso Condicional, Privileged Identity Management, auditoría y revisiones de acceso.
• Microsoft Purview: clasificación y etiquetas, cifrado en etiquetas, DLP para correo/SharePoint/OneDrive/Teams/endpoints, políticas de retención, eDiscovery.
• Defender: Microsoft Defender for Endpoint (EDR, vulnerabilidades, aislamiento), Defender for Office/Apps/Identity, y Defender for Cloud para Azure.
• Azure: Management Groups, Azure Policy, Log Analytics, Microsoft Sentinel, Key Vault (CMEK), Backup, almacenamiento con inmutabilidad.
• Portales de cumplimiento: catálogos y documentación del proveedor para anexar como referencia en auditorías del cliente.

Metodología paso a paso: del requisito a la evidencia

La secuencia transforma requisitos en controles y controles en evidencias repetibles:

1. Definir alcance: servicios, datos tratados, categoría ENS y apetito de riesgo. Determinar zonas (DEV/TEST/PROD) y dependencias internas/externas.
2. Mapear controles: relacionar requisitos ENS/ISO con capacidades Microsoft: identidad, datos, red, configuración, registro, detección, respuesta y continuidad.
3. Identificar brechas: evaluar impacto y probabilidad; estimar esfuerzo de remediación; priorizar cierres rápidos que reduzcan más riesgo.
4. Aplicar remediación: políticas como código, iniciativas de Policy, segmentación de asignaciones, etiquetas, excepciones documentadas con fecha de caducidad.
5. Consolidar evidencias: exportaciones firmadas temporalmente, informes con filtros y periodos claros, capturas con contexto, ubicación de custodia y responsables.
6. Revisar y mejorar: auditoría interna, acciones correctivas, lecciones aprendidas e incorporación a procedimientos.

Identidad y acceso (Entra ID)

La mayoría de incidentes modernos se apoyan en credenciales. El control de acceso en Entra ID reduce drásticamente esa superficie de riesgo.

Objetivos

• Autenticación fuerte universal: MFA para todas las identidades (incluidas cuentas de servicio compatibles).
• Acceso Condicional: exigir requisitos según contexto (riesgo de usuario y de sesión, plataforma, cumplimiento del dispositivo, ubicación).
• Privilegios efímeros: PIM para otorgar administración just-in-time con aprobación, registro y caducidad.
• Resiliencia: cuentas de emergencia (break-glass) controladas, con monitorización y uso excepcional.
• Revisión continua: campañas de Access Reviews para roles y grupos críticos.

Implementación sugerida

1. Inventariar roles y administradores actuales; retirar asignaciones directas y delegar por grupos.
2. Crear políticas de Acceso Condicional base: requerir MFA, bloquear países de alto riesgo no usados, requerir dispositivo compatible para aplicaciones sensibles.
3. Habilitar PIM para roles globales y de servicio; definir flujos de aprobación y duración mínima viable.
4. Configurar dos cuentas de emergencia con controles de uso y alertas; custodia fuera de banda.
5. Planificar revisiones trimestrales de accesos y limpiar miembros inactivos.

Evidencias útiles

• Export de políticas de Acceso Condicional con listado de exclusiones y motivo.
• Reportes de actividad PIM (activaciones, motivos, duraciones, aprobaciones).
• Actas de revisiones de acceso con decisiones y responsables.

Protección de datos y privacidad (Microsoft Purview)

El objetivo es que la sensibilidad de la información viaje con el dato y que las salidas indebidas se eviten o se registren con claridad.

Objetivos

• Clasificación y etiquetado: taxonomía simple y comprensible; etiquetas con cifrado para lo que realmente lo requiere.
• DLP por canal: reglas coherentes para correo, sitios y endpoints; comenzar en auditoría para entender el impacto y ajustar.
• Retención: conservar lo necesario por obligaciones legales o de negocio; evitar retener datos sin propósito.
• Investigación: eDiscovery y auditoría unificada para reconstruir eventos cuando haga falta.
• Control criptográfico: Customer Key cuando se precise un plus de control de claves.

Implementación sugerida

1. Definir taxonomía con negocio y legal: ejemplos concretos por etiqueta y responsables de asignación.
2. Publicar etiquetas en modo informativo y medir adopción; activar cifrado solo donde sea imprescindible.
3. Desplegar DLP en auditoría (correo y SharePoint/OneDrive), revisar falsos positivos/negativos y pasar a bloqueo gradual.
4. Configurar políticas de retención por tipo documental (contracts, HR, fiscal, etc.) con excepciones justificadas.
5. Establecer proceso de revisión trimestral de incidentes DLP y ajustes de reglas.

Evidencias útiles

• Listado de etiquetas y ámbitos; capturas de aplicación y descifrado autorizado.
• Informes DLP por periodo, con tendencias y acciones correctivas.
• Políticas de retención con justificante normativo y resultados de auditorías de eliminación.

Ejemplo conceptual de DLP

Condición: Documento con etiqueta "Confidencial" + destinatario externo
Acción: Bloquear envío y notificar
Excepción: Responsables designados con justificación y registro

Gobierno técnico en Azure (Management Groups, Policy, Key Vault)

El gobierno técnico reduce desviaciones de configuración y hace visibles las excepciones. La herencia de Management Groups permite controlar por defecto qué se puede y qué no se puede desplegar.

Objetivos

• Herencia clara: estructura de Management Groups por entorno y/o región.
• Política como guardarraíl: iniciativas que evalúen y, cuando proceda, impidan despliegues no conformes.
• Registro centralizado: envío de diagnósticos a un workspace común con retención adecuada.
• Claves bajo control: Key Vault y CMEK para recursos que lo admitan.
• Red mínima expuesta: uso de Private Endpoints, TLS moderno y cierre de protocolos heredados.

Implementación sugerida

1. Definir estructura de Management Groups (org → región/negocio → entorno) y asociar suscripciones.
2. Asignar la iniciativa ISO 27001 y otras relevantes (CIS/NIST/benchmarks sectoriales) en el grupo raíz.
3. Habilitar Diagnostic settings por suscripción para Activity/Resource logs a Log Analytics.
4. Establecer estándares de red: NSG/ASG, subredes privadas, Private DNS, puertas de enlace seguras.
5. Gestionar claves en Key Vault, con rotación y acceso mediante RBAC/PIM y registros de auditoría.
6. Gestionar excepciones de Policy con tiempo de expiración, motivo y dueño.

Evidencias útiles

• Relación de assignments de Policy y su cumplimiento por suscripción.
• Listados de excepciones activas con fecha de caducidad y plan de cierre.
• Estados de claves, rotación y registros de acceso a Key Vault.

Postura y riesgo (Defender for Cloud y Microsoft Defender for Endpoint)

La postura sintetiza el estado de hardening y exposición. Priorizar por riesgo evita dispersión de esfuerzos y acelera la reducción real del ataque.

Objetivos

• Prioridad por impacto: recomendaciones que más suben el secure score y cierran brechas críticas.
• Visión de vulnerabilidades en endpoints y servidores, con plan de parches y remediaciones.
• Señales que bloquean: riesgo del dispositivo (MDE) integrado con cumplimiento y Acceso Condicional.

Implementación sugerida

1. Activar Defender for Cloud en suscripciones y revisar Regulatory Compliance y recomendaciones por servicio.
2. Desplegar MDE en endpoints y servidores, activar reducción de superficie de ataque y probar aislamiento.
3. Configurar flujo de trabajo de remediación por sprints con responsables y fechas de cierre.
4. Usar el riesgo de MDE para marcar dispositivos no conformes y condicionar el acceso.

Evidencias útiles

• Evolución del secure score y detalle de recomendaciones cerradas.
• Informes de exposición a vulnerabilidades y métricas de reducción.
• Casos de MDE con línea temporal de acciones y resultados.

Registro, detección y respuesta (Log Analytics, Sentinel, KQL)

Sin registros no hay forense ni cumplimiento defensible. Centralizar, detectar de forma consistente y responder de manera automatizada acorta tiempos y deja trazabilidad.

Objetivos

• Ingesta completa de Entra ID, Microsoft 365, Azure (Activity/Resource), MDE/MDO/MDA en un workspace central.
• Detecciones relevantes en Sentinel, con severidades y supresiones bien diseñadas.
• Respuesta orquestada con Logic Apps: aislar equipos, revocar tokens, abrir incidencias en ITSM.

Implementación sugerida

1. Establecer conectores de datos en Sentinel y validar volúmenes y retenciones.
2. Activar reglas base (identidad, privilegios, exfiltración) y ajustar umbrales para reducir ruido.
3. Diseñar playbooks para casos frecuentes (phishing, token robado, equipo comprometido) y probarlos.
4. Versionar consultas KQL y paneles; documentar parámetros y supuestos.

Ejemplo KQL (inicios administrativos fuera de horario)

SigninLogs
| where ResultType == 0
| where Identity matches regex ".*(admin|adm).*"
| where hour_of_day(TimeGenerated) < 7 or hour_of_day(TimeGenerated) > 20
| summarize intentos=count() by Identity, bin(TimeGenerated, 1h)

Evidencias útiles

• Listado de reglas activas y su justificación.
• Capturas de ejecución de playbooks con sello temporal.
• Paneles con rango temporal definido y resultados exportados.

Continuidad y resiliencia (BCP/DR, RTO/RPO, inmutabilidad)

El ensayo controlado es la única evidencia sólida de que la organización puede volver a operar tras un incidente. La resiliencia no es un hábito puntual, es un proceso continuo.

Objetivos

• RTO/RPO realistas por servicio y datos, acordados con negocio.
• Backups inmutables y copias fuera de línea o con retención que soporte fraude interno o ransomware.
• Arquitecturas resilientes: zonas de disponibilidad, regiones emparejadas, tráfico privado y separación de planos.
• Simulacros con actas, tiempos medidos y acciones de mejora.

Implementación sugerida

1. Catalogar servicios y dependencias; documentar RTO/RPO y métricas de criticidad.
2. Configurar políticas de backup con inmutabilidad y pruebas de restauración periódicas.
3. Definir libros de ejecución (qué, quién, cómo) para interrupciones típicas.
4. Ejecutar simulacros semestrales y cerrar acciones derivadas.

Evidencias útiles

• Plan de BCP/DR firmado, topologías y responsables.
• Informes de backup y registros de restauraciones reales.
• Actas de simulacros con resultados y mejoras.

Checklist ENS por dominios con ejemplos

Relación orientativa de medidas ENS y su reflejo técnico en Microsoft. La prioridad final depende del análisis de riesgos y de la categoría ENS del sistema.

Checklist ISO 27001 (Annex A 2022) aplicado

Selección de controles con mayor impacto en Microsoft. El SoA del cliente debe reflejar controles aplicables, exclusiones y motivos.

Plantillas de trazabilidad, evidencias y “pruebas de humo”

Matriz de trazabilidad (resumen)

Checklist express (pruebas de humo)

Ejemplos breves

Política conceptual — “Bloquear acceso sin MFA”

Condición: Usuario sin método MFA

Acción: Requerir MFA; denegar si no se supera
Excepción: Cuentas de emergencia documentadas, con revisión

KQL — actividad administrativa inusual

SigninLogs

| where ResultType == 0
| where Identity matches regex ".(admin|adm)."
| where hour_of_day(TimeGenerated) < 7 or hour_of_day(TimeGenerated) > 20
| summarize intentos=count() by Identity, bin(TimeGenerated, 1h)

Errores frecuentes y cómo evitarlos

• Confundir conformidad del proveedor con conformidad propia. Los certificados del proveedor son referencia, no sustituto de los controles del cliente.
• Excepciones de Policy sin control. Toda excepción necesita motivo, alcance y fecha de fin; sin eso, se convierten en permanentes.
• Sin registro de cambios. La ausencia de trazabilidad ralentiza auditorías y encarece análisis forense.
• DR no probado. La evidencia válida es la restauración ejecutada y medida, no el plan escrito.
• Reglas de Sentinel sin mantenimiento. Si no se revisan umbrales y tuning, el ruido oculta las alertas relevantes.

Preguntas frecuentes

Enlaces oficiales

• Real Decreto 311/2022 (ENS) — BOE
• Normativa ENS — CCN
• Guías CCN-STIC (series 800/1000 para tecnologías Microsoft)
• ENS en Microsoft (Azure/Microsoft 365)
• Cumplimiento en Azure
• Azure Policy — iniciativa ISO 27001
• Azure — ISO/IEC 27001
• Microsoft Compliance offerings
• ISO/IEC 27001 — ficha oficial
• CCN-STIC-884 — Perfil ENS en Azure
• CCN-STIC-885A — Configuración segura para Office 365

Conclusión

Tratar ENS e ISO 27001 como un programa continuo —con controles por defecto, revisiones periódicas y evidencias claras— reduce riesgos y simplifica auditorías. Con Entra ID, Purview, Azure Policy, Defender for Cloud, MDE y Sentinel, el cliente dispone de una base técnica sólida y trazable.