Introducción al marco de certificación de Microsoft 365

En este artículo se proporciona información detallada sobre la certificación de Microsoft 365, incluida una lista de los controles de seguridad necesarios e instrucciones para ISV y desarrolladores.

La certificación de Microsoft 365 es una auditoría independiente de seguridad y privacidad de aplicaciones, complementos, agentes y entorno de back-end de soporte (denominados colectivamente aplicaciones) que se integra con la plataforma de Microsoft 365. Las aplicaciones que aprueben se designarán como Microsoft 365 certificadas en todo el ecosistema de Microsoft 365 y se pueden encontrar fácilmente en los marketplaces de Microsoft 365 a través de filtros de búsqueda centrados en el cumplimiento normativo y la personalización de marca. Los ISV tendrán la oportunidad de compartir los atributos de cumplimiento de sus aplicaciones en páginas dedicadas dentro de este conjunto de documentación.

La certificación de Microsoft 365 está disponible para los siguientes tipos de aplicaciones:

• Complementos de Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
• Aplicaciones de Teams
• Soluciones de SharePoint
• Aplicaciones web (SaaS)
• Extensiones de Copilot

Importante

La certificación de Microsoft 365 es una revisión rigurosa de la seguridad y el cumplimiento de una aplicación con respecto al marco de certificación de Microsoft 365 y requiere un compromiso sustancial de tiempo y recursos para completarse. Antes de empezar, revise los marcos de control de cumplimiento para comprobar que su aplicación es apta. Si tiene alguna pregunta, envíe un correo electrónico a appcert@microsoft.com.

Terms

Al participar en el programa de certificación de Microsoft 365, acepta estos términos complementarios y cumplir con cualquier documentación complementaria que se aplique a su participación en el programa de certificación de Microsoft 365 con Microsoft Corporation ("Microsoft", "nosotros", "nos" o "nuestro"). Usted declara y nos garantiza que tiene la autoridad para aceptar estos términos complementarios de la Certificación de Microsoft 365 en su nombre, en el de una empresa y/o en el de otra entidad, según corresponda. Podemos cambiar, enmendar o cancelar estos términos complementarios en cualquier momento. Su participación continuada en el programa de certificación de Microsoft 365 después de cualquier cambio o modificación significa que acepta los nuevos términos complementarios. Si no acepta los nuevos términos complementarios o si rescindimos estos términos complementarios, debe dejar de participar en el programa de certificación de Microsoft 365.

Requisitos previos

Para poder conceder la certificación de Microsoft 365, una aplicación debe completar lo siguiente:

Verificación del editor Cuando una aplicación tiene un editor comprobado, Microsoft ha comprobado que la organización que publica la aplicación es auténtica. La comprobación de una aplicación incluye el uso de una cuenta de partner de la nube de Microsoft Program (CPP) que se haya comprobado y la asociación del PartnerID verificado con el registro de una aplicación. Obtener comprobación del editor

La atestación de editores es un proceso de autoservicio en el que los desarrolladores de aplicaciones (ISV) completan una serie de preguntas sobre sus prácticas de seguridad, como el control de datos confidenciales. Una vez completada, la aplicación recibirá una página de documentos que pueden compartir con los clientes que incluye las respuestas proporcionadas.

Revise los criterios de control. No siempre es un requisito cumplir con todos los controles para obtener una certificación. Sin embargo, existen umbrales (que no se divulgarán) para cada uno de los tres dominios de seguridad que se analizan en este documento general y deben superarse. Si no se cumplen los controles críticos etiquetados como "fallo grave", se reprobará la evaluación.

Estructura de costos

ISV trabajará con la firma de auditoría para pagar la certificación. Para obtener más información y configurar una cuenta con la firma de auditoría Claranet, haga clic aquí.

Tipo de auditoría	Qué incluye	Cualificaciones
Estándar	Evaluación completa de todos los controles aplicables	Necesario para nuevas evaluaciones y recertificaciones que no califican para una auditoría satelital. Necesario si una recertificación no cumple los criterios de riesgo establecidos para una auditoría de satélites
Auditoría de satélites	Cuando se cumplen los criterios, se establece un control reducido para el segundo y tercer año de evaluación	Apto tras completar la certificación estándar en el año 1. Para el año 2 y el año 3 si no se han producido cambios significativos y superar la evaluación de riesgos
Complemento en tiempo extra	Compilable bajo pedido, incluye tiempo de informe	Se agrega solo cuando un envío necesita más tiempo con el auditor
Tasa diaria de prueba de penetración	Pentest por compromiso y en línea con los requisitos de certificación que cubren todo el alcance acordado de la evaluación	Necesario si la aplicación aún no tiene una prueba de penetración de terceros de buena reputación en los últimos 12 meses
Clone	Confirmación de una presentación clonada, revisión de cualquier control que necesite evidencia adicional	Una aplicación que comparte el mismo entorno de back-end que una aplicación que ha completado recientemente la certificación

Marco de tiempo de envío

El proceso de envío para obtener la certificación consta de dos etapas:

Etapa 1: Presentación inicial del documento (plazo de 14 días)

En esta fase, el ISV debe presentar documentación que proporcione información general sobre el entorno de soporte de su aplicación. Esto incluye, entre otros:

• Diagrama arquitectónico/flujo de datos
• Listas de componentes del sistema
• Inventarios de activos de software

Un analista revisará esta documentación para definir el alcance de la evaluación. El ISV tiene 14 días para completar y cargar la documentación requerida. El incumplimiento de esta fecha límite puede retrasar el proceso o resultar en un envío fallido.

Etapa 2: Revisión completa de la evidencia (marco de tiempo de 60 días)

Una vez definido el alcance, el ISV procederá a la fase de recogida de pruebas. En esta etapa:

1. El ISV debe cargar pruebas en todos los controles aplicables definidos a partir del ámbito.

2. Esta evidencia se someterá a revisión, revisiones (si es necesario) y un proceso final de preguntas y respuestas.

3. También se pueden realizar pruebas de penetración durante este tiempo.

El ISV tiene 60 días para completar esta etapa, a partir de la primera presentación de pruebas, que incluye:

• Carga de evidencia para todos los controles
• Revisión y comentarios de analistas
• Cualquier revisión necesaria de la evidencia presentada
• Finalización del proceso de preguntas y respuestas

Incumplimiento de la fecha límite

Si el fabricante de software independiente no puede completar el proceso dentro del plazo de 60 días, se producirá un error en la evaluación. Sin embargo, a discreción del analista, se puede otorgar una extensión de hasta 60 días adicionales en circunstancias válidas, tales como:

• Vacaciones estacionales
• Retrasos en las pruebas de penetración
• Cambios internos
• Tiempo necesario para aplicar los cambios necesarios para cumplir los requisitos de control

