Dominio de seguridad: tratamiento de datos Seguridad y privacidad

Este dominio de seguridad está diseñado para garantizar que todos los datos consumidos de Microsoft 365 estén adecuadamente protegidos tanto en tránsito como en reposo. Este dominio también garantiza que el ISV satisfaga las preocupaciones de privacidad de los consumidores (interesados), en línea con GDPR (Reglamento General de Protección de Datos) e HIPAA (Ley de Portabilidad y Responsabilidad de Seguros de Salud de 1996).

Datos en tránsito

Los requisitos de conectividad de las aplicaciones y complementos desarrollados por Microsoft 365 requieren la comunicación a través de redes públicas, específicamente Internet. Por lo tanto, los datos en tránsito deben protegerse adecuadamente. Esta sección trata sobre la protección de las comunicaciones de datos a través de Internet. 

Control n.º 1

ERROR GRAVE

Proporcione evidencia de que:

• Todas las configuraciones de TLS son TLS1.2 o superior, como se destaca en los requisitos de configuración de perfil de TLS. 

• Se conserva y mantiene un inventario de claves y certificados de confianza.

Requisitos de configuración de perfiles

Intención: TLS

La intención de este subpunto es asegurarse de que los datos de Microsoft 365 que consume su organización se transmitan de forma segura. La configuración del perfil TLS se usa para definir requisitos específicos de TLS que ayuden a garantizar la seguridad del tráfico frente a ataques de tipo "Man in the middle". 

Directrices: TLS

La forma más fácil de evidenciar esto es ejecutar la herramienta de prueba de servidor SSL de Qualys contra TODOS los oyentes web, incluidos los que se ejecutan en puertos no estándar. 

Recuerde marcar la opción "No mostrar los resultados en los tableros", que evita que la URL se agregue al sitio web. 

Los requisitos de configuración del perfil TLS se pueden demostrar proporcionando pruebas de comprobaciones individuales. Para proporcionar pruebas de configuraciones específicas, como deshabilitar la compresión TLS, se pueden usar opciones de configuración, scripts y herramientas de software. 

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran los resultados del escaneo SSL de Qualys para la byendbagh6a0fcav.z01.azurefd.net webappfrontdoor. 

La sección Protocolos muestra que TLS1.2 es el único protocolo admitido/habilitado.

Nota: Los analistas de certificación revisarán el resultado completo del examen para confirmar que se cumplen todos los requisitos de configuración del perfil TLS. Se espera que se proporcionen exámenes para todos los puntos de conexión que se exponen públicamente (direcciones IP y direcciones URL) al entorno back-end que está en el ámbito. Dependiendo de la evidencia que se haya proporcionado, los analistas pueden ejecutar su propio escaneo Qualys. 

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran las opciones de configuración de TLS en Azure App Service seguido de la enumeración de TLS mediante PowerShell. 

Intención: claves y certificados

La intención de este subpunto es garantizar que se mantenga un inventario completo de claves y certificados confiables, lo que implica identificar varios sistemas, servicios y aplicaciones que dependen de estos elementos criptográficos. 

Directrices: claves y certificados

Las pruebas deben demostrar que existe y se mantiene un inventario de claves y certificados de confianza. Además, se pueden proporcionar pruebas aplicables de las herramientas usadas para almacenar las claves y certificados reales, como Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud, etc. 

Prueba de ejemplo: claves y certificados

La siguiente captura de pantalla muestra que se mantiene un inventario de claves y certificados en Confluence Cloud. 

En la captura de pantalla siguiente se muestra la lista aprobada de claves y certificados de confianza. Incluye detalles como el certificado, las claves, los códigos y los sistemas en los que están instalados. 

La siguiente captura de pantalla es de HashiCorp Vault. Los certificados que se describen y se registran en la lista de inventario se almacenan en esta bóveda en línea. HashiCorp Vault es una herramienta de código abierto para la gestión de secretos, el cifrado como servicio y la gestión de acceso privilegiado.

La siguiente captura de pantalla es una extracto del certificado real y las claves almacenadas en el almacén en línea.

Nota: Se espera que la ubicación de almacenamiento de las claves tenga los controles de acceso adecuados. Si la clave privada se ve comprometida, alguien podría suplantar el servidor con un certificado legítimo. 

Prueba de ejemplo: claves y certificados

En la siguiente captura de pantalla se muestran ejemplos de evidencia de certificados almacenados en Azure KeyVault.  

Prueba de ejemplo: claves y certificados

También se puede mantener un inventario de claves y certificados de confianza con Microsoft 365 Defender, que proporciona una característica de inventario, como se muestra en la siguiente captura de pantalla.

En la captura de pantalla siguiente se muestran los detalles del certificado.

Tenga en cuenta: Estos ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier URL, usuario registrado y el sello de fecha y hora para la revisión de evidencia. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema. 

Control n.º 2

Proporcione evidencia de que:

La compresión TLS está deshabilitada para todos los servicios públicos que manejen solicitudes web para evitar la relación de compresión Filtración de información simplificada (CRIME). 

TLS HTTP Strict Transport Security (HSTS) está habilitado y configurado con una antigüedad mínima de 180 días en todos los sitios. 

Intención: TLS

El ataque CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) es una vulnerabilidad en la compresión de los protocolos Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Por este motivo, las recomendaciones del sector son deshabilitar la compresión SSL. 

La Seguridad de transporte estricta de HTTP (HSTS) es un mecanismo de seguridad diseñado para proteger los sitios web contra ataques de tipo "Man in the middle" forzando conexiones TLS a través de un campo de encabezado de respuesta HTTPS denominado "Strict-Transport-Security". 

Directrices: TLS

Esto se puede evidenciar a través de la herramienta Qualys SSL Labs. Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestra que la compresión SSL/TLS está deshabilitada. 

En la captura de pantalla siguiente se muestra que HSTS está habilitado.

Nota: El analista de certificación revisará la salida completa para confirmar que se cumplen todos los requisitos de configuración del perfil TLS (proporcione capturas de pantalla de la salida del análisis completo). Dependiendo de la evidencia que se haya proporcionado, los analistas pueden ejecutar su propio escaneo Qualys. 

Otras herramientas que se pueden usar para comprobar que HSTS está habilitado son "HTTP Header Spy" y

securityheaders.com como se muestra en los ejemplos siguientes. Evidencia adicional

Se pueden proporcionar capturas de pantalla, como los ajustes de configuración de los encabezados de seguridad, específicamente HSTS, para demostrar aún más la posición de seguridad de la huella pública. 

Las capturas de pantalla siguientes muestran la configuración de Azure Front Door y el conjunto de reglas implementado para reescribir los encabezados. 

En la captura de pantalla siguiente se muestra el análisis de encabezados de seguridad realizado y que se implementan todos los encabezados de seguridad, no solo HSTS.

Nota: Si se utiliza el escáner SSL de Qualys o los encabezados de seguridad, se espera que el informe completo se proporcione para una revisión. 

Datos en reposo

Cuando los ISV almacenan los datos consumidos de la plataforma Microsoft 365, es necesario protegerlos adecuadamente. En esta sección se tratan los requisitos de protección de los datos almacenados en bases de datos y almacenes de archivos. 

Control n.º 3

ERROR GRAVE

Proporcione evidencia de que:

Los datos en reposo se cifran de acuerdo con los requisitos del perfil de cifrado, utilizando algoritmos de cifrado como; Advanced Encryption Standard (AES), Blowfish y XChaCha20. 

Tamaños de clave de cifrado de un mínimo de 128 bits. 

Requisitos de perfil de cifrado 

Intención: Se sabe que algunos algoritmos de cifrado más antiguos contienen algunas debilidades criptográficas, lo que aumenta las posibilidades de que un actor de amenazas pueda descifrar los datos sin conocer la clave. Por este motivo, la intención de este control es asegurarse de que solo se usen algoritmos de cifrado aceptados por la industria para proteger los datos M365 almacenados. 

Directrices: La evidencia se puede proporcionar a través de capturas de pantalla, que muestran el cifrado que se emplea para proteger los datos de M365 dentro de las bases de datos y otras ubicaciones de almacenamiento. La evidencia debe demostrar que la configuración de cifrado está en línea con los requisitos de configuración de perfil de cifrado de la certificación de Microsoft 365. 

Prueba de ejemplo: La siguiente captura de pantalla muestra que el TDE (cifrado de datos transparente) está habilitado en la base de datos Contoso. La segunda captura de pantalla muestra la página de documentación de Microsoft Cifrado de datos transparente para SQL Database, SQL Managed Instance y Azure Synapse Analytics que muestra que se usa el cifrado AES 256 para Azure TDE. 

Tenga en cuenta: en los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Ejemplo de evidencia: En la captura de pantalla siguiente se muestra Azure Storage configurado con cifrado para blobs y archivos. En la captura de pantalla siguiente se muestra la página de documentación de Microsoft Cifrado de almacenamiento de Azure para los datos en reposo, que muestra que Azure Storage usa AES-256 para el cifrado. 

Retención, copia de seguridad y eliminación de datos

Cuando los ISV consumen y almacenan datos de Microsoft 365, existe el riesgo de que los datos se vean comprometidos en caso de que un actor de amenazas ponga en peligro el entorno de ISV. Para minimizar este riesgo, las organizaciones solo deben conservar los datos que necesitan para prestar servicios y no los datos que "pueden" ser útiles en el futuro. Además, los datos solo deben conservarse durante el tiempo necesario para proporcionar los servicios para los que se capturaron. La retención de datos debe definirse y comunicarse con los usuarios. Una vez que los datos superan el período de retención definido, deben eliminarse de forma segura para que los datos no se puedan reconstruir ni recuperar. 

