¿Qué se revisa en una auditoría de seguridad de Microsoft 365?
Una auditoría de seguridad de Microsoft 365 revisa identidades, privilegios, autenticación y Conditional Access; también dispositivos, correo, colaboración, aplicaciones y protección de la información. Contrasta la configuración de Microsoft Defender y la monitorización con la cobertura real: qué usuarios y equipos están protegidos, qué excepciones existen y quién responde a las alertas. La evaluación combina configuración, registros y pruebas acordadas con el contexto del negocio, las licencias y los controles compensatorios. El resultado debe identificar riesgos con evidencia suficiente y proponer un plan de mejora priorizado. Microsoft Secure Score es una entrada útil, pero su puntuación no sustituye esa evaluación.
Publicado y revisado el .
En Microsoft 365, el problema rara vez es que no existan controles de seguridad. El trabajo está en averiguar cuáles están configurados, a quién protegen, qué excepciones existen y si están funcionando como esperábamos.
En una revisión suelo empezar por una pregunta concreta: qué tendría que demostrarme la organización para dar por protegido un acceso importante. «Tenemos MFA» es una respuesta inicial. Falta saber qué cuentas lo necesitan, en qué aplicaciones, con qué métodos y qué ocurre con las que quedaron fuera.
Microsoft 365 no se audita mirando una puntuación
Microsoft Secure Score ayuda a localizar mejoras y seguir su evolución. Es una base útil para la revisión. Microsoft indica expresamente que sus recomendaciones no cubren todas las superficies de ataque de cada producto. También permite reconocer mitigaciones alternativas y soluciones de otros fabricantes. Documentación de Secure Score.
Una puntuación razonablemente alta puede coexistir con una cuenta administrativa excluida de una política, consentimientos antiguos de aplicaciones o información confidencial compartida de forma demasiado amplia. Son escenarios que conviene comprobar, no una afirmación sobre todos los tenants.
Un tenant es el entorno de la organización en los servicios cloud de Microsoft. Si has llegado buscando una «auditoría Office 365», esta guía aborda la revisión de seguridad del entorno Microsoft 365; algunas suscripciones y servicios mantienen la denominación Office 365.
| Aspecto | Microsoft Secure Score | Auditoría de seguridad |
|---|---|---|
| Objetivo | Medir el avance en recomendaciones cubiertas por el servicio. | Evaluar riesgos y efectividad de controles dentro de un alcance acordado. |
| Contexto | Información disponible para el producto y sus recomendaciones. | Procesos, datos, exposición, licencias y restricciones del negocio. |
| Automatización | Recogida y puntuación automatizadas, con acciones que admiten intervención. | Combina recogida automatizada, entrevistas, análisis y pruebas acordadas. |
| Evidencias | Estado y detalle de las recomendaciones disponibles. | Configuración, cobertura, registros, muestras y límites de lo comprobado. |
| Excepciones | Las que reflejan sus recomendaciones y estados. | Justificación, propietario, vigencia y efecto de las exclusiones relevantes. |
| Riesgo de negocio | Orientación sobre mejoras técnicas. | Consecuencias sobre operaciones, personas e información. |
| Controles compensatorios | Permite reconocer soluciones alternativas. | Comprueba si esas alternativas cubren el escenario y con qué evidencia. |
| Priorización | Acciones recomendadas y su contribución a la puntuación. | Exposición, impacto, viabilidad y dependencias. |
| Resultado | Puntuación, tendencias y recomendaciones. | Hallazgos sustentados y un plan de mejora con responsables. |
Identity Secure Score se centra en la postura de identidad de Microsoft Entra ID. No debe confundirse con el conjunto de Microsoft Secure Score ni utilizarse como medida completa del tenant. Alcance de Identity Secure Score.
Antes de abrir las consolas: contexto, alcance y licencias
La misma configuración puede representar riesgos distintos según qué protege. Antes de valorar controles, necesito entender los usuarios, las ubicaciones, el trabajo remoto, los dispositivos, las aplicaciones críticas y los datos sensibles. También los proveedores con acceso y cualquier arquitectura híbrida con sistemas locales.
El sector, los requisitos contractuales o regulatorios, la madurez y los incidentes previos ayudan a decidir dónde profundizar. Las licencias se revisan por capacidades y usuarios beneficiados: que aparezca una opción en el portal no demuestra que pueda utilizarse con cualquier plan.
Auditar una configuración sin entender qué protege produce hallazgos técnicamente correctos pero poco útiles.
Separaría desde el principio cuatro referencias: requisitos aplicables a la organización, recomendaciones de Microsoft, un benchmark externo como CIS Microsoft 365 Foundations y buenas prácticas propuestas por ACBSEC. Un desvío frente a un benchmark no demuestra por sí solo un incumplimiento legal.
La recogida se acuerda con permisos mínimos y, cuando sea posible, de lectura. No hace falta pedir Global Administrator para toda la revisión. Las pruebas con impacto, los cambios de configuración y su reversión tienen que quedar autorizados y separados de la observación.
- ContextoDeterminar qué procesos y datos necesitan protección.
- IdentidadIdentificar usuarios, administradores e identidades de aplicaciones.
- AccesoContrastar políticas, exclusiones y accesos efectivos.
- DispositivosComprobar las condiciones exigidas a cada tipo de equipo.
- DatosRevisar permisos, compartición y movimientos legítimos.
- AplicacionesEntender qué integraciones pueden actuar y sobre qué recursos.
- DetecciónVerificar cobertura, registros y respuesta a alertas.
- EvidenciaSeparar lo comprobado de lo pendiente de validar.
- RiesgoRelacionar la debilidad con una consecuencia plausible.
- Plan de mejoraAsignar prioridad, dependencias y responsable.
Es un enfoque de trabajo de ACBSEC, no una metodología oficial de Microsoft ni una secuencia obligatoria para todos los entornos.
Identidad: quién existe y cómo demuestra quién es
En Microsoft Entra ID revisaría primero el ciclo de vida de las identidades y sus mecanismos de autenticación. Una cuenta inactiva con acceso relevante plantea una pregunta distinta de un usuario activo con un método de autenticación débil.
Cuentas, invitados y entorno híbrido
Relacionaría cuentas personales, administrativas, invitadas y de servicio con su propietario y finalidad. La última conexión es una señal, no una orden automática de borrado. Hay que comprobar accesos no interactivos, dependencias y procesos de baja. En un entorno híbrido, también importa de dónde procede la identidad y qué ocurre cuando falla la sincronización.
Métodos y resistencia al phishing
La autenticación multifactor (MFA) exige más de un factor, pero no todos los métodos ofrecen la misma protección. Revisaría registro, recuperación y métodos permitidos. Las authentication strengths permiten exigir combinaciones de métodos en Conditional Access; entre ellas, autenticación resistente al phishing. Microsoft Learn: authentication strengths.
Si procede adoptar passkeys/FIDO2, comprobaría compatibilidad, recuperación y despliegue real antes de darlo por resuelto. La guía de passkeys en Entra ID desarrolla esa implantación sin repetirla aquí.
Con Microsoft Entra ID Protection, revisaría las detecciones y el tratamiento del riesgo de usuario e inicio de sesión que permita la licencia. La experiencia completa requiere Entra ID P2; disponer de algunos datos no equivale a tener todas las capacidades. Disponibilidad y licenciamiento.
Conditional Access: qué protege realmente cada política
Revisar Conditional Access consiste en comprobar qué decisiones de acceso se aplican a cada escenario. Microsoft lo define como su motor de políticas de Zero Trust: utiliza señales de identidad, dispositivo, ubicación y otras condiciones para decidir el acceso. Requiere Entra ID P1; las políticas basadas en riesgo de usuario o inicio de sesión requieren P2. Alcance y licencias.
«Requerir MFA» es el nombre, no la evidencia
- ¿A quién?
- Usuarios y grupos incluidos, pertenencias reales y cuentas excluidas.
- ¿Sobre qué recursos?
- Aplicaciones cubiertas, exclusiones y dependencias del acceso.
- ¿Qué satisface el control?
- MFA admitido o authentication strength exigida; requisitos combinados con «todos» o «uno de» cuando corresponda.
- ¿En qué condiciones?
- Clientes, dispositivos, ubicaciones, riesgo y controles de sesión.
- ¿Qué ocurrió realmente?
- Resultado en registros de inicio de sesión y pruebas representativas acordadas.
Miraría especialmente administradores, invitados, dispositivos no gestionados y clientes heredados que sigan presentes. Una ubicación de confianza no demuestra por sí sola que el equipo sea seguro. Tampoco basta con revisar una política aislada: hay que entender las demás que coinciden en ese acceso.
Report-only evalúa, pero no aplica los controles de acceso de la política. Sus resultados sirven para estudiar el impacto; no son evidencia de bloqueo. Microsoft advierte además de posibles solicitudes de certificado de dispositivo en determinados escenarios, por lo que tampoco lo presentaría como un modo siempre invisible para el usuario. Evaluación en report-only.
Usaría las herramientas de simulación como apoyo y contrastaría sus resultados con los registros. Que no aparezca una nueva petición de MFA no demuestra que se haya evitado el requisito: puede haberse satisfecho mediante una autenticación previa. La conclusión debe apoyarse en el detalle del acceso.
Privilegios: quién puede hacer qué y durante cuánto tiempo
El número de Global Administrators es una señal inicial. Importan también los demás roles, el alcance de sus permisos, quién puede asignarlos y si una cuenta cotidiana comparte credenciales con tareas administrativas.
Revisaría asignaciones permanentes y elegibles, cuentas de servicio y privilegios específicos de cada carga de trabajo. Con Privileged Identity Management (PIM), comprobaría activación, duración, justificación y aprobación donde esté configurada. PIM requiere Entra ID P2 o Entra ID Governance; otras funciones de gobierno tienen condiciones propias. Licencias de Identity Governance.
Las cuentas de acceso de emergencia, o break-glass, merecen un tratamiento separado. Hay que validar independencia, credenciales, protección, monitorización y pruebas de acceso. Una exclusión destinada a evitar el bloqueo del tenant no debe convertirse en una cuenta de uso habitual ni interpretarse como una recomendación de dejarla sin MFA. Recomendaciones actuales de Microsoft.
Dispositivos: qué cambia cuando el equipo no está gestionado
Una identidad válida no describe el estado del equipo desde el que accede. Si hay Intune, revisaría las políticas de cumplimiento, su asignación y cómo utiliza Conditional Access ese resultado. Estar registrado en Entra, estar inscrito en Intune y cumplir una política son estados diferentes. Relación entre Intune y Conditional Access.
| Escenario | Qué intentaría comprobar |
|---|---|
| Usuario válido + equipo gestionado | Si el dispositivo realmente cumple las condiciones exigidas y tiene protección activa. |
| Usuario válido + dispositivo personal | Qué puede consultar, descargar o sincronizar y qué protección alternativa existe. |
| Credenciales comprometidas + equipo desconocido | Qué barreras siguen actuando y qué señales permitirían detectar el acceso. |
No asumiría que Intune o Defender for Endpoint están desplegados. Si la empresa utiliza otras herramientas, el análisis debe recogerlas y comprobar su cobertura. Para dispositivos personales —BYOD—, la decisión puede ser limitar determinados usos o proteger aplicaciones, según contexto y licencias, en lugar de exigir la misma gestión que a un equipo corporativo.
Correo: qué puede entrar, salir o desviarse
En Exchange Online revisaría tanto la protección del mensaje como las rutas que pueden desviar información. Las políticas antispam y antiphishing se evalúan con sus asignaciones, exclusiones y resultados, no solo por existir.
Comprobaría SPF (remitentes autorizados), DKIM (firma del mensaje) y DMARC (política del dominio ante fallos de autenticación) en relación con todos los remitentes legítimos del dominio, incluidos proveedores. Un cambio de autenticación de correo sin ese inventario puede interrumpir envíos válidos. Safe Links, Safe Attachments y la protección avanzada frente a suplantación se revisan cuando el plan de Defender for Office 365 correspondiente las cubre. Configuraciones recomendadas por Microsoft.
También buscaría reenvíos externos, reglas de bandeja de entrada relevantes, conectores y permisos sobre buzones compartidos. Una regla no es maliciosa por ser automática: se contrasta su destino, autor, fecha y necesidad. Los protocolos y aplicaciones que sigan utilizando mecanismos heredados se comprueban con evidencias actuales, sin dar por hecho que todos han desaparecido.
Colaboración: quién puede compartir qué información
SharePoint, OneDrive y Teams requieren revisar quién puede llegar a los datos y cómo se amplía ese acceso. La configuración general del tenant no describe por sí sola los permisos de cada sitio, equipo o archivo.
Una organización puede tener MFA bien configurado y compartir información confidencial mediante enlaces anónimos. No hay contradicción: el control de autenticación y el mecanismo de compartición protegen situaciones diferentes. Revisaría enlaces «Anyone», permisos directos, invitados, propietarios y la necesidad de mantener espacios antiguos.
En Teams distinguiría acceso externo para comunicarse de acceso como invitado y de los mecanismos de canales compartidos. Después seguiría los archivos hasta SharePoint o OneDrive. La revisión relaciona sensibilidad, acceso externo y dispositivos, evitando concluir que desactivar una opción en Teams resuelve toda la compartición. Modelo de compartición externa.
Aplicaciones y OAuth: accesos sin una sesión interactiva
Las aplicaciones pueden conservar acceso a información aunque nadie vuelva a abrir su interfaz. Por eso revisaría registros de aplicaciones, aplicaciones empresariales y sus service principals, las identidades locales con las que actúan en el tenant. Relación entre aplicación y service principal.
Los permisos delegados y los permisos de aplicación no son equivalentes. Los primeros permiten actuar en nombre de un usuario; los segundos permiten a una aplicación actuar con su propia identidad, sin usuario conectado. OAuth es el marco de autorización utilizado para conceder acceso; no demuestra que la finalidad de una integración siga siendo válida. Permisos y consentimiento.
La pregunta empresarial es qué aplicaciones pueden leer correo, archivos o datos de Microsoft Graph sin que una persona inicie sesión cada vez. Buscaría propietario, finalidad, permisos concedidos, consentimiento administrativo, uso reciente y vigencia de secretos o certificados. Una aplicación conocida puede tener más acceso del necesario; una integración antigua puede seguir siendo crítica. Hay que comprobarlo antes de retirar permisos.
La MFA de usuarios no cubre por sí sola todos los accesos de identidades de aplicación. Tampoco deben darse por aplicables a esas identidades las mismas políticas de Conditional Access de usuarios.
Defender: comprobar cobertura y respuesta a las alertas
La revisión de Microsoft Defender empieza por lo que está licenciado, incorporado y enviando señales. Microsoft Defender XDR relaciona información de las soluciones disponibles; la presencia del portal no demuestra que todas estén contratadas o desplegadas. Requisitos de Defender XDR.
Comprobaría la protección del correo con Defender for Office 365, equipos incorporados y estado de sensores en Defender for Endpoint, cobertura de identidad cuando exista Defender for Identity e integraciones de aplicaciones con Defender for Cloud Apps. La selección depende de la arquitectura y de los planes disponibles.
En cada uno interesa comparar el inventario esperado con la cobertura observada, las exclusiones y la última comunicación. Después seguiría una alerta hasta su destinatario: quién la recibe, cómo la investiga, cuándo escala y qué puede contener. Un control que genera alertas que nadie revisa tiene una limitación operativa que debe aparecer en el informe.
Purview: empezar por la información que necesita protección
Antes de crear reglas de prevención de pérdida de datos (DLP), hay que entender qué información se protege, dónde está, quién la utiliza y qué movimientos son legítimos. Después se decide qué comportamiento se quiere impedir y cómo atender las excepciones.
Cuando aplique Microsoft Purview, revisaría clasificación, etiquetas de sensibilidad, publicación de etiquetas y políticas DLP sobre los canales realmente cubiertos. Una etiqueta no implica siempre cifrado; su efecto depende de la configuración. Retención, Audit o capacidades de riesgo interno se evalúan por separado, según necesidades y licencias.
Las capacidades avanzadas no están incluidas universalmente. La descripción oficial del servicio es la referencia de licenciamiento; la guía de Purview de ACBSEC ayuda a orientarse. El enfoque de DLP desarrolla las decisiones de negocio previas a las reglas.
Logs: comprobar si podremos reconstruir un incidente
Tener registros no garantiza poder utilizarlos cuando hagan falta. Revisaría qué eventos se recogen, desde cuándo, cuánto se conservan, quién puede consultarlos y si se exportan a una plataforma de análisis o SIEM (gestión de información y eventos de seguridad).
Los registros de inicio de sesión de Entra y Microsoft Purview Audit son fuentes distintas, con retención y condiciones diferentes. Entra documenta, para los registros habituales de auditoría e inicio de sesión, siete días en Free y treinta en P1/P2. Para conservarlos más tiempo hay que planificar la exportación y el almacenamiento, o una alternativa aplicable. Microsoft documenta también retención ampliada de registros de auditoría de Entra mediante Purview Audit (Premium) con licencias adecuadas. Retención de Entra.
En Purview, comprobaría que la auditoría esté efectivamente habilitada y qué retención corresponde a los usuarios y actividades del alcance. Microsoft advierte que no está activada por defecto en determinados planes para pymes; no basta con asumirlo por disponer de Microsoft 365. Estado de la auditoría y condiciones.
Una comprobación útil es pedir al equipo que reconstruya una acción conocida y autorizada: quién accedió, desde dónde, qué cambió y qué evidencia conserva. Si faltan datos, el hallazgo debe decirlo. No se puede prometer reconstruir meses de actividad cuando esos registros nunca se conservaron.
Excepciones: propietario, justificación y vigencia
Las excepciones merecen tanta atención como la política principal. Revisaría por qué se excluyó una cuenta, dispositivo o aplicación, quién lo autorizó, desde cuándo y qué condición permitiría retirar la exclusión.
El mismo análisis sirve para Conditional Access, exclusiones de Defender y excepciones DLP. «Se hizo para que funcionara» explica el origen, pero no demuestra que siga siendo necesario. Algunas exclusiones son razonables; deben tener un alcance proporcionado y un control compensatorio comprobable.
Un registro sencillo con propietario, motivo, riesgo aceptado, medida alternativa y fecha de revisión suele ser más útil que una lista de excepciones sin contexto. Es una propuesta de gobierno de ACBSEC, no un formato documental obligatorio de Microsoft.
Del hallazgo técnico a una decisión
Un hallazgo debe permitir decidir qué hacer el lunes siguiente. «Hay catorce usuarios excluidos de CA-01» no permite valorar el riesgo hasta saber quiénes son y qué otros controles les afectan.
| Hallazgo y alcance | Catorce usuarios excluidos de CA-01; dos administran un servicio crítico. La muestra no confirma una protección equivalente para esos dos accesos. |
|---|---|
| Evidencia | Exportación fechada de la política, pertenencias de grupos y registros de los accesos revisados. Se identifica la ventana y lo que no pudo comprobarse. |
| Riesgo | Uso de credenciales comprometidas para acceder al servicio sin las condiciones de autenticación previstas. |
| Probabilidad e impacto | Valorar exposición, métodos admitidos y sensibilidad del servicio. No convertir dos cuentas en una probabilidad numérica inventada. |
| Control existente | Documentar políticas coincidentes y otras barreras; validar si compensan la exclusión. |
| Recomendación | Confirmar la necesidad y retirar o limitar las exclusiones sin justificación, con piloto, supervisión y reversión. |
| Prioridad y esfuerzo | Atender primero los accesos privilegiados sin protección equivalente. Estimar el trabajo tras validar las dependencias. |
| Dependencias y responsable | Compatibilidad de la aplicación, métodos de autenticación y acceso de emergencia. Responsable sugerido: identidad, con el propietario del servicio. |
Priorizar por riesgo y viabilidad
La prioridad combina exposición, impacto, facilidad de explotación, alcance y controles compensatorios. El esfuerzo y las dependencias ordenan la ejecución, pero no hacen desaparecer un riesgo grave porque resulte caro corregirlo.
Reducir exposición inmediata
Contener accesos o datos especialmente expuestos. Si la corrección definitiva necesita tiempo, acordar una medida temporal.
Cerrar debilidades relevantes
Resolver cobertura, permisos y dependencias con cambios probados y propietarios identificados.
Mejorar la operación
Hacer repetibles las revisiones, mantener evidencias y reducir excepciones acumuladas.
Caso ficticio: una empresa de 400 empleados
Hay controles, pero la cobertura no está clara
La empresa trabaja en híbrido y utiliza Microsoft 365 E3. Tiene políticas de Conditional Access y MFA, además de herramientas de protección de equipos. Las capacidades adicionales se revisan según las licencias contratadas; el caso no presupone P2 ni la suite completa de Defender.
La revisión detecta exclusiones antiguas, privilegios permanentes, invitados sin propietario vigente y una aplicación con permisos amplios sobre datos. También identifica dispositivos personales con acceso mayor del previsto y espacios de colaboración con compartición demasiado permisiva.
Primero se valida cada situación: una integración puede ser necesaria y un invitado puede seguir trabajando en un proyecto activo. El resultado es una lista de decisiones justificadas, no un borrado masivo. Se priorizan los accesos privilegiados y los datos expuestos; las correcciones pasan por pruebas y responsables.
La conclusión no es comprar E5 automáticamente. Parte de la mejora consiste en ordenar lo existente. Las capacidades adicionales se valoran solo cuando cubren un riesgo que las medidas actuales no resuelven de forma suficiente.
¿Quieres saber qué está ocurriendo realmente en tu tenant?
En ACBSEC revisamos alcance, cobertura y excepciones para convertir la configuración en un plan de mejora priorizado. El punto de partida son tus riesgos y las capacidades disponibles.
Revisar mi entorno Microsoft 365 →Qué debería entregar una revisión y qué pediría antes
Una buena revisión deja un resumen ejecutivo, alcance y metodología, evidencias, hallazgos, riesgos y recomendaciones. El plan debe separar mejoras inmediatas, dependencias y decisiones que requieren al negocio, con una sesión de devolución para acordar los siguientes pasos.
También debe explicar sus límites: servicios no incluidos, muestras utilizadas, datos que faltan y controles no verificados. Exportar recomendaciones automáticas no sustituye ese trabajo. La auditoría de ciberseguridad proporciona esa evaluación; la consultoría técnica puede abordar la implantación posterior.
Información inicial
Pediría usuarios, dominios, licencias, servicios utilizados, arquitectura híbrida, responsables, objetivos y problemas conocidos. Con ello se concreta el alcance y el acceso necesario. No pediría contraseñas ni secretos de aplicaciones en un correo de preparación.
Veinte preguntas para revisar tu punto de partida
Marca las preguntas para las que tienes una respuesta contrastada. No es un test de conformidad ni produce una nota de seguridad. Las marcas solo ayudan a la lectura; no se guardan ni se envían.
Cuándo repetir la revisión
La frecuencia depende del cambio y de la exposición, además de los requisitos aplicables. Conviene combinar una revisión periódica acordada con comprobaciones ante incorporaciones relevantes, cambios de identidad, integraciones, fusiones o incidentes.
El seguimiento de alertas y cambios forma parte de la operación cotidiana; una auditoría puntual no lo sustituye. Después de corregir un hallazgo, hay que verificar el resultado. No presentaría una revisión anual o trimestral como una obligación universal de Microsoft, ISO o NIS2.
Preguntas frecuentes
¿Qué incluye una auditoría de Microsoft 365?
Un alcance acordado sobre identidades, accesos, privilegios, dispositivos, correo, datos, aplicaciones y detección. Debe contrastar cobertura y excepciones, conservar evidencias y entregar recomendaciones priorizadas.
¿Microsoft Secure Score sustituye una auditoría?
No. Ayuda a localizar mejoras, pero sus recomendaciones no cubren todas las superficies de ataque. La auditoría añade contexto, pruebas, dependencias y valoración del riesgo.
¿Se puede revisar Microsoft 365 sin tener E5?
Sí. Se revisan los controles disponibles y los riesgos del entorno. E5 no es un requisito universal para una auditoría; cualquier capacidad adicional debe justificarse por necesidades y licencias concretas.
¿Tener MFA activado significa que todas las cuentas están protegidas?
No necesariamente. Hay que comprobar usuarios, aplicaciones, métodos admitidos, excepciones y registros. Una autenticación previa puede satisfacer MFA sin mostrar una nueva petición.
¿Microsoft exige MFA en todos los accesos de Microsoft 365?
La obligatoriedad desplegada por Microsoft tiene ámbitos y fases concretos, incluidos determinados portales y herramientas de administración. No demuestra que todos los usuarios, aplicaciones y escenarios del tenant tengan la cobertura deseada.
¿Qué licencia necesita Conditional Access?
Las políticas de Conditional Access requieren Entra ID P1; las basadas en riesgo de usuario o inicio de sesión requieren P2. Otras capacidades e identidades pueden tener requisitos distintos. Hay que validar el escenario y la asignación de licencias.
¿Una política en report-only bloquea accesos?
No aplica el control de acceso: evalúa el resultado para revisarlo en los registros. Algunos escenarios de dispositivo pueden generar solicitudes de certificado, por lo que conviene probar también la experiencia del usuario.
¿Qué diferencia hay entre una auditoría de Entra ID y una de Microsoft 365?
La primera se centra en identidad y acceso. Una revisión de Microsoft 365 amplía el alcance a correo, colaboración, protección de información, dispositivos, aplicaciones y operación, según lo acordado.
¿Es seguro excluir las cuentas de emergencia?
La decisión debe permitir recuperar acceso sin dejar una cuenta de uso ordinario fuera de protección. Microsoft recomienda métodos resistentes al phishing, monitorización y pruebas. Hay que evaluar las exclusiones y sus controles compensatorios.
¿Cuánto tiempo requiere una auditoría?
Depende del número de tenants, servicios, integraciones, complejidad híbrida y disponibilidad de evidencias. La estimación debe indicar alcance, muestras, reuniones y entregables; el número de usuarios por sí solo no basta.
¿La revisión requiere contraseñas de administradores?
No se deben compartir contraseñas. Se acuerda acceso nominal con los permisos mínimos adecuados, duración limitada y trazabilidad, o sesiones acompañadas y exportaciones cuando proceda.
¿La auditoría cambia la configuración?
La revisión y la implantación de cambios deben distinguirse en el alcance. Cualquier prueba o modificación necesita acordarse, considerar su impacto y disponer de supervisión y reversión.
¿Cuánto tiempo se conservan los registros?
Depende de la fuente, la licencia y la configuración. Entra documenta siete días en Free y treinta en P1/P2 para los registros habituales de auditoría e inicio de sesión. Purview Audit tiene condiciones distintas; se debe comprobar la evidencia realmente disponible.
¿La revisión demuestra cumplimiento de ISO 27001 o NIS2?
Por sí sola, no. Puede aportar evidencias a una evaluación más amplia. Las obligaciones dependen del alcance y del marco aplicable; una recomendación de Secure Score no se convierte por ello en requisito normativo.
¿Qué debería recibir al terminar?
Un resumen ejecutivo, alcance y límites, hallazgos respaldados por evidencia, riesgos y recomendaciones. También un plan priorizado con dependencias, responsables sugeridos y una sesión para acordar los siguientes pasos.
Ámbitos de MFA obligatorio de Microsoft.
Comprobar si las decisiones acumuladas siguen teniendo sentido
Microsoft 365 cambia con cada usuario, aplicación, excepción y servicio que se incorpora. La documentación no siempre avanza al mismo ritmo. Una revisión permite comprobar qué decisiones siguen siendo válidas, cuáles han perdido su justificación y qué riesgo ha quedado sin atender.
Si quieres revisar cómo está realmente configurado tu entorno, el servicio de Microsoft Security de ACBSEC conecta la evaluación con la mejora. La prioridad es que puedas decidir qué corregir y que tu equipo tenga capacidad para mantenerlo.
Fuentes y criterios de revisión
Documentación oficial consultada el 16 de septiembre de 2026. Los requisitos de producto y licencia se distinguen de las recomendaciones de Microsoft y de las propuestas de revisión de ACBSEC.
- Microsoft Secure Score
- What is Identity Secure Score?
- What is Conditional Access?
- Analyze Conditional Access Policy Impact
- Conditional Access authentication strengths
- What is Microsoft Entra ID Protection?
- Manage emergency access accounts in Microsoft Entra ID
- Microsoft Entra ID Governance licensing fundamentals
- Mandatory multifactor authentication for Azure and admin portals
- Learn about Conditional Access and Intune
- Recommended email and collaboration threat policy settings for cloud organizations
- Overview of external sharing in SharePoint and OneDrive in Microsoft 365
- Application and service principal objects in Microsoft Entra ID
- Overview of permissions and consent in the Microsoft identity platform
- Microsoft Defender XDR prerequisites
- Microsoft Purview service description
- Turn auditing on or off
- Microsoft Entra data retention
- Microsoft 365 for enterprise overview
CIS Microsoft 365 Foundations Benchmark: referencia externa para contrastar configuraciones; no sustituye el análisis del contexto ni constituye por sí misma una obligación.