No se pueden otorgar más extensiones, una vez que se hayan agotado ambos plazos de 60 días.

Ámbito de certificación

El entorno dentro del ámbito abarca todos los sistemas e infraestructuras necesarios para entregar el código de la aplicación, el complemento o el agente, junto con cualquier sistema back-end compatible con el que la aplicación, complemento o agente puedan comunicarse. Cualquier entorno adicional conectado al entorno dentro del ámbito también debe incluirse en el ámbito a menos que se implemente una segmentación adecuada y los entornos conectados no puedan comprometer la seguridad del entorno dentro del ámbito.

Tenga en cuenta: Cualquier entorno de recuperación ante desastres separado también debe incluirse dentro del entorno dentro del alcance, ya que estos entornos pueden ser críticos para mantener la continuidad del servicio en caso de fallas del entorno principal.

Además, los entornos de copia de seguridad remota también deben incorporarse al ámbito, ya que pueden almacenar datos confidenciales de Microsoft. Por lo tanto, se deben implementar controles de seguridad adecuados para estos entornos.

El término componentes del sistema dentro del ámbito incluye todos los dispositivos y sistemas utilizados activamente dentro del entorno definido dentro del ámbito. Estos componentes incluyen, pero no se limitan a:

• Aplicaciones web
• Servidores (físicos o virtuales, ubicados en el entorno local o en la nube)
• Modificadores
• Equilibradores de carga
• Infraestructura virtual
• Portales de administración web de proveedores de nube
• Recursos en la nube (Virtual Machines, App Services, cuentas de almacenamiento, bases de datos, etc.)

Importante

Los componentes del sistema orientados al público son especialmente vulnerables a los ataques de actores externos y, por tanto, corren un mayor riesgo. Por lo general, estos sistemas deben aislarse de los componentes internos del sistema mediante la implementación de controles de seguridad de red (NSC), como una zona desmilitarizada (DMZ). El propósito de una DMZ es actuar como una zona de amortiguamiento, limitando la confianza extendida a los sistemas externos y mejorando la seguridad para proteger los sistemas y datos internos. Aunque una red perimetral (DMZ) puede seguir siendo la ideal en algunos casos, las arquitecturas en la nube modernas suelen basarse en medidas de seguridad alternativas adaptadas a escenarios de implementación específicos.

Infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como servicio (SaaS)

Cuando se utilice IaaS y/o PaaS para admitir el entorno dentro del ámbito que se está revisando, el proveedor de la plataforma en la nube será responsable de algunos de los controles de seguridad evaluados a lo largo del proceso de certificación. El proveedor de la plataforma en la nube deberá proporcionar a los analistas una verificación externa independiente de las mejores prácticas de seguridad a través de informes de cumplimiento externos como PCI-DSS, Attestation of Compliance (AOC), ISO 27001 o SOC 2 Type II.

Para obtener más información sobre qué controles de seguridad son probablemente aplicables al tipo de implementación y si el entorno procesa o transfiere datos de Microsoft 365, consulte el Apéndice C. Los tipos de implementación incluyen:

• ISV Hosted: aplicación hospedada por proveedores de software independientes.
• IaaS Hosted: Infraestructura proporcionada por plataformas en la nube de terceros.
• PaaS/Serverless Hosted: Aplicaciones que promedian la arquitectura basada en plataforma o sin servidor.
• Hospedado híbrido: una combinación de componentes locales y hospedados en la nube.
• Hospedado compartido: entornos de nube compartidos utilizados por varios inquilinos.

En los casos en los que IaaS o PaaS están en uso, la evidencia debe validar que la implementación se alinea con los controles de seguridad esperados para la arquitectura relevante.

Muestreo

Para garantizar una evaluación exhaustiva, el muestreo de los componentes del sistema dentro del ámbito debe considerar factores como los sistemas operativos, la función del dispositivo principal, el tipo de dispositivo (por ejemplo, servidores, enrutadores, controles de seguridad de red) y la ubicación geográfica. Las muestras se seleccionan al comienzo del proceso de certificación en función de estas consideraciones. La siguiente tabla guía el tamaño de la muestra en función de la población de componentes dentro del alcance:

Tamaño de la población	Muestra
<=5	1
>5 & <10=	2
>10 & <= 30	3
>30	4

Esto garantiza una evaluación representativa del cumplimiento del entorno en diversas configuraciones y modelos de implementación.

Nota:

Si se identifican discrepancias entre dispositivos durante la evaluación, el tamaño de la muestra puede ajustarse para garantizar una presentación adecuada del entorno.

Información general sobre el proceso de certificación

Para comenzar el proceso de certificación de Microsoft 365:

1. Atestación de editor Vaya al Centro de partners y complete el formulario de atestación de editores. Nota: Si el envío tiene más de tres meses, debes volver a enviarlo para su revisión y validación.

2. Iniciar certificación Una vez en el Centro de partners, selecciona la opción "Iniciar certificación" para comenzar el envío inicial del documento. Este paso ayuda a los analistas de certificación a identificar el ámbito de la evaluación en función de la arquitectura de la aplicación y cómo administra los datos de Microsoft. En este punto, se le pedirá que configure una cuenta con Claranet Limited.

La certificación se lleva a cabo en dos etapas principales:

1. Envío inicial de documentos En esta etapa, proporciona detalles clave para ayudar a los analistas a comprender el diseño de la aplicación, el flujo de datos y el entorno dentro del ámbito. Los analistas determinarán los controles de seguridad aplicables y describirán los componentes del sistema que requieren evidencia. Debe proporcionar documentación precisa para facilitar esta revisión, que representa aproximadamente el 5% del proceso general.

2. Revisión completa de la evidencia En esta etapa, presenta evidencia detallada que demuestre el cumplimiento de los controles de seguridad para el entorno dentro del alcance. Los analistas trabajarán estrechamente con usted durante esta fase para revisar, aclarar y comprobar sus envíos. Esta fase toma el resto del proceso.

Evaluación

Una vez aprobada la Presentación Inicial de Documentos, aparecerá en el portal una lista de los controles de seguridad necesarios. Tiene 60 días para proporcionar evidencia para cada control, confirmando que está en su lugar y operativo. Los analistas revisarán su evidencia y la aprobarán o solicitarán detalles o revisiones adicionales.

Certificación

Una vez que tu envío haya sido revisado y validado por un analista, recibirás una notificación sobre la decisión de certificación. Las aplicaciones que cumplan correctamente los criterios de certificación recibirán un distintivo, que se mostrará en su lista de AppSource y en las páginas de Microsoft Docs asociadas. Estas páginas también proporcionarán informes detallados sobre los atributos de seguridad y cumplimiento de la aplicación.