Control n.º 4

Proporcione evidencia de que:

Se establece y documenta formalmente un período de retención de datos aprobado. 

Intención: Una política de retención documentada y seguida es importante no solo para cumplir con algunas obligaciones legales, por ejemplo, la legislación de privacidad de datos, como, entre otros, el Reglamento General de Protección de Datos (RGPD de la UE) y la Ley de Protección de Datos (DPA del Reino Unido 2018), sino también para limitar el riesgo de una organización. Al comprender los requisitos de datos de las organizaciones y cuánto tiempo se necesitan los datos para que la empresa realice sus funciones, las organizaciones pueden asegurarse de que los datos se eliminen correctamente una vez que expire su utilidad. Al reducir los volúmenes de datos almacenados, las organizaciones están reduciendo la cantidad de datos que se expondrían en caso de que se produzca un compromiso de los datos. Esto limitará el impacto general. 

A menudo, las organizaciones almacenarán datos porque es bueno tenerlos por si acaso. Sin embargo, si la organización no necesita los datos para realizar su servicio o función comercial, entonces los datos no deben almacenarse, ya que esto aumenta el riesgo de la organización innecesariamente. 

El objetivo de este control es confirmar que la organización ha establecido y documentado formalmente un período de retención de datos aprobado para todos los tipos de datos pertinentes. Esto implica no solo especificar la duración durante la cual se almacenarán los diferentes tipos de datos, sino también delinear los procedimientos para la eliminación de datos o el archivo posterior al vencimiento.  

Directrices: Proporcionar la política de retención de datos completa que detalla claramente cuánto tiempo deben conservarse los datos (debe cubrir todos los tipos de datos) para que la empresa pueda realizar sus funciones empresariales. La directiva de retención debe cubrir claramente todos los datos de clientes almacenados en el entorno back-end de la aplicación que se está certificando. 

Prueba de ejemplo: La siguiente captura de pantalla muestra la directiva de retención de datos de Contoso. 

Nota: Estas capturas de pantalla muestran una instantánea de un documento de directiva o proceso. Se espera que los ISV compartan la documentación real de la directiva o el procedimiento de apoyo y no que proporcionen simplemente una captura de pantalla. 

Control n.º 5

Proporcione evidencia de que:

Los datos se conservan solo durante el período de retención definido, tal como se describe en el control 4. 

Intención: la intención de este control es simplemente validar que se cumplen los períodos de retención de datos definidos. Como ya se ha comentado, las organizaciones pueden tener la obligación legal de cumplir con esto, pero también mantener los datos necesarios y durante el tiempo necesario ayuda a reducir el riesgo para la organización en caso de que se produzca una violación de datos. Esto garantiza que los datos no se conserven durante un tiempo excesivamente largo ni se eliminen prematuramente, lo que podría suponer riesgos de diversa naturaleza, legales, operativos o relacionados con la seguridad. 

Directrices: proporcione evidencia de captura de pantalla (o a través de uso compartido de pantalla) que muestre que los datos almacenados (en todas las diversas ubicaciones de datos, incluidas bases de datos, recursos compartidos de archivos, archivos y copias de seguridad) no exceden la política de retención de datos definida. Entre los ejemplos de capturas de pantalla aceptables se incluyen:

los registros de base de datos con un campo de fecha, buscados en el orden de registro más antiguo, y/o

Ubicaciones de almacenamiento de archivos que muestran marcas de tiempo que se encuentran dentro del período de retención. Nota: Todos los datos personales o confidenciales de los clientes deben redactarse en la captura de pantalla. 

Registros de copia de seguridad que muestran que los datos de copia de seguridad se conservan dentro del período de retención definido y se eliminan correctamente después de este período. 

Evidencia de ejemplo: la evidencia siguiente muestra una consulta SQL que muestra el contenido de la tabla de base de datos ordenada en orden ascendente en el campo "DATE_TRANSACTION" para mostrar los registros más antiguos de la base de datos. Esto muestra que los datos tienen menos de dos meses de antigüedad, lo que no supera el período de retención definido. 

Nota: Esta es una base de datos de prueba, por lo tanto, no hay muchos datos históricos dentro de ella. 

Nota: En los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema.

Control n.º 6

Proporcione evidencia de que:

Existen procesos para eliminar datos de forma segura después de su período de retención. 

Intención: la intención de este control es asegurarse de que el mecanismo utilizado para eliminar los datos que superan el período de retención lo hace de forma segura. Los datos eliminados a veces se pueden recuperar; Por lo tanto, el proceso de eliminación debe ser lo suficientemente sólido como para garantizar que los datos no se puedan recuperar una vez eliminados. 

Directrices: Si el proceso de eliminación se realiza mediante programación, proporcione una captura de pantalla del script que se usa para realizar esto. Si se ejecuta según una programación, proporcione una captura de pantalla que muestre la programación. Por ejemplo, un script para eliminar archivos dentro de un recurso compartido de archivos se puede configurar como un trabajo CRON, captura de pantalla del trabajo CRON que muestra la programación y el script que se ejecuta; y proporcione el script que muestra el comando utilizado. 

Ejemplo de evidencia: Este es un script simple que podría usarse para eliminar todos los registros de datos retenidos en función de la fecha -DONDE DateAdd es -30 días, lo que purgará todos los registros retenidos con más de 30 días de antigüedad respecto a la fecha de retención de datos seleccionada. Tenga en cuenta que necesitaremos el guión; evidencia del trabajo que se está ejecutando y los resultados. 

Tenga en cuenta: en los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Prueba de ejemplo: La siguiente captura de pantalla se ha tomado de la directiva de retención de datos de Contoso (del control 4): esto muestra los procedimientos usados para la destrucción de datos.

Nota: Esta captura de pantalla muestra una instantánea de un documento de directiva o proceso. Se espera que los ISV compartan la documentación real de la directiva o el procedimiento de apoyo y no que proporcionen simplemente una captura de pantalla. 

Prueba de ejemplo: en este ejemplo se ha creado un Runbook y la programación correspondiente en Azure para eliminar de forma segura los registros que tienen una fecha de finalización creada a partir de los 30 días posteriores a la expiración de la directiva de retención de registros de datos. Este trabajo está configurado para ejecutarse todos los meses el último día del mes. 

En la captura de pantalla siguiente se muestra que el runbook se ha editado para buscar registros y tiene comandos de eliminación que no aparecen a la vista, como el script.

Nota: La dirección URL completa y el nombre de usuario deben estar a la vista para estas capturas de pantalla y los ISV deberán mostrar una captura de pantalla del recuento de registros antes de la eliminación y una captura de pantalla del recuento de registros posterior a la eliminación. 

Estas capturas de pantalla son puramente ejemplos de las diferentes formas en que se puede abordar esto.

Control n.º 7

Proporcione evidencia de que:

Existe un sistema de copia de seguridad automatizado y está configurado para realizar copias de seguridad en horas programadas según un procedimiento de copia de seguridad documentado. 

La información de copia de seguridad se restaura periódicamente para confirmar la confiabilidad e integridad de los datos según el procedimiento de copia de seguridad documentado. 

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. 

Intención:

El objetivo de este control es confirmar que la organización cuenta con un sistema automatizado de copias de seguridad, que está configurado para ejecutar copias de seguridad en momentos predeterminados. 

Directrices:

Proporcione capturas de pantalla de los ajustes de configuración de la solución de copia de seguridad que muestren que las copias de seguridad se realizan en períodos/intervalos de tiempo programados. Si la solución realiza la programación de copias de seguridad automáticamente, esto puede respaldarse proporcionando documentación del proveedor. 

Ejemplo de evidencia:

La siguiente captura de pantalla se aplica a Azure Database for MySQL, que es una instancia administrada. Indica que se ha completado una primera copia de seguridad automatizada.

La siguiente captura de pantalla tomada después de que haya transcurrido un período muestra que se han realizado más copias de seguridad completas. Las copias de seguridad en servidores flexibles se basan en instantáneas, donde la primera copia de seguridad de la instantánea se programa inmediatamente después de crear un servidor y se realizan más copias de seguridad de instantáneas una vez al día. 

La siguiente captura de pantalla muestra una instantánea de la documentación en línea que describe la frecuencia de copia de seguridad y la capacidad de copia de seguridad automatizada. 

Intención: El objetivo de este control es corroborar que la información de respaldo no solo se genera según el cronograma, sino que también es confiable y mantiene su integridad a lo largo del tiempo. Para cumplir con este objetivo, se realizarán pruebas periódicas en los datos de copia de seguridad. 

Directrices: La evidencia para cumplir con este control dependerá del proceso y procedimiento de la organización para probar los datos de respaldo. Se podría proporcionar evidencia que muestre que las copias de seguridad se prueban con éxito junto con registros de finalización de pruebas históricas. 

Prueba de ejemplo: La siguiente captura de pantalla muestra que existe y se mantiene un programa de copia de seguridad y un procedimiento de restauración y que se define una configuración de copia de seguridad para todos los sistemas aplicables, incluida la frecuencia de las copias de seguridad que se realizan en la plataforma Confluence.

