Microsoft 365 e ISO 27001: quién conserva acceso y cómo demostrar el control

Una empresa puede exigir doble factor y seguir sin saber quién conserva acceso a sus archivos, aplicaciones y funciones administrativas. El problema aparece cuando las altas, los cambios de cargo, los invitados, las aplicaciones conectadas y las excepciones avanzan por caminos distintos. Microsoft 365 ofrece herramientas para gestionar identidades, autenticación y permisos; ISO/IEC 27001:2022 exige que la organización gobierne sus riesgos y pueda demostrar que sus controles funcionan. Ninguna de las dos cosas equivale, por sí sola, a tener los accesos bajo control.

Esta guía toma como punto de partida una infografía sobre Microsoft Entra ID, autenticación multifactor, acceso condicional y mínimo privilegio. Su mensaje es útil, pero incompleto si se convierte en una lista de productos. La pregunta empresarial es más exigente: ¿puede la dirección explicar quién accede a qué, por qué, durante cuánto tiempo y qué ocurrió cuando dejó de necesitarlo? Respondemos con un modelo de decisiones y evidencias para empresas que utilizan Microsoft 365 en Colombia, España y otros mercados, sin atribuir a una función técnica el cumplimiento automático de la norma.

Qué muestra la imagen y qué conviene matizar

La pieza presenta una secuencia intuitiva. Entra ID administra identidades y grupos; MFA añade una comprobación de autenticación; el acceso condicional decide según señales del inicio de sesión; el mínimo privilegio limita permisos. Después asocia ese conjunto a tres controles del Anexo A: 5.15, 5.17 y 5.18. El cierre reconoce que la tecnología necesita políticas, procedimientos, revisiones periódicas y evidencias de operación. Ese último renglón es, en realidad, el centro de la historia.

Hay cuatro matices relevantes. Primero, autenticar a una persona no prueba que deba conservar una autorización concreta. Segundo, una condición de ubicación o dispositivo no reemplaza una evaluación de riesgos ni convierte un acceso en legítimo. Tercero, las capacidades dependen de la licencia, configuración, alcance y conectores de cada organización: no todas las funciones aparecen por el mero hecho de pagar Microsoft 365. Cuarto, una certificación ISO de servicios de Microsoft corresponde al alcance certificado del proveedor, no certifica el sistema de gestión del cliente. La organización debe definir, ejecutar y evaluar sus propios controles. Microsoft describe expresamente responsabilidades compartidas en la gestión de cuentas y en sus ofertas de cumplimiento.

Conviene además ampliar la correspondencia normativa: junto a control de acceso (5.15), información de autenticación (5.17) y derechos de acceso (5.18), la gestión de identidades (5.16) también es relevante. La numeración orienta el análisis, pero no sustituye el texto licenciado de la norma, la Declaración de Aplicabilidad ni el criterio de auditoría. ISO/IEC 27001 es un sistema de gestión basado en contexto, riesgos, operación, evaluación y mejora, no un catálogo fijo de botones que se marcan en una consola.

La pregunta de negocio: autorización vigente, no solo inicio de sesión

Imagine que una analista cambia de área. Su cuenta continúa activa, el teléfono registra MFA correctamente y una política de acceso condicional considera conforme su portátil. No hay un fallo de autenticación. Sin embargo, el grupo antiguo conserva acceso a informes financieros y el nuevo cargo ya no lo justifica. El control falló en la transición del rol, no en la contraseña ni en la verificación adicional. Si además un proveedor invitado mantiene una carpeta compartida tras terminar su contrato, el inventario de empleados tampoco describe todo el riesgo.

La dirección debería distinguir cinco preguntas: ¿quién es la identidad?, ¿cómo se autentica?, ¿qué autorización tiene?, ¿bajo qué condiciones se concede cada sesión?, ¿cuándo y con qué evidencia se revisa o retira? La plataforma puede ayudar a ejecutar y registrar partes de ese recorrido. La decisión sobre necesidad, propietario, plazo y aceptación de excepciones pertenece a la empresa. Esta distinción permite evaluar el servicio de SGSI e ISO/IEC 27001 de Insylux como un trabajo de gobierno y evidencia, no como instalación de un producto.

