Para demostrar que un ajuste de Microsoft 365 no ha cambiado desde su última auditoría necesita tres cosas que la plataforma no guarda por usted: una instantánea fechada de la configuración, un registro de cada cambio entre instantáneas y una nota de quién autorizó cada uno. Los registros por sí solos no bastan. Microsoft Entra conserva los datos de auditoría y de inicio de sesión 7 días en el nivel Free y 30 días en P1 y P2. Microsoft Purview Audit (Standard) conserva la mayoría de los registros 180 días. Su ciclo de certificación es de 365. El hueco entre esas cifras es la parte del año que no puede evidenciar solo con la plataforma.
Esto no es una crítica a los valores por defecto. La retención está dimensionada para la investigación operativa, donde la ventana útil son días. El aseguramiento hace otra pregunta a lo largo de un periodo más largo, y cerrar la diferencia es tarea suya.
La pregunta para la que nadie se prepara
Casi todos los equipos se preparan para la evaluación equivocada. Capturan el estado actual, confirman que la autenticación multifactor se aplica hoy y presentan un paquete ordenado que muestra un tenant sano.
Entonces el evaluador hace una pregunta de otra forma. No «¿está activa esta política?» sino «¿lo ha estado desde la última vez que hablamos, y si alguna vez estuvo desactivada, quién la desactivó y quién estuvo de acuerdo en que era aceptable?». Le auditan si la configuración aguantó durante todo el periodo.
En casi ningún tenant lo sabe nadie. Puede que alguien añadiera una exclusión en febrero y la quitara en marzo, y en otoño ya nada lo recuerda. El cambio era legítimo. La ausencia de registro es el hallazgo.
Qué guarda la plataforma, y durante cuánto tiempo
Importan tres ventanas de retención, y no son las mismas.
Registros de auditoría y de inicio de sesión de Microsoft Entra. Siete días en Microsoft Entra ID Free, 30 días en P1 y P2. Aquí viven los cambios de directorio: ediciones de políticas de Conditional Access, asignaciones de rol, consentimiento de aplicaciones. Los cambios de retención no son retroactivos, así que pasar de Free a P1 le da 30 días hacia adelante, no 30 días de historia.
Microsoft Purview Audit (Standard). 180 días por defecto, no 90. Eso cambió el 17 de octubre de 2023, y mucha documentación interna sigue diciendo 90. Los registros generados antes de esa fecha mantienen el periodo antiguo de 90 días; los posteriores reciben 180 días. Este es el registro de auditoría unificado que cubre Exchange, SharePoint, OneDrive, Teams y más, un sistema separado del de los registros de Entra.
Microsoft Purview Audit (Premium). La política de retención de un año por defecto es más estrecha de lo que sugiere el nombre. Cubre registros de Microsoft Entra, Exchange, SharePoint y OneDrive, y solo para usuarios con una licencia Office 365 o Microsoft 365 E5, una licencia de Microsoft Purview Suite o el complemento E5 de eDiscovery y Audit. Los usuarios sin E5 y los invitados se quedan en 180 días, igual que la actividad de otras cargas de trabajo salvo que una política personalizada diga otra cosa.
Los registros de la plataforma caducan según un calendario de operaciones; el aseguramiento corre sobre uno de doce meses.
El desajuste, trabajado con fechas reales
Tome un tenant certificado el 14 de octubre de 2025 con la renovación reservada para octubre de 2026. El 12 de octubre de 2026 el evaluador pregunta si la política que exige autenticación multifactor se ha aplicado de forma continua desde que se emitió el certificado, y si se añadieron exclusiones. Trabaje hacia atrás desde esa fecha con Entra ID P1:
- El registro de auditoría de Entra responde hasta el 12 de septiembre de 2026. Treinta días. Muestra cualquier edición de política del último mes y quién la hizo.
- Purview Audit (Standard) responde hasta alrededor del 15 de abril de 2026. Seis meses, menos de la mitad del año de certificado.
- Purview Audit (Premium), si lo tiene, responde hasta el 12 de octubre de 2025 para registros de Entra, pero solo para usuarios cubiertos por una licencia de clase E5. Con Business Premium o un entorno mixto, esa puerta está cerrada.
Así que en el tenant que la mayoría de las organizaciones tiene, del 14 de octubre de 2025 a mediados de abril de 2026 no hay ningún registro consultable de la plataforma: seis meses del año de certificado en los que la respuesta a «¿se aplicaba esta política?» es un encogimiento de hombros.
Un detalle pilla a quien resuelve esto tarde. En Purview la retención aplicada a un registro se decide cuando entra en el proceso, así que una política personalizada más larga creada en septiembre no extiende los registros generados en marzo. La retención se decide por adelantado o no se decide.
El mapeo de los ajustes de Microsoft 365 a los controles de Cyber Essentials e ISO 27001 le dice qué ajustes soportan un control. Este artículo trata de demostrar que aguantaron.
Tres artefactos que sobreviven a los registros
La instantánea de configuración. Una exportación fechada y legible por máquina de los ajustes que soportan sus controles. No una captura de pantalla: una captura demuestra qué aspecto tenía una página, mientras que una exportación JSON de una política de Conditional Access demuestra qué contenía, exclusiones incluidas, y se puede comparar con la copia del mes anterior.
El registro de deriva. La diferencia entre instantáneas consecutivas. Esto convierte un montón de exportaciones en un argumento: aquí está el 1 de marzo, aquí el 1 de abril, aquí las cuatro cosas que cambiaron. La deriva responde «¿ha cambiado?», la pregunta real del evaluador.
El registro de autorización. Para cada cambio del registro de deriva, quién lo pidió, quién lo aprobó y contra qué ticket o decisión de riesgo. Las organizaciones casi nunca tienen este, y es el que convierte un hallazgo en una respuesta limpia.
Estos sobreviven a cualquier periodo de retención de registros, porque usted controla dónde viven. Guárdelos en algún sitio inmutable o con control de versiones y acceso de escritura restringido, y calcule sus hashes.
Construir una línea base defendible
Una línea base tiene que ser lo bastante completa para importar y lo bastante pequeña para ejecutarse. Cubra los ajustes de los que dependen sus controles: políticas de Conditional Access con sus exclusiones, la política de métodos de autenticación, las asignaciones de roles de directorio incluidas las elegibles, los ajustes de acceso entre tenants, los perfiles de cumplimiento de dispositivos, los ajustes de compartición de todo el tenant y las aplicaciones con permisos consentidos. Una primera pasada:
Connect-MgGraph -Scopes 'Policy.Read.All','Directory.Read.All','RoleManagement.Read.Directory'
$stamp = (Get-Date).ToString('yyyy-MM-dd')
$out = ".\baseline-$stamp"
New-Item -ItemType Directory -Path $out -Force | Out-Null
Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json -Depth 12 | Set-Content "$out\conditional-access.json"
Get-MgPolicyAuthenticationMethodPolicy | ConvertTo-Json -Depth 12 | Set-Content "$out\auth-methods.json"
Get-MgDirectoryRole -All | ConvertTo-Json -Depth 8 | Set-Content "$out\directory-roles.json"
Get-ChildItem "$out\*.json" | Get-FileHash | Export-Csv "$out\hashes.csv" -NoTypeInformation
Importan dos reglas.
Ejecútela con una programación. Una línea base sin programar tiene huecos que no puede explicar, y un hueco se ve peor que un cambio.
Ponga la cadencia por debajo de su retención de registros más corta. Si el registro de auditoría de Entra guarda 30 días y usted toma instantáneas cada trimestre, cuando aparezca una diferencia no podrá averiguar quién la hizo, porque la entrada de auditoría que la nombraba caducó semanas antes. Tome instantáneas semanales, o quincenales como mínimo, y cada diferencia seguirá siendo atribuible mientras el registro que la explica siga vivo.
Convertir un registro de deriva en evidencia
Una comparación le dice qué cambió. Un evaluador quiere saber quién lo cambió y quién estuvo de acuerdo. Unir esas dos cosas es todo el ejercicio, y tiene que ocurrir dentro de la ventana del registro. Para cada objeto cambiado, traiga la entrada correspondiente del registro de auditoría de Entra, que guarda quién la inició:
$since = (Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $since and category eq 'Policy'" -All |
Select-Object ActivityDateTime, ActivityDisplayName,
@{n='Actor';e={$_.InitiatedBy.User.UserPrincipalName}},
@{n='Target';e={$_.TargetResources[0].DisplayName}} |
Export-Csv ".\policy-changes-$((Get-Date).ToString('yyyy-MM-dd')).csv" -NoTypeInformation
Después añada lo que la plataforma no puede saber: la referencia del cambio y la persona que lo aprobó. Con una línea por cambio basta. Fecha, objeto, qué cambió, quién lo cambió, ticket, aprobador. Añadida a un registro que nunca se trunca, esa línea sigue respondiendo preguntas dentro de tres años.
Cuando un cambio no tiene ticket ni aprobador, regístrelo también. Un evaluador está mucho más cómodo con «esto no estaba documentado, y esto es lo que hicimos al respecto» que con un registro que no contiene ninguna excepción en absoluto.
La deriva y la higiene de identidades llegan juntas, así que una baja que conservó una exclusión es un hallazgo habitual; la lista de comprobación de offboarding cubre eso.
Dónde se rompe
Microsoft Entra ID Free. Siete días no es una ventana contra la que se pueda ejecutar un proceso mensual. Arregle esto primero, recordando que la mejora no rellena hacia atrás.
Invitados y usuarios sin E5. El valor por defecto de Premium se detiene en la frontera de la licencia, así que un entorno mixto tiene una posición de retención mixta. Sepa qué usuarios están cubiertos antes de apoyarse en un año de historia que existe solo para algunos de ellos.
Exportaciones que nadie puede consultar. Una carpeta de PDF es deberes, no evidencia. Si responder «¿qué cambió en marzo?» supone abrir archivos a mano, el proceso se abandonará.
Acceso delegado en proveedores de servicios gestionados. Cuando el cambio lo hace un socio, el actor en el registro de auditoría del cliente es una identidad del socio mientras la aprobación vive en el sistema propio del socio. Decida qué lado guarda el registro de autorización y cómo lo obtiene el cliente, porque en la renovación es al cliente a quien evalúan. Eso pertenece al paquete de informe mensual.
Suponer que la renovación es la única fecha límite. Los cuestionarios de seguros, las revisiones de seguridad de clientes y las peticiones de aseguramiento de proveedores hacen la misma pregunta.
Dónde encaja EtherInsights
Ejecutar una instantánea semanal, compararla y mantener un registro atribuible es fácil de describir y tedioso de sostener a mano. EtherInsights existe en parte por esa razón: captura la configuración del tenant y el estado de identidad, sigue qué se movió entre capturas y mantiene el registro consultable mucho después de que los propios registros de la plataforma hayan caducado, de modo que la evidencia de renovación es un informe que vuelve a ejecutar en lugar de quince días de arqueología.
Para los socios la multiplicación es la clave, porque la misma pregunta llega de todos los clientes dentro de las mismas pocas semanas cada otoño, y seguridad y conformidad de Microsoft 365 es donde la postura y las evidencias se sientan juntas. Nuestra lista de comprobación de Cyber Essentials v3.3 cubre qué arreglar; esto cubre cómo demostrar que siguió arreglado. Conformidad ISO y preparación para auditorías recoge el rastro de evidencias más amplio.
Explore la seguridad y conformidad de Microsoft 365 para ver cómo las líneas base, la deriva y el registro de autorización se juntan antes de la próxima evaluación.