Revisión y recertificación

Las aplicaciones certificadas de Microsoft 365 deben someterse a una recertificación anual para garantizar el cumplimiento continuo de los estándares de Microsoft. El proceso de recertificación implica volver a evaluar los controles dentro del ámbito para confirmar que se alinean con el entorno actual. Puedes comenzar el proceso de recertificación hasta 90 días antes de que expire la certificación para evitar interrupciones. Las certificaciones seguirán siendo válidas durante este período.

Si la recertificación no se completa antes de la fecha de expiración, se revocará la certificación. Como resultado:

• Se quitará el distintivo de certificación y la personalización de marca de la aplicación.

• Los ISV ya no podrán comercializar la aplicación como Microsoft 365 Certified.

Si hay cambios significativos en la aplicación fuera del período de recertificación programado, los ISV deben informar al Programa de cumplimiento de aplicaciones de Microsoft para asegurarse de que la aplicación sigue siendo compatible.

Presentación inicial de documentos

Su envío inicial debe incluir la siguiente información:

Información general de la documentación	Detalles de la documentación
Descripción de la aplicación, complemento o agente	Una descripción del propósito y la funcionalidad de la aplicación, complemento o agente. Esto debería proporcionar al analista de certificación una buena comprensión de cómo funciona la aplicación, complemento o agente y cuál es su uso previsto.
Informe de pruebas de penetración	Un informe de prueba de penetración completado en los últimos 12 meses. Este informe debe incluir el entorno que admite la implementación de la aplicación, complemento o agente junto con cualquier entorno adicional que admita el funcionamiento de la aplicación, complemento o agente. Nota: si el ISV no realiza actualmente pruebas de penetración anuales, el equipo de auditoría puede completar una con un costo adicional.
Diagramas de arquitectura	Diagrama de arquitectura lógica que representa una descripción general de alto nivel de la infraestructura auxiliar de la aplicación. Esto debe incluir todos los entornos de hospedaje y la infraestructura auxiliar que admite la aplicación. Este diagrama DEBE representar todos los diferentes componentes del sistema de soporte dentro del entorno para ayudar a los analistas de certificación a comprender el ámbito de los sistemas y ayudar a determinar el muestreo. Indique también qué tipo de entorno de alojamiento se utiliza; ISV hospedado, IaaS, PaaS o híbrido. Nota: Dónde se usa SaaS, indique los distintos servicios SaaS que se usan para proporcionar servicios auxiliares dentro del entorno.
Huella pública	Detallando todas las direcciones IP públicas y URL utilizadas por la infraestructura auxiliar. Debe incluir el intervalo IP enrutable completo asignado al entorno, a menos que se haya implementado una segmentación adecuada para dividir el intervalo en uso (se requerirá evidencia adecuada de segmentación).
Diagramas de flujo de datos	Diagramas de flujo que detallan lo siguiente:
	✓ Flujos de datos de Microsoft 365 hacia y desde la aplicación/complemento/agente (incluidos EUII y OII).
	✓ Flujos de datos de Microsoft 365 dentro de la infraestructura de soporte (cuando corresponda).
	✓ Diagramas que destacan dónde y qué datos se almacenan, cómo se transmiten los datos a terceros externos (incluidos los detalles de qué terceros) y cómo se protegen los datos en tránsito a través de redes abiertas/públicas y en reposo.
Detalles del punto de conexión de API	Una lista completa de todos los puntos de conexión de API que usa la aplicación. Para ayudar a comprender el ámbito del entorno, proporcione ubicaciones de puntos de conexión de API dentro de su entorno.
Permisos de API de Microsoft	Proporcione documentación que detalle TODAS las API de Microsoft que se usan junto con los permisos que se solicitan para que la aplicación, complemento o agente funcionen, junto con una justificación de los permisos solicitados
Tipos de almacenamiento de datos	Documentos de almacenamiento y manejo de datos que describen:
	✓ En qué medida se reciben y almacenan los datos de Microsoft 365 EUII y OII
	✓ El período de retención de datos.
	✓ Por qué se capturan los datos de Microsoft 365.
	✓ Dónde se almacenan los datos de Microsoft 365 (también deben incluirse en los diagramas de flujo de datos proporcionados anteriormente).
Confirmación de cumplimiento	La documentación complementaria de los marcos de seguridad externos se incluye en el envío de la atestación del publicador o que se debe tener en cuenta al revisar los controles de seguridad de la certificación de Microsoft 365. Actualmente, se admiten los cuatro siguientes:
	✓ Atestación de Cumplimiento (AOC) de PCI DSS .
	✓ Informes SOC 2 Tipo I/Tipo II.
	✓ ISMS IEC - Declaración de aplicabilidad (SoA) y certificación ISMS / IEC - 1S0 / IEC 27001.
	✓ Paquete de autorización de FedRAMP e Informe de evaluación de preparación de FedRAMP.
Dependencias web	Documentación en la que se enumeran todas las dependencias usadas por la aplicación con versiones en ejecución actuales.
Inventario de software	Un inventario de software actualizado que incluye todo el software utilizado dentro del entorno dentro del ámbito junto con las versiones.
Inventario de hardware	Un inventario de hardware actualizado que usa la infraestructura de soporte técnico. Esto se utilizará para ayudar con el muestreo al realizar la fase de evaluación. Si su entorno incluye PaaS, proporcione detalles de los servicios en la nube o los recursos consumidos.

Actividades de recopilación y evaluación de evidencia

Los analistas de certificación deberán revisar la evidencia en todos los componentes del sistema dentro del conjunto de muestra definido. Los tipos de evidencia requeridos para respaldar el proceso de evaluación incluyen alguno o todos los siguientes:

Recopilación de evidencia

• Documentación inicial, resaltada dentro de la guía de envío de documentación inicial
• Documentos de directiva
• Procesar documentos
• Opciones de configuración del sistema
• Cambiar vales
• Registros de control de cambios
• Informes del sistema
• Actas de reunión
• Contratos/acuerdos

Se utilizarán varios métodos para recopilar las pruebas necesarias para completar el proceso de evaluación. Esta recopilación de evidencia puede ser en forma de:

• Documentos
• Capturas de pantalla
• Entrevistas
• Pantalla compartida

Las técnicas de recopilación de evidencia utilizadas se determinarán durante el proceso de evaluación. Para obtener ejemplos específicos del tipo de evidencia requerida en su presentación, consulte la Guía de evidencia de muestra.

Compartir evidencia