La siguiente captura de pantalla muestra una página de registros históricos de pruebas de copia de seguridad para cada uno de los sistemas aplicables. Observe que en el lado derecho de la mesa se hacen referencia a los tickets JIRA para cada una de las pruebas. 

Las siguientes cuatro capturas de pantalla muestran el proceso integral de restauración de Azure Database for MySQL a partir de una instantánea. Usando la opción 'Restauración rápida' podemos iniciar el proceso de restauración de la base de datos SQL. 

En la captura de pantalla siguiente se muestra la página de configuración donde podemos personalizar la restauración.

Una vez seleccionadas la ubicación de destino, la red y la instantánea desde la que se restaurará la base de datos, podemos iniciar la implementación. Observe que nuestra instancia de base de datos ahora se llama "test".

Después de un total de cinco minutos, la base de datos SQL se restauró completa y satisfactoriamente desde la instantánea de copia de seguridad, como se muestra a continuación.

Una vez completadas las pruebas, de acuerdo con el proceso, se creó un ticket JIRA para registrar las pruebas de copia de seguridad y los detalles de la restauración realizada. Esto garantiza que los datos históricos estén disponibles para fines de cumplimiento, así como que existan registros completos para su revisión en caso de un incidente o desastre para permitir que la organización realice un análisis de causa raíz. 

Intención: Siguiendo con el control anterior, deben implementarse controles de acceso para limitar el acceso solo a los usuarios individuales responsables de los datos de copia de seguridad. Al limitar el acceso, se limita el riesgo de que se realicen cambios no autorizados y, por tanto, se introduzcan cambios no seguros. Se debe adoptar un enfoque con privilegios mínimos para proteger las copias de seguridad. 

Para proteger adecuadamente los datos, las organizaciones deben ser conscientes de qué datos consumen su entorno / sistemas y dónde se almacenan los datos. Una vez que esto se entienda y documente completamente. 

Las organizaciones pueden entonces no solo implementar una protección de datos adecuada, sino que también pueden consolidar dónde se encuentran los datos para implementar la protección de manera más efectiva. Además, cuando los datos se consolidan en el menor número posible de lugares, es mucho más fácil implementar un RBAC (control de acceso basado en roles) adecuado para limitar el acceso al menor número de empleados posible. 

Directrices: Se debe proporcionar evidencia del sistema / tecnología utilizada que demuestre los permisos de acceso a las copias de seguridad y las soluciones de respaldo con documentación de respaldo de la lista de acceso aprobada. 

Ejemplo de evidencia: Podemos ver en las siguientes capturas de pantalla presentadas que los controles de acceso se implementan en la instancia de la base de datos para restringir el acceso solo a las personas autorizadas según el rol del trabajo. 

Ejemplo de evidencia:

Las instancias administradas de Azure SQL Database y las instancias administradas de Azure SQL son administradas por Azure y su integridad es responsabilidad de la plataforma Azure; ningún usuario tiene acceso a ellas y se cifran en reposo sin posibilidad de ataques de ransomware. También se replican en otras regiones para su protección. 

Administración de acceso a datos

El acceso a los datos debe limitarse a un número menor de personas para reducir las posibilidades de que los datos se vean comprometidos de forma maliciosa o accidental. El acceso a los datos y las claves de cifrado debe limitarse a los usuarios con una necesidad empresarial legítima de acceso para desempeñar su función laboral. Se debe implementar un proceso bien documentado y bien establecido para solicitar acceso. El acceso a los datos y a las claves de cifrado debe seguir el principio de privilegios mínimos. 

Control n.º 8

Proporcione evidencia de que:

Se mantiene una lista de usuarios con acceso a datos y/o claves de cifrado incluyendo la justificación comercial para cada persona. 

Esta lista de usuarios se aprobó formalmente en función de los privilegios de acceso necesarios para su función laboral. 

Los usuarios se configuran con los privilegios descritos en las aprobaciones. 

Nota: Se seleccionará una muestra de usuarios para demostrar los puntos B y C.

Intención:

Las organizaciones deben limitar el acceso a los datos y las claves de cifrado a la menor cantidad de empleados posible. La intención de este control es garantizar que el acceso de los empleados a los datos y/o claves de cifrado se restrinja a los empleados con una necesidad empresarial clara de dicho acceso. 

Directrices:

Se debe proporcionar documentación o capturas de pantalla de sistemas internos que documentan a todos los empleados con acceso a datos y/o claves de cifrado junto con la justificación comercial de por qué estas personas tienen acceso. El analista de certificación usará esta lista para muestrear usuarios para los controles siguientes. 

Ejemplo de evidencia:

El siguiente documento muestra la lista documentada de usuarios con acceso a los datos y la justificación comercial.

Nota: Esta captura de pantalla muestra un documento de directiva o proceso, se espera que los ISV compartan la documentación real de directiva o procedimiento de apoyo. 

Intención: El proceso para otorgar acceso a los datos y/o las claves de cifrado debe incluir la aprobación, asegurando que el acceso de una persona sea necesario para su función laboral. Esto garantiza que los empleados sin una razón genuina para acceder no obtengan acceso innecesario. 

Directrices: Por lo general, la evidencia proporcionada para el control anterior puede ayudar a respaldar este control. Si no hay una aprobación formal sobre la documentación suministrada, la evidencia puede consistir en una solicitud de cambio que se plantea y se aprueba para el acceso dentro de una herramienta como Azure DevOps o Jira. 

Prueba de ejemplo: Este conjunto de imágenes muestra incidencias de Jira creadas y aprobadas para el control (i) para conceder o denegar el acceso a datos confidenciales o claves de cifrado. Esta imagen muestra que se ha creado una solicitud en Jira para obtener la aprobación diaria de Sam para las claves de cifrado en el entorno backend del sistema. Esto se hace como el siguiente paso en el que se ha obtenido autorización por escrito. 

Esto muestra que la solicitud para dar acceso a Sam Daily ha sido aprobada por Jon Smith, una persona de la dirección. (Tenga en cuenta que la aprobación debe proceder de alguien con autoridad suficiente para permitir la solicitud de cambio, no puede ser otro desarrollador).

Lo anterior muestra un flujo de trabajo en Jira para este proceso. Tenga en cuenta que nada se puede agregar como Listo a menos que haya pasado por el proceso de aprobación que está automatizado y, por lo tanto, no se puede omitir.

La junta del Proyecto ahora muestra que se ha aprobado el acceso de Sam Daily a las claves de cifrado. En la siguiente lista de pendientes se muestra la aprobación de la solicitud de Sam Daily y la persona asignada para realizar el trabajo.

Para cumplir los requisitos de este control, debe mostrar todas estas capturas de pantalla o evidencia similar/equivalente aplicable con una explicación para demostrar que ha cumplido el requisito del control. 

Tenga en cuenta: en los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Ejemplo de evidencia: En el siguiente ejemplo, se han solicitado permisos de acceso de administrador y control total para un usuario a la base de datos de producción. La solicitud se ha enviado para su aprobación como se puede ver a la derecha de la imagen y se ha aprobado como se muestra a la izquierda. 

La siguiente imagen indica que el acceso se ha aprobado y firmado como completado.

Tenga en cuenta: en los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Intención La intención de este subpunto es confirmar que el acceso a la clave de cifrado o datos está configurado según lo documentado. 

Directrices: La evidencia podría proporcionarse mediante una captura de pantalla que muestre los privilegios de acceso a los datos y/o a la clave de cifrado otorgados a las personas muestreadas. La evidencia debe cubrir todas las ubicaciones de datos. 

Prueba de ejemplo: Esta captura de pantalla muestra los permisos concedidos al usuario "John Smith", que serían cruzados

referenciado contra la solicitud de aprobación para este mismo usuario según la evidencia para el control anterior. 

Tenga en cuenta: el siguiente ejemplo no es una captura de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier URL, usuario conectado y el sello de fecha y hora para la revisión de evidencia. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema. 

Control n.º 9

Proporcione evidencia de que:

Se mantiene una lista de todos los terceros con los que se comparten los datos. 

Existen acuerdos de intercambio de datos con todos los terceros que consumen datos. 

Intención: Cuando se usan terceros para el almacenamiento o procesamiento de datos de Microsoft 365, estas entidades pueden suponer un riesgo significativo. Las organizaciones deben desarrollar un buen proceso de gestión y diligencia debida de terceros para garantizar que estos terceros almacenen / procesen los datos de forma segura y para garantizar que cumplirán con las obligaciones legales que puedan tener, por ejemplo, como procesador de datos según GDPR. 

Las organizaciones deben mantener una lista de todos los terceros con los que comparten datos, con algunos o todos los siguientes:

qué servicio(s) se presta(n)

Qué datos se comparten

Por qué se comparten los datos

información de contacto clave (es decir, contacto principal, contacto de notificación de infracciones, DPO, etc.)

Renovación/vencimiento del contrato

obligaciones legales/de cumplimiento (es decir, GDPR, HIPAA, PCI DSS, FedRAMP, etc.)

Directrices: Proporcionar documentación que detalle TODOS los terceros con los que se comparten datos de Microsoft 365. 

Nota: Si los terceros no están en uso, esto deberá ser confirmado por escrito (correo electrónico) por un miembro del equipo de liderazgo senior. 

Ejemplo de evidencia:

Tenga en cuenta: - En los ejemplos anteriores no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Ejemplo de evidencia:

La siguiente captura de pantalla muestra un ejemplo de correo electrónico de un miembro del equipo de altos directivos que confirma que no se usan terceros para procesar los datos de Microsoft 365. 

Tenga en cuenta: - En estos ejemplos, no se utilizaron capturas de pantalla completas, sin embargo, TODAS las capturas de pantalla de evidencia enviadas por ISV deben ser capturas de pantalla completas que muestren la URL, cualquier usuario registrado y la hora y fecha del sistema. 

Intención: cuando los datos de M365 se comparten con terceros, es importante que los datos se traten de forma adecuada y segura. Deben existir acuerdos de intercambio de datos para garantizar que terceros procesen los datos solo cuando sea necesario y que comprendan sus obligaciones de seguridad. La seguridad de una organización es tan fuerte como el eslabón más débil. La intención de este control es garantizar que terceros no se conviertan en un eslabón débil de la organización. 

Directrices: proporcione los acuerdos de intercambio de datos vigentes con los terceros. 

Prueba de ejemplo: La siguiente captura de pantalla muestra un ejemplo simplificado de un acuerdo de uso compartido de datos. 

Nota: El acuerdo completo debe compartirse y no una captura de pantalla.

Privacidad

El cumplimiento de la privacidad y la administración de la información son esenciales para proteger los derechos de las personas y garantizar un tratamiento responsable de los datos. Para que una organización establezca un sistema eficaz de información de privacidad, debe saber qué datos personales tiene y el propósito de procesar y almacenar dichos datos. Una organización debe mapear el flujo de información y cómo se procesa, reconociendo que pueden estar ocurriendo varios tipos diferentes de procesamiento. 

Control n.º 10 – Datos personales

Proporcione pruebas de que su organización:

Mantiene un inventario actualizado de todos los datos personales recopilados, procesados y almacenados, incluido el propósito de cada elemento de datos.  

Diseña formularios de recopilación de datos para incluir solo los campos que son necesarios para el propósito empresarial e implementa los campos obligatorios y opcionales de forma adecuada.  

Desarrolla y aplica políticas que especifican los tipos de datos personales que se pueden recopilar y los fines para los que se pueden usar.  

Permite a los usuarios optar por no procesar o mostrar de forma amplia sus datos personales esenciales no empresariales.  

Intención: la intención de este control es asegurarse de que se respeta la privacidad de los datos relacionados con la recopilación de datos, asegurarse de que hay una justificación para que los datos se capturen y ser transparente con qué y por qué se recopilan los datos. También es importante que los usuarios (interesados) tengan la capacidad de no participar en el procesamiento.   

Directrices: Este control podría evidenciarse de la siguiente manera:

A) Proporcionar una versión actual del Registro de actividades de tratamiento (RoPA) de la organización (véase el artículo 30 del RGPD) o un documento similar en el que se detallen los datos, los elementos y los fines del tratamiento (véase el artículo 5.1.b del RGPD).  

En la mayoría de los casos, se trata de una hoja de cálculo de Excel (que podría extraerse de herramientas, como OneTrust).  

Si el archivo es demasiado grande o contiene datos confidenciales, se podría proporcionar un extracto, que muestre todos los campos de datos de una muestra determinada de datos, que puede redactarse parcialmente siempre que la evidencia pueda proporcionar la garantía de que el RoPA está en su lugar.  

No compatible: Los registros no existen, son muy antiguos/están desactualizados o faltan campos clave.  

B) Con el fin de "Minimizar los datos" (véase el artículo 5.1.c del RGPD), proporcionar todos los formularios utilizados para obtener datos, ya sea en línea, mediante tabletas o dispositivos similares (por ejemplo, en una conferencia) o en papel. Estos podrían ser en blanco / plantillas.  

No conforme: los formularios tienen campos obligatorios que no son necesarios para el propósito previsto de procesamiento. Por ejemplo, solicitar números de teléfono, edad o sexo, para enviar un folleto por correo electrónico o a una dirección postal.   

C) Con el fin de "legalidad, equidad y transparencia" (véase el artículo 5.1.a) del RGPD, debe estar en vigor la Política de privacidad (destinada a los empleados), debe estar en vigor el Aviso de privacidad (destinado a los usuarios/clientes). Por lo general, el Aviso de privacidad debe estar disponible públicamente en el sitio web de la organización.   

No compatible: las directivas no existen o faltan elementos clave.  

Elementos clave:

Política de privacidad/Aviso: recopilación y uso de información, elementos de datos procesados, los fines del procesamiento, la legalidad del procesamiento, las transferencias de datos a otros países, los derechos del interesado, el almacenamiento y la retención de datos.   

D) Para el mecanismo de exclusión voluntaria (consulte el artículo 4.11 del RGPD, el artículo 6 del RGPD y el artículo 7 del RGPD), normalmente en una página web. Compruebe la navegación que el usuario tendría que seguir para llegar a esa página (por ejemplo, ¿es fácil de encontrar?).  

No compatible: no hay una funcionalidad de exclusión clara, o una opción de exclusión "genérica", sin granularidad.  

Ejemplo de evidencia:

Para A):

Para B):

Para C):

Para D):

Control n.º 11 – Conocimiento del usuario

Proporcione pruebas de que los usuarios conocen:

Quién tiene acceso a sus datos. 

Quién tiene acceso a los espacios en los que está trabajando. 

Que podrían obtener acceso a sus datos a través del uso compartido o flujos de datos para que puedan tomar decisiones informadas. 

Intención: La intención de este control es demostrar que se cumple el principio de "transparencia" de protección de datos (consulte el artículo 5.1.a del RGPD). 

Directrices: Para demostrar que esto está en su lugar, idealmente debe haber algún tipo de reconocimiento del usuario (por ejemplo, haber leído la Política de privacidad) y registrarse. 

En la práctica, solo que la Política de privacidad (para empleados), el Aviso de privacidad (para usuarios y clientes), proporcionen detalles suficientes sobre lo siguiente:

- Con quién se comparten los datos personales (encargados, subencargados, terceros, contratistas, etc.). 

No conforme: No existen reconocimientos, o la Política de privacidad/Aviso de privacidad no existen. 

Ejemplo de evidencia:

OR

Control n.º 12 – Acuerdos de procesamiento de datos (DPA)

Proporcionar pruebas del Acuerdo de procesamiento de datos, que debe tener una lista de todos los terceros/subprocesadores aprobados. 

Intención: Asegurarse de que está siendo transparente con los interesados, asegurándose de que se les informa sobre qué terceros/subprocesadores podrían tener acceso a sus datos, el papel que desempeñan en el procesamiento (controlador de datos, procesador de datos), sus respectivas responsabilidades y los mecanismos de seguridad implementados. 

Además, cuando el uso compartido de datos implicaría transferencias de datos a territorios fuera de la UE (según el RGPD), los detalles del mecanismo para garantizar que las transferencias sean legales. (Consulte el artículo 5 del RGPD y los artículos 44-50 del RGPD)

Para el RGPD, los territorios para el procesamiento deben cumplir una de las siguientes condiciones:

- Ser un Estado miembro de la Unión Europea. 

- Ser considerado por la Comisión Europea como "salvaguardias adecuadas". La lista actual se puede encontrar aquí: Adecuación de la protección de datos para países no pertenecientes a la UE 

A partir del 13 de junio de 2025:

• Formar parte del Marco de Privacidad de Datos (DPF), y enumerarse aquí: Marco de Privacidad de Datos 

• Contar con Normas Corporativas Vinculantes (BCR). 

• Tener Standard Contractual Clauses (SCCs) en su lugar. 

Pautas: La evidencia podría ser mediante el muestreo de un par de acuerdos de procesamiento de datos (DPA) con subprocesadores existentes. En algunos casos, es posible que las organizaciones no dispongan de DPA, pero sí adendas a los contratos, o "Cláusulas de privacidad". 

No compatible:

• Falta la lista de terceros o subencargados. 

• No se dan detalles sobre los países receptores. 

• Los países no figuran como "países adecuados" y no existen BCR ni SCC. 

Prueba de ejemplo: En este ejemplo se muestra un ejemplo de DPA de la IAPP, o la prueba podría ser un documento relacionado en el que se enumeren las partes con las que se comparten los datos. 

Además, compruebe los mecanismos de transferencia de datos fuera de la UE.

Control n.º 13 – Evaluaciones de impacto de la protección de datos (EIPD)

Proporcione pruebas de que su organización lleva a cabo la Evaluación de Impacto de Protección de Datos (EIPD)

     OR

Proporcione el nombre de la evaluación relacionada con la privacidad y protección de datos a la que está conectada esta revisión de privacidad. 

Intención: La intención de este control es asegurarse de que está realizando evaluaciones sobre los riesgos potenciales para los derechos y libertades de las personas, especialmente relacionados con la introducción de nuevas tecnologías o usos novedosos de tecnologías existentes. (Consulte el artículo 35 del RGPD)

Directrices: Este control se evaluaría mediante la revisión de una EIPD reciente o documentación de evaluación relacionada. 

No compatible:

Una EIPD debe tener los siguientes elementos:

• Identificación de la necesidad de una EIPD. 

• Descripción del tratamiento previsto, incluido el ámbito, el contexto y los finalidades. 

• Evaluación de la necesidad y proporcionalidad. 

• Identificación y evaluación de riesgos. 

• Identificación de medidas para reducir el riesgo. 