Una sesión válida tampoco demuestra ausencia de abuso. Un atacante con una sesión robada, un usuario legítimo que excede su necesidad o una aplicación con permisos excesivos pueden operar después de superar una barrera de entrada. La respuesta exige combinar prevención, revisión y detección; el alcance debe incluir identidades humanas, invitadas, de servicio y aplicaciones cuando afectan información crítica. Tratar cada categoría de forma idéntica puede dejar huecos o bloquear procesos esenciales.

El recorrido del acceso, desde la solicitud hasta la baja

El siguiente gráfico es un modelo conceptual: no representa métricas de incidentes, porcentajes de eficacia ni una secuencia normativa obligatoria. Muestra cómo una autorización necesita decisiones y comprobaciones a lo largo del tiempo. Las barras recorren sus etapas en un ciclo visual para facilitar la lectura; el contenido completo sigue disponible sin animación.

Cuatro decisiones para mantener un acceso legítimo

La evidencia conecta una necesidad del negocio con un permiso real y su cierre.

1. 1. Solicitar y aprobarPropietario, recurso, motivo, perfil, vigencia y aprobador identificados.
2. 2. Autenticar y condicionarMétodo adecuado al riesgo; señales de sesión y dispositivo según política.
3. 3. Revisar y detectarComparar necesidad vigente con permisos efectivos, invitados y privilegios.
4. 4. Retirar y comprobarDesactivar o revocar en los sistemas incluidos y registrar el resultado.

El orden no termina en una línea recta. Un cambio de cargo devuelve el acceso a la etapa de aprobación; un incidente puede exigir una retirada urgente; una aplicación nueva obliga a reconsiderar propietarios y permisos. Por eso una revisión trimestral, cuando corresponda a la criticidad, no compensa que un proceso de baja tarde semanas. El objetivo es que los eventos del negocio activen cambios verificables y que una comprobación periódica descubra los desvíos no detectados.

Primero identifique personas, recursos y propietarios

Empiece por los procesos que pueden afectar clientes, pagos, información sensible o continuidad. Enumere aplicaciones, espacios de SharePoint, Teams, bibliotecas, buzones compartidos, grupos, roles administrativos y aplicaciones registradas que acceden a datos. El inventario de cuentas por sí solo no responde quién puede leer, compartir, administrar o exportar. Para cada recurso crítico, nombre a una persona que pueda aprobar y revisar la necesidad de acceso desde el negocio.

Las identidades de invitado requieren especial atención. Su existencia puede ser legítima para colaborar con clientes y proveedores, pero el patrocinador interno, la caducidad prevista y la responsabilidad por los archivos compartidos deben poder explicarse. Un invitado retirado de un grupo aún podría conservar otra vía de acceso, dependiendo de la configuración y de lo que se compartió. Compruebe las rutas efectivas, no suponga que una sola acción revoca todos los permisos.

Incluya cuentas de administración, automatizaciones e integraciones. Los permisos de una aplicación pueden abarcar información de muchos usuarios, incluso cuando ningún empleado interactúa con ella a diario. Un informe de personas con MFA habilitado no cubre necesariamente identidades de carga de trabajo o secretos de aplicaciones. Registre propietario, propósito, permisos concedidos, credenciales, vencimiento y ruta para desactivar cada integración. Antes de quitar permisos, evalúe el impacto para no interrumpir procesos legítimos.

Entra ID es el punto de coordinación, no el dueño de cada decisión

Microsoft Entra ID ofrece el directorio, grupos, roles, registros de inicio de sesión y funciones de gobierno cuya disponibilidad depende del plan contratado. Su valor aparece cuando las fuentes de recursos humanos, los dueños de aplicaciones y la operación de TI acuerdan qué evento inicia una alta, un traslado o una baja. Si una solicitud se aprueba por chat y alguien agrega manualmente a la persona a varios grupos sin registrar motivo, el directorio refleja el permiso final pero no su justificación.