Durante el proceso de certificación, los ISV pueden optar por compartir sus pruebas de cumplimiento directamente con los clientes potenciales. La casilla situada en el cuadro de diálogo de carga de archivos, que está activada de forma predeterminada, concede a los administradores de Microsoft 365 acceso a las evidencias de certificación de la aplicación en el Centro de Administración de Teams y el Centro de Administración de Microsoft 365. (Los administradores de Microsoft 365 son responsables de configurar, administrar y proteger los servicios y recursos de Microsoft 365 dentro de una organización). Esta transparencia tiene como objetivo agilizar la diligencia debida de las organizaciones que evalúan nuevas aplicaciones para acelerar la toma de decisiones. Si un ISV prefiere no hacer pública esta evidencia, simplemente puede desmarcar la casilla en el momento de la presentación, conservando el control total sobre cómo y cuándo se divulga su documentación de cumplimiento.

Actividades de evaluación

Los analistas de certificación revisarán las pruebas enviadas para comprobar que se cumplen todos los controles necesarios para la certificación de Microsoft 365. Para acelerar el proceso, asegúrese de que toda la documentación especificada en la Presentación de documentación inicial esté completa y se proporcione con anticipación.

Durante la revisión, los analistas evaluarán la evidencia de la presentación inicial y la certificación del editor. Determinarán el alcance de la investigación, el lado del muestreo y si es necesaria evidencia adicional. Los analistas usarán toda la información recopilada para evaluar el cumplimiento de la especificación de certificación de Microsoft 365 y decidir si la aplicación cumple los controles definidos.

Criterios de certificación de aplicaciones

La aplicación, su infraestructura complementaria y la documentación complementaria se evaluarán en los tres dominios de seguridad siguientes:

1. Seguridad de aplicaciones
2. Seguridad operativa
3. Tratamiento, seguridad y privacidad

Cada uno de estos dominios de seguridad incluye controles clave específicos que abarcan uno o más requisitos que se evaluarán como parte del proceso de evaluación. Para garantizar que la certificación de Microsoft 365 sea inclusiva para desarrolladores de todos los tamaños, cada uno de los dominios de seguridad se evalúa mediante un sistema de puntuación para determinar una puntuación general de cada uno de los dominios. Las puntuaciones de cada uno de los controles de certificación de Microsoft 365 se asignan entre 1 (baja) y 3 (alta) en función del riesgo percibido de que ese control no se implemente. Cada uno de los dominios de seguridad tendrá una nota porcentual mínima para ser considerado aprobado. Determinados factores dan lugar a errores automáticos, entre los que se incluyen:

• Uso de permisos de API que no se ajustan al principio de privilegios mínimos (PoLP)

• Falta de informes de pruebas de penetración cuando sea necesario.

• Ausencia de defensas antimalware.

• Error al implementar la autenticación multifactor (MFA) para el acceso administrativo.

• Faltan procesos de aplicación de revisión o son insuficientes.

• Falta de aviso de privacidad RGPD compatible.

Seguridad de aplicaciones

El dominio de seguridad de aplicaciones evalúa las siguientes áreas:

• Pruebas de penetración
• Validación de permisos de la Graph API
• Inteligencia artificial responsable

Prueba de penetración

Las pruebas de penetración son fundamentales para identificar y mitigar los riesgos asociados con la aplicación o el complemento y su entorno de soporte técnico. Esto garantiza que la aplicación proporcione garantías de seguridad adecuadas a los clientes.

Las pruebas de penetración son obligatorias para cualquier aplicación que se conecte a servicios externos no hospedados o administrados por Microsoft. Si la aplicación se implementa como una solución independiente que solo usa servicios de Microsoft, como GraphAPI, es posible que no se necesiten pruebas de penetración. Sin embargo, las aplicaciones hospedadas en Azure deben someterse a pruebas de penetración para garantizar la seguridad del entorno dentro del ámbito.

Alcance de las pruebas de penetración

Pruebas de infraestructura: para la infraestructura interna y externa, las pruebas de penetración deben realizarse en el entorno de producción activo que admita la aplicación, el complemento o el agente. Esto incluye lo siguiente:

El entorno donde se hospeda el código de la aplicación, el complemento o el agente (normalmente se hace referencia en el archivo de manifiesto).

Cualquier entorno adicional que interactúe o admita el funcionamiento de la aplicación, complemento o agente (por ejemplo, si la aplicación, complemento o agente se comunica con otras aplicaciones web fuera de Microsoft 365).

Al definir el alcance de las pruebas de penetración, es fundamental incluir todos los sistemas o entornos conectados que pueden afectar la seguridad del entorno dentro del ámbito.

Recomendaciones

Pruebas de penetración de aplicaciones web: Se recomienda que las pruebas de penetración de aplicaciones web se realicen directamente en el entorno de producción en vivo. Sin embargo, las pruebas de aplicaciones web se pueden realizar en un entorno de prueba/UAT (pruebas de aceptación del usuario), siempre que el informe de prueba de penetración confirme que se está usando el mismo código base en producción en el momento de la prueba.

Validación de segmentación: si se utilizan técnicas de segmentación para aislar entornos dentro del alcance de otros, el informe de prueba de penetración debe validar la efectividad de estas técnicas de segmentación. Esto garantiza que no se introduzcan vulnerabilidades a través del proceso de segmentación.

Requisitos de las pruebas de penetración

Se revisarán los informes de pruebas de penetración para asegurarse de que no haya vulnerabilidades que cumplan los siguientes criterios de errores automáticos descritos en los controles siguientes.

Tipo de criterios	Controles de prueba de penetración
Criterios generales	Las pruebas de penetración de la infraestructura web (autenticadas y no autenticadas) y tanto internas (si procede) como externas DEBEN realizarse anualmente (cada 12 meses) y ser realizadas por una empresa independiente de confianza.
	La corrección de las vulnerabilidades críticas y de alto riesgo identificadas DEBE completarse en el plazo de un mes a partir de la conclusión de la prueba de penetración, o antes, según el proceso de aplicación de revisiones documentado del ISV.
	La superficie externa completa (direcciones IP, direcciones URL, puntos de conexión de API, etc.) DEBE incluirse dentro del alcance de las pruebas de penetración y debe estar claramente documentado en el informe de pruebas de penetración.
	A menos que el entorno se alinee con PaaS, las redes internas completas DEBEN incluirse dentro del alcance de las pruebas de penetración y deben estar claramente documentadas en el informe de pruebas de penetración.
	Las pruebas de penetración de aplicaciones web DEBEN incluir todas las clases de vulnerabilidad; por ejemplo, el OWASP Top 10 más reciente o el SANS Top 25 CWE. La recomendación es que esto se detalla dentro del informe de prueba de penetración, de lo contrario será difícil de demostrar.
	Las vulnerabilidades críticas y de alto riesgo o las vulnerabilidades consideradas como una falla automática DEBEN volver a probarse por la empresa de pruebas de penetración y destacarse claramente como corregidas dentro del informe de pruebas de penetración.