• Resultados registrados. 

Si falta alguno de los anteriores, o simplemente se realiza a un nivel superficial, este control se puede marcar como no compatible. 

Ejemplo de evidencia:

La plantilla completa de una EIPD se puede encontrar en el sitio web de la ICO aquí dpia-template.docx

Control n.º 14 – Datos biométricos

¿La aplicación interactúa con datos biométricos? En caso afirmativo,

Proporcionar pruebas de que los datos biométricos han pasado la revisión legal, están protegidos y los usuarios están informados y se les da la opción de participar o no en la recopilación de datos biométricos. 

Intención: Este control está interesado en garantizar protecciones adecuadas de los datos biométricos, que según el artículo 9 del RGPD se clasifican como una categoría especial de datos.  El uso de datos biométricos ha sido sometido a un análisis de legalidad. 

Directrices: El uso de datos biométricos debe pasar por una revisión legal, por lo que debe proporcionarse como parte de la recopilación de pruebas. Si no existe ninguna, solicita la plantilla que se usaría (para comprobar su preparación). 

No compatible:

La revisión legal sobre el tratamiento de datos biométricos debe contener lo siguiente:

• Base legal del tratamiento (una o varias de las siguientes):

• Enumere una condición válida para procesar datos biométricos (una o varias de las siguientes):

• Consideración del uso de alternativas, en lugar de datos biométricos.

Si falta alguno de los anteriores, o simplemente se realiza a un nivel superficial, este control se puede marcar como no compatible.

Ejemplo de evidencia:

Fuentes:

- Artículo 9 del RGPD – Tratamiento de categorías especiales de datos: Art. 9 RGPD – Tratamiento de categorías especiales de datos personales - Reglamento general de protección de datos (RGPD)

- ICO '¿Cómo procesamos los datos biométricos legalmente?': ¿Cómo procesamos los datos biométricos legalmente? | ICO

Control n.º 15 – Conclusiones de datos

Proporcionar evidencia de que las métricas solo muestran datos agregados y anonimizados sin datos identificables individualmente. El inquilino debe poder configurar el límite inferior de su nivel de agregación preferido, con un mínimo absoluto de cinco permitidos por el producto. Proporcionar pruebas de que los datos biométricos han pasado la revisión legal, están protegidos y los usuarios están informados y se les da la opción de participar o no en la recopilación de datos biométricos. 

Intención: la intención de este control es asegurarse de que ha implementado y mantiene el estado de los datos anonimizados y seudonimizados durante todo el ciclo de vida de los datos. (Ver

Directrices: Para ayudar a demostrar que este control está en su lugar, se debe proporcionar evidencia a través de GUI o CLI para demostrar:

• Configuración a nivel de usuario para los límites más bajos de los niveles de agregación. 

• Una muestra de métricas. 

Evalúe si el usuario puede configurar un umbral para sus niveles de agregación preferidos en un mínimo de 5. La evidencia debe demostrar que solo el anonimato está presente en la muestra de métricas. 

No compatible:

• Los usuarios no pueden personalizar sus niveles de agregación hasta un mínimo de 5, o no se pueden esperar los conocimientos técnicos necesarios para hacerlo del usuario típico. 

• Los datos personales están presentes en la muestra de métricas; por ejemplo: nombre, apellidos, DNI, número de cliente, número de teléfono, dirección de correo electrónico, dirección postal, datos bancarios, familiares, etc. 

Prueba de ejemplo: Capturas de pantalla de opciones de configuración, que muestran los detalles específicos. 

Muestra de métricas recopiladas. Quizás pregunte sobre el proceso para lograr la anonimización. 

RGPD

La mayoría de las organizaciones procesarán datos que son potencialmente datos de ciudadanos europeos (interesados). Cuando se procesan datos de CUALQUIER interesado, las organizaciones deberán cumplir con el Reglamento General de Protección de Datos (GDPR). Esto se aplica tanto a los Controladores de datos (está capturando directamente dichos datos) como a los Procesadores de datos (está procesando estos datos en nombre de un Controlador de datos). Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave de GDPR para ayudar a obtener cierta seguridad de que la organización se toma en serio GDPR. 

Control Núm. 16

Proporcione pruebas que demuestren el cumplimiento de los derechos del interesado mostrando:

• Facilitación de la solicitud de acceso del sujeto (SAR): documentación que confirma que los interesados son informados de su derecho a acceder a sus datos personales y pueden enviar solicitudes de acceso del sujeto (SAR) a su organización. 

• Descubrimiento de datos y cumplimiento de SAR: evidencia de la capacidad de su organización para localizar y recuperar todos los datos personales pertenecientes a un sujeto de datos individual en todos los sistemas y repositorios en respuesta a un SAR. 

Intención: La intención de este control es garantizar que existan mecanismos adecuados para que los interesados realicen solicitudes sobre sus datos personales en poder de la organización, y que el cumplimiento de las solicitudes legítimas sea exhaustivo. (Consulte el artículo 15 del RGPD). 

Pautas: A) El Aviso de privacidad debe contener detalles sobre cómo hacer un SAR, que podría ser utilizando los siguientes métodos:

• Usar un formulario web proporcionado por la organización

• Usar una dirección de correo electrónico proporcionada por la organización

• Usar un número de teléfono/chat web proporcionado por la organización

• Uso de una autoridad supervisora (por ejemplo, la ICO en el Reino Unido)

Solicitar evidencia del método implementado; Las capturas de pantalla deberían ser suficientes. 

B) Se puede utilizar un documento RoPA o similar para identificar las ubicaciones donde residen los datos personales pertenecientes al interesado, ya sean digitales o como parte de sistemas de archivo (físicos). 

Alternativamente, los ejercicios de e-discovery pueden lograr el mismo resultado. 

Solicite pruebas del proceso o flujo de trabajo que se usarían para completar un SAR y una explicación de cómo se determinó que el proceso es exhaustivo y no perdería ningún dato personal relacionado con el interesado. 

No compatible:

A) No se proporciona información en el sitio web de la organización (normalmente en el Aviso de privacidad). 

B) La evidencia indica que el proceso para recopilar los datos personales no es exhaustivo o puede carecer de detalles técnicos (por ejemplo, no se dan nombres/ubicaciones para las bases de datos). 

Ejemplo de evidencia:

A) Los siguientes son ejemplos de qué evidencia podría proporcionarse para cubrir el punto A). 

• Formulario web:

Fuente: Solicitud de acceso del sujeto - Police Care UK

• Email dirección o número de teléfono:

Fuente: ¿Cuál? Política de privacidad - Which?

• Chat web:

Fuente: Realizar una solicitud de acceso de sujeto a HMRC - GOV.UK

• A través de una autoridad supervisora (por ejemplo, la ICO):

Fuente: Realizar una solicitud de acceso al sujeto | ICO 

B) Artefactos de evidencia suministrados Detallando flujos de trabajo o descripciones de procesos con suficientes detalles técnicos, que podrían usarse de manera plausible para cumplir con el SAR.    En la siguiente captura de pantalla se muestra evidencia de ejemplo de la capacidad de una organización para localizar y recuperar todos los datos personales relacionados con un interesado específico de una base de datos de Azure SQL en respuesta a una solicitud de acceso del sujeto (SAR). El ejemplo muestra a un administrador ejecutando un procedimiento almacenado predefinido dentro de la Azure SQL Editor de Power Query para recuperar registros asociados a un identificador único del interesado en varias tablas de bases de datos de producción. 

En la siguiente captura de pantalla se muestran ejemplos de evidencia de la capacidad de una organización para localizar y recuperar todos los datos personales relacionados con un tema específico desde una cuenta de almacenamiento de Azure en respuesta a una solicitud de acceso del sujeto (SAR). En el ejemplo se muestra a un administrador que ubica todos los documentos asociados a un identificador único del interesado en Azure Blob Storage, lo que demuestra la capacidad de la organización para identificar y recuperar datos personales no estructurados almacenados en el entorno.

Control Núm. 17

ERROR GRAVE

Proporcione el Aviso de privacidad, que debe contener todos los elementos requeridos de la siguiente manera:

• La identidad y los datos de contacto de la organización, y el responsable de protección de datos (DPO), si procede. 

• Los tipos de datos personales que maneja su organización (nombre, apellidos, número de cliente, dirección de correo electrónico, número de teléfono, etc.). También, las fuentes de datos personales (por ejemplo, de dónde proceden los datos personales), en caso de que la organización no los haya obtenido directamente de los interesados. 

• Los propósitos del procesamiento de datos personales. 

• La base legal para el procesamiento de datos personales (incluidos los intereses legítimos cuando corresponda). 

• Partes con las que la organización comparte datos personales. 

• Detalles de cuánto tiempo se conservarán los datos personales. 

• Detalles de los derechos de los interesados:

• Derecho a ser informado

• Derecho de acceso

• Derecho de rectificación

• Derecho de supresión

• Derecho a la limitación del tratamiento

• Derecho a la portabilidad de datos

• Derecho de oposición

• Derechos en relación con la toma de decisiones automatizada, incluida la elaboración de perfiles

• Los detalles relativos a cualquier transferencia de datos personales a un tercer país y las medidas de seguridad tomadas. 

• El derecho a presentar una queja ante una autoridad supervisora, proporcionando los datos de contacto de la autoridad supervisora (por ejemplo, la ICO en el Reino Unido). 