El diseño de grupos y roles merece cuidado. Un grupo llamado “Ventas” puede otorgar acceso a un buzón, a un sitio y a una aplicación de terceros: cambiar la pertenencia modifica tres exposiciones a la vez. La herencia reduce tareas, pero también puede ocultar privilegios acumulados. Documente qué concede cada grupo crítico y qué excepciones existen. Pruebe con un perfil de ejemplo antes de automatizar altas masivas; verifique tanto lo que debería verse como lo que debería permanecer inaccesible.

En cambios de puesto, compare el estado anterior y el nuevo. No basta con añadir los permisos nuevos. Identifique los antiguos que deben retirarse, los que permanecen por una transición aprobada y la fecha límite de esa excepción. Conserve la decisión del propietario y el resultado de la retirada. La revisión posterior debe buscar acumulación de accesos, no únicamente cuentas deshabilitadas.

MFA reduce una clase de riesgo, pero los métodos importan

La autenticación multifactor dificulta el uso de credenciales robadas, pero no todos los métodos ofrecen la misma resistencia frente a phishing ni todos los escenarios se resuelven con un aviso en el teléfono. Microsoft recomienda métodos resistentes a phishing para roles administrativos y advierte que activarlos sin registrar previamente a los administradores puede bloquear el entorno. Una llave de seguridad o passkey FIDO2, cuando se configura adecuadamente, ofrece propiedades distintas de un código enviado por SMS. El método elegido debe responder al riesgo y a las necesidades de recuperación.

Observe cobertura efectiva, no solo una casilla de configuración. Pregunte qué identidades y aplicaciones quedan excluidas, qué métodos se aceptan, cómo se registran dispositivos nuevos y quién puede restablecer factores. Un proceso de recuperación débil puede permitir que un tercero sustituya un factor de una cuenta legítima. Simule, con autorización y sin exponer datos reales, el recorrido de un empleado que pierde su dispositivo y el de una persona que intenta convencer a soporte de restablecerle el acceso.

La política para cuentas de emergencia necesita un diseño deliberado. Microsoft recomienda cuentas separadas, cloud-only, con autenticación resistente y verificación periódica; algunas políticas de acceso condicional que podrían impedir su uso deben tratarlas de forma especial. Esto no equivale a crear una excepción permanente sin supervisión. Documente custodia, acceso, alertas, pruebas y respuesta ante uso. Una cuenta de emergencia olvidada o compartida sin trazabilidad crea un riesgo diferente al que pretendía resolver.

El acceso condicional exige pruebas antes de activarse

Las políticas de acceso condicional pueden exigir una fortaleza de autenticación, limitar sesiones o bloquear acceso según usuarios, aplicaciones y señales. Su utilidad depende de a quién abarcan y de qué sucede cuando varias políticas coinciden. Una regla diseñada para administradores no protege a todos los invitados; una regla para dispositivos administrados puede bloquear a un proveedor que usa un equipo propio. Diseñe escenarios y exclusiones a partir de procesos reales, no de una plantilla sin adaptación.

Microsoft aconseja planificar las políticas y usar el modo de solo informes antes de exigirlas, especialmente para observar efectos no deseados. Incluya pruebas para trabajo remoto, viajes, teléfonos de sustitución, servicio de soporte, colaboración externa y cuentas críticas. No interprete la ubicación como prueba de confianza: redes compartidas, VPN y cambios de conectividad pueden volver esa señal insuficiente. El estado de un dispositivo también requiere gobierno de inscripción y respuesta a pérdida o incumplimiento.

Revise el licenciamiento antes de prometer una capacidad. Las funciones básicas de MFA y los valores de seguridad predeterminados pueden estar disponibles ampliamente; el acceso condicional requiere planes específicos de Entra y la evaluación de riesgo de inicio de sesión puede requerir una edición superior. Las revisiones de acceso y el gobierno avanzado tienen requisitos propios que Microsoft actualiza. Una propuesta responsable separa el control que se necesita de la función exacta y su coste, y confirma las condiciones vigentes del tenant antes de implantar.