Criterios de error automático:	Presencia de un sistema operativo no compatible o de una biblioteca JavaScript no compatible.
	Presencia de cuentas administrativas predeterminadas, enumerables o adivinables.
	Presencia de riesgos de inyección de código SQL.
	Presencia de scripts entre sitios.
	Presencia de vulnerabilidades de recorrido de directorios (ruta de acceso de archivos).
	Presencia de vulnerabilidades HTTP, por ejemplo, división de respuesta de encabezado, contrabando de solicitudes y ataques de desincronización.
	Presencia de divulgación de código fuente (incluido LFI).
	Cualquier puntuación crítica o alta según lo definido por las pautas de administración de parches CVSS.
	Cualquier vulnerabilidad técnica significativa que pueda aprovecharse fácilmente para poner en peligro una gran cantidad de EUII u OUI.

Importante

Los informes deben poder proporcionar suficiente garantía de que se pueda demostrar todo lo detallado dentro de la sección anterior de requisitos de prueba de penetración.

Validación de permisos de la API de Graph API

Esto garantiza que la aplicación, complemento o agente no solicita permisos excesivos o excesivamente permisivos. Los analistas de certificación revisan manualmente los permisos solicitados por la aplicación y los comparan con el envío de atestación de editores.

El objetivo es confirmar que los permisos solicitados se adhieren al principio de privilegios mínimos. Si los analistas descubren que la aplicación solicita permisos que exceden lo necesario, se pondrán en contacto con el ISV para validar la justificación comercial de estos permisos. Cualquier discrepancia identificada entre los permisos solicitados y el envío de la atestación del publicador debe abordarse y resolverse durante esta revisión.

Inteligencia artificial responsable

La información enviada en respuesta a los controles de IA responsables se revisará junto con el archivo de manifiesto de la aplicación proporcionado por el fabricante de software independiente. Esto permite al analista comprobar la integración de Microsoft Copilot con la aplicación que se está sometiendo a la certificación, lo que proporciona una comprensión clara de cómo interactúan entre sí y qué acciones se llevan a cabo en nombre del cliente. Reconocemos que es vital que la IA se utilice de forma responsable y donde el cliente esté totalmente informado. Siempre que la información compartida se alinee con la funcionalidad esperada de la aplicación y el Standard de IA responsable de Microsoft o el Centro de recursos de inteligencia artificial confiable & responsable del NIST, estos controles se considerarán aprobados (sujeto a las comprobaciones habituales de preguntas y respuestas).

La intención es seguir trabajando con Microsoft para proporcionar algunos detalles de esta comprobación en las páginas de orientación pública relevantes, para permitir que los clientes tomen decisiones totalmente informadas sobre el uso de sus datos en lo que respecta a Copilot y la aplicación relacionada.

Seguridad operativa

Este dominio mide la alineación de la infraestructura auxiliar de una aplicación y los procesos de implementación con los procedimientos recomendados de seguridad.

Controles

Familia de control	Controls
Aprendizaje de concienciación	Proporcionar evidencia de que la organización proporciona capacitación de concientización de seguridad establecida a los usuarios del sistema de información (incluidos gerentes, altos ejecutivos y contratistas) como parte de la capacitación inicial para nuevos usuarios o cuando lo requieren los cambios en el sistema de información.
	Proporcionar evidencia de una frecuencia de capacitación de concientización definida por la organización.
	Proporcionar evidencia de documentación y monitoreo de actividades de concientización sobre seguridad del sistema de información individual mientras se conservan registros de capacitación individuales en una frecuencia definida por la organización.
Protección contra malware: antivirus	Proporcione pruebas de que la solución antimalware está activa y habilitada en todos los componentes del sistema muestreados y configurada para cumplir los siguientes criterios:
	Si es antivirus, ese análisis en acceso está habilitado y que las firmas están actualizadas dentro de un día y bloquea automáticamente el malware o las alertas y cuarentenas cuando se detecta malware.
	O si EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), se está realizando un examen periódico, se generan registros de auditoría, se mantiene actualizado continuamente y tiene capacidades de autoaprendizaje.
	Si EDR/NGAV, bloquea el malware conocido, e identifica y bloquea nuevas variantes de malware en función de comportamientos de macros, además de tener capacidades completas de lista segura.
Protección contra malware: controles de aplicaciones	Proporcione pruebas demostrables de que existe y está actualizada una lista aprobada de software / aplicaciones con justificación comercial.
	Que cada solicitud se someta a un proceso de aprobación y firma antes de su implementación.
	Esa tecnología de control de aplicaciones está activa, habilitada y configurada en todos los componentes del sistema muestreados como se documenta.
Administración de parches: aplicación de revisiones y clasificación de riesgos	Suministre documentación de directivas que rija cómo se identifican las nuevas vulnerabilidades de seguridad y cómo se les asigna una puntuación de riesgo.
	Proporcione evidencia de cómo se identifican las nuevas vulnerabilidades de seguridad.
	Proporcionar evidencia que demuestre que a todas las vulnerabilidades se les asigna una clasificación de riesgo una vez identificadas.
	Proporcione evidencia de que todos los componentes del sistema muestreados se están parcheando de acuerdo con los plazos de aplicación de revisión definidos por la organización y que los sistemas operativos y componentes de software no compatibles no están en uso. Cuando corresponda, debe incluir la base de código si se usa tecnología sin servidor o PaaS, o infraestructura y base de código si se usa IaaS.
	Pautas de plazos de parcheo establecidas, por ejemplo, "crítico: dentro de los 14 días, alto: dentro de los 30 días, medio: dentro de los 60 días".
Examen de vulnerabilidad	Proporcionar los informes trimestrales de análisis de vulnerabilidades de infraestructura y aplicaciones web. El análisis debe llevarse a cabo en toda la superficie pública (direcciones IP y URL) y en los intervalos IP internos.
	Proporcione evidencia demostrable de que la corrección de las vulnerabilidades identificadas durante el análisis de vulnerabilidades se parchea de acuerdo con su período de tiempo de aplicación de parches documentado.
Controles de seguridad de red (NSC)	Proporcione evidencia de que los controles de seguridad de red (NSC) se instalan en el límite del entorno dentro del ámbito y se instalan entre la red perimetral y las redes internas.
	Y si es híbrido, local, IaaS también proporciona evidencia de que todo el acceso público termina en la red perimetral.
	Valide que todos los controles de seguridad de red (NSC) estén configurados para eliminar el tráfico no definido explícitamente en la base de reglas y que las revisiones de reglas de controles de seguridad de red (NSC) se lleven a cabo al menos cada 6 meses.