Intención: La intención es garantizar que el Aviso de privacidad publicado contenga suficientes detalles al incluir los elementos y principios anteriores, de conformidad con el Capítulo 3 del RGPD. 

Directrices: según el Control 10.c, por el cual debe publicar un Aviso de privacidad que cubra el servicio incluido en la Certificación de Microsoft 365. Este Aviso de privacidad debe contener los elementos y principios resaltados anteriormente. 

No compatible:

Consulte el Control 10.c. 

Ejemplo de evidencia:

Nota: Su propio aviso de privacidad debe reflejar con precisión su aplicación y sitio web reales. El aviso debe publicarse y estar disponible públicamente en el sitio web de su empresa.  

HIPAA (Ley de Portabilidad y Responsabilidad del Seguro Médico)

La Ley de Portabilidad y Responsabilidad del Seguro Médico de 1996 (HIPAA) es una legislación federal aplicable a ciudadanos estadounidenses y organizaciones de atención médica. Es importante tener en cuenta que esta legislación también cubre cualquier organización fuera de los EE. UU. que procese datos de atención médica de ciudadanos estadounidenses. La introducción de la legislación encargó al Secretario del Departamento de Salud y Servicios Humanos de los Estados Unidos (HHS) desarrollar regulaciones que protejan la privacidad y seguridad de cierta información de salud. Algunas organizaciones pueden procesar datos que son información de salud potencialmente protegida (ePHI), es decir, información de salud identificable individualmente transmitida por medios electrónicos, mantenida en medios electrónicos o transmitida o mantenida en cualquier otra forma o medio. Cuando se procesan datos de salud de CUALQUIER parte interesada, las organizaciones deberán cumplir con HIPAA. 

HIPAA tiene dos leyes que deben considerarse: 'La Regla de Privacidad', o Estándares para la Privacidad de la Información de Salud Identificable Individualmente, que describe los estándares nacionales para la protección de cierta información de salud, y 'Los Estándares de Seguridad' para la Protección de la Información de Salud Protegida Electrónica, también conocida como la 'Regla de Seguridad'. Este último establece un conjunto nacional de estándares de seguridad para proteger cierta información de salud que se mantiene o transfiere en forma electrónica. 

Desde una visión general de alto nivel, "La Regla de Seguridad" es una implementación práctica de las protecciones ofrecidas por la "Regla de Privacidad". Describe las medidas técnicas y no técnicas que las "entidades cubiertas" deben implementar para garantizar la seguridad de la "información médica electrónica protegida" (e-PHI) de las personas. Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave de HIPAA para ayudar a obtener alguna garantía de que la organización cumple con el requisito y que la organización está protegiendo la información de salud que procesa. 

Control n.º 18

Proporcione evidencia que verifique el cumplimiento de su organización con la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) al proporcionar evidencia de que:

• Aviso de Prácticas de Privacidad (NPP) y Capacitación de la Fuerza Laboral: Existe un Aviso de Prácticas de Privacidad y se establece un programa de capacitación de la fuerza laboral sobre el manejo de la Información de Salud Protegida (PHI) bajo HIPAA para empleados, contratistas, proveedores y otras partes relevantes. 

• Salvaguardas para la información médica protegida electrónica (ePHI): Su organización ha implementado medidas de seguridad administrativas, físicas y técnicas según lo exige la Regla de seguridad de HIPAA para garantizar la confidencialidad, integridad y disponibilidad de toda la PHI electrónica (ePHI) que crea, recibe, mantiene o transmite. 

• Políticas de gestión de riesgos: su organización cuenta con políticas y medidas de gestión de riesgos para protegerse contra cualquier amenaza o peligro razonablemente anticipado para la seguridad o integridad de ePHI. 

Intención: La intención de este subpunto es garantizar que las organizaciones hayan establecido protocolos que sirvan como procedimientos estándar para administrar la información de salud, lidiar con emergencias e interrupciones de servicios, y el acceso del personal a información y capacitación de salud. Además, se espera que las organizaciones mantengan y describan estas salvaguardas administrativas como parte de su programa de seguridad HIPAA. Este es un aspecto crucial para cumplir con las regulaciones de HIPAA. 

Directrices: Esto se evidenciaría al proporcionar la documentación establecida de la organización que describe la política y el procedimiento de HIPAA. Los analistas de certificación revisarán esto para asegurarse de que se aborde toda la información proporcionada dentro del control. 

Prueba de ejemplo: Las capturas de pantalla muestran instantáneas de una directiva HIPAA. Tenga en cuenta: se espera que los ISV compartan la documentación real de la directiva o el procedimiento de apoyo y no proporcionen simplemente una captura de pantalla. 

Nota: Se espera que un fabricante de software independiente comparta la documentación completa de la política o el procedimiento y no simplemente proporcione una captura de pantalla. 

Intención:

Para comprender la intención de este subpunto y garantizar el cumplimiento de la Regla de Seguridad, las "entidades cubiertas" primero deben saber cómo se definen los términos de confidencialidad, integridad y disponibilidad en § 164.304:

Confidencialidad: "la propiedad de que los datos o la información no se pongan a disposición o no se divulguen a personas o procesos no autorizados". 

Integridad: "la propiedad de que los datos o la información no han sido alterados o destruidos de manera no autorizada". 

Disponibilidad: "la propiedad de que los datos o la información son accesibles y utilizables a pedido por una persona autorizada". 

La intención de este requisito es que las organizaciones implementen salvaguardas/medidas técnicas como controles de acceso, auditoría, integridad y transmisión dentro de la infraestructura de TI para garantizar la confidencialidad de la ePHI mientras mantienen su integridad y disponibilidad para los usuarios autorizados. 

Directrices:

La evidencia puede proporcionarse mediante ajustes de configuración de los mecanismos de protección utilizados para garantizar que los datos de ePHI estén protegidos de acuerdo con el requisito de control. Dichos mecanismos pueden incluir controles de acceso, procedimientos de acceso de emergencia, RBAC, cifrado, etc. 

Prueba de ejemplo: controles de acceso e integridad

La siguiente captura de pantalla muestra que existe una lista de acceso autorizado de personas que tienen permisos para controlar ubicaciones de almacenamiento de ePHI y se mantiene dentro del documento de política de HIPAA. Además, en las capturas de pantalla que siguen a la lista de inventario aprobado, se puede observar que el acceso de escritura en todo el clúster es limitado, y solo el administrador y el analista de mantenimiento de bases de datos pueden leer y escribir en el clúster. 

La siguiente captura de pantalla tomada de una de las bases de datos de almacenamiento de ePHI en Atlas Mongo demuestra que solo los usuarios autorizados tienen el acceso documentado y que todas las cuentas tienen ID de usuario únicos para garantizar la responsabilidad. 

La primera captura de pantalla muestra la ubicación de almacenamiento principal / clúster de base de datos para ePHI. 

La segunda captura de pantalla muestra que los usuarios aprobados solo tienen los roles y el acceso documentados.

Las dos capturas de pantalla siguientes muestran una vista más detallada de cada uno de los roles asignados y todos los permisos asociados que están en línea con la aprobación de acceso anterior.

Cada rol personalizado tiene un conjunto de permisos y un ámbito de acceso.

Por último, la siguiente captura de pantalla demuestra desde una perspectiva de redes, que solo el intervalo IP autorizado, que es la red corporativa segura, tiene permiso de acceso al clúster.

Ejemplo de evidencia: controles de auditoría

Estas capturas de pantalla muestran que el registro y las alertas se implementan para el clúster de base de datos. La primera captura de pantalla muestra que las alertas están habilitadas. Tenga en cuenta que se espera que la evidencia proporcionada también muestre las reglas de alerta que se establecieron en función de la necesidad/implementación de la organización. La segunda captura de pantalla muestra que se está habilitando la auditoría de la base de datos. 

En la captura de pantalla siguiente se muestra el historial de acceso al clúster de base de datos que se está registrando. La expectativa es que las alertas se configuren y, en función de los registros de auditoría y cualquier acceso no autorizado que no cumpla las condiciones predefinidas, desencadenará una alerta.

Las dos últimas capturas de pantalla muestran que se generan registros de auditoría para el clúster de base de datos y que los registros se pueden exportar para su análisis.

Tenga en cuenta que la expectativa es que exista un proceso para que se analicen los registros de auditoría generados, también se debe proporcionar evidencia del proceso de revisión. Si esto se logra mediante programación, se deben proporcionar capturas de pantalla de los ajustes de configuración de la ingesta de registros en la plataforma / solución de registro utilizada, así como capturas de pantalla de las reglas para su revisión. 

Ejemplo de evidencia: controles de cifrado y transmisión

Las siguientes capturas de pantalla muestran que la ubicación de almacenamiento tiene datos en reposo cifrados de forma predeterminada. Tenga en cuenta que si la plataforma no realiza el cifrado de forma predeterminada y sus propias claves de cifrado están en uso, se espera que esas claves estén adecuadamente protegidas y se proporcionan pruebas para demostrarlo. 

Las dos capturas de pantalla siguientes muestran que la ubicación de almacenamiento tiene datos en tránsito cifrados de forma predeterminada. En la primera captura de pantalla se muestra que una API de datos está habilitada con permisos de "lectura y escritura".

Un examen SSL del punto de conexión demuestra que los datos en tránsito se cifran a través de TLS 1.2.

Ejemplo de evidencia: controles de disponibilidad y recuperación