Mínimo privilegio significa permisos adecuados durante el tiempo adecuado

El principio no significa que nadie pueda hacer su trabajo. Significa que un rol concede lo necesario para una tarea concreta, con una duración razonable y revisión cuando cambia la necesidad. Microsoft recomienda limitar el número de administradores permanentes y utilizar acceso justo a tiempo cuando el contexto y la licencia lo permiten. Antes de adoptar PIM o una herramienta similar, identifique roles actuales, personas que realmente administran, actividades que requieren elevación y el procedimiento de aprobación.

Una cuenta con privilegio alto debe tratarse de manera distinta de una cuenta cotidiana. Separe tareas administrativas cuando corresponda, reduzca permisos permanentes y examine rutas indirectas: quien administra grupos, credenciales de aplicaciones o políticas de acceso puede adquirir impacto amplio aunque su título de rol no diga “administrador global”. Registre activaciones, justificación y revisiones, pero no convierta el número de activaciones en una medida de seguridad por sí mismo.

Para datos compartidos, el privilegio también se expresa en enlaces y permisos de colaboración. Si un sitio permite compartir ampliamente y nadie revisa su población real, una estructura ordenada de roles de Entra no resuelve todo el acceso a la información. Incluya los propietarios de datos y los equipos de negocio. La decisión sobre quién necesita leer un contrato o descargar un reporte debe estar cerca del proceso que lo usa.

Qué relación tiene con ISO/IEC 27001:2022

ISO/IEC 27001:2022 establece requisitos para un SGSI; el Anexo A ofrece controles de referencia que la organización considera en su tratamiento de riesgos. En este tema, las familias de control de acceso, gestión de identidades, información de autenticación y derechos de acceso ayudan a formular preguntas concretas. No significa que todo control se satisfaga por tener una suscripción ni que exista una equivalencia universal entre un ajuste y un numeral. La aplicabilidad debe justificarse según alcance, riesgo, requisitos y controles seleccionados.

La Declaración de Aplicabilidad debe explicar por qué un control es pertinente y cuál es su estado; el plan de tratamiento conecta brechas con responsables y decisiones. Una política de accesos redactada pero no aplicada no demuestra eficacia. Una consola configurada sin aprobación, revisión o registros de excepciones puede dejar incompleto el sistema. Para que el SGSI funcione, hay que observar una muestra de solicitudes, concesiones, cambios, revisiones y bajas, y comparar el resultado con lo declarado.

La certificación de Microsoft 365 como servicio y la certificación de su empresa son asuntos diferentes. Consulte los informes y el alcance del proveedor para entender qué parte de la infraestructura controla Microsoft; documente qué configuraciones, usuarios, procesos y decisiones gestiona su organización. En una auditoría, la responsabilidad compartida debe convertirse en una matriz operativa: proveedor, cliente, tercero integrador y dueño del proceso, cada uno con evidencias identificables.

Una matriz de evidencia que se pueda comprobar

Un auditor o un cliente puede pedir prueba de un control. Es más útil mostrar un recorrido consistente que entregar decenas de capturas desconectadas. Esta matriz es orientativa; no reproduce requisitos normativos ni garantiza conformidad. El período, la muestra y el criterio se definen en el SGSI de cada organización.

Evite exportar indiscriminadamente datos personales o secretos para “tener evidencia”. Limite lectores, período de conservación y detalle; registre dónde se conserva la prueba y quién puede consultarla. Los logs de Entra y el registro unificado de Microsoft 365 son fuentes distintas con retenciones y licencias distintas. Microsoft documenta, por ejemplo, que los registros de inicio de sesión y auditoría de Entra Free y P1/P2 tienen ventanas predeterminadas diferentes. Si necesita conservar evidencias durante más tiempo, planifique la exportación y verifique su coste y protección antes de que venza la ventana disponible.