Cambiar control	Proporcionar evidencia de que cualquier cambio introducido en los entornos de producción se implementa a través de solicitudes de cambio documentadas que contienen el impacto del cambio, detalles de los procedimientos de retroceso, pruebas a realizar, revisión y aprobación por parte del personal autorizado.
	Proporcione evidencia de que existen entornos separados para que: los entornos de desarrollo y prueba/ensayo impongan la separación de tareas del entorno de producción, la separación de tareas se aplique a través de controles de acceso, los datos de producción confidenciales no estén en uso dentro de los entornos de desarrollo o prueba/ensayo.
Implementación o desarrollo de software seguro	Proporcionar directivas y procedimientos que admitan el desarrollo seguro de software e incluyan estándares del sector o procedimientos recomendados para una codificación segura. Por ejemplo, los 10 principales del Proyecto de seguridad de aplicaciones web abiertas (OWASP) o los 25 principales puntos débiles comunes (CWE) de SysAdmin, Audit, Network and Security (SANS).
	Proporcione evidencia de que los repositorios de código están protegidos para que: todos los cambios de código se sometan a un proceso de revisión y aprobación por parte de un segundo revisor antes de fusionarse con la rama principal, se implementen los controles de acceso apropiados, todo el acceso se aplique a través de la autenticación multifactor (MFA)
	Proporcionar evidencia de que todas las versiones realizadas en los entornos de producción se revisan y aprueban antes de su implementación.
Administración de cuentas	Proporcione pruebas de que las credenciales predeterminadas se deshabilitan, quitan o cambian en los componentes del sistema muestreados.
	Proporciona pruebas de que existe un proceso para proteger (reforzar) las cuentas de servicio y de que se ha seguido este proceso.
	Proporcione evidencia de que: se emiten cuentas de usuario únicas para todos los usuarios, se siguen los principios de privilegios mínimos del usuario dentro del entorno, se implementa una directiva segura de contraseña / frase de contraseña u otras mitigaciones adecuadas, se implementa un proceso que se sigue al menos cada tres meses para deshabilitar o eliminar las cuentas que no se usan dentro de los tres meses.
	Valide que MFA esté configurado para todas las conexiones de acceso remoto y todas las interfaces administrativas que no sean de consola, incluido el acceso a cualquier repositorio de código y a las interfaces de administración en la nube.
Registro de eventos de seguridad, revisión y alertas	Proporcione pruebas de que un mínimo de 30 días de datos de registro de eventos de seguridad está disponible inmediatamente, con 90 días de registros de eventos de seguridad conservados.
	Proporcione pruebas de que los registros se revisan periódicamente y de que se investigan y abordan los posibles eventos o anomalías de seguridad identificados durante el proceso de revisión
	Proporcione pruebas de que las reglas de alerta están configuradas para que se desencadenen alertas para la investigación de los siguientes eventos de seguridad, cuando corresponda: creación/modificaciones de cuentas con privilegios, actividades u operaciones con privilegios o alto riesgo, eventos de malware, alteración del registro de eventos, eventos IDPS/WAF. (si está configurado)
Administración de riesgos de la información	Proporcionar evidencia de que se documenta y establece una política/proceso formal de gestión de riesgos de seguridad de la información ratificada.
	Proporcionar pruebas de que se lleva a cabo una evaluación formal de riesgos de seguridad de la información en toda la empresa al menos una vez al año.
	OR para el análisis de riesgos dirigidos: se documenta y realiza un análisis de riesgos dirigido al menos cada 12 meses para cada instancia en la que no se implemente un control tradicional o una mejor práctica de la industria, donde una limitación de diseño/tecnología crea un riesgo de introducir una vulnerabilidad en el entorno o pone en riesgo a los usuarios y los datos, tras sospecha o confirmación de compromiso.
	Valide que la evaluación de riesgos de seguridad de la información incluya el componente del sistema o el recurso afectado, las amenazas y vulnerabilidades o equivalentes, las matrices de impacto y probabilidad o equivalentes, la creación de un registro de riesgos / plan de tratamiento de riesgos.
	Proporcione evidencia de que cuenta con procesos de gestión de riesgos que evalúan y administran los riesgos asociados con los proveedores y socios comerciales y puede identificar y evaluar los cambios y riesgos que podrían afectar su sistema de controles internos.
Respuesta a incidentes de seguridad	Proporcione su plan o procedimiento de respuesta a incidentes de seguridad (IRP) ratificado.
	Proporcione evidencia que describa cómo responde su organización a los incidentes, que muestre cómo se mantiene y que incluye detalles del equipo de respuesta a incidentes, incluida la información de contacto, un plan de comunicación interna durante el incidente y comunicación externa con las partes relevantes, como partes interesadas clave, marcas de pago y adquirentes, organismos reguladores (por ejemplo, 72 horas para GDPR), autoridades supervisoras, directores, clientes, así como pasos para actividades como la clasificación de incidentes, la contención, la mitigación, la recuperación y el regreso a las operaciones comerciales normales según el tipo de incidente
	Proporcionar evidencia de que todos los miembros del equipo de respuesta a incidentes han recibido capacitación anual que les permite responder a incidentes.
	Proporcione evidencia de que la estrategia de respuesta a incidentes y la documentación de respaldo se revisan y actualizan en función de las lecciones aprendidas de un ejercicio de mesa, las lecciones aprendidas de responder a un incidente o los cambios organizacionales.
Plan de continuidad del negocio y plan de recuperación ante desastres	Proporcione evidencia de que existe y se mantiene la documentación que describe el plan de continuidad del negocio.
	Proporcionar evidencia de que el plan de continuidad del negocio detalla al personal relevante y sus roles y responsabilidades, que incluyen: funciones comerciales con requisitos y objetivos de contingencia asociados, procedimientos de respaldo de datos y sistemas, configuración y programación/retención, prioridad de recuperación y objetivos de plazos, un plan de contingencia que detalla acciones, pasos y procedimientos a seguir para devolver a la operación los sistemas de información críticos, las funciones comerciales y los servicios en caso de una Interrupción inesperada y no programada, un proceso establecido que abarca la eventual restauración completa del sistema y el retorno al estado original.
	Proporcione evidencia de que existe documentación, se mantiene y describe el plan de recuperación ante desastres e incluye como mínimo: personal y sus roles, responsabilidades y proceso de escalamiento, inventario de los sistemas de información utilizados para respaldar funciones y servicios comerciales críticos, procedimientos y configuración de respaldo de datos y sistemas, un plan de recuperación que detalla las acciones y procedimientos a seguir para restaurar los sistemas de información y datos críticos a operar.
	Proporcionar evidencia de que el plan de continuidad del negocio y el plan de recuperación ante desastres se revisan al menos cada 12 meses para garantizar que siga siendo válido y efectivo durante situaciones adversas.
	Proporcionar evidencia de que el plan de continuidad del negocio se actualiza en función de la revisión anual del plan, todo el personal relevante recibe capacitación sobre sus roles y responsabilidades asignados en los planes de contingencia, los planes se prueban a través de ejercicios de continuidad del negocio o recuperación de desastres, los resultados de las pruebas se documentan, incluidas las lecciones aprendidas del ejercicio o los cambios organizacionales.