En la captura de pantalla siguiente se muestra que el clúster de base de datos se replica en tres regiones para garantizar la disponibilidad. Mongo Atlas lo hace de forma predeterminada. Además, la copia de seguridad está habilitada y activa.

En la captura de pantalla siguiente se muestra el panel de copia de seguridad del clúster, que también muestra que ya se ha creado una instantánea.

Las dos capturas de pantalla siguientes muestran que existe una directiva de copia de seguridad para realizar copias de seguridad programadas en diferentes puntos en el tiempo (PIT).

Lo siguiente indica que existe una directiva de retención para las instantáneas y la restauración a un momento dado (PIT).

Intención: La intención de este subpunto se alinea con la regla de seguridad que se desarrolló para garantizar la flexibilidad y escalabilidad para que una "entidad cubierta" pueda implementar políticas, procedimientos y soluciones tecnológicas que se ajusten a su propósito para el tamaño de la entidad, su estructura organizativa y sus riesgos específicos, así como su apetito por el riesgo. Desde una perspectiva práctica, esto significa que las medidas de seguridad adecuadas implementadas dependerán de la naturaleza del negocio de la "entidad cubierta", así como de su tamaño y recursos. 

Es vital que todas las organizaciones realicen un análisis de riesgos exhaustivo para descubrir posibles riesgos y vulnerabilidades a la confidencialidad, integridad y disponibilidad de la e-PHI. A través de este análisis de riesgos, las organizaciones pueden implementar controles de seguridad adecuados para mitigar estos riesgos identificados. 

Directrices: La evidencia puede proporcionarse a través de los resultados del análisis de riesgos. Cuando el análisis de riesgos se realice y mantenga a través de una plataforma en línea, se deben proporcionar capturas de pantalla de toda la salida. 

Ejemplo de evidencia: Las siguientes capturas de pantalla muestran instantáneas del proceso de evaluación de riesgos, seguidas del análisis de riesgos que se realizó para determinar en qué medida los controles se implementan correctamente y funcionan según lo previsto para proteger ePHI. La segunda captura de pantalla muestra un análisis de riesgos de los riesgos identificados en la evaluación de riesgos y los controles de compensación y las mitigaciones implementadas para disminuir el nivel de riesgo. 

Ejemplo 1: Instantánea del proceso de evaluación de riesgos dentro de la política de HIPAA y el análisis de riesgos realizado

Nota: Esta captura de pantalla muestra una instantánea de un documento de análisis de riesgos, esto es solo un ejemplo, y la expectativa es que los ISV compartan la documentación real y no simplemente proporcionen una captura de pantalla.

Ejemplo 2: capturas de pantalla del proceso de evaluación de riesgos dentro de la política HIPAA y el análisis de riesgos realizado (mantenido en la plataforma en la nube de Confluence)

La segunda captura de pantalla muestra un análisis de riesgos de los riesgos identificados en la evaluación de riesgos y los controles de compensación y las mitigaciones implementadas para disminuir el nivel de riesgo. Podemos ver que esto existe y se mantiene en la plataforma en la nube de Confluence.

Control n.º 19

Proporcione evidencia de que:

Su organización ha establecido e implementado un Plan de Copia de Seguridad de Datos y un Plan de Recuperación ante Desastres como parte de su Plan de Contingencia, de acuerdo con las Salvaguardas Administrativas de la Regla de Seguridad HIPAA bajo 45 CFR §164.308 (a) (7) (ii) (A) (Plan de Copia de Seguridad de Datos) y 45 CFR §164.308 (a) (7) (ii) (B) (Plan de Recuperación ante Desastres). 

Intención: La Regla de Privacidad define qué partes de la Información de Salud Protegida (PHI) están cubiertas por la ley y prohíbe los usos y divulgaciones indebidos de la PHI. La intención de este subpunto es que una organización debe limitar el acceso y el uso de e-PHI solo a aquellos que la necesitan para fines autorizados y que deben cumplir con la regla mínima necesaria, que requiere que usen o divulguen solo la cantidad mínima de e-PHI necesaria para lograr su propósito previsto. 

Debe existir una combinación de salvaguardas técnicas y administrativas para restringir el uso de ePHI y garantizar que disminuya el riesgo de divulgación de la ePHI. 

Directrices: La evidencia proporcionada debe mostrar las salvaguardas técnicas existentes, como las tecnologías y los mecanismos que se utilizan para proteger la e-PHI, y cómo la organización controla el acceso y el movimiento de dichos datos. 

Prueba de ejemplo: Las siguientes capturas de pantalla muestran la Prevención de pérdida de datos de Microsoft Purview (DLP), que es una plataforma integrada que permite a las organizaciones administrar sus directivas de DLP desde una única ubicación centralizada. 

Puede observar a continuación que está habilitada una directiva "mejorada por HIPAA de EE. UU.", esto proporciona la capacidad de evitar que los usuarios peguen datos confidenciales en sitios web específicos, incluido el correo electrónico personal, los avisos de IA generativa, los sitios de redes sociales y más cuando se accede a través de un explorador web compatible. 

En la captura de pantalla siguiente se proporciona información general más completa sobre la directiva, incluido el ámbito al que se aplica. La directiva se establece en todas las cuentas en ubicaciones como SharePoint, Dispositivos, OneDrive, etc.

Al seleccionar la opción "Editar directiva", se muestra una vista más detallada de las configuraciones específicas disponibles.

Las dos capturas de pantalla siguientes muestran la definición de contenido y las condiciones que deben cumplirse para que se aplique la directiva.

La directiva abarca varios tipos de datos confidenciales, así como un conjunto de clasificadores.

En la siguiente sección se muestran las acciones que se configuran para realizarse cuando se cumplen las condiciones mostradas en las capturas de pantalla anteriores.

En la captura de pantalla siguiente se muestra que la directiva DLP está configurada para impedir que los usuarios copien y peguen información confidencial, como información de identificación personal (PII), de las bases de datos internas de la organización en sus cuentas de correo electrónico personales, bots de chat y sitios de redes sociales en exploradores compatibles.

Finalmente, las notificaciones de usuario están configuradas para notificar y brindar orientación a los usuarios a medida que manejan datos de ePHI.

En la siguiente captura de pantalla se muestra el panel de configuración para generar alertas cuando se produce un incidente.

Intención: La intención de este subpunto es que una organización debe capacitar a su personal sobre cómo manejar la e-PHI de manera segura y adecuada, y que debe hacer cumplir las políticas y procedimientos para garantizar el cumplimiento de la Regla de seguridad. 

Pautas: La evidencia proporcionada debe demostrar que la capacitación de HIPAA se realiza sobre cómo manejar la ePHI y que existen registros de asistencia y finalización de la capacitación. Cuando corresponda, esto puede respaldarse con la documentación de políticas y los materiales de capacitación utilizados. 

Ejemplo de evidencia: Los siguientes ejemplos muestran la evidencia potencial que se puede presentar para demostrar que la capacitación adecuada de HIPAA se realiza de acuerdo con la política. 

La siguiente captura de pantalla muestra una instantánea de la política HIPAA con una sección específica que describe el requisito para la capacitación. Tenga en cuenta que esto es solo un ejemplo y no un documento / implementación completo, la expectativa es que el ISV tenga un proceso establecido que sea aplicable a su organización. 

Ejemplo 1: Formación de usuarios de HIPAA a través de un proceso administrativo

En la siguiente captura de pantalla, la diapositiva de información general del curso muestra un resumen de los objetivos del curso. Si la capacitación se construye internamente, los materiales de capacitación deben proporcionarse para su revisión, tenga en cuenta que se debe enviar el material completo y no solo una captura de pantalla del resumen.

En la captura de pantalla siguiente se muestra el registro de asistencia de los empleados que participaron en la formación. El registro también muestra el puntaje de aprobación, así como la próxima fecha programada de entrenamiento.

El segundo ejemplo muestra cómo se puede usar Microsoft 365 Defender para establecer y lanzar campañas de aprendizaje.

Ejemplo 2: formación de usuarios de HIPAA a través de la plataforma de simulación de ataques de Microsoft 365 Defender (todos los usuarios)

En la captura de pantalla anterior se muestra la campaña de aprendizaje de seguridad de HIPAA, la duración total en minutos, así como el estado de finalización. La siguiente captura de pantalla proporciona información general sobre los usuarios a los que se asignó el entrenamiento y el estado del entrenamiento que demuestra la finalización correcta.

Ejemplo 3: Formación de usuarios de HIPAA a través de la plataforma de simulación de ataques de Microsoft 365 Defender (usuario individual)

Mientras que el ejemplo anterior se centró en demostrar que todos los usuarios completaron la campaña de capacitación anual, el ejemplo final muestra evidencia específica que demuestra la finalización de un empleado.

Puede observar en las dos capturas de pantalla anteriores que tan pronto como se lanzó la campaña de capacitación, cada empleado recibió un correo electrónico confirmando la asignación de capacitación y la fecha de vencimiento, así como los módulos asignados, la duración, etc.

Con el vínculo disponible en la notificación por correo electrónico, la siguiente captura de pantalla muestra la página Tareas de aprendizaje para el usuario y los dos módulos que se han completado.

Intención: Según la Regla de seguridad de HIPAA, un plan de respaldo de datos y un plan de recuperación ante desastres son obligatorios para cualquier "entidad cubierta" que maneje información médica protegida electrónica (ePHI). Dichos planes son parte de la estrategia de contingencia que tiene como objetivo garantizar la disponibilidad y seguridad de ePHI en caso de una emergencia u otra ocurrencia que dañe los sistemas que contienen ePHI. 