La evidencia también debe mostrar excepciones. Una cuenta sin MFA por una incompatibilidad, un invitado con acceso prolongado o un permiso privilegiado temporal no desaparecen al ocultarlos de un reporte. Registre propietario, causa, medida compensatoria, fecha de revisión y decisión de cierre. Una lista de excepciones sin vencimientos ni aceptación responsable no es un control gestionado.

Caso hipotético: una empresa que creció más rápido que sus permisos

Escenario ilustrativo, no cliente ni resultado real de Insylux. Una empresa colombiana de servicios profesionales emplea Microsoft 365 para proyectos, contratos y atención. Pasó de un equipo pequeño a varias unidades, incorporó consultores externos y mantuvo permisos de la etapa inicial. Exigió MFA a las cuentas humanas, pero dos excontratistas seguían en grupos de colaboración, un responsable de ventas conservaba acceso a una carpeta financiera y una aplicación heredada mantenía un permiso amplio. El ejemplo sirve para mostrar una secuencia de análisis, no para insinuar una brecha confirmada.

El equipo decide comenzar por contratos y datos de clientes, nombra propietarios de esos recursos y contrasta tres muestras: una persona que cambió de rol, un invitado cuyo proyecto terminó y una integración que lee archivos. La revisión encuentra que el proceso de bajas solo desactiva cuentas internas y que la aprobación de invitados ocurre fuera del registro de solicitudes. La respuesta prioriza retirar accesos injustificados tras comprobar dependencias, definir un patrocinador para cada invitado, revisar el permiso de la aplicación y establecer una comprobación recurrente. No se necesita prometer una herramienta nueva para cada hallazgo.

La dirección recibe cuatro resultados: permisos corregidos, responsables asignados, excepciones con plazo y una muestra trazable que demuestra cómo se autoriza y retira acceso. Si el análisis descubre que el problema se extiende a otras aplicaciones y sedes, la empresa puede ampliar el alcance del SGSI o solicitar un Security GAP Assessment de Insylux para priorizar brechas. La decisión depende del riesgo observado, no de vender un paquete de controles.

Seis errores que una consola bien configurada puede ocultar

1. Medir MFA como sinónimo de acceso correcto. El factor valida un inicio de sesión; la autorización necesita propietario y revisión.
2. Olvidar identidades no humanas. Aplicaciones, integraciones y cuentas de servicio pueden conservar capacidades amplias.
3. Revisar solo el directorio. Permisos sobre archivos, sitios y aplicaciones conectadas requieren un inventario de recursos.
4. Confundir política creada con política aplicada. Alcance, exclusiones, modo de operación y escenarios deben probarse.
5. Retirar sin plan de continuidad. Revocar un permiso legítimo de una integración crítica puede detener el negocio; el cambio requiere propietario, ventana y reversión.
6. Guardar capturas sin decisión. Una imagen aislada no demuestra por qué se aprobó, cuándo se revisó o cómo se cerró una excepción.

Estos errores no se corrigen únicamente con más capacitación general. La empresa necesita que recursos humanos, tecnología, dueños de datos, compras y seguridad compartan un circuito de eventos y responsabilidades. Un CISO as a Service puede ayudar a gobernar prioridades, responsables e indicadores cuando no existe dirección de seguridad dedicada; su alcance debe definirse por separado de la administración diaria del tenant.

Una ruta de 30 días para pasar de configuración a control

Primera semana: delimitar. Seleccione dos o tres procesos de alto impacto y sus recursos de Microsoft 365. Identifique propietario, usuarios internos, invitados, administradores y aplicaciones conectadas. Registre licencias, políticas activas y excepciones. Evite prometer cobertura de toda la empresa si aún no conoce sus dependencias.

Segunda semana: muestrear. Tome solicitudes reales de alta, cambio y baja dentro de un período definido. Compare aprobación, grupos, permisos efectivos y registros de sesión sin recopilar más datos de los necesarios. Incorpore un caso de proveedor y otro de administrador. Documente discrepancias con su consecuencia empresarial, no solo con una captura técnica.