Tratamiento, seguridad y privacidad de datos

Para garantizar la seguridad de los datos, todos los datos en tránsito entre el usuario de la aplicación, los servicios intermediarios y los sistemas ISV deben cifrarse mediante una conexión TLS (Seguridad de la capa de transporte). Como mínimo, se requiere TLS 1.2, con TLS 1.3 o superior. Para más detalles, véase el Apéndice A.

Para las aplicaciones que recuperan o almacenan datos de Microsoft 365, es obligatorio implementar un esquema de cifrado de almacenamiento de datos. Esto debe ajustarse a las especificaciones descritas en el Apéndice B.

Controles

Familia de controles	Controls
Datos en tránsito	Proporcione pruebas de que valida que la configuración TLS es TLS1.2 o superior dentro de los requisitos de configuración del perfil TLS y que se conserva y mantiene un inventario de claves y certificados de confianza.
	Proporcionar evidencia que muestra que la compresión TLS está deshabilitada para todos los servicios públicos que manejan solicitudes web para evitar la relación de compresión Filtración de información simplificada (CRIME) y TLS HSTS está habilitado y configurado en 180 días en todos los sitios.
Datos en reposo	Proporcionar pruebas de que los datos en reposo se cifran de acuerdo con los requisitos de perfil de cifrado, mediante algoritmos de cifrado como Advanced Encryption Standard (AES), RSA y Twofish con tamaños de clave de cifrado de 256 bits o superiores.
Retención, copia de seguridad y eliminación de datos	Proporcionar pruebas de que se ha establecido y documentado formalmente un período de retención de datos aprobado.
	Proporcione pruebas de que los datos se conservan solo durante el período de retención definido, tal como se explicó en el control anterior.
	Proporcionar pruebas de que existen procesos para eliminar datos de forma segura después de su período de retención.
	Proporcione evidencia de que existe un sistema de copia de seguridad automatizado y está configurado para realizar copias de seguridad en horas programadas.
	Proporcionar evidencia La información de respaldo se prueba de acuerdo con el procedimiento de programación de copias de seguridad y se restaura periódicamente para confirmar la confiabilidad e integridad de los datos.
	Proporcionar evidencia Se implementan controles de acceso y mecanismos de protección adecuados (es decir, copias de seguridad inmutables) para garantizar que las copias de seguridad / instantáneas del sistema estén protegidas contra el acceso no autorizado y para garantizar la confidencialidad, integridad y disponibilidad de los datos de copia de seguridad.
Administración de acceso a datos	Proporcionar pruebas de que se mantiene una lista de usuarios con acceso a los datos y/o a las claves de cifrado. Incluyendo la justificación comercial para cada persona y la confirmación, esta lista de usuarios se aprobó formalmente en función de los privilegios de acceso necesarios para su función laboral y los usuarios se configuran con los privilegios descritos en la aprobación.
	Proporcionar pruebas de que se mantiene una lista de todos los terceros con los que se comparten los datos y de que existen acuerdos de uso compartido de datos con todos los terceros que consumen datos.
Privacidad	¿Su organización tiene un sistema de administración de información de privacidad (PIM) establecido, implementado y mantenido que mantenga el compromiso del liderazgo por medio de una política u otra forma de documentación / sistema computarizado sobre cómo se mantienen sus esfuerzos de administración de información de privacidad para la confidencialidad e integridad del sistema? Determina los roles, responsabilidades y autoridades de cada persona que mantiene el sistema, incluidos los procesadores y controladores de PII.
	Proporcionar evidencia de los procesos para verificar que se esté llevando a cabo la minimización de la PII, la desidentificación y eliminación de la PII se realiza al final del período de procesamiento, existen controles para la transmisión de PII, incluida cualquier confidencialidad, existe un registro de transferencia de PII de un país/región a otro con el consentimiento expreso para hacerlo.
RGPD	Proporcionar pruebas de que los interesados pueden generar SAR, que el ISV puede identificar todas las ubicaciones de los datos de los interesados al responder a una solicitud de SAR, que existe un período de retención para las copias de seguridad que permite a los clientes que solicitan la eliminación de datos a través de SAR para eliminarlos a medida que se eliminan las copias de seguridad continuas durante un período (ciclo de vida de las eliminaciones de copia de seguridad más antiguas o se reescriben).
	Proporcione el aviso de privacidad, que debe contener todos los elementos necesarios de la siguiente manera: detalles de la organización (nombre, dirección y otra información de identificación personal), el tipo de datos personales que se procesan, cuánto tiempo se conservarán los datos personales, la legalidad del procesamiento de datos personales, los derechos de los interesados; incluyendo: derechos del interesado, derecho a ser informado, derecho de acceso por parte del interesado, derecho a la supresión, derecho a la restricción del tratamiento, derecho a la portabilidad de los datos, derecho a oponerse, derechos en relación con la toma de decisiones automatizada, incluida la elaboración de perfiles.
HIPAA	Proporcione evidencia de que: existe una política para el manejo de HIPAA e HIPAA dentro de su organización para personal, contratistas, proveedores, etc. Verificar que nuestra organización garantiza la confidencialidad, integridad y disponibilidad de ePH.
	Compruebe que: proporcionar protección contra usos o divulgaciones razonablemente previstos de dicha información que no están permitidos por la regla de privacidad, garantizar el cumplimiento de la regla de seguridad por parte de su personal. Proporcionar una copia de seguridad de datos y un plan de recuperación ante desastres en virtud de 164.308 (a) (7) (ii) (A) y 164.308 (a) (7) (ii) (B).

Revisión del marco de cumplimiento externo opcional

Si su organización ya cumple con los marcos de seguridad externos, como ISO 27001, PCI-DSS, FedRAMP o SOC 2 Tipo 2, puede elegir aprovechar estas certificaciones para satisfacer algunos de los controles de certificación de Microsoft 365. Los analistas intentarán alinear los marcos de seguridad externos existentes con los requisitos de certificación de Microsoft 365.

Sin embargo, si la documentación de soporte técnico no demuestra que los controles de Certificación de Microsoft 365 se evaluaron explícitamente como parte de la auditoría o evaluación del marco externo, debe proporcionar pruebas adicionales para comprobar que estos controles están en su lugar.

Requisitos de documentación:

La documentación debe demostrar claramente que el entorno dentro del ámbito para la certificación de Microsoft 365 se incluye dentro del ámbito de los marcos de seguridad eternos. La validación de estos marcos se llevará a cabo mediante la aceptación de pruebas de certificaciones válidas emitidas por auditores externos acreditados y acreditados.

Estos auditores externos deben ser miembros de organismos internacionales de acreditación, tales como:

• Normas de certificación y conformidad para ISO 27001

• Evaluadores de seguridad de calidad (QSA) para PCI-DSS

Para obtener más información, consulta las directrices y estándares específicos de los marcos externos relevantes para tu certificación.

La siguiente tabla describe los marcos y la documentación necesarios aceptados por los analistas de certificación como parte del proceso de validación.

Estándar	Requisitos
ISO 27001	Se requerirá una versión pública de la Declaración de aplicabilidad (SOA) y una copia del certificado ISO 27001 emitido. La SOA resume su posición sobre cada uno de los 114 controles de seguridad de la información y se usará para identificar si se excluyen los controles que no se detallan satisfactoriamente en el certificado ISO 27001. Si esto no se puede determinar revisando la versión pública de la SOA, es posible que el analista necesite acceder a la SOA completa si se va a usar ISO 27001 para validar algunos de los controles de seguridad de la Certificación de Microsoft 365. Además de validar el alcance de las actividades de evaluación ISO 27001, los analistas también confirmarán la validez de la empresa de auditoría como se describió anteriormente.
ISO 22301	Se debe proporcionar un certificado ISO 22301 válido emitido por un organismo de certificación acreditado y un documento que describa el alcance de la evaluación del Sistema de Gestión de Continuidad del Negocio (BCMS). El certificado y la documentación de alcance se utilizarán para verificar que la aplicación dentro del alcance, los servicios de soporte y los procesos operativos se han evaluado como parte de un programa formal de gestión de continuidad del negocio. Los analistas de evaluación revisarán el alcance de la certificación, confirmarán la validez del organismo de certificación y determinarán qué controles de continuidad empresarial de Certificación de Microsoft 365 se pueden satisfacer a través de la evidencia de evaluación ISO 22301.
ISO 27031	Se debe proporcionar un certificado ISO 27031 válido o un informe de evaluación emitido por un organismo de certificación o evaluación acreditado, que identifique claramente la aplicación, la infraestructura y los servicios de tecnología de la información y la comunicación (TIC) de apoyo dentro del alcance. La documentación se utilizará para evaluar la preparación de las TIC para la continuidad de las actividades, incluida la planificación de la recuperación ante desastres, las capacidades de recuperación y los procesos de resiliencia. Los analistas de evaluación revisarán el alcance de la evaluación, confirmarán la validez de la organización de evaluación y determinarán qué controles de recuperación ante desastres y resiliencia operativa de la certificación de Microsoft 365 se pueden satisfacer a través de la evidencia de evaluación ISO 27031
PCI DSS	Se debe proporcionar un documento válido de Atestación de cumplimiento (AOC) de nivel 1 que identifique claramente la aplicación en el ámbito y los componentes del sistema. No se aceptará una AOC de autoevaluación como prueba de que se cumplen las mejores prácticas de seguridad. El AOC se usará para determinar cuáles de los controles de la especificación de certificación de Microsoft 365 se han evaluado y confirmado como parte de la evaluación PCI DSS.
SOC 2	El informe SOC 2 (Tipo II) debe estar actualizado (emitido en los últimos 15 meses y el período de tiempo declarado iniciado en los últimos 27 meses) para usarse como prueba de conformidad con cualquiera de los controles de evaluación dentro de este marco de certificación de Microsoft 365.
FedRAMP	El Programa Federal de Gestión de Riesgos y Autorización (FedRAMP) es un programa para todo el gobierno federal de EE. UU. establecido en 2011. Proporciona un enfoque estandarizado para la evaluación de la seguridad, la autorización y la supervisión continua de los productos y servicios en la nube.

Marco	Consideraciones adicionales
ISO 27001	Apéndice C: Recopilación de evidencia - Deltas para ISO 27001.
PCI-DSS	Apéndice D: Recopilación de evidencia - Deltas para PCI-DSS.
SOC 2	Apéndice E: Recopilación de evidencia - Deltas para SOC 2.

Nota:

Aunque los estándares o marcos de seguridad externos se pueden enviar como evidencia de respaldo para cumplir con ciertos controles de la certificación de Microsoft 365, la obtención de la certificación de Microsoft 365 requiere una evaluación independiente. Lograr la certificación de Microsoft 365 no implica que la aplicación haya pasado completamente las auditorías para estos marcos externos. La especificación de certificación de Microsoft 365 se centra en un subconjunto específico de controles derivados de estos marcos para proporcionar a Microsoft un mayor nivel de garantía con respecto a la posición de seguridad de la aplicación.

Requisitos para usar marcos de cumplimiento externos

Requisitos para usar marcos de cumplimiento externos

El entorno dentro del ámbito y todos los procesos empresariales auxiliares deben incluirse dentro del ámbito de cualquier marco de cumplimiento de seguridad externo compatible. Estos deben estar claramente documentados en la documentación suministrada.

Los marcos de cumplimiento de seguridad externa deben estar actualizados, lo que significa que deben evaluarse en los últimos 12 meses (o 15 meses si se puede verificar una reevaluación en curso con evidencia de respaldo)

Las evaluaciones de cumplimiento de seguridad externa deben ser realizadas por una empresa independiente y acreditada.

Criterios de validación de marco externo

Evaluación SOC 2 tipo 2

• El informe SOC 2 debe ser un informe de tipo 2
• La auditoría SOC 2 debe incluir el entorno M365 que se está evaluando
• La auditoría SOC 2 debe completarse en los últimos 12 meses
• Los controles deben presentarse de manera justa y diseñarse adecuadamente como se requiere para un informe Tipo 2
• La auditoría SOC 2 debe ser realizada por un tercero externo cualificado
• Los procedimientos de prueba deben confirmar que existen controles de seguridad y que el auditor los valida adecuadamente.

Evaluación ISO 27001

• La auditoría ISO 27001 debe incluir el entorno especificado en esta evaluación M365
• El certificado ISO 27001 debe estar actualizado y ser aplicable a la entidad
• La evaluación ISO 27001 debe ser realizada por un tercero externo acreditado (no se aceptan auditorías internas ISO 27001)
• La evaluación ISO 27001 debe completarse en los últimos 12 meses

Evaluación PCI-DSS

• El documento AOC debe definir claramente el entorno M365 que se está evaluando
• El AOC debe estar actualizado
• El AOC debe ser firmado por la QSA y la entidad

Más información

• ¿Qué es la atestación de editores?
• Cómo obtener la certificación de Microsoft 365