La intención del plan de copia de seguridad de datos es crear y mantener copias idénticas recuperables de ePHI, esto también debe incluir pruebas periódicas de las copias de seguridad para garantizar que sea posible la recuperación de datos. El objetivo del plan de recuperación ante desastres es restaurar cualquier posible pérdida de datos en caso de desastre, y esto debe especificar los pasos que se deben seguir para restaurar el acceso a los datos, incluido cómo se deben restaurar los archivos a partir de las copias de seguridad. 

Directrices: Proporcione la versión completa del plan / procedimiento de recuperación ante desastres que debe cubrir el plan de respaldo y el plan de recuperación. Proporcione el documento PDF/Word real si está en una versión digital, alternativamente si el proceso se mantiene a través de una plataforma en línea, proporcione una exportación de PDF o si no puede exportar debido a las limitaciones de la plataforma, proporcione capturas de pantalla que cubran toda la política. 

Prueba de ejemplo: La siguiente captura de pantalla muestra instantáneas de la directiva de seguridad de HIPAA que contienen información general sobre el procedimiento de copia de seguridad general y de alto nivel y el plan de recuperación ante desastres. 

Nota: Esta captura de pantalla muestra una instantánea del documento de política o proceso, esto es solo un ejemplo, y se espera que los ISV compartan la documentación completa de la política o el procedimiento de apoyo real y no simplemente proporcionen una captura de pantalla.

Libros

Murdoch D. (2018) Manual del equipo azul: Edición de respuesta a incidentes: una guía de campo condensada para el respondedor de respuesta a incidentes de seguridad cibernética. 2ª edición, editor: CreateSpace Independent Publishing Platform.

Referencias

• Informes de delitos cibernéticos contra el fraude de acción Disponible en: https://www.actionfraud.police.uk/ (Consultado: 10/12/2023).

• UE. (2021) Lista de verificación del RGPD para controladores de datos Disponible en: https://gdpr.eu/checklist/ (Consultado: 10/12/2023).

• Microsoft. (2018) Registro de eventos (Windows Installer) Disponible en: Registro de eventos (Consultado: 05/03/2024).

• Tecnologías positivas. (2020) Cómo abordar el desarrollo seguro de software Disponible en: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Consultado:12/10/2023).

• Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos) (Texto pertinente a efectos del EEE) (2016) Disponible en: https://www.legislation.gov.uk/eur/2016/679/contents (Consultado: 12/10/2023).

• Métricas de seguridad. (2020) Guía de métricas de seguridad para el cumplimiento de PCI DSS. Disponible en: https://info.securitymetrics.com/pci-guide-2020(Consultado: 10/12/2023).

• Williams J. Clasificación de riesgo de OWASP Disponible en: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Consultado: 10/12/2023).

• Qualys. (2014) SSL Labs: Nuevos grados para problemas de confianza (T) y desajuste (M) Disponible en: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Consultado: 10/12/2023).

• NIST SP800-61r2: Guía de manejo de incidentes de seguridad informática Disponible en: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Consultado: 10/12/2023).

• Creación de una canalización de CI/CD con Azure Pipelines y Google Kubernetes Engine | .NET

• Google Cloud (Consultado: 10/10/2023).

• El Plan de Recuperación ante Desastres en: https://www.sans.org/white-papers/1164/ (Consultado: 10/10/2023).

• https://github.com/ (Consultado: 10/10/23).

• Plantillas de directivas de seguridad en: https://www.sans.org/information-security-policy/ (Consultado: 10/10/23).

• https://www.openedr.com/ (Consultado: 10/02/23).

• https://www.atlassian.com/software/confluence (Consultado: 10/10/23).

• https://www.atlassian.com/software/jira (Consultado el 28/09/23).

• Plantilla de ejercicios de mesa del Plan de Continuidad del Negocio (BCP) en: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Consultado: 10/10/23).

• Resumen de la regla de seguridad de HIPAA | HHS.gov (Consultado: 18/10/2023).

• Leyes de privacidad de la información de salud en la era digital: HIPAA no se aplica - PMC (nih.gov) (consultado: 18/10/2023).

• ¿Cuál es el propósito de HIPAA? Actualización 2023 (hipaajournal.com) (Consultado: 18/10/2023).

• ¿Qué se considera PHI según HIPAA? Actualización de 2023 (hipaajournal.com) (Consultado: 18/10/2023).

• Políticas y procedimientos de HIPAA (hipaajournal.com) (Consultado: 18/10/2023).

• Diseño de políticas de HIPAA & políticas administrativas | Dash Solutions (dashsdk.com) (Consultado: 18/10/2023).

• 45 CFR § 164.304 - Definiciones. | Código Electrónico de Regulaciones Federales (e-CFR) | Ley de EE. UU. | LII

• / Instituto de Información Jurídica (cornell.edu) (Consultado: 18/10/2023).

• ¿Qué es el cumplimiento de HIPAA? Leyes & reglas de HIPAA | Proofpoint Reino Unido (Consultado: 18/10/2023).

• Reglas, regulaciones y estándares de seguridad de HIPAA (training-hipaa.net) (Consultado: 18/10/2023).

• Resumen de la regla de seguridad de HIPAA | HHS.gov (Consultado: 18/10/2023).

• SP 800-66 Rev. 1, Una guía introductoria de recursos para implementar la regla de seguridad de la Ley dePortabilidad y Responsabilidad del Seguro Médico (HIPAA) | CSRC (nist.gov) (Consultado: 18/10/2023).

• La regla de seguridad | HHS.gov (Consultado: 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Consultado: 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Consultado: 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Consultado: 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Consultado: 19/10/2023).

• Configurar cifrado — Manual de MongoDB (Consultado: 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Consultado: 19/10/2023).

• Prevención de pérdida de datos de Microsoft Purview: anuncio de la disponibilidad general de varias funcionalidades

• Centro de comunidad de Microsoft (consultado: 24/10/2023).

• 45 CFR § 164.308 - Salvaguardas administrativas. | Código Electrónico de Regulaciones Federales (e-CFR)

• | Ley de EE. UU. | LII / Instituto> de Información Jurídica (cornell.edu) (Consultado: 24/10/2023).

• ¿Cuándo debemos proporcionar información de privacidad? | ICO (Consultado: 11/08/2023).

• ¿Cómo debemos redactar nuestra información de privacidad? | ICO (Consultado: 11/08/2023).

• Marco de rendición de cuentas | ICO (Consultado: 11/08/2023).

• Requisito 5.1 de la norma ISO 27001 - Liderazgo & compromiso | ISMS.online (Consultado: 11/08/2023).

• Plataforma de navegación en línea (OBP) (iso.org) (Consultado: 11/08/2023).

• Cláusula 5.3 Funciones, responsabilidades y autoridades organizativas - Formación ISO (Consultado: 11/08/2023).

• 5.3 Roles, Responsabilidad y Autoridad (iso9001help.co.uk) (Consultado: 11/08/2023).

• Desidentificación y reidentificación de PII en conjuntos de datos a gran escala utilizando protección de datos confidenciales| Centro de arquitectura de la nube | Google Cloud (Consultado: 11/08/2023).

• Desidentificación de datos confidenciales | Documentación de protección de datos confidenciales | Google Cloud (Consultado: 11/08/2023).

• Guía para la seguridad de los datos | ICO (Consultado: 11/08/2023).

• Transferencias internacionales de datos | ICO (Consultado: 11/08/2023).

• Administración y seguridad de registros | ICO (Consultado: 11/08/2023).

• ISO 27701 - Gestión de la información de privacidad (Consultado: 11/08/2023).

• ISO 27701 Sistema de gestión de la información de privacidad (PIMS) | ISMS.Online (Consultado: 11/08/2023).

Imágenes o texto extraídos de documentos de Microsoft

• https://www.sans.org/information-security-policy/ (Consultado: 18/02/21).

• Obtenga análisis de comportamiento y detección de anomalías (Consultado: 05/03/24).

• ¿Qué son las alertas de Azure Monitor? (Consultado:03/05/24).

• Obtenga análisis de comportamiento y detección de anomalías

• (Consultado:03/05/24).

• Administración y respuesta a alertas de seguridad en Microsoft Defender para la nube (Consultado:03/05/24).

• Administración y respuesta a alertas de seguridad en Microsoft Defender para la nube (Consultado:03/05/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Consultado: 10/09/23).

• ¿Qué es Azure Information Protection?

• Cifrado de datos transparente para SQL Database, SQL Managed Instance y Azure Synapse Analytics (Fecha de consulta: 05/03/24).

• Inicio rápido: Creación de una asignación de directivas para identificar recursos no compatibles (Acceso: 05/03/24).

• Configuración de Protección contra amenazas avanzada para la base de datos Azure SQL (Acceso: 05/03/24).

• Copias de seguridad y restauración en Azure Database for MySQL: servidor flexible (Fecha de consulta: 05/03/24).

• Inventario de certificados (Fecha de consulta: 05/03/24).

• Copia de seguridad y restauración en Azure Database for MySQL (Fecha de consulta: 05/03/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Consultado: 11/08/2023).

Más información

• Guía de evidencia de muestra - Descripción general
• Guía de evidencia de muestra - Operaciones