Tercera semana: corregir con control de cambios. Atienda primero accesos injustificados a información crítica y privilegios altos. Revise el efecto operacional antes de revocar integraciones o grupos. Diseñe y pruebe políticas de acceso condicional en modo de informes cuando corresponda. Acorde con soporte cómo se recuperará un usuario legítimo sin debilitar el proceso de identidad.

Cuarta semana: verificar y sostener. Repita la muestra que reveló la brecha, asigne revisiones con cadencia proporcional al riesgo y documente excepciones. Presente a dirección el número de recursos cubiertos, accesos sin dueño, altas o bajas fuera de plazo y acciones cerradas con evidencia. Estos son indicadores del alcance elegido, no una puntuación universal de cumplimiento. Decida qué sistemas fuera de Microsoft 365 entrarán en la siguiente fase.

Aplicación en Colombia y España sin promesas regulatorias automáticas

En Colombia, empresas que atienden clientes corporativos suelen necesitar demostrar autorización y custodia de datos en procesos que atraviesan proveedores y personal externo. En España, la misma arquitectura de identidad puede formar parte de sistemas sujetos a obligaciones contractuales, de protección de datos o sectoriales diferentes. Este artículo no afirma que una configuración concreta cumpla por sí sola esas obligaciones. Cada organización debe analizar sus tratamientos, contratos, jurisdicciones y asesoría jurídica aplicable.

La decisión comercial útil es explicar el alcance de la evaluación. Si Insylux revisa un tenant y dos procesos, el informe debe decir qué identidades, aplicaciones, períodos y controles quedaron dentro; qué evidencias se observaron; qué depende de terceros; y qué queda pendiente. Un resultado acotado y honesto es más valioso que declarar “Microsoft 365 seguro” o “ISO 27001 cumplida” después de activar MFA. La presencia de Insylux en Medellín y Madrid permite orientar conversaciones con equipos de ambos mercados sin extrapolar una obligación de un país al otro.

Preguntas frecuentes

¿Tener Microsoft 365 significa cumplir ISO 27001?

No. Microsoft ofrece servicios y capacidades técnicas, y certifica determinados servicios bajo alcances propios. La organización debe gestionar su SGSI, riesgos, controles, operación, evaluación y mejora en el alcance que declara.

¿Basta con activar MFA para todos los empleados?

No. Es una capa importante de autenticación, pero se necesita revisar métodos, exclusiones, recuperación, permisos, invitados y aplicaciones. Un usuario puede autenticarse correctamente y conservar acceso que ya no necesita.

¿Qué diferencia hay entre Entra ID y acceso condicional?

Entra ID es la plataforma de identidad que reúne varias capacidades. El acceso condicional es una función de políticas dentro de ese ecosistema; decide condiciones de acceso según usuarios, recursos y señales, sujeta a licencias y configuración.

¿Cada empresa necesita PIM y revisiones automáticas?

No necesariamente. Primero establezca riesgos, roles, propietarios y una revisión que se cumpla. Algunas funciones avanzadas pueden reducir trabajo manual o mejorar trazabilidad si el volumen y el licenciamiento las justifican. Un procedimiento manual bien ejecutado puede ser un punto de partida válido.

¿Qué mostrar ante una solicitud de evidencias?

Una muestra trazable de solicitud, aprobación, permiso efectivo, revisión y retirada, junto con políticas aplicables, excepciones y responsables. Proteja la información personal y secretos que aparezcan en los registros.

Fuentes, fecha y límites del análisis

Fuentes primarias consultadas el 12 de octubre de 2026: ISO/IEC 27001:2022; planificación de acceso condicional de Microsoft; MFA y licencias; revisiones de acceso; roles y mínimo privilegio; cuentas de emergencia; retención de registros de Entra; y alcance de la certificación del proveedor. La infografía aportada por el usuario es el punto de partida editorial, no una prueba de que su autor sea Microsoft ni una fuente normativa. Las rutas, matrices, caso hipotético y gráfico son elaboración de Insylux; deben adaptarse a licencia, tenant y alcance reales.

Compruebe quién conserva acceso antes de